#ESPhome logs

1 messages · Page 1 of 1 (latest)

wary portal
#

Where are you proposing doing that?

pearl stone
#

same screen where you can find all the entities an esphome device can support not sure what it is named.

pearl stone
#

for example in a block under the device info,

wary portal
#

It’s an ESPHome specific option for the specific config entry so you have to change it on the config entry. ESPhome uses the one device per config entry model but devices have no concept of integration specific options

#

I considered implementing it as a switch but that would have lost state on restart and it would have been annoying to have to turn it back on every time

pearl stone
#

is that different from for example the ZHA integration?

wary portal
#

Zha has multiple devices per config entry

pearl stone
#

I tried sometime ago to understand how it all is connected together. But i always get lost. And the doc's did not help much for.

wary portal
#

Short version is that if we want to change persistent configuration for an integration architecture requires it be done through options. Options are only available on the config entry. Anything else would not persist across restarts in Home Assistant. Since this needs to persist on the HA side we need to configure it in options

pearl stone
#

can you go a step back.

#

So we have different configuration options. some persistent and some just there until restart.

#

the entities we see above are the type correct?

wary portal
#

The entities reflect the state of the device

#

All state is persisted on the device itself (or not if you reboot it and it doesn’t store it in flash)

pearl stone
#

then i am still lost. I dont understand which config settings are persistent and which are not.

wary portal
#

Config entry options are persistent because we store them in storage in Home Assistant

#

Entity state is always determined by the device itself and may be temporarily restored at startup but in general the device is the decider of the state not Home Assistant

#

Summary: config entry options: stored in Home Assistant storage, HA is the sole decider when they change

#

Entity state: read from the device, may be restored at startup from cache, device is the decider of when they change

pearl stone
#

kk. got that now. In the screen above. Just to be sure, Is everything we see not persistent? Or could we add a section that IS persistent?

wary portal
#

In the screen above it’s a mix because you have logbook there as well and some device meta data. But for the purposes of your question I think you mean all the entities on that screen, so in that cases HA doesn’t store the state except to cache it and the device is in charge of populating that data

pearl stone
#

no. i mend the whole screen indeed not only the entities.

#

In the screen above it’s a mix because you have logbook there as well and some device meta data.
So when it is already a mix. we could add them at the left sidebar between for example the device info block and the Automation block, and store the persistently?

wary portal
#

Anything can be done. What you are proposing would require an architecture change to implement device options and a storage mechanism for them

pearl stone
#

From what you say I understand we could not use the same mechanism in the above screen.

wary portal
pearl stone
#

How about the "device name changer" dialog, has that also a different mechanism to store those settings?

wary portal
#

We store metadata about the device in the device registry but it has no concept of integration specific options

#

All integration specific options get stored in the config entry storage

#

What you are proposing to collapse down the configuration in a single panel makes a lot of sense for ESPHome but it doesn’t work well for integrations that have multiple devices per configuration entry

pearl stone
#

but it doesn’t work well for integrations that have multiple devices per configuration entry
I'm missing your point here. how can you have on configuration entry for multiple devices?

wary portal
#

ZHA, zwavejs, HomeKit controller hubs, any type of hub really is going to have one configuration entry and multiple devices

pearl stone
#

yeah you said that before but i'm still confused about it.

wary portal
#

When you add something on the integrations screen it generates a config entry for whatever you add

#

That integration usually (not always but better not go into that to make it more complex) has a single connection to some device. It might be a hub, it might be a cloud service, it might be a single esp board

#

That integration can register any number of devices

#

with ESPHome it happens to be 1:1 as in one config entry (integration) per device

pearl stone
#

ha, it is the hub that makes the difference (in short).

wary portal
#

MQTT and ZHA are examples where it’s 1 config entry and many devices

pearl stone
#

Side note: I'm working on an espnow integration for esphome. One of me ideas is to have a UART dongle with esp32 on it that needs to connect the espnow device to HA. that would also be a hub setup then, do i understand that correct?

pearl stone
wary portal
#

Assuming you want the espnow devices to show in Home Assistant as via the main device it would change the whole device model for the ESPHome integration because you would no longer have 1:1 mapping of device to config entry

pearl stone
#

yeah, that is something i wanted to talk about with you at some point. do you mind when i DM you about this in the near future?

wary portal
#

If you are looking to change Home Assistant architecture it’s better to discuss in a thread so it can be viewed publicly. If it’s ESPHome specific and doesn’t have public value DM is fine.

pearl stone
#

At first i need to understand more about what is possible and useful to do before i like to discuss it openly.

#

It us first concentrate about the architecture change to allow story options in multiple storage solutions from within the device page.

#

BTW. on other option (not sure if that could be done) is to have an extra button that shows the persisted configuration page/

wary portal
#

For an architecture change to be accepted you’ll need to take off the ESPHome hat and show that there are many integrations that could make use of it and how they would do so.

pearl stone
#

noted.

#

I'm off to bed now, nice talk 😄

wary portal
#

Cheers. I’ve got another hour or so before my flight lands GMT-10 for the next few weeks

pearl stone
#

@wary portal just wondering about the storage options, from what i understand we have the persistent config entry options, the device registry for metadata, and cache memory for entity states.
Is there also a persistent device specific storage?

#

Not sure if we could use the metadata registry for that?

wary portal
wary portal
#

Code is in homeassistant.helpers.device_registry