Cover panel states fail initialization automation path

[haywiremk]

I had this in another ticket on initialization error due to a different underlying cause that was closed by the author but do think this is gap that you might want to close. Just close out this ticket if not.

Cover needs the 2 other states opening and closing added. If cover entity has this state the initialization automation path will fail in the loop.

I have a group helper. It has 3 blinds. One was in a weird state and reporting state as opening, Maybe a HA reboot during an opening or zigbee message missed. This state is not in the btn_pic. Only open and closed. I think you should add opening and closing in there as well. As far as I can tell there is no "else" catch for the buttons, maybe a 🤷 icon for those would be nice to at least boot. Also might need opening/closing in btn_bg and btn_txt_font or at least and else catch

Also: If I set the helper to state of open in developer tools and reboot then panel boots fine.

[Blackymas]

hi not sure what you mean - do you have a example?

[Blackymas]

ah you mean this https://github.com/Blackymas/NSPanel_HA_Blueprint/issues/435#issuecomment-1469235832

[haywiremk]

Yes that ticket. Sorry should have linked to it. If you set the status of a cover to state_closing or state_opening that are valid states for a cover and try to boot the panel when in this state the automation initialization flow will stop at the cover with this status with "Error: expected int for dictionary value @ data['message']"

[deejaybeam]

but opening and closing are only while moving

[haywiremk]

As anyone in commercial grade home automation knows, the statement ONLY or ALWAYS should never be used. Most covers tend to be wireless zigbee or zwave and built in China using at best the actual standards(yes had to make a quirk for mine). If they are commanded and do respond with transitioning they may not successfully report back 100% to HA as transitioned. I have rooms with 3-5 blinds in HA helper groups assigned to panels. My blinds also open at sunrise and close at sunset. They are zigbee and I would say commanding all blinds 2 times a day at the same time at best get 2-3 sigma finding all blinds in the proper open/closed position with same rate stuck reporting opening/closing. But 3-5 covers in a HA helper group the odds 1 in the group is stuck in opening/closing is high so at best 1 sigma the group state is wrong. This is not a big deal since the physical device is generally in a state needed or can just be told to move again. However a HA reboot for an update or config change reboots the panels and they then get stuck initializing until manually resolve the state and then manually rebooting the panel. This leads to a sub optimal WAF. Just catching all valid states or have a default in all if/elsif/ifesif/else -> default set something vs hanging/halting handles all the theoretical ONLY/ALWAYS cases. I find my panels in rooms with this hung at least every other week. More often if making many HA config updates. It got to the point I hand to hunt down the issue vs just pressing reboot.

[Blackymas]

We'll take a look.

But the fact is that this problem actually lies somewhere completely different.

It is difficult to include everything for each case. We also have to adhere to the current set of rules here.

I can say that I currently use 8 Ikea roller blinds via z2m and have not yet found the problem.

[tom-hampton]

@Blackymas I can confirm the same as @haywiremk. I have Zemismart Zigbee blind motors integrated with ZHA. All report opening or closing as the state when they are anywhere other than 0% or 100% depending on the direction of the last movement. EG: 50% -> 25% = closing. 50% -> 75% opening. My blinds are horizontal blinds, so they are open when at the 50% position, and closed at either 0% or 100% (even though the integration reports 100% as OPEN.

I have the same issue...I cannot load a button page when my blinds are in a valid open position because they report "opening" for a state. I've confirmed if I close the blinds using HA, then the page loads correctly.

Regardless, if its transient or not, its a valid state.

[edwardtfn]

What would you expect on the panel when the blind is on "opening" or "closing" states? Should it be displayed similar to "open" when "opening" and similar to "closed" when "closing"? Or change depending on the threshold at 50%? Any other ideas?

[edwardtfn]

I believe with #613 the blueprint will survive for this situation of a curtain stuck with opening or closing states (previously only open and closed where expected. This is already in DEV and should be included in the next release.