Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define a way to handle NULL values #284

Open
stedon81 opened this issue Jan 5, 2024 · 3 comments
Open

Define a way to handle NULL values #284

stedon81 opened this issue Jan 5, 2024 · 3 comments

Comments

@stedon81
Copy link

stedon81 commented Jan 5, 2024

Hi,
if devices run into issues, like cannot measure a value correctly, there's no chance to communicate this to the controller (e.g. SmartHome system).
Not updating the value means that the currently retained value will remain unchanged, which is a wrong information.
I'd like to see a possibility to explicitly tell the controller that there is no value available. Unfortunately, currently this can only be done by defining a "special value" within the current value range that must be known by both devices and filtered out accordingly. For some applications, there is no value that can be excluded from the value range to serve this purpose.

Long story short: I'd like to see an update in the convention that defines a NULL value, irrespective of the data type.

Best regards,
stedon81

@Tieske
Copy link
Contributor

Tieske commented Jan 8, 2024

the status can be updated to "alert" to indicate this situation, see https://homieiot.github.io/specification/#device-lifecycle (in Homie5 this state has been removed).

In Homie5 there are alternatives:

Lastly one could define a specific property for error states, but that would be device specific.

@stedon81
Copy link
Author

Hi Tieske,
Thanks for your answer and suggestions.

Your proposals would not meet the purpose intended.
There might be devices that have a primary and a secondary purpose, i.e. a roller shutter that also reports room temperature. If the temperature cannot be determined, it would not be reasonable to set the whole's device status to an alert state although the primary function is still working normal.
I understand that it would be possible to define elaborate enums describing all kinds of malfunctional states, reported via the alert topic. However, this still does not resolve the problem that the temperature property still contains an invalid value because the alert topic is not related to the temperature property.
In case of OpenHAB as a receiver, it still would plot the wrong temperature into grafana charts although on the other channel the alert has been recognized. The user would need to explicitly write a rule to NULL the temperature item in case of an alert.

In my opinion, it still would be beneficial to have a possibility on a per-property basis to indicate that a retained value is not valid anymore .

Best regards,
stedon81

@stedon81
Copy link
Author

stedon81 commented Feb 3, 2024

Hi,
obviously I'm not the only one requiring such a feature.
OpenHab developers have included a respective functionality in their mqtt binding just recently:
openhab/openhab-addons#16307

Would be great if the Homie convention could be adapted accordingly.
Cheers,
Stefan D.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants