[Overkiz] garage door status does not refresh when using somfy remote control
The problem
I have a garage door controlled by a somfy keygo io. I always open the garage door with Home Assistant. When I do that, the status of the door changes to "open" in Home Assistant after a few seconds, which is ok. Then I close the garage door with the somfy keygo io: the status does not change in home assistant, even after quite a few minutes. It is still "open". I see no event in the logs after the door has been opened.
NB: if I open the tahoma classic app in my smartphone, then the status of the garage door changes to "closed" after a few seconds in home assistant.
This problem is recent because it was working fine until a few weeks/months. I can't say exactly when.
In the logfile :
- 18:40: I open the door with home assistant => status change OK
- 18:42 : I close the door with the somfy keygo io => no status change
- 18:48 : I open the tahoma classic app in my smartphone => status change OK
What version of Home Assistant Core has the issue?
2024.8.2
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Overkiz
Link to integration documentation on our website
https://www.home-assistant.io/integrations/overkiz/
Diagnostics information
home-assistant_overkiz_logs20240820-1840.log
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
Hey there @imicknl, @vlebourl, @tetienne, @nyrodev, @tronix117, @alexfp14, mind taking a look at this issue as it has been labeled with an integration (overkiz) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of overkiz can trigger bot actions by commenting:
-
@home-assistant closeCloses the issue. -
@home-assistant rename Awesome new titleRenames the issue. -
@home-assistant reopenReopen the issue. -
@home-assistant unassign overkizRemoves the current integration label and assignees on the issue, add the integration domain after the command. -
@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the issue. -
@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
overkiz documentation overkiz source (message by IssueLinks)
I use my 2 houses in a similar way as this. And it has always been like that. I am frustrated that the garage door is showing open even after 5 minutes as it triggers my critical alerts.
First garage door was installed in March 2024, and immediately added to HASS. Second garage door was installed in August. Both have big delays to notice a change of status when changed with the io remote. I have to close it with Siri when driving so that home assistant stop complaining in critical notifications.
How can I contribute?
I don’t think this issue is caused by the integration itself but by the Somfy TaHoma side of things. I have the same issue with roller shutters that when controlled using Somfy Smoove remote don’t report state back to HA. What I noticed is that they also don’t report the state back in TaHoma application. If they are controlled only from HA or the TaHoma application the state is correct.
I have the same problem with an Ixengo.io until recently the using the Somfy remote the door status was shown as open/closed now it is only showing closed. The only time the status changes is if I use the HA app to open or close the door, then I get the correct status.
Not sure if this contributes, but I am facing exactly the same. A week ago I have installed a garage door opener. Since it's based on two doors I made a flow: If the small door is open, stop opening the big door.
This worked fine, until I had to change something in the Motor itself. I had to recalabrate the motor and my Home assistant side got another name. Since then I haven't been able to get the status update anymore. Quite frustrating. Removed everything on the somfy side and also on the Home assistant side. Rebooted multiple times, but the status isn't working anymore from within the remote.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Same here. It seems that integration don't know of status changes if its happened over Somfy/Tahoma hardware.
Problem still persists for me and I am on the latest version of host/core/supervisor/integration
Can you please collect the following information:
- Turn on debug mode for the Overkiz integration
- Generate your diagnostics
- Close the door with your Somfy remote control
- Generate your diagnostics again
- Collect your Home Assistant log
- Open the Somfy app
- Generate your diagnostics again and collect your log again
Attach the diagnostics and your log to a post (please be clear from which step you collected which diagnostics/logs), and I will have a look.
You might be facing an issue here with the Somfy API limitations (https://www.home-assistant.io/integrations/overkiz/#overkiz-api-limits).
Hi, I have the same problem, so I made your process , here is an archive with the logs.
Note 1 : Opening the somfy app does not change anything, the state is not updated until one command is made throw the app or HA... Note 2 : I have 2 garages doors, the 1st one have the problem, but the 2nd works fine.
Hi all,
I'm having the exact same issue here: somfy iO equipments integrated via overkiz don't have their status updated in HomeAssistant if the equipment had an action triggered by physical push buttons, in-built timer or radio remote controls.
On the other hand, the Overkiz integration clearly state this limitation in its documentation:
Some Overkiz devices do not broadcast status changes. To update their status, the vendor’s app (for example, Somfy TaHoma) requests a status update when opened. The app then broadcasts the states via events that the Overkiz integration also listens to. The Overkiz integration cannot replicate this behavior, as it does not know when you access the Home Assistant dashboard or run automations.
As a result, the state of some Overkiz devices in Home Assistant may not always be up-to-date.
Adding sensors on the equipments (open/close, power consumption, vibration, ...) could be a solution to have HomeAssistant trigger "status refresh" automations but it's a bit clunky.
Would it be possible to have an "action" in overkiz integration to request the equipment status update the same way the vendor app does? or maybe there is already inside the somfy local developer-mode API ?
not necessarily to be triggered automatically/periodically, but so that one could integrate it inside an automation to request an up-to-date status refresh based on chosen events..?
here's a feature request already if you wish to upvote
On the other hand, I've also noticed that it was possible to refresh the status of my somfy gate (which would appear open although it was already closed after the built-in timer went out) by pressing the "stop" button on the gate "cover" entity. This currently serves as a workaround, but not a so reliable at that since triggering the "stop" action during open/close actions may freeze the gate in a undesired position...
This is indeed a difficult issue. In the past we did look into creating a background separate task that would just refresh the state every hour, but that is also not a solution for most users, as you can never depend on the actual state. This endpoint should not be called to often as it is an 'expensive operation' on the gateway, and Somfy will also block this if you hit their Cloud API to often.
For now we have made the decision to document this as a limitation for certain devices.
An expected benefit of a smart home for this device is to get a warning if the garage door stays open when it should have closed.
I get a critical alarm if the car or last person left home 5 minutes ago and the garage door is open.
Sadly with this limitation we get the alarm each time.
~You could look into https://github.com/rstrouse/ESPSomfy-RTS, as this should be able to capture radio signals from your remotes as well.~
~Haven't tried this, but worth looking into.~
I don't see it as a reliable solution for a IO remote. But thanks for the idea
I wish simply to have a feature to refresh before triggering the alarm.
Instead of checking status too frequently, how could I trigger a refresh of that status? Simply by reloading the integration?
Hi @iMicknl, thanks for your feedback on this topic!
Yes, I indeed saw the thread where it was discussed to have the frequency of the status refresh brought down. But indeed, having (more) frequent status update (when not needed) is very different from triggering the status refresh when needed.
but what do you mean by
This endpoint should not be called to often as it is an 'expensive operation' on the gateway
are you referring to the API endpoint that allows to refresh all the connected devices' states at once? and which cannot be executed selectively on particular device?
and by gateway, do you mean the overkiz cloud API? is it something that can only occur by somehow reaching cloud API? i.e. it cannot be run exclusively using the local API?
or did you actually mean the physical gateway (e.g. tahoma switch)?
@chriscatuk Using a garage door open/close tilt sensor, and some automation rules, I have managed to have my garage door (somfy dexxo io) state become "near real-time" accurate despite being opened or closed via push buttons or iO remotes.
and I'm planning to do the same with my front gate, albeit with a little more work, wires and sensors (as it is a 2 door gate system with "pedestrian" position). I have good hope to achieve same sense of real-time-ness in the end....
but still, there could be a lot saved if only I could trigger the status refresh on my own as part of the automation (e.g. "if gate is moving, wait for it to stop moving then poll current state", and that would be it!)
@chriscatuk sorry, that was my mistake, RTS Somfy won't work with IO devices. For a second I thought you had IO devices... Please disregard my comment.
are you referring to the API endpoint that allows to refresh all the connected devices' states at once? and which cannot be executed selectively on particular device?
and by gateway, do you mean the overkiz cloud API? is it something that can only occur by somehow reaching cloud API? i.e. it cannot be run exclusively using the local API?
@aquarilis, we haven't tried this endpoint (yet) on the Local API, thus I can't comment on that. The 'expensive' wording was mentioned in their cloud API doc of long long time ago. But my understanding was that it did refer to the physical gateway, most likely this command requires more compute power and should not be called too frequent.
There is an endpoint and some devices do also offer a refresh command. This command didn't work for all devices, where the endpoint (all devices, or scoped to a single device) did work for most of them.
Anyways, happy to dive into this. Would you be willing to have a Discord chat (_imick) on this topic? So that we can see what is a feasible alternative that works around these limitations, and what might be accepted into core. One of the main challenges here is 'triggering the status refresh when needed.', we need to figure out what 'when needed means'. in the context of Home Assistant (e.g. an entity service that can be called in an automation).
I'm trying one of those two actions before sending a critical alarm on iPhone.
I will update this thread with the results
- action: homeassistant.reload_config_entry
metadata: {}
data:
entry_id: 01JK99CKG....EDQ0RT7A6Y # found in URL for the Overkiz integration
- action: homeassistant.update_entity
metadata: {}
data:
entity_id:
- cover.garage_door
@chriscatuk this will work, but is a huge anti pattern. Reloading the config entry will call /setup (which will retrieve all data from the gateway). If you call this to often on the cloud API, you often will receive a (temporary) ban as this adds unnecessary load on their server. Thus proceed with caution here :-).
@iMicknl sure thing. I've tried to add you on discord (mine is aquarilis)
@chriscatuk this will work, but is a huge anti pattern. Reloading the config entry will call /setup (which will retrieve all data from the gateway).
it didn't solve my issue. The garage door still shows as open.
@iMicknl , You mentioned will retrieve all data from gateway. And I opened the somfy app that I never use. It is there that the issue lies. Somfy is not updating their own gateway when the garage get closed with a IO remote or the button.
I thought buying a IO model with status detection would address that issue but never checked after setting up home assistant.
Somfy is not updating their own gateway when the garage get closed with a IO remote or the button.
Indeed, that is a huge shortcoming from Somfy io hardware (at least from a home automator perspective): they don't proactively broadcast their status changes if manipulated via push buttons or io remotes (which can be considered as a wired-in push-button trigger in that respect, i.e. not a software trigger).
But their status can be queried remotely as demonstrated by their somfy app... so there is still hope 🤞
Note for later: 2 position covers is still having the somfy/tahoma app confused in terms of retrieved/updated state: if I set the cover position to "pedestrian" in HA/Overkiz (and not via the vendor app), the gate correctly opens to that position in the real world. So far so good.
But if I open the tahoma app at that moment: it will refresh the gate state and detect the gate as open, but it won't recognize that it was set to "pedestrian" position so it will report and set the gate to "fully open".... I guess it's a slightly different issue, but which will probably reappear somehow as we're trying to solve the "status update" issue.
their status can be queried remotely as demonstrated by their somfy app... so there is still hope 🤞
I can't find a way to request the Tahoma to check the status of the garage door without asking to open/close it from the app.
they don't proactively broadcast their status changes if manipulated via push buttons
without going as far as broadcasting to the API users, it's shocking that they don't even update their own Tahoma gateway about the status change when a IO garage door get closed without the API.
it's shocking that they don't even update their own Tahoma gateway about the status change when a IO garage door get closed
I kind of remember some somfy employee mentionning on the french somfy forum that it was a matter of limiting the traffic on the proprietary "io" network: they would request status update only when opening the app (or maybe even when opening a device tile in the app) in order to avoid congestion due to equipments sending updates randomly... (or maybe just bad developments of their own API preventing them to properly deal with such events 😆)
Anyhow, I'm only having 2 somfy iO equipment (and probably won't be adding any given their poor "connectivity" 😒), but I can imagine the "traffic" (and "gateway computing") issue to be quite different if you had dozens of such equipment in a given setup (e.g. all your mansion's roller shutters + multiple garage doors etc...)
@chriscatuk if you can add me on Discord as well (_imick), I will add you to a group. Let's discuss what the best solution would be to work around these Somfy limitations.
If people that face issues can post the diagnostics for the device where you face issues, that would help in understanding which devices have these limitations. If I am not mistaken these are mainly the garage doors, normal covers with remotes often don't have these limitations..
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.