Repository navigation
every hour ten minute past it runs through all entitites even things I dont have #637
Description
First of all thanks for the huge effort you are putting into this.
I have a quite simple setup mh201 gateway, with lights and advanced shutters. Everything is working well with the new v2 where in the past i had some isssue like everyone else with the updates of HA.
Anyway. Looking at the bus card you created, i see that every hour ten minutes past it seems to run through all the entities, even things that i dont have, like sound and heating. At that time it locks and unlocks as well the entities.
Maybe it normal but wanted to check, as when i had 0.94 it spit out errors for that. 0.94 worked for a months or so and recently it started to hang once in a while, so i had a go and upgraded to v2.
setup
"home_assistant_version": "2026.9.4", docker
"integration_version": "2.0.0b14",
"ownd_version": "2.0.0b9",
hopefully it helps.
again thank you for your great work!
Activity
[-]every hour ten past it runs through all entitites even things I dont have[/-][+]every hour ten minute past it runs through all entitites even things I dont have[/+]GreenGrassBlueOcean commentedon Oct 5, 2026
Thanks for the kind words, and for the trace. It helped.
What I see in it: at about 16:10 the integration sends its startup discovery sweep. It asks the bus for status of lighting, automation, heating and audio in turn (#10##, #20##, #40##, #160*5##). The sweep asks about every subsystem, whether or not you have devices on it, which is why you see heating and sound. Your gateway doesn't have them and just won't answer.
This sweep is only meant to run once, when the integration starts or reconnects. It shouldn't run every hour. That the lights and shutters briefly lock and unlock fits the same picture: something is making the integration reconnect or restart around :10 each hour. I don't yet know what.
Could you help me narrow it down?
Please attach the Home Assistant log from around 16:00 to 16:20, and ideally the same window an hour earlier or later. Filter on custom_components.myhome if you like. I'm looking for lines such as "Closing event listener", "reconnected", or the integration being set up again.
If you can, turn on debug logging for the integration first:
Is anything on your side scheduled hourly at about :10? Examples are a Docker or host restart, a network or Wi-Fi reconnect, or a backup. Or did you reload the integration around then? A gateway that closes the session on a timer could also cause this.
Nothing is broken on your side, and no action is needed to stop the sweep. I just want to find out why it re-triggers.
imfreddie commentedon Oct 6, 2026
Hi and thanks for your quick reply. A bit embarrassing, i had a automation running with the recylce of updating myhome which i tried to use earlier when it hanged under v 0.9.3. i removed it now and it stopped coming up. thank you i never though of it!!
the only warning im getting in the log now is:
Logger: custom_components.myhome
Source: custom_components/myhome/gateway_sessions.py:234
Integration: MyHOME (documentation, issues)
First occurred: 5 October 2026 at 17:58:25 (21 occurrences)
Last logged: 06:46:36
[MH201 gateway - 192.168.0.3] No bus traffic for 3900s; assuming stale connection, reconnecting...
[MH201 gateway - 192.168.0.3] Connection closed by the gateway while negotiating event session (busy or out of session slots?); will retry.
[MH201 gateway - 192.168.0.3] Event session: negotiation failed (connection_closed). Retrying in 1s (attempt 1/5).
[MH201 gateway - 192.168.0.3] Timed out negotiating event session.
[MH201 gateway - 192.168.0.3] Event session: negotiation failed (negotiation_timeout). Retrying in 2s (attempt 2/5).
GreenGrassBlueOcean commentedon Oct 6, 2026
Thanks for confirming that the hourly reload automation was the culprit for the discovery sweeps!
The warnings you are seeing now are completely benign and safe to ignore, but here is what is happening under the hood:
Nothing is broken on your plant, but we will look into tuning the inactivity watchdog and reconnect backoff so quiet plants don't log alarming warnings during the night.
GreenGrassBlueOcean commentedon Oct 6, 2026
Addressed in #640 (disables the passive 65-minute event inactivity watchdog in gateway sessions so quiet plants without bus traffic remain connected without triggering spurious reconnection warnings).
fix(transport): propagate and test inactivity_timeout in AsyncTcpTran…
fix(gateway): disable passive event inactivity timeout on quiet plants (
Merge pull request #640 from GreenGrassBlueOcean/fix/issue-637-event-…
GreenGrassBlueOcean commentedon Oct 7, 2026
Resolved in #640 (merged into
v2-phase1-architectureasa50dabe9).Root Cause & Resolution
On quiet installations with few bus events, the TCP event transport's 3600-second (1 hour) passive inactivity timeout was expiring. When the event connection dropped, the integration automatically reconnected and ran the gateway reconnection routine, triggering a full inventory walk across all supported subsystems every hour at ten minutes past.
In #640, passive event inactivity timeout is disabled (
inactivity_timeout = 0) on quiet plants, preventing the unneeded disconnects and hourly sweeps.Included in v2.0.0b15. Thank you @imfreddie for reporting this and providing the trace!