Shelly Modbus 1.2: Warum zwei Shellys alle paar Minuten das Log füllten

Auf meiner Instanz schrieben zwei Shelly-Geräte, die ich nie in die Integration aufgenommen hatte, rund um die Uhr alle paar Minuten dieselben zwei Zeilen ins Home-Assistant-Log:

WARNING [pymodbus.logging] Failed to connect [Errno 111] Connect call failed ('192.168.20.230', 502)
WARNING [pymodbus.logging] Repeating....

Behoben ist das in Version 1.2.0 von shelly-modbus-home-assistant.

Die Ursache

Der Zeroconf-Schritt gab jedes angekündigte Shelly sofort an den Modbus-Client weiter, damit der die Identität des Geräts liest – bevor irgendetwas bestätigt war. Ein Gerät, dessen Modbus-Server ausgeschaltet ist, verweigert Port 502. pymodbus meldet das als Warnung und versucht es erneut, und Home Assistant startet bei jeder erneuten Ankündigung einen neuen Discovery-Flow. Ein einziges Shelly im Netz mit abgeschaltetem Modbus reichte also für dieses Zeilenpaar auf unbestimmte Zeit. Auch mit dem Log-Level der Integration ließ sich das nicht ausblenden, denn die Warnung stammt von pymodbus.

Was sich geändert hat

Erst ein einfacher TCP-Connect

Bevor der Modbus-Client überhaupt ins Spiel kommt, klärt ein schlichter TCP-Connect, ob auf dem Port etwas lauscht. Lauscht nichts, bricht der Flow ohne eine Zeile im Log ab. Dieselbe Prüfung läuft im manuellen Schritt: Ein Tippfehler in der Adresse führt dort sofort zu „Verbindung nicht möglich“, statt dass erst die Wiederholungen ablaufen müssen.

Modbus-Probe hinter einer Bestätigung

Ein erkanntes Gerät zeigt jetzt einen Bestätigungsdialog mit Name und Adresse. Erst nach der Bestätigung liest die Integration etwas vom Gerät. Das entspricht dem, was Home Assistant von Discovery-Schritten erwartet, und stellt sicher, dass ein angekündigtes Gerät nie gelesen wird, bevor man es will.

Der Preis dafür: Ein Shelly, das kein Modbus spricht, taucht als gefundenes Gerät auf, bis man es einmal ignoriert. Vorher wurde es automatisch verworfen – mit dem Log-Rauschen, das diese Version beseitigt.

Zwei Abbruchgründe waren unübersetzt

Schlug eine Erkennung nach der Bestätigung fehl, zeigte der Dialog den rohen Schlüssel cannot_connect. Dieser und der neue Grund no_components – erreichbar, aber nichts Bekanntes zum Lesen – sind jetzt auf Deutsch und Englisch ausformuliert. Ein Test prüft, dass der nächste nicht vergessen wird.

Update

Es ist nichts zu tun. Bestehende Config-Einträge, Entitäten und deren Verlauf bleiben unberührt; die Änderung betrifft nur, wie Geräte hinzugefügt werden.