Auf Grund eines Ausfalls eines physischen Servers, und weil ich diesen dann mit VMs ersetzt habe, hatten einige meiner Shelly-Geräte plötzlich Verbindungsprobleme.

Bis zur intensiven Debugging-Session wusste ich aber nicht, wieso.

Die Symptome:

• Es waren nur Shellys mit dem Web-Interface der ersten Generation betroffen (sprich Shelly 2.5, welche in der Eigentumswohnung die Rollläden steuern, ein Shelly 3EM, der dort den Stromverbrauch misst, sowie Shelly Temperatursonden (die Todessterne))
• Die Shellys verbanden sich anstandslos mit dem WiFi

• Die Shellys waren anpingbar
• Im Web-Interface wurde ganz oben ein gelbes Cloud-Symbol angezeigt, und wenn man mit der Maus darüberfuhr, hiess es „Trying to establish cloud connection“
• Im Web-Interface wurde oben rechts anstelle der Uhrzeit „–:–“ angezeigt
• Die Shelly Cloud sandte mir ein Email mit dem Titel „Mass offline devices“

Das Problem, und die Lösung: Offenbar unterstützt das Mongoose OS, welches auf diesen Shellys läuft, nur genau einen DNS-Server (der massgebliche Tipp stammte von hier). Verteilt man die IP mitsamt DNS-Server der Shellys mit einem lokalen DHCP-Server, muss der DNS-Server mit der ersten IP funktionieren, sprich Namen auflösen können. Das tat er in meinem Fall nicht, weshalb die Shellys weder time.google.com auflösen konnten, noch die Adresse(n) der Shelly Cloud. Somit verfügten diese weder über eine Verbindung zum Zeitserver, noch zur Cloud — funktioniertem im lokalen Netzwerk aber tadellos.

Die Shellys mit dem neueren Web-Interface scheinen diese Beschränkung nicht zu haben, denn diese waren immer online.

Doch bis zu dieser Erkenntnis war es ein langer Weg:

Das Problem mit der Uhrzeit löste ich als Workaround, indem ich im Web-Interface anstelle von time.google.com die IP eines NTP-Servers im lokalen LAN angab. Nach einem Reboot wurde die Uhrzeit wieder angezeigt.

Doch wie löste ich nun das Cloud-Problem? Das Debugging führte mich zum neu aufgesetzten, virtualisierten DNS-Server. Interessanterweise erschienen im BIND9 Query Log auf diesem Server ausschliesslich anfragen vom localhost (127.0.0.1). Ich dachte mir anfänglich nicht viel weiteres dabei.

Doch irgendwann einmal machte es Klick: Das Problem mit der Zeit respektive dem NTP-Server und der nicht möglichen Cloud-Verbindung mussten zusammenhängen.

Ich versuchte deshalb, von einem anderen Linux-System im LAN gegen den via DHCP als erstes verteilten DNS-Server eine Domain aufzulösen.

Resultat:

# host emeidi.com 1.2.3.4
;; communications error to 1.2.3.4#53: connection refused
;; communications error to 1.2.3.4#53: connection refused
;; no servers could be reached

Ich nahm die Konfigurationsdatei des BIND 9 auseinander, startete ihn mehrmals neu — das Problem blieb. Bis ich plötzlich realisierte, dass ich via DHCP die IP des DHCP-Servers als ersten DNS-Server verteilte, und nicht die des pimären DNS-Servers. Schwupp-di-Wupp, DHCP-Konfiguration angepasst, Shellys neu gebootet — und siehe da, schön der Reihe nach änderten alle Shellys mit Cloud-Verbindungsproblemen die Farbe des Cloud-Icons von Gelb auf Grün:

Übrigens: Ich habe nun bei all diesen Shellys den Eco-Mode deaktiviert. Nützts nüt, schadts nüt.

Was ich auch noch gelernt habe: Die Shelly 2.5 sterben sehr oft an Altersschwäche eines Kondensators.