Update state and attributes when event received from TahomaClient

[laszlojakab]

• [x] I have read the README, including the Advanced section regarding debugging.

Is your feature request related to a problem? Please describe. I'm developing a lovelace card for my Somfy raffstores, and would like to sync the animation of it as the raffstore goes up or down. The 30 seconds update of the integration is terrible rear for it. In the worst case when I open one of my raffstore it takes 30 seconds to update the image in the raffstore card (in that time in reality the raffstore is 2/3 part opened at that time). I checked in pyhoma the TahomaClient.fetch_events method what happens when I open a raffstore. When I opened the raffstore an event almost immediatly fired with the following device states:

• core:MovingState=true
• core:TargetClosureState=0

When the raffstore fully opened another event also received immediatly with the following state:

• core:MovingState, false

When the first time the raffstore opens I could measure the time (from code) between the two events and next time I can animate raffstore image synchronized with reality.

Can integration update cover state and attributes when an event arrives from TahomeClient?

Describe the solution you'd like Update HA cover state and attributes when event received from TahomaClient.

Additional context Maybe should_poll has to be set to false in cover entity (possibly in all tahomaentity) and async_schedule_update_ha_state function should be used to force HA to update state when event received from TahomaClient. As I see integration uses DataUpdateCoordinator. I have never used DataUpdateCoordinator in my integrations so maybe async_schedule_update_ha_state won't work in this architecture.

[tetienne]

What you described is already what we do. See https://github.com/iMicknl/ha-tahoma/blob/master/custom_components/tahoma/coordinator.py

Can you check the event you see is well of type device changed?

If yes, it probably means we have to modify cover.py to handle the state variable you gave.

As remark, this almost instant update can be only done when the action is triggered from HA.

[laszlojakab]

OK there are multiple issues:

• I used position slider to set position to 0 (close) or to 100 (open). In that way state never changes to closing or opening. Can integration change this behaviour? If target position is 0 then set the state to closing, and if target position is 100 than set state to opening during the operation.
• The recorder logs of closing the raffstore (by pressing close button, not setting position to 0), contains an "open" state which is missleading (it should be closing):

timestamp	state	attributes
2021-06-13 17:22:44.206931	open	{"current_position": 100, "current_tilt_position": 100, "rssi_level": 58.0, "core:NameState": "Ebedlo", "core:PriorityLockTimerState": 0, "core:StatusState": "available", "core:DiscreteRSSILevelState": "normal", "core:RSSILevelState": 58.0, "core:MovingState": true, "core:ClosureState": 0, "core:OpenClosedState": "open", "core:SlateOrientationState": 0, "core:Memorized1PositionState": 100, "core:SecuredPositionState": 0, "core:TargetClosureState": 0, "friendly_name": "Ebedlo", "supported_features": 655, "device_class": "blind"}
2021-06-13 17:25:19.592901	closing	{"current_position": 100, "current_tilt_position": 100, "rssi_level": 58.0, "core:NameState": "Ebedlo", "core:PriorityLockTimerState": 0, "core:StatusState": "available", "core:DiscreteRSSILevelState": "normal", "core:RSSILevelState": 58.0, "core:MovingState": true, "core:ClosureState": 0, "core:OpenClosedState": "open", "core:SlateOrientationState": 0, "core:Memorized1PositionState": 100, "core:SecuredPositionState": 0, "core:TargetClosureState": 0, "friendly_name": "Ebedlo", "supported_features": 655, "device_class": "blind"}
2021-06-13 17:25:21.054993	closing	{"current_position": 100, "current_tilt_position": 100, "rssi_level": 58.0, "core:NameState": "Ebedlo", "core:PriorityLockTimerState": 0, "core:StatusState": "available", "core:DiscreteRSSILevelState": "normal", "core:RSSILevelState": 58.0, "core:MovingState": true, "core:ClosureState": 0, "core:OpenClosedState": "open", "core:SlateOrientationState": 0, "core:Memorized1PositionState": 100, "core:SecuredPositionState": 0, "core:TargetClosureState": 100, "io:PriorityLockOriginatorState": null, "io:PriorityLockLevelState": null, "friendly_name": "Ebedlo", "supported_features": 655, "device_class": "blind"}
2021-06-13 17:25:43.186836	open	{"current_position": 54, "current_tilt_position": 0, "rssi_level": 58.0, "core:NameState": "Ebedlo", "core:PriorityLockTimerState": 0, "core:StatusState": "available", "core:DiscreteRSSILevelState": "normal", "core:RSSILevelState": 58.0, "core:MovingState": true, "core:ClosureState": 46, "core:OpenClosedState": "open", "core:SlateOrientationState": 100, "core:Memorized1PositionState": 100, "core:SecuredPositionState": 0, "core:TargetClosureState": 100, "friendly_name": "Ebedlo", "supported_features": 655, "device_class": "blind"}
2021-06-13 17:26:14.197069	closed	{"current_position": 0, "current_tilt_position": 0, "rssi_level": 58.0, "core:NameState": "Ebedlo", "core:PriorityLockTimerState": 0, "core:StatusState": "available", "core:DiscreteRSSILevelState": "normal", "core:RSSILevelState": 58.0, "core:MovingState": true, "core:ClosureState": 100, "core:OpenClosedState": "closed", "core:SlateOrientationState": 100, "core:Memorized1PositionState": 100, "core:SecuredPositionState": 0, "core:TargetClosureState": 100, "friendly_name": "Ebedlo", "supported_features": 655, "device_class": "blind"}

• In reality the actual closed state reached at about 17:26:00 (it is not reported by HA). I have ran a TahomaClient in console parallel during closing operation. Here is the "log" from it (closed state reached at 17:26:02):

timestamp	device_states
1623604952725	device_states: core:MovingState=false
1623605120179	device_states: core:TargetClosureState=100, core:MovingState=true, io:PriorityLockOriginatorState=None, io:PriorityLockLevelState=None
1623605140497	device_states: core:SlateOrientationState=100, core:ClosureState=46, core:OpenClosedState=open
1623605160724	device_states: core:ClosureState=95, core:OpenClosedState=open
1623605162951	device_states: core:ClosureState=100, core:OpenClosedState=closed, core:MovingState=false

• If you check core:TargetClosureState values in first table don't look good. In the last two row the core:TargetClosureState should be 0.
• Notice: between the last two row there is about 31 seconds. This is probably the 30 seconds update interval of HA (I have a RPI 3B which is not fast so probably thats why the 1 second difference). I think closing states from TahomaClient received well until HA periodical (30 sec) update not run. After the first periodical update the events from TahomaClient of closing operation not handled by the integration or by HA.

[tetienne]

If you check core:TargetClosureState values in first table don't look good. In the last two row the core:TargetClosureState should be 0.

To clarify, all the attributes like core:xxxxx are directly retrieved from Somfy (overkiz) servers. We don’t alter them. We just map them to HA. So core:TargetClosureState cannot be wrong. It’s what we receive.

The recorder logs of closing the raffstore (by pressing close button, not setting position to 0), contains an "open" state which is missleading (it should be closing):

Are you also refering here to a core:xxxx attribute?

Can you confirm, when you open and close through HA, your device behaves correctly?

Can you please also share the firmware of your device. You can find it within the device details. It look like Firmware: io:HorizontalAwningIOComponent

I used position slider to set position to 0 (close) or to 100 (open). In that way state never changes to closing or opening. Can integration change this behaviour?

Got it. That’s indeed not supported. Apparently, we can use (as you mention):

{ "name": "core:TargetClosureState", "type": 1, "value": "11" },
      { "name": "core:MovingState", "type": 6, "value": "true" },

And look at these values within https://github.com/iMicknl/ha-tahoma/blob/master/custom_components/tahoma/cover.py#L318

[tetienne]

@laszlojakab Can you please have a look into https://github.com/iMicknl/ha-tahoma/pull/460/files ? You can directly edit the files on your system. Or download the component here: https://github.com/iMicknl/ha-tahoma/archive/refs/heads/enhancement/use_target_closure.zip

I tested with my own covers, and when setting the position I can well see the opening/closing state.

[laszlojakab]

@laszlojakab Can you please have a look into https://github.com/iMicknl/ha-tahoma/pull/460/files ? You can directly edit the files on your system. Or download the component here: https://github.com/iMicknl/ha-tahoma/archive/refs/heads/enhancement/use_target_closure.zip

I tested with my own covers, and when setting the position I can well see the opening/closing state.

Tested. It looks OK for me too.

[laszlojakab]

Are you also refering here to a core:xxxx attribute?

No, HomeAssistant cover state at 2021-06-13 17:25:43.186836.

Can you confirm, when you open and close through HA, your device behaves correctly?

Yes.

Can you please also share the firmware of your device. You can find it within the device details. It look like Firmware: io:HorizontalAwningIOComponent

Firmware: io:ExteriorVenetianBlindIOComponent