Actual state is written once again when using cover.close_cover

[bcutter]

Using v0.4.0 I discovered something new, very confusing:

Closing all covers with an automation sending "cover.close_cover" to a group with all covers.

Based on todays observation, the only one closing fine (open -> automation -> closed) is a 1800:

All others (1200 if that makes a pattern) behave different which creates confusion on several places (open -> closing -> open -> closed), few examples:

[gluap]

I have been thinking about this - Do you know whether the shutter was already 100% down while homeassistant showed "wird geöffnet"? I believe the meassage may mean "received an opening state that was not 0%" so it could just be an intermediate state -

My take on this would be: -> Automation sends close -> Cover starts closing -> Cover not yet closed but sends a status update "I'm at 30% closed" (homeassistant interprets this as "my new state is open", because "closed" is state == 0% open and nothing else. -> some seconds later: Cover closed and sends state 0% open -> Homeassistant interprets this as "my new state is closed".

[bcutter]

Not it wasn't. Your assumption is right: the log entry signals the initiated action (closing/opening). It is shown instantly once the action is started.

It's just that this message (and state because this message also triggers the history graph etc.) is totally wrong - here performed manually using the UI (no automation involved):

Not sure if it's a HA thing or was introduced with 0.4.0 of this integration. In the end it creates wrong states/data and leads to confusion -.-

As due to a quick research there's no issue on the HA Core repo on this, I tend to say it was introduced with this integration. Can you debug/reproduce this behavior?

[gluap]

In 0.4.0 i experimentally introduced the "opening" and "closing" states - Duofern had them but I hadn't exposed them to homeassistant before 0.4.0. Therefore until 0.4.0 the blinds could only be either "open" or "closed" but not "opening" or "closing". But I also observe that "opening" and "closing" seem to be unreliable on my end. I only have RolloTron 2510 and they get stuck in "opening" or "closing" state very often. Which is bad because that makes homeassistant disable the "open" and "close" buttons until it receives the next state from the blind. Which sometimes never happens.

I think I'll have to disable the "opening" and "closing" states again.

I also think that the "update device state" action (which - as you guessed - tries to update all shutters at once) will have to be changed to only address one blind. My impression is that it often does not work and I suspect that the problem is that the responses come in while the loop is still sending the requests for the reminding blinds and that as a result the blinds all talk over each other and no state is successfully received.

[bcutter]

I think I'll have to disable the "opening" and "closing" states again.

To bad as it basically is a nice feature - if it works as intended and does not create that kind of confusion -.- I would really like to keep that but I'm not sure if that's possible.

I also think that the "update device state" action (which - as you guessed - tries to update all shutters at once) will have to be changed to only address one blind. My impression is that it often does not work and I suspect that the problem is that the responses come in while the loop is still sending the requests for the reminding blinds and that as a result the blinds all talk over each other and no state is successfully received.

That would be perfect anyway:

• I still suffer from #18, even it is quite rare.
• That way I could reenable my manual state fix (as a backup solution) and fire the "update device state" service against single devices, not all of them (possibly creating some unneeded RF noise).
• That's exactly how I used the "cover.stop_cover" before.
• See https://github.com/gluap/pyduofern-hacs/issues/18#issuecomment-1371494350 for my thoughts/question on that service.
• Anyway it would still be good if it would work with groups, so setting the "entity_id" to a "cover.group_of_covers" would be necessary from my point of view. But that would be the same like today at least from the DuoFern point of view, right?
• Basically from my side a warm "go" on limiting this service.

[bcutter]

I will test v0.4.1 asap.

What about

Add a low-key auto update by letting the devices schedule an update themselves every five minutes when duofern asks for their state

Does this mean there will be a constant radio transmission (from every device, every five minutes, forever)? Or only "once when using the ask-for-update-service on a random time within 5 minutes" (to avoid sending states from multiple devices at the same time)?

I fear having constant radio transmissions in order to workaround the state not reported accurate/at all issue -.- So I'd be happy to better understand how exactly this change is intended to work.

[gluap]

Yes, constant means: it will send a short "what's your state" for every device every 5 minutes.

That's about what for instance weather stations (including duofern), thermometers and humidity sensors do in the same 433 MHz frequency band and lawfully it's ok in Europe, see for instance for Germany

I can also disable that again.

[bcutter]

I can also disable that again.

50/50. While it sounds in theory it should solve a few missing states problems (and therefore I definitely want and will test this), on the other hand it means a constant RF noise (in my case I have many DuoFERN devices).

How about a config option for this? Maybe using two services

• duofern.enable_constant_state_check
• duofern.disable_constant_state_check ?

[bcutter]

Coming back to the original core of this issue:

irritatingly set states since the opening and closing states have been introduces (which I basically don't want to miss anymore, they are quite helpful).

With 0.5.5 I still see that very same behavior on random devices from time to time (made no full screening, just checked few step by step only today and already the 3rd and 4th shutter have this in logs - so do no 5 and no 6, stopped checking at the 8th):

[gluap]

If you check the logs after such an occurence my bet is you will find that when "was opened" is displayed the logs show that a message was received by the shutter. The message said something like "my opening state is 50%" (intermediate state between "100% open" and "closed"). Homeassistant sasys "hey 50% is not closed" so the shutter is obviously open now -> "was opened". once it receives the "shutter is 100% closed" message it displays "shutter was closed".

[bcutter]

I didn't check it (yet), but you are probably/very likely right. The question is: how can we adjust that behavior. Cause it's quite irritating that an opened shutter is opened again :-D

[bcutter]

I didn't check it (yet), but you are probably/very likely right. The question is: how can we adjust that behavior. Cause it's quite irritating that an opened shutter is opened again :-D

Ah OK that's an answer, in a way :-)