That’s not by design for sure. Have you also the Somfy API integration enabled?
Yes, that’s correct. I’m using the integration.
Can you try to uninstall the Somfy integration and reinstall the ha-tahoma integration?
Yes, this one.
I have in HACS the ha-tahoma which is nowadays called: Overkiz (by Somfy) version 2.7.2.
In the Home Assistant | Settings | Integrations there is only this version.
I have installed it and removed the other integration. Will monitor how it goes, thanks!
Hello @tetienne and everybody.
I’m ready to buy a Tahoma V2 BOX to control my Pergola, which has 3 Somfy motors (IO).
AFAYK the box works perfectly with those motors, but I would like to integrate them with HA as well.
Looking at the instructions, seems that I need then to activate an account on https://www.somfy-connect.com/ to then activate the box.
So which integration should work fine? The Tahoma - Home Assistant or the Somfy - Home Assistant or the https://github.com/iMicknl/ha-tahoma or whatever?
Before purchasing, I would like to be sure.
Thanks, Simon
thanks to the new my position attribute I now can spot this percentage:
which is of course a bit odd. I know the installer can manually set the IO motors to adjust to specific heights, but this would go beyond 100% ? Is this a bug maybe, either in the integration, or at Somfy’s?
I got this value from my awning too. And I think it’s when there is no my position recorded.
In our side, we didn’t do any modification. We just retrieve the data returned by Somfy.
hmm, 105% as indication no My position has been set
Ill have my installer set one tomorrow and hope to see a different reading then.
Thanks for the response for now!
something else, please help me out…
I am using the Powercalc integration to compute power and energy consumption of my devices, and try to do that with the Tahoma covers. (0.3 W standby, 104 W when moving).
I can eg create a template to determine power based on motion. Right now, if I open or close my cover, this is hardly displayed in the HA states, and it takes too long for the system to show ‘opening’ or closing on the cover entity. Isnt there a setting on the Tahoma hub/cover (now not imported in to HA) you could import to display a more immediate ‘moving’ state? That would be most welcome. Maybe override the 30 sec on start of MovingState: true
…?
I did see this in the debug for coordinator:
2021-09-21 08:55:42 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.EXECUTION_REGISTERED/07237a09-ac10-3e01-7473-4d352c1be7e0 (device: None, state: None -> None)
2021-09-21 08:55:42 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.EXECUTION_STATE_CHANGED/07237a09-ac10-3e01-7473-4d352c1be7e0 (device: None, state: ExecutionState.INITIALIZED -> ExecutionState.NOT_TRANSMITTED)
2021-09-21 08:55:42 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.GATEWAY_SYNCHRONIZATION_STARTED/None (device: None, state: None -> None)
2021-09-21 08:55:42 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.EXECUTION_STATE_CHANGED/07237a09-ac10-3e01-7473-4d352c1be7e0 (device: None, state: ExecutionState.NOT_TRANSMITTED -> ExecutionState.TRANSMITTED)
2021-09-21 08:55:42 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.GATEWAY_SYNCHRONIZATION_ENDED/None (device: None, state: None -> None)
2021-09-21 08:55:42 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.DEVICE_STATE_CHANGED/None (device: io://1236-2325-6238/2422368, state: None -> None)
2021-09-21 08:55:42 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.EXECUTION_STATE_CHANGED/07237a09-ac10-3e01-7473-4d352c1be7e0 (device: None, state: ExecutionState.TRANSMITTED -> ExecutionState.IN_PROGRESS)
2021-09-21 08:56:00 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.DEVICE_STATE_CHANGED/None (device: io://1236-2325-6238/2422368, state: None -> None)
2021-09-21 08:56:04 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.DEVICE_STATE_CHANGED/None (device: io://1236-2325-6238/2422368, state: None -> None)
2021-09-21 08:56:05 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.DEVICE_STATE_CHANGED/None (device: io://1236-2325-6238/2422368, state: None -> None)
2021-09-21 08:56:05 DEBUG (MainThread) [custom_components.tahoma.coordinator] EventName.EXECUTION_STATE_CHANGED/07237a09-ac10-3e01-7473-4d352c1be7e0 (device: None, state: ExecutionState.IN_PROGRESS -> ExecutionState.COMPLETED)
and that seems not completely correct (given all the None’s there). However, at least there is an opening EXECUTION_REGISTERED which might be helpful? Or do you already use that event.
We already listen for this MovingState attribute. If you move your cover from HA, you have an instant update. If you move it outsite HA, you will have to wait at most 30 seconds.
But if I rembember well in your case, for an unknow reason the state is not immediately reported. I have a pending PR to enhance the logs, and I have a better picture of what returns Somfy/Overkiz.
Thanks!
would a ‘Hey google’… command be a HA command if we do that via the Nabu Casa cloud? If so, that would be a good reason to integrate those via Nabu Casa, instead of integrating Tahoma directly in the Google Home app (and not using Nabu Casa for it), which I do now
Any reason there are all these device: None
listings?
If you linked HA to your Google Home, (Nabu Casa or DYI), it will call our compoment, so yes you will have instant update.
the new imported logging looks promising, and returns a Hazard on my cover (which shows an exclamation mark when opening, and stops at 99%:
2021-09-21 11:17:39 DEBUG (MainThread) [custom_components.tahoma.coordinator] Event(timestamp=1632215858618, name='CommandExecutionStateChangedEvent', setupoid=2fdf53redactedbfe6, owner_key=None, type=None, sub_type=None, time_to_next_state=None, failed_commands=None, failure_type_code=<FailureType.WHILEEXEC_BLOCKED_BY_HAZARD: 161>, failure_type='WHILEEXEC_BLOCKED_BY_HAZARD', condition_groupoid=None, placeoid=None, label=None, metadata=None, camera_id=None, deleted_raw_devices_count=None, protocol_type=None, gateway_id=None, exec_id='07a5redactedc5af', deviceurl=io://****-****-6238/8742048, device_states=[], old_state=None, new_state=<ExecutionState.FAILED: 'FAILED'>)
2021-09-21 11:17:39 DEBUG (MainThread) [custom_components.tahoma.coordinator] Event(timestamp=1632215858619, name=<EventName.EXECUTION_STATE_CHANGED: 'ExecutionStateChangedEvent'>, setupoid=2fdredacted9f****-b83redactede6, owner_key=2redacted9f****-b8redactede6, type=1, sub_type=1, time_to_next_state=-1, failed_commands=[{'deviceurl': 'io://1236-redacted2048', 'rank': 0, 'failure_type': 'WHILEEXEC_BLOCKED_BY_HAZARD'}], failure_type_code=<FailureType.WHILEEXEC_BLOCKED_BY_HAZARD: 161>, failure_type='WHILEEXEC_BLOCKED_BY_HAZARD', condition_groupoid=None, placeoid=None, label=None, metadata=None, camera_id=None, deleted_raw_devices_count=None, protocol_type=None, gateway_id=None, exec_id='07redactedf045c5af', deviceurl=None, device_states=[], old_state=<ExecutionState.IN_PROGRESS: 'IN_PROGRESS'>, new_state=<ExecutionState.FAILED: 'FAILED'>)
2021-09-21 11:17:39 DEBUG (MainThread) [custom_components.tahoma] Finished fetching device events data in 0.036 seconds (success: True)
Can you please block your cover (and see the ! within the Somfy application or website), restart HA, copy all the related logs and report an issue on our repository please ? With the new log I will be able (normally) to see how Somfy output this error.
hmm, this was with the ! in the app, but ok, sure, will do
Well yes, it was the log when your cover was blocked when moving. But I would like also understand why when you restart the priority lock originator is not correct.
ok, I didnt check up on that.
let me have another look for that too in the opening log, If anything Ill add it to the issue https://github.com/iMicknl/ha-tahoma/issues/572, but upon restart, the issue had disappeared from the HA logs (while the ! was still in the app)