Feature request: property attribute "$hidden"

[backinabit]

As the name of this attribute suggests, if $hidden=true, the property should not be visible to UI.

This would be an optional property with default value: false, so as to have no impact unless it is both enabled, and understood.

The value of this attribute is that it can allow for a property to be defined that can be used for logging or automation purposes without cluttering up a UI.

Example;

Consider a thermostat as a device defined under homie; There are several different boolean states that can be reported; First stage cooling, Second stage cooling, First stage heating, Second stage heating, Fan running, Heat pump blocked (heat pumps need to rest a few minutes after the end of a cycle before starting again or risk damage), Idle, etc.

For logging to a database, there are 7+ boolean properties. For reporting to a user, they can be sent as a single string property for a status display.

The string is unsuitable for logging to a database since it can't easily be used for statistical analysis. The boolean values are unsuitable for reporting in a UI, since there are so many of them.

Defining these boolean properties as hidden makes it possible to direct them each to the proper receiver.

[backinabit]

The $hidden attribute may also have value at the node level to hide an entire node from the UI. Note that it wouldn't be equivalent to set all properties of the node to $hidden, since the node itself would remain present in the UI, without any properties.

[Tieske]

I think that this is a "UI hint" type setting. But I think it should be expanded. Instead of a boolean I would like to propose it to be an enum with the following values;

• "user": the main user facing UI (eg. primary screen for a light; brightness + on/off go here)
• "user-advanced": user facing UI, after a "secondary click" (eg. secondary screen for a light, the color controls shown after clicking "advanced")
• "config": a property used for configuring the device, not visible to regular users (eg. "auto turn of after xxx seconds")
• "config-advanced": advanced config property, hidden after another click on the configuration screen, not visible for regular users (eg. "minimum dimmer %" and "maximum dimmer %" for a light)
• "hidden" not shown on any UI

@schaze I think we discussed this before? any thoughts?

[schaze]

IMHO this should be handled by an extension to the convention. The core convention should not be concerned about UI representation of the devices/nodes/properties. How should a device make assumptions about the way it is supposed to be presented to a user? There are vastly different UIs, like e.g. a smarthome dashboard with a minimalistic representation vs e.g. the admin ui of the smarthome which will have a different focus on what a user should see and on which level.

[Tieske]

yes agree, it makes sense as an extension.

Thinking out loud;

The actors in a play like this are; the device author, the device, the gui, the gui author, and the admin running the system. What they know;

• the admin; has the full understanding of the end-to-end system and knows it all.
• the device author; has a generic idea of what the properties mean
• the others; have no clue

If the admin is to configure it, then it must be configurable. And hence it must be a Homie property on a Homie Node somewhere. And hence it must be added by the author of the device when he writes it. That's most likely not going to happen for all devices, and that's then a bad user experience.

If the device author has to do it; same thing: not all authors will do it, so bad user experience.

That leaves me with a specific mqtt topic related to a Homie Property, but that topic is then NOT owned by the Homie device itself. But the GUI/Controller application. By specifying the topic name, and possible values, it can be shared across controllers/GUIs. Since GUIs/controllers actually reap the benefits of following such an extension, they are also most likely to implement it.

This will however forego on the devices listing the extensions they support, since the device itself would not be involved (it doesn't own the mqtt topic).

[schaze]

yes agree, it makes sense as an extension.

Very good, then I vote to close this issue with this comment.

That leaves me with a specific mqtt topic related to a Homie Property, but that topic is then NOT owned by the Homie device itself.

This a general problem with the extensions. E.g. the meta extension that allows adding labels to a device. Extremely useful in general, but how do I add it to a device that does not support it natively? I want to tag all my devices but from "the outside". Of course I could just publish the according retained messages within the device topic, but I cannot add the extension to the device spec. I think this might be worth a separate issue and should be discussed in general. There is a "adminstrative" level around devices that is not really covered.

[Tieske]

let's leave it open until we create a new issue to formulate what's needed. For now I'll tag it as extension.