Settable property indication #12
Comments
|
I do agree! Your suggestion handles the following:
What about strings (which can be anything, not only enums), floats, more specific types like colors ( I would rather define data types. Each data types could have optional parameters (like min, max...). Something like: homie/686f6d6965/switch/$properties → on:settable[enum:true,false] What do you think? |
|
I would even replace the homie/686f6d6965/ledstrip/$properties → led[1-3]:settable(enum:true,false) |
|
Good thinking with data types. I completely agree with what you suggested. Strings should be relatively simple to handle. For example, setting a color using predefined names can be done like this: Multivariable settings are slightly tougher, but I think using a separator should be able to handle it, like so: This would indicate that there are three settable integers for this property, each within the range [0, 255]. The color can be set like this: |
|
I do agree, that announcing unit, datatype and range of one property should be standardized in the homie convention. In fact I feel like this would be one of the important details of a convention thriving to become a discoverable IoTs-on-MQTT convention. My proposal:
Side note: Using the word "properties" in this context might have been a bad idea...
The table above is just an example and open for discussion. Additionally I would suggest to introduce for completeness:
|
|
I've implemented the Openhab 2 Homie binding, that is why I also came across this point @ThomDietrich. It's rather difficult to map the properties to datatypes - or even a meaningful UI representation. Your suggestion would allow to do so. |
|
@Kwave I've taken a quick look at your feature branch. Would you agree, that it would be beneficial if another "Property property" would be $category holding one of the defined ESH channel categories. $settable already covers Accessible Mode and the exact ESH Item type to use can probably be derived from $unit+$datatype+$range. |
|
@ThomDietrich I'am not sure if data representation should be part of the homie specification. It depends on how you define the term "Node":
However I'am much more attracted by the $-meta information solution than overloading the |
|
Hello @Kwave,
If the abstraction is (as in this case) high enough, I do not see any issue with that. Remember, that I asked you if your OH binding would benefit from the category. If that is not the case, we can just as well leave it out. It would be great to hear some thoughts from @marvinroger. How do you feel about the presented approach and how realistic is an implementation in that direction? Best Regards! Thomas |
|
Okay, let's recap with a sample environment device. SampleDevice propertiesNode properties (and property properties)temperature nodeweather nodeI like this approach. Range for each datatypes
I am not sure about the |
|
Hey @marvinroger great to get in touch with you ;) Your examples look great to me! After going through all possible use cases, I realized that the You can also ignore The discovery processThe whole idea behind this definition is to make a device discoverable. How would the discovery actually be implemented?
It might be beneficial to provide a better way to solve step 1. Steps 2,3,4 are only possible if all messages are retained messages. Otherwise, this will create a race condition. Would you agree with this description? Is anything missing? @Kwave ? If you want to go forward with this approach, maybe it would be good to choose a new word besides "properties". Topics starting with "$" could be called "attributes" for example. Best Regards! |
|
@ThomDietrich it's a pleasure too, sorry for the long response time, I was busy with school! Great then. For everyone who read this, please use the For the discovery, I've taken a different approach for one of my projects (see https://github.com/INTECH-RGB/homie-dashboard/blob/master/server/lib/bridges/mqtt-infrastructure.js). Let's imagine you have the representation of your infrastructure in a structure (JSON for the example): {}Basically, we subscribe to {
"686f6d6965": {
"nodes": {}
}
}Then, we would see that the node does not exist, that the property does not exist, and so on... To end up with: {
"686f6d6965": {
"nodes": {
"temperature": {
"properties": {
"degrees": {
"datatype": "float"
}
}
}
}
}
}And a device is considered discovered when all required information are populated in the representation. I hope you get the idea? |
|
Get it, like it ;) Makes me speculate if it might be easier to streamline everything a bit to begin with. How would you feel about all the above (all $attributes), but serialized in one message?
|
|
It would not help. A discovery service must be able to discover devices even after the devices are powered up. So "one-shot" announces on |
|
Oh, you are totally right with the first part! Of course each device needs it's own retained topic (I would suggest to turn it around). I did not get the second part of your argument though. The one retained message on All the above assumes, that the goal here is to make all variables and capabilities of on device known through an announcement process upon mqtt connection rather than step by step while its operation... |
|
Oh okay, I thought you wanted to keep the current structure of the messages, only announcing through You said earlier, and I totally agree with that:
Your suggestion was basically to exploit the potential of MQTT by making use of semantic topics rather that one "fit-it-all" topic. Your JSON based announce does not follow this approach. Moreover, JSON is pretty costly in terms of memory needed on micro-controllers (ESP8266 for example) which is why we avoided any JSON in the payloads. |
Excellent point.
Not necessarily. This is a mixture of both. It's not a full description and needs further messages to make a full discovery possible. Do you see any benefits in this? This is a very interesting discussion! -Thomas |
|
@marvinroger you want me to recap and post an updated definition? I think we've settled all the open questions. |
|
@ThomDietrich my bad once again, I am currently looking for an internship in Paris and it takes a lot of time! Yes, please go ahead! And if anybody has other advices, let's discuss. 😉 |
|
@marvinroger @ThomDietrich I've created a Pull Request that sums up the discussed items. Please comment in the PR if I did get anything wrong. |
I like that property/settable indicates that a property can be set. However, it may not be obvious for the front-end app to figure out which values or ranges that the property can be set to, so I suggest the following:
homie/686f6d6965/switch/$properties → on:settable[true,false]
indicates that a switch "on" can be set to "true" or "false"
homie/686f6d6965/temperature/$properties → temperature:settable[60-100]
indicates that the temperature (for example, a sous vide machine) can be set between 60 to 100 (unit defined elsewhere)
This would make settable properties more clear and obvious.
The text was updated successfully, but these errors were encountered: