#mqtt text output
glacial glacier
I have found that having a space between the values at least improves the rendering.
true talon
Personally I'd suggest looking for a more human friendly version of those
glacial glacier
They aren't specified by me and I don't necessarily know them beforehand.
tiny wyvern
that's what an enum is for, don't make text entities
true talon
Ah... well... that limits your options then
glacial glacier
I can't make an enum if I don't know them beforehand, can I?
glacial glacier
the enum says that you have to give all available values.
true talon
Wait those are states, not names of entities?
glacial glacier
It is a translation of states from a bitmask.
so for instance, the "State" value for a solar inverter may have 10+ sates it is in (receiving solar, connected to grid, voltage is proper, etc, etc, etc)
true talon
Yeah, that's really really ugly and not very usable
tiny wyvern
This
glacial glacier
Those text values are specified by the manufacturer of the equipment
true talon
You've got to think about how people could use those states... some binary sensors would be much more usable - one for connected to grid, etc
tiny wyvern
You've got to think about how people could use those states... some binary senso...
that's also a good idea
glacial glacier
but as I'm saying -- this is a generic protocol implementation where the data definition is specified by the manufacturer, not me -- I'm not even sure how I'd make those into binary states asides from creating a single entity for each named value coming in
tiny wyvern
do they specify linkages between the 2 topics?
if they do, then you'd use the list as your entities that will be generated
otherwise, if you don't want any of that, don't output the lists.
glacial glacier
but what about proving the negative -- so lets say that OUTPUT_CONNECTED stops being reported. I can't necessarily know that I should make that entity a binary-false, because my app might be restarted and no longer have the state (and I'm not keeping track of state in the app, simply relaying the information)
true talon
At the very least you need to track that, so you can report it in a way that's useful to the end user
Simply passing the proverbial buck makes the result painful for the end user
They then have to parse the output and work out when you stop reporting something in that wall of text
That's ... pretty user unfriendly
glacial glacier
Is there a way in the mqtt discovery payload to indicate that 'after no sign of this entity, auto delete it?' or something like that? I'm trying to think through the decision tree on how I keep track of state for entities that might be orphaned (storage failure?)
or rather, after-this-time, default-to-false
true talon
You can have it go unavailable though, from memory
tiny wyvern
they remain, but allow deletion depending on criteria