Device profiles聽#319
Description
Hi! As I slowly work on a TypeScript / Node.js implementation of a Homie Controller, I was starting to look at the general concept of device profiles, which appears to be lacking from V5 of the spec.
I got here because I am planning to integrate my controller with Apple's HomeKit, which imposes certain requirements when it comes to the shape of a connected device. Window coverings must have a 0 - 100 position, for example. Mapping Homie devices to any other domain, including Apple HomeKit's, cannot be automated without the ability to make a few assumptions about their shapes.
Even leaving integrations aside, the same assumptions enabled by having devices declare which profiles they implement would dramatically simplify some UX and UI work in prioritising certain properties over others, depending on the nature of a device. In turn, this would also help with accessibility work.
Perusing through past discussions I stumbled into 1 and then into 2 and 3, both indicating that some thought and some work have already been put into this concept. Why is it not a part of the convention? Has there been further discussion that resulted into the deliberate choice of not supporting device profiles? Or is it simply a matter of time and interest?
Is there anyone else interested in pushing forward with device profiles?
Activity
Tieske commentedon Mar 17, 2025
See https://github.com/homieiot/homie5-device-profiles
I rewrote what was done in this PR homieiot/homie5-device-profiles#8
TLDR; a lot needs to be done, but yes, we need profiles
jacoscaz commentedon Mar 17, 2025
I don't know how I managed to miss that repo; thank you for pointing me to it.
At first glance and compared to my own investigations into how I would apply device profiles to the current V5 draft, the separation between capability profiles and device profiles feels to me like somewhat of an unbalanced tradeoff in terms of expressiveness vs. complexity, with too strong a bias towards the latter.
The waning interest by @schaze and this comment of yours, which I quote, make me wonder whether we could look for a different tradeoff.
Personally, having put some thought and done some prototyping in the last few weeks, I would suggest going for the simpler option of modelling profiles at the node level. The primary reason behind this approach is that a node doesn't necessarily have to represent a physical part of the device but can also represent a logical view of it, much like views in relational databases. Complex hierarchy of physical nodes, mirroring very complex devices, can still be complemented by simpler views that facilitate modelling across quasi-but-not-perfectly compatible domains.
As an example, I've recently been adding remote control capabilities to my window shutters via Shelly Wave Shutters. Using the Homie topology I would model each device as follows, mirroring their modelling at the Z-Wave level:
This representation closely matches what I'm getting via Z-Wave and is very powerful and expressive. However, it is also fairly complex, hard to map to other domains and hard to adequately represent in terms of UX and UI.
So, I would add is an additional complementary node:
['window_covering']This node effectively duplicates a subset of the information already present in other nodes but does so in a way that would match a hypothetical
window_coveringprofile. This way, controllers dealing with complex devices would simultaneously retain the ability to monitor and/or control any possible aspect of the device (if guided by human or, these days, a reasonably capable LLM) while still having access to a "known quantity" safely assumed to have certain characteristics.That said, in most cases devices are simple enough that I do not think they would require dedicated, logical nodes in order to implement profiles. They would likely only require one node implementing whatever profile describes that specific class of devices. Property duplication would only take place in those cases in which a device is so complex that its actual, physical structure / topology does not match a profile.
Tieske commentedon Mar 17, 2025
have you seen the
$targetattribute in homie5?You can have a
positionthat has a value of the actual position, and a$targetattribute. From that most info can be derived; opening/closing, motor active or not. This is pretty much the exact use-case of that attribute.This feels like mapping a profile to specific hardware, I think it should map to a functionality independent of hardware. And that is the hard part.
jacoscaz commentedon Mar 18, 2025
Hello!
Indeed I had, though yesterday I failed to account for it in my examples. Thank you for reminding me of it. I will make better examples in the rest of this post.
I agree, that is the hard part, but that's exactly the reason behind my argument for "logical" nodes. I think I did a bad job at illustrating it yesterday, let me try again.
The starting point of my argument is that having separate capability-level and device-level profiles would likely lead to an exceedingly complex specification, as mentioned in homieiot/homie5-device-profiles#8 . The solution I propose is focusing solely on node-level profiles.
In the majority of cases, implementors would simply expose a node implementing the profile matching the type of device. For example, in the case of a simple shutter controller:
shutter controllerdefaultimplementing profiles['window_covering']position: 0 - 100 (% of opening) (mandatory) (read/write)state: 0 | 1 (whether motor is active or not) (mandatory) (read-only)However, profiles generally cover the minimal subset of functionality that is assumed to be present in devices of a given type. In the specific case of my shutter controllers, for example, the Z-Wave modelling follows a much more hardware-specific hierarchy:
shutter controllermotorposition_a: 0 - 100 (% of opening) (mandatory) (read/write)state_a: 0 | 1 (whether motor is active or not) (mandatory) (read-only)position_b: 0 - 100 (% of opening) (mandatory) (read/write)state_b: 0 | 1 (whether motor is active or not) (mandatory) (read-only)electric meterpowerconfigurationswapped_inputsswapped_outputsalarmsheat_warningovercurrent_warningI agree that this hierarchy is exceedingly hardware-specific and cannot be taken as a reference point for how a profile should look. However, I also believe that profiles and hardware-specific hierarchies should not be mutually exclusive and that the spec should accomodate for both. So, how do we reconcile the two?
The solution, in my opinion, could be allowing implementors to duplicate information between nodes, so that a hardware-specific hierarchy could be complemented by "logical" nodes implementing specific profiles:
shutter controllerdefaultimplementing profiles['window_covering'](THIS IS THE "LOGICAL" NODE)position: 0 - 100 (% of opening) (mandatory) (read/write) (duplicate)state: 0 | 1 (whether motor is active or not) (mandatory) (read-only) (duplicate)motorposition_a: 0 - 100 (% of opening) (mandatory) (read/write)state_a: 0 | 1 (whether motor is active or not) (mandatory) (read-only)position_b: 0 - 100 (% of opening) (mandatory) (read/write)state_b: 0 | 1 (whether motor is active or not) (mandatory) (read-only)electric meterpowerconfigurationswapped_inputsswapped_outputsalarmsheat_warningovercurrent_warningWith this approach, integrations and UX/UI work could benefit from the assumptions implicit in nodes implementing specific profiles while maintaining the spec's wonderful capability to model any hierarchy and topology.
schaze commentedon Mar 20, 2025
This is actually exactly the way I defined my smarthome profiles. It is all done on a node level.
A light bulb might have the following definition:
type: homie-homecontrol/v1/type=switch
type: homie-homecontrol/v1/type=dimmer
type: homie-homecontrol/v1/type=colorlight
Depending on what the light bulb supports all or only some of them will be there. If it is only a white dimming bulb
colorlightwill not be there or if it is only a plug or a non-dimmable bulb you would have only aswitchnode and nothing else.Based on the available node types you can take assumptions for what components a UI shows to control the device.
Actual Device definition as an example:
{ "name": "wz_stehlampe_papier_1", "version": -2478458571223613400, "homie": "5.0", "root": "dev-deconz2homie", "parent": "dev-deconz2homie", "nodes": { "switch": { "name": "On/Off switch", "type": "homie-homecontrol/v1/type=switch", "properties": { "action": { "name": "Change state", "datatype": "enum", "format": "toggle", "settable": true, "retained": false }, "state": { "name": "On/Off state", "datatype": "boolean", "format": "off,on", "settable": true, "retained": true } } }, "dimmer": { "name": "Brightness control", "type": "homie-homecontrol/v1/type=dimmer", "properties": { "action": { "name": "Change Brightness", "datatype": "enum", "format": "brighter,darker", "settable": true, "retained": false }, "brightness": { "name": "Brightness Level", "datatype": "integer", "format": "0:100", "settable": true, "retained": true, "unit": "%" } } }, "colorlight": { "name": "colorlight", "type": "homie-homecontrol/v1/type=colorlight", "properties": { "color": { "name": "Color", "datatype": "color", "format": "xyz", "settable": true, "retained": true }, "color-temperature": { "name": "Color temperature", "datatype": "integer", "format": "153:555", "settable": true, "retained": true } } } } }schaze commentedon Mar 20, 2025
I created a whole dashboard application for homie with this: https://github.com/homie-homecontrol/hc-dashboard
jacoscaz commentedon Mar 21, 2025
@schaze that's super cool! And, I'm happy to see that the node-level approach worked so well! Would you be interested in working on a collection of profiles to later put forward as a (proposed) attachment to the spec? We could start from your own if you'd like!
schaze commentedon Mar 26, 2025
@jacoscaz: I would be interested as long as we keep on a node level and do not add additional topics to the spec on mqtt level. My initial idea was to only have a few definitions of different type profiles (on a node level) that uses the homie5 spec as is. Besides these points I am opinionated on some things regarding the profiles but in general open on how to approach it. I would welcome more input since the ones I have are pretty much based only on my needs and I have no real grip on how useful they are for someone else.
@Tieske: I know this differs quite a bit of what you intended with work we (pretty much you) did on the profiles so far - but would you also be on board with this?
jacoscaz commentedon Mar 27, 2025
@schaze this is exactly where I am at. I don't want to change the spec. The underlying principles feel very solid and I think it's a brilliant spec. However, I am myself working on both a) a dashboard and b) bridging with the HomeKit ecosystem and none of these two can be done without profiles. I also 100% agree on keeping profiles at the node level as a nice, balanced compromise that allows implementors to model devices however they see fit while also offering the option of adding "typed" nodes to project subsets of their devices into known shapes.
dcj commentedon Mar 30, 2025
I just found/saw this thread....
I am beginning to think about how to bridge Matter to Homie.
The Matter "data model" is complex, IMO because the domain it is attempting to represent is itself complex, and I am quite the Matter-newbie, so I have a lot to learn before I can be at all confident to define any sort of reasonable Matter->Homie mapping.
AFAICT, Matter has "nodes" (what I think of as a physical device), and nodes contain "clusters", one of which may be a "composed cluster", and a "cluster" generally has some number of "endpoints".
(When thinking in the context of both Matter and Homie, I'm afraid I am going to need to be precise about a Matter-Node vs a Homie-Node...)
Very roughly (and with no confidence at all), I am thinking:
Anyway, just wanted to mention my thinking/effort and I will contemplate the seemingly related thinking to HomeKit in this issue
Tieske commentedon Apr 18, 2025
Matter derives from Zigbee. Which came later than Zwave, hence zigbee and matter have a more complex model. And zwave has some legacy to deal with, due to their over simplified structure.
The main thing is the separation of physical and logical devices, which is something that Homie doesn't have to care about since it only caters for functional devices (relations in the physical world are represented in Homie as parent-child-device relations)
This is a hardware model, where there is a distinction between physical devices and logical devices. Homie doesn't have the distinction, but does allow you to model it through child devices.
Mapping it to Homie:
Examples of mapping the devices to homie:
Tieske commentedon Apr 18, 2025
I don't think they are that different. What I wrote also is on Node level, same thing. Just more elaborate.
I do think however that device profiles are also needed;
As for adding topics to the spec; I agree we shouldn't add anything to the spec. However, I think we do need a topic to identify a device or node profile (see my proposal in the discussion wrt namespacing the type). This is very powerful considering that we can query the MQTT server for only the devices/nodes we need. It can be specified in an extension, doesn't need to go in the spec. I named it
$profilein my docs.jacoscaz commentedon Apr 18, 2025
I think I see what you mean but, IMHO, being able to discriminate whether a device is a pump or a dimmable light doesn't necessarily have to depend on implementing different device-level profiles.
For example, the nature of a device could be inferred by looking at
$description.nameand$decription.type, assuming we could use the latter to generically indicate the class of the device (light, pump, ...) and reserve the$profiletopic for signalling implementation of profiles.Furthermore, does a dimmable light need to be controllable or would it be acceptable for a possible implementation to only report on the current brightness level? Should that difference even matter when defining the nature of a device? IMHO, no, it should not. A light is a light, regardless of whether it can also be controlled or merely polled for its state. Profiles as descriptors of (available) functionality should not be used to define the nature of a device.
Eventually, in the long term, I do expect device-level profiles to emerge as a separate concept. In the short term, however, I think working on node-level profiles alone would be a better compromise between expressive power and simplicity.
Yes, agreed!
(I'll be on a break until wednesday 23/04 but following with interest)
Tieske commentedon Apr 18, 2025
For full control
$nameand/or$typeshould be machine parseable. And that would need a format. And that would mean changing the current spec. Which is a no go at this stage. Adding$profilelater would then be duplicate info.So personally I think it's better to do it all at once in
$profilelater (or whatever name we choose).schaze commentedon Apr 18, 2025
I strongly believe we should start from a goals perspective for device/node profiles first before diving into the spec on a technical level.
Otherwise I am pretty sure we will get lost. Also this should help all 3 of us to get behind a more clearly defined and aligned goal target picture.
From my own experience the usage you get out of these types/profiles ist more limited than it first looks like.
Tieske commentedon Apr 23, 2025
I think we can create PR's against the readme document: https://github.com/homieiot/homie5-device-profiles
Just reread it, and I'm still behind the goals outlined in that doc.
jacoscaz commentedon Apr 24, 2025
@Tieske sounds good to me, we can keep profile-oriented work in that repo. Feel free to close this issue or move it.
@schaze yes, absolutely. If only to make sure we understand each other and where we come from. This is also something we might want to address in the repo above.
However, before working on profiles, I suspect whatever time we are able to spare might be better off allocated to finalising and releasing V5, closing #299 .
Tieske commentedon Apr 24, 2025
to be clear; what I meant with this is that it is probably easier to incrementally add/update/remove from that document through PR's discussing the changes individually. Rather than discussing this in a single issue here, top-down, which becomes unwieldy very quickly.
jacoscaz commentedon Apr 26, 2025
I agree @Tieske . Feel free to close this issue or move it to either an issue or discussion in that repo.
Tieske commentedon May 12, 2025
fyi, I updated my proposal for the profiles. Along the concept of a "UI" (dialog box) consisting of "UI components" (labels, list-box, buttons). Where eg. the button is a generic UI component, but the higher-level UI customizes it by specifying the text displayed on the button.
So the node-level capabilities are generic, and the device-profile prescribes further details to make it usable for that specific type of device.
It now also features several device profiles as examples. The
power-switchandshutterdevices are straight forward and rely on the underlying node-level capabilities. Thedimmable-lightis a more complex example.Details are here: https://tieske.github.io/homie5-device-profiles/
Tieske commentedon May 27, 2025
There have been no PR's against https://github.com/homieiot/homie5-device-profiles does that mean we all agree that the "goals" listed there are solid?
schaze commentedon May 27, 2025
Not yet, I am working on an "Argumenter" for some of the topics in there. Give me 3-4 more days...
jacoscaz commentedon Jul 7, 2025
For research purposes, the BACnet protocol is very profile-driven and the spec makes for some interesting reading.
Tieske commentedon Aug 2, 2025
Hey guys, any updates on this?
jacoscaz commentedon Aug 2, 2025
@Tieske I'm still working on Homie implementations which will require profiles at some point. However, work is happening more slowly than I had anticipated due to other priorities. I've also done a bunch of work on BACnet, which ultimately produced https://github.com/bacnet-js/device, which I found very informative when it comes to structuring device profiles. So, no actual update on my end but definitely lots of interest and plan to work on Homie profiles in the second half of 2025.
schaze commentedon Aug 2, 2025
Unfortunately, I鈥檝e had very little time over the past few months. The few days I could spare were spent maintaining my existing implementations rather than making meaningful progress.
I'm concerned that, given this, I might end up holding you back.
That said, I鈥檝e been revisiting an idea related to general semantic information for devices, in the context of a potential Homie MCP server project. The goal would be to make Homie more accessible as a tool for LLMs. However, I鈥檓 not sure how well this concept aligns with the idea of device profiles.
Tieske commentedon Aug 3, 2025
I think very much. Device profiles add meaning to the individual devices and their properties, with exact descriptions of expected behaviour. I'd consider the profiles to be similar to OpenAPI specs for an API. By feeding that into an LLM, the MCP becomes much more powerful.
schaze commentedon Aug 3, 2025
I meant it more in the way that the profiles alone won't be enough and what I need in addition is most likely out of scope for the device profiles. It's things like multiple bulbs (everyone a single homie device) belonging to a single lamp or information about location of the device (e.g. livingroom,..) which will be needed to give more context to the llm. especially in interaction with a human who will address devices with this context knowledge...
jacoscaz commentedon Aug 3, 2025
Heh, this is actually one of my goals for 2025 :)
I agree on (a part of) the context necessary for MCP being "out of scope" for device profiles at the homie level. I've recently begun experimenting around this subject with various forms of context enrichment using declarative approaches.
Tieske commentedon Aug 7, 2025
IMHO this would be device metadata. Tagging could be one way of solving this.
Probably a generic tagging system with a set of predefined/standardised tags that have a defined meaning? Would that have to be singular-tags, or key-value-tags? (Former being way easier to implement probably)
For llm usage I'd say one would need to provide the most context;
Anyway, this is off topic since I think we're in agreement this isn't part of the profiles.