Dynamic channel creation discussion

[seime (Arne S)]

@jimtng

, one would think that the esphome binding got the channel details directly from the esphome device, and that information should be exactly the same as configured in your esphome yaml.

Yes, but keep in mind that a single ESPHome component (ie climate) may provide multiple entities/channels, and retrieving those names from the esphome yaml would probably require parsing C++ code as well.

@jimtng

skip this interrogation step. I don’t know the ins and outs of the binding to understand

State updates from the device are done using a unique 32 bit key, and not by transmitting the full entity/channel name. The key is provided during the interrogation step. I’m not sure whether they are static across a reboot, but I’m pretty sure they won’t be static across a flashing process (ie version upgrade or modification).

So you cannot skip the interrogation step.

@jimtng

So I would love to see the esphome binding allow static channel configuration

As I wrote in an earlier post:

@seime

If you are using item files, that would be the place where you write down the expected channel names. It is just one layer less of redirection (in your case Device -> MQTT Thing -> Item channel link - in my case Device -> Item channel link).

Wouldn’t a “A python yaml to items generator” solve it?

Do you mean that if the device doesn’t actually provide all statically configured channels, the thing should refuse to go online? Opposed to some centralized logic checking for broken links every X seconds and informing you about the problem - and that applies for all kinds of thing types?

@jimtng

What about a utility that queries the ESPHome (using API or mqtt discovery), and generate the .things file.

Wouldn’t a general tool be even more awesome? See Adjust width of F7 dialog + include clipboard icon - #5 by splatch

(Specific: In order to interrogate an ESPHome device you would have to provide credentials in most cases)