Multiple contact sensor state updates within polling period are not processed in Overkiz

[jameslshannon]

The problem

Similar to #125222 I'm using the Somfy door contact sensor to monitor and alert on mailbox opening. However, whilst the status is shown correctly in the TaHoma app (always) and Home Assistant (sometimes), many of the status updates are missed by Home Assistant resulting in missed Mailbox opened alerts.

Reading the above issue it sounds like the Overkiz integration polls for updated states every minute (so state changes could be delayed up to a minute - which is fine) but in many cases I'm not seeing any status updates after one minute. I suspect this is because the mailbox status changes from closed>open>closed relatively quickly when mail is deposited (maybe around 5-10 secs). Does this explain why the state change is missed completely by Home Assistant as these state changes are occurring between the one minute polls?

Looking at the Somfy Local API, POST /events/{listenerId}/fetch should "Fetch events available after registration and from previous fetch." - in which case surely the events that occurred since the last poll should then be received and reflected in Home Assiatant even if they occurred between polls?

What version of Home Assistant Core has the issue?

core-2025.1.1

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

config_entry-overkiz-01JFWDWC99T112VK42JFSAZR4Y.json

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant]

Hey there @iMicknl, 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 close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign overkiz Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove 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)}}

[iMicknl]

@jameslshannon can you verify if the state is correct in Home Assistant within 30 seconds after you open the Somfy TaHoma app?

[jameslshannon]

@iMicknl no, opening the app before I change the state doesn't appear to make a difference - it feels like the state is only being updated when it's polled, which means that it's almost always closed (as it's never open for more than a few seconds).

If I leave it open for 30 secs to a minute then of course the state changes to open, but if I then close it immediately the state doesn't change to closed for another 30 secs or so. Also, if I open and close it several times only a single state change is recorded in Home Assistant (vs multiple in the TaHoma app) which makes me think it's not retrieving the interim state changes between polls.

[iMicknl]

I meant opening the Somfy TaHoma app after the state should have been updated. This is most likely a duplicate of #125222. We should add this limitation to the documentation.

Somfy calls a specific refreshAllStates endpoint when you open the app. This will request an update of all states and these will be broadcasted via the event mechanism (which is the one Home Assistent listens to). In Home Assistant we cannot do this, since we don't know when you are using the dashboard and anyways state data used by automations might be outdated. This is unfortunately a limitation of some Somfy devices which do not broadcast their realtime status automatically...

[jameslshannon]

Based on my testing just now, I don't think this is a Somfy device or TaHoma switch limitation but maybe a limitation of the listener integration approach taken...here's what I just did:

• I registered an event listener with the TaHoma switch local API using /events/register. According to their API docs this listener is automatically destroyed after 10 mins of inactivity or on reboot. So polling this every minute (or even 5 minutes) would keep this listener alive indefinitely until a reboot. This call returns a listenerId.

• Ensuring that the TaHoma app and web portal were closed on all devices I then went and briefly opened and closed the mailbox

• I then called /events/{listenerId}/fetch using the local API of the TaHoma switch which returned the following:

[
    {
        "deviceStates": [
            {
                "name": "core:ContactState",
                "value": "open",
                "type": 3
            }
        ],
        "deviceURL": "io:\/\/2086-2518-0499\/8911134",
        "name": "DeviceStateChangedEvent"
    },
    {
        "deviceStates": [
            {
                "name": "core:ContactState",
                "value": "closed",
                "type": 3
            }
        ],
        "deviceURL": "io:\/\/2086-2518-0499\/8911134",
        "name": "DeviceStateChangedEvent"
    }
]

As you can see, both state change events that occurred since the last call to /events/{listenerId}/fetch were returned. Neither state change was recorded in Home Assistant by the Overkiz integration. After 5 minutes I open the TaHoma app and it shows the open and close state changes in the sensor history. After a few minutes I then check Home Assistant and still no state updates logged for that device.

Would it therefore not be possible to use the listener mechanism provided by the TaHoma switch local API above to capture these state change events between polls? It could register the event listener when first connecting to the API and then still poll every minute, but it means that all state change events would be captured and HA automations could be triggered by Somfy sensor state changes.

I'm hoping this alternative approach might help solve this perceived limitation with Somfy devices, as so far the TaHoma switch seems stable, offers a performant local API and acts as a key gateway to many devices already installed in homes such as shutters, gates, etc.

Thanks in advance and let me know if there's anything else I can help with to improve the listener integration. Also please feel free to correct me if I've missed the point! But from what I've tested above, it definitely seems possible to capture these near real-time state changes from the Somfy door/window sensors.

[iMicknl]

Can you turn on debug mode? Overkiz integration uses the same endpoints as you mentioned, thus if your device does broadcast events, they should show up in your log.

We do fetch/poll this event listener every 30 seconds, and in 2025.2 this will be lowered to 5 seconds for the local API.

[jameslshannon]

Debug log & Logbook screenshot below - I opened and closed the mailbox 3 times each with extending duration (~2 secs, then ~5 secs then ~10 secs).

I can see all 3 open/close states in the debug log but only one is logged in Home Assistant and hence my automation only fired once.

debug.log

[iMicknl]

@jameslshannon the issue here might be that when it polls every 30 seconds; the Overkiz integration only processes the last known device state if there are multiple (and not the previous states).

It seems to only miss duplicate events in a 30 second timeframe?

[jameslshannon]

Yes, quite possibly - which is obviously no good in use cases where a sensor is only ever in the state required to trigger an automation for a brief period e.g. "open" for a mailbox. It's therefore likely that the final state always captured is "closed" and also makes the behaviour prone to perceived intermittency based on when the poll happens relative to state changes - which shouldn't ever matter. This could potentially also worsen with a reduced poll frequency of 5 secs.

Ideally the integration would capture all returned state changes in HA in the sequence that they occur so that any open states may trigger automations if required and the final state is still accurate.

I notice that there are no timestamps though, but would assume that they're returned in the sequence that they occur. If the poll frequency is reduced to 5 secs for the local API this should also be less of an issue for the HA Logbook timestamps.

[harezidencia]

I have the same problem! Sonoff SNZB-04 sensors work for me. Owerkizz detects all open-close events, but HA does not receive all events, not even retroactively.

[iMicknl]

@harezidencia your sensor is a Zigbee device. Best option is to connect this direct to Home Assistant, where you will have real-time status updates. Overkiz will always have a delay as we need to poll for updates.

@jameslshannon thanks! I would need to investigate if we can broadcast multiple states and if HA can process this. This might be more difficult as we indeed don't receive a timestamp and it seems HA only stores the last event at the moment.

[jameslshannon]

@iMicknl understood - although I guess with the polling interval being reduced to 5 secs for the local API soon it would be possible to add incrementing timestamps to the state changes based on their sequence and the polling timestamp before passing them to HA if they're required?