#Hi 👋 Have a look at https github com

1 messages · Page 1 of 1 (latest)

steel ravine
#

I hope its ok to start a thread about this - but i think there will rise up some more questions during this conversation
first of all - thanks for your answers

  1. for sure, a defined enum would be the best solution, casting to int would just be the easiest "quick and dirty" solution to further handle those values on the home assistant side
  2. the last two parts are clear, but speaking about the first (newer than the KNX schema) - this basically means that the KNX schema is just kind of "outdated" in regards to this specific topic and could get updated to also support the options option (more or less) easily?
  3. simple: yes and no - i unterstand the idea of the event, but to use events i have to define a (generic) sensor, i have to define the event, and i have to define some "glue code" so the event updates my (generic) sensor? (sry, not absolutelly sure about that, i'm not that deep inside the code of the KNX integration and HA in general at this time)
    as far as i have the understanding about all this - for the user it would be a lot easier to just define one KNXSensor (including enum support as discussed in 1.) and done - am i right about this or did i missunterstand something here?
finite grail
#

Sure a thread is fine. Github Issue at xknx or a forum thread would also be ok - so others can follow easier.
I'm not sure if it would even pass review to let users manually set enum options. Imho its also not easy to gasp for users. The user input would need to be mapped back to some value, so the user would need to know all possible values and insert them. Consider following scenarios

  • a value is received that wasn't configured
  • an option is configured that isn't supported by the DPT
    I think these options are mean purely to be able to translate states. Otherwise a sensors native_value can just return a plain str.
#

For DPT3 I think this shouldn't be supported outside of events, as these are momentary actions (move up; stop; dimm down). In HA these shall not be represented as entities.

#

For DPT2 I see the point. But why a sensor? Wouldn't a user-actionable entity like select be a better fit? (or maybe support both)

#

I was also thinking of changing unavailable system in knx. Currently an entity is set unavailable when the connection is cut. This could be changed in favour of a availability_address that supports DPT 1 and 2. That way, if an entity (eg. cover) is locked by DPT 2 it would show unavailable until it is unlocked. Since there is no read_only temporary attribute for entities this could be a good fit.

finite grail
#

@steel ravine any thoughts?

steel ravine
#

@finite grail sry - i got sick... 😵‍💫

you are right with DPT3, it doesn't make sense to have a sensor for it

regarding DPT2 and why to not use a select - just because (in my case) the user should not be able to change it
think of a situation where you have an "administration office" which can control the lights in all rooms, at the same time you have, in each room, a touchscreen for this specific room, where you can control the light - but on the rooms touchscreen i want to inform the user "hey, you currently cant turn on the light in the room, because it is forced of by the office administration", otherwise the user would wonder why he cant turn on the light now
or maybe for some shutters it would make even more sense, because the shutters are forced open (because its to windy and they would break otherwise)
in those cases i want the user only to be informed about that, but definitly not that he can change this state
i also really like the idea with the unavailable state - currently i use a entity for the light (DPT1), when this light is forced on via DPT2 you can still toggle the light in HA ui, it just doesnt work, which seems like there is something broken
showing the light (or entity in general) to be unavailable would make things much clearer!
maybe it would be even better to introduce another state "locked" (maybe event locked-on and locked-off) for this? (not sure if HA supports this, i know about unavailable and unknown states in HA - do they have any special meaning to HA or would it technically also be possible to set it to something else like locked? have to research this, just a quick idea)

#

regarding your concerns about the enum type
i see the problem... i reasearched for alternatives - currently not 100% sure how this works exactly inside HA but what about "templating"?
https://www.home-assistant.io/docs/configuration/templating/
https://www.home-assistant.io/integrations/template

it seems like it would already be possible to add a knx sensor and then add another template sensor on top of it to process the sensor values
this works, but seems to be more complicated then it must be (you have two sensors/entities, instead of just the one KNX sensor)
what about adding another "knw raw sensor" which just gets the raw knx value and the user needs to use templating to process those values using the value_template option?
some of the core components of HA already do it this way, for example here: https://www.home-assistant.io/integrations/sensor.command_line/#cpu-temperature

steel ravine
#
  • introducing new state locked/locked-on/locked-off
    HA itself doesnt care about what a state value is, so its ok to set it to locked
    but sadly the UI kind of breaks when doing this - it hides the toggle button and instead shows the state as string on the dashboard view und when you open the entity as modal the button can still be toggled and is not disabled like when the state is set to unavailable
    i will wait for an response - maybe we could also update the ui? add own/extended ui components? idk?

PS: relevant UI code starts here
https://github.com/home-assistant/frontend/blob/dev/src/panels/lovelace/entity-rows/hui-toggle-entity-row.ts#L44
https://github.com/home-assistant/frontend/blob/dev/src/panels/lovelace/cards/hui-light-card.ts#L136

finite grail
finite grail
#

HA doesn't have a "locked" / "read only" mode for its entities yet. But in theory this could be changed some time. It would just take some good arguments and someone who is willing and capable of doing it.

finite grail
steel ravine
# finite grail Unfortunately, no. <https://github.com/home-assistant/core/pull/47734>

wow... this decission is, uhm, ....
maybe we could try to reopen this PR and discuss this topic again?
i mean its ok to say "That's the separation we have." - but then why the MQTT sensor (https://www.home-assistant.io/integrations/sensor.mqtt/) still, two years after this comment, has this ability, without even a notice that this option is deprecated or something like similiar? the whole documentation does not even notice the possibility to use a template sensor (maybe because its absolutely stupid for this use case 🤫 )
in my opinion the mqtt sensor should be argument enough to also allow the value_template to be used for the knx sensor - maybe HA core developers noticed them selfs, that this option is very usefull in the meantime

steel ravine
finite grail
#

Meanwhile I think it was a good decision. Having template support directly in knx config would be a support nightmare. Having it separated in helpers is good separation of concerns and support questions for templating issues can be addressed properly.
Also, meanwhile the main needs for value templates in sensors are solved by HA core. That would be conversion to different units (Wh -> kWh; °C -> F etc.) and display precision of values (rounding).
MQTT is a different topic (which I don't know anything about), but you can see in analytics, it is the 4th most used integration, while KNX is not really relevant. So don't expect them to be treated equally when it comes to exceptions for architectural decisions 😬

#

The one thing it would make most sense imho would be expose. But even there it is not a very user-friendly experience to set that in yaml, reload to see if it was valid etc.
I'm planning to move expose to UI in the future. There we could at least live-check a template and its result.

finite grail