Wrong device status after reloading integration

[bcutter]

Tried the reload feature of https://github.com/gluap/pyduofern-hacs/releases/tag/v0.5.12:

✅ Worked without any errors in HA log

❌ Unfortunately the default state of the cover entities is read/initialized wrong. State of all covers when reloading the integration: closed. After reloading it was open for all covers, shortly after that switching to closed. That triggers other things unfortunately. The other two entities are nearly irrelevant (to me).

cover entities:

manual mode entities:

toggle entities:

[gluap]

This is my understanding of how one implements a reload in homeassistant: One writes a function async_unload_entry to tear down the integration (especially: properly close the serial port device so it can be used after reload). After tearing it down, one signals Homeassistant "we're done, go" and Homeassistant removes the devices and entities and sets it up anew similar to when it is started for the first time.

So by design HA has no memory of what the state was before the reload (and also, I would argue, this is intentional, as the normal case of a reload is an issue with the integration, so its memory of what device states were is not accurate any more, so re-using the state from before the reload would possibly perpetuate broken states).

So I don't think that this should be fixed in the way that state is retained through a reload.

Other integrations with external sources of knowledge (for instance mqtt) may persist state through a reload because they pull the state from the network device or other source they read from already during startup and creation of the devices. But duofern can't know during startup until it receives messages from the shutters.

If you know of an integration that seems local (like zigbee sticks or so) that retains state through a reload feel free to point me the right way so I can check what tricks they pull to do it.

[bcutter]

Noticed the same behavior when restarting HA. All (cover) entities set to open first.

So by design HA has no memory of what the state was before the reload (and also, I would argue, this is intentional, as the normal case of a reload is an issue with the integration, so its memory of what device states were is not accurate any more, so re-using the state from before the reload would possibly perpetuate broken states).

It has a memory - and that sits in core.restore_state file. I find a load of entities there (about 50 % of all my entities - but nothing from duoFERN / cover.* etc., also nothing from my (as compared earlier) deCONZ (ZigBee) integration [*1]).

[*1] but they seem to handle this a bit different: the entities don't have that "wrong state during initialization progress" issue. I don't know how they solve this exactly.

---

In case we don't can or want to use that memory (but I think it's worth spending a few thoughts on that first), we should at least default the state during initialization of the entities to e. g. unknown. Because that's (like unavailable for problematic states) a magic state. My covers are closed, not open. If the integration does not know/remind the state prior the polling/update takes place, that's what unknown was made for - definitely not open :-)

[gluap]

Thanks for the pointer, indeed, the is_open is now also allowed to return None. We already had that for position, now it should be returned correctly for is_open, too (with 0.5.14).

edit: and testing locally I see that the state is as expected:

notice that the transition from "unknown" to "closed" is also interpreted as "was closed" by homeassistant. But at least now the state is consistent with what we know about the entity at that point.