Bei einer Vielzahl von Sensoren den Akkustand prüfen

Inzwischen haben sich jede Menge Zigbee-Sensoren angesammelt. Diese halten mit einer Batterie echt lange durch. Viele zwei Jahre und mehr. Trotzdem geht die Batterie irgendwann mal zur Neige und davon möchte ich nicht überrascht werden. Also habe ich einen kleinen Flow in Node-RED, welcher die Akkustände jeden Tag einmal prüft und mich bei Bedarf benachrichtigt.

Um nicht für jeden Sensor neue Nodes ergänzen zu müssen, nutze ich die Möglichkeit, Nachrichten mit node.send(msg); asynchron zu versenden.

Sensoren zentral hinterlegen und einzeln durchgehen

var zigbeesensoren = [2,4,5,6,9,10,11,14,15,16,17,21,23,26,29,30,31,32,33,34,36,38,41,44,45,46,49,50,51,52,53,56,57,58];

zigbeesensoren.forEach(function(val) {
    msg.topic = "deconz.0.Sensors."+val+".battery";
    node.send(msg);
});

return;

Im Array zigbeesensoren sind einfach die abzufragenden Sensornummern (der ioBroker-Objekte) hinterlegt. Die forEach-Schleife sorgt dafür, dass das ganze Array durchgegangen wird und das richtige msg.topic für jeden Sensor gebaut und als Nachricht abgeschickt wird. So kann über „IoB read value“ jeder einzelne Batteriestand ausgelesen und in der Funktion „Batterie leer?“ geprüft werden. Wie gewohnt erstellt „UI Notification“ im Bedarfsfall die Benachrichtigung und leitet sie an das zentrale Benachrichtigungssystem.

Einen ähnlichen Aufbau kann man natürlich auch für beliebige andere Objekte nutzen, die vielfach ausgewertet werden müssen.

Dumme Haustechnik einfach smart machen

Alle Angaben ohne Gewähr. Alle Ideen, die aus diesem Artikel entstehen, auf eigene Gefahr.
Die beschriebenen Möglichkeiten sollte man als Mieter gar nicht erst lesen, oder direkt wieder vergessen.

Die Steuergerät meiner Gastherme und der Solarpumpe sind dumm. Natürlich kann man einiges einstellen, aber Schnittstellen, um sie smart zu machen, gibt es nicht. Zwar könnte ich für absurde Beträge zumindest der Gastherme mit einem Zusatzgerät ein wenig Vernetzung einhauchen, aber beim Blick auf die Kosten verzichtete ich darauf. Stattdessen trickse ich die Steuergeräte über ihre Sensoren einfach aus.

Was will ich steuern?

Am Anfang stand die Sorge um die Solarthermie-Anlage. Im Hochsommer bringt sie enorme Erträge und heizt den Warmwasserspeicher (leider unterdimensioniert) so weit und so schnell auf, dass die Gefahr besteht, dass sie in praller Mittagssonne aufgrund der nötigen Temperaturbegrenzung aufhört zu arbeiten, die Solarflüssigkeit sich nicht mehr bewegt und anfängt zu kochen. Das Steuergerät hat keine Funktion, dem zu begegnen. Also wollte ich die Möglichkeit, die Solaranlage bei Bedarf in der Nacht laufen zu lassen, um den Speicher abzukühlen, damit es am nächsten Tag nicht zu Problemen kommt.

Weiter ging es, als ich eigene Sensoren am Warmwasserspeicher hatte, und so in schönen Charts mit ansehen konnte, wie schnell das warme Wasser auch ohne Nutzung wieder kalt wird. Dies galt es effektiver zu gestalten und so wollte ich ein Bestellsystem für Warmwasser aufbauen, welches Komfort und Energieeffizienz unter einen Hut bringt. Das Bestellsystem benötigen wir sowieso eigentlich nur im Winter, weil die überwiegende andere Zeit im Jahr genug Warmwasser durch die Solarthermie-Anlage zusammenkommt.

Wie lässt sich die Steuerung umsetzen? (Theorie)

Die Steuerungen von Therme und Pumpe basiert auf Sensorwerten. Anhand dieser Sensorwerte werden bestimmte konfigurierbare Automatismen ausgelöst. Durch die Manipulation der Sensorwerte kann ich also bestimmen, wann ein Automatismus ausgelöst werden soll, und wann nicht. Voraussetzung dafür ist, dass ich die wahren Sensorwerte kenne, damit ich selbst den Überblick habe.

Da es mir nicht möglich war, die Sensorwerte aus den Hausgeräten auszulesen, habe ich eigene Sensoren (DS18B20) am Speicher und der Solarstation ergänzt und mit den Sensoren der Hausgeräte entsprechend abgeglichen.

Beispiel Solarthermie Steuerung: Die Solarthermie-Steuerung vergleicht die Temperatur im Speicher mit der Temperatur auf dem Dach. Ist die Temperatur auf dem Dach um ein konfiguierbares Offset höher als die im Speicher, startet die Steuerung die Pumpe. Wenn ich also mitten in der Nacht sage: „Hallo Steuerung, im Speicher sind es nur 5°C“, dann ist im Hochsommer die Temperatur auf dem Dach definitiv höher und die Solarpumpe bringt fleißig überschüssige Wärme zurück auf das Dach.

Beispiel Gastherme / Warmwasser: Die Steuerung der Gastherme hält den Speicher in einem konfigurierbaren Zeitraum auf einer gewissen Temperatur. Wenn ich also dem Steuergerät vorspiegele, dass die Speichertemperatur über der Zieltemperatur liegt, sieht sie keinen Handlungsbedarf. Schalte ich auf den realen Sensor um, greift wieder die eingebaute Steuerung und das Aufheizen des Speichers kann beginnen.

Wie lässt sich die Steuerung in der Praxis umsetzen?

Für die technischen Umsetzung muss man sich erst einmal vergegenwärtigen, wie ein Temperatursensor technisch funktioniert. Je nach Temperatur liefert der Sensor einen gewissen elektrischen Widerstand. Dieser unterscheidet sich von Modell zu Modell. Weiter hilft hier das Handbuch des Hausgeräts, in dessen Anhang meist eine Tabelle der Widerstände und zugehörigen Temperaturen zu finden ist. Teils muss man dafür das Installateurs-Handbuch bemühen, aber das findet man auch meist online.

Widerstände des Speichertemperaturfühlers einer Buderus GB172-14

Der erste Schritt ist also den passenden Widerstand für die beabsichtigte Temperatur zu besorgen – natürlich müssen es dabei nicht die exakten Werte aus der Tabelle sein, da es egal ist, ob es bspws. 57,0 oder 57,2°C sind. Der zweite Schritt bringt ein wenig Nervenkitzel ins Spiel, wenn man das Sensorkabel des Hausgeräts möglichst mit gut Luft in beide Richtungen einfach durchschneidet (Gerät vorher abschalten!) – im Ernstfall beeinflusst eine Lüsterklemme den Widerstand/Sensorwert aber auch nicht.

Mit einem herkömmlichen Relaisboard an den GPIO des Raspberry PI richtig verkabelt, hat man dann die Möglichkeit, zwischen echtem Sensorwert und vorbestimmten Sensorwert hin und her zu schalten. Meine Geräte stören sich daran nicht. Nach ausgiebigen Tests landete das ganze dann noch auf einer Platine.

Links das Relaisboard, rechts die Platine mit den Anschlüssen für die Sensorkabel und den Widerständen.

Dashboard / UI

Im Winter bemühen wir also jetzt das Dashboard, wenn es um Warmwasser geht.

Im Dashboard habe ich nach anfänglich komplizierten Überlegungen die Steuerelemente sehr simplifiziert. Für Heute, Morgen und Übermorgen gibt es je die Möglichkeit, Warmwasser für den Morgen, Mittag oder Abend im Voraus zu bestellen. Um Mittnacht rutscht natürlich Morgen ➡ Heute und Übermorgen ➡ Morgen. Weiterhin gibt es neben der aktuellen Speichertemperatur auch eine Bewertung der Lage, inkl. Prognose, wie lange der aktuelle Warmwasserbestand noch für eine ausgiebige Dusche reicht. Für die Berechnung der Prognose habe ich Langzeitdaten über die Abkühlung des Speichers erhoben und ausgewertet.

„Nur halb aufheizen“ kommt zum Einsatz, wenn vrstl. nur wenig Warmwasser benötigt wird. Hier schaltet das Relais schon vor erreichen der Zieltemperatur auf den Fake-Wert um und die Therme sieht ihre Arbeit als erledigt an und hört auf zu heizen.

Auch kann man „Warmwasser jetzt!“ bestellen, dann dauert es durch die Leistung der Gastherme nur gut fünf Minuten, bis man duschen kann. Hat man eine trägere Wärmeerzeugung, ist das natürlich bei allen Überlegungen zu berücksichtigen.

Tipps / Warnhinweise

  1. Die Verkabelung am Relais sollte so erfolgen, dass im Fehlerfall (Raspberry Pi kaputt, Relaisboard ohne Strom, etc.) der reale Wert an das Hausgerät gemeldet wird. So kann man zur Not auch mit „Stecker ziehen“ beim Raspberry Pi den „Normalzustand“ wiederherstellen.
  2. Man sollte versuchen, alle Eventualitäten zu durchdenken. Hat man zum Beispiel eine thermische Desinfektion in seiner Warmwasserbereitung aktiviert, hat man neben dem beeinflussten Sensor-Trigger auch einen zeitlichen Trigger, der das Heizen startet. Hat die Therme in diesem Fall keine realen Speichertemperaturen, heizt sie im Ernstfall ohne Ende.
  3. Wiederum ist es ratsam, einmal in der Woche gut durchzuheizen, um Kontaminationen zu verhindern.
  4. Man sollte die Speichertemperaturen überwachen und mit entsprechenden Regeln reagieren. Steigt die Temperatur im Speicher zu stark an, wird bei mir z.B. automatisch der korrekte Sensorwert der Gastherme bereitgestellt.
  5. Es kann günstig sein, einen zweiten Indikator zur Überwachung mit einzubeziehen, zum Beispiel einen Zwischenstecker mit Power Measurement. So kann man am Stromverbrauch des Gerätes ablesen, wie der Status des Hausgerätes ist und ob Steuerbefehle ausgeführt werden.

ioBroker out / Type / ACK

Was hat es mit dem Type des „ioBroker out“ – Nodes in Node-RED auf sich?

value? command? Was wie wo?

Nachdem ich in den Anfängen meiner SmartHome-Experimente festgestellt hatte, dass Adapter wie ioBroker.deconz oder ioBroker.sonoff die Befehle aus Node-RED nur ausführen, wenn man den Type auf „command“ stellt, machte ich das bis jetzt eigentlich immer so. Dass die Objekte im ioBroker dann teils Rot waren, ignorierte ich, funktionierte ja. Nach einigen Recherchen – ausgelöst durch einen Kommentar zu einem anderen Blogbeitrag – weiß ich jetzt, dass dies nicht unbedingt richtig war.

Was macht der Type im Node „ioBroker out“?

Der Type setzt das ioBroker Attribut ACK (ACKnowledgement = Bestätigung). Dabei steht „value“ für ACK = true, und „command“ für ACK = false.

Warum sollte man ack = false / command setzen?

Viele Adapter verarbeiten Änderungen von Adapter-States, die von anderen Adaptern geändert wurden, nur dann, wenn diese ACK=false haben (auf der Admin-Seite rot dargestellt).

Also werden Werte beispielsweise nur an ein Gerät geschickt, wenn ACK = false ist. Dieses quittiert den Empfang des Befehls auf ihre protokollspezifische Weise, was dann durch ein ACK = true im ioBroker vermerkt wird.

Wann sollte man ack = true / value setzen?

Nutzt man ein State/Objekt nur zum Speichern von Werten (zum Beispiel in 0_userdata), so nutzt man Type = value. Das mache ich jetzt auch häufiger.

Übrigens: In Node-RED hat man im „ioBroker in“ – Node die Wahl, ob nur ACK = true verarbeitet werden soll.

Tasmota OTA auf Shelly flashen

Okay, ich gebe zu: ich bin ein bisschen begeistert. Daher hier erstmal schnell der Disclaimer.

Die nachfolgend beschriebene Methode, einen Shelly auf eine andere Firmware zu flashen, basiert auf einer Fremd-Firmware, auf welche ich keinen Einfluss habe. Die Methode kann deinen Shelly auch kaputt machen.
Dein eigenes Risiko.

Was?

Diese Möglichkeit, Tasmota auf Shelly Geräte zu flashen, funktioniert aktuell NICHT für Shelly Plus (ESP32) Geräte. Leider wurde die Firmware seit Januar 2021 nicht weiterentwickelt, sodass es fraglich ist, ob eine Unterstützung für weitere Geräte noch folgt.

Aktuell werden unterstützt:

  • Shelly 1
  • Shelly 1PM
  • Shelly Plug S
  • Shelly 2
  • Shelly 2.5
  • Shelly RGBW2 (color mode, latest firmware needed)
  • Shelly Dimmer 1
  • Shelly Dimmer 2
  • Shelly EM
  • Shelly Bulb
  • Shelly Vintage
  • Shelly Plug US
  • Shelly Duo
  • Shelly H&T
  • Shelly i3
  • Shelly 1L
  • Shelly Plug 2
  • Shelly Uni
  • Shelly Duo RGBW

Warum?

Ich betreibe meine Shelly 2.5 eigentlich alle mit der original Firmware. (warum steht hier) So hielt ich es auch mit einen Shelly 2.5, den ich nicht als Rolladen-Steuerung einsetze, sondern für einen Doppel-Lichtschalter. Einmal in der Wand verbaut, traten Probleme auf, die ich mit der Shelly Firmware nicht lösen konnte. Außerdem funktioniert das MQTT der Shelly-Firmware nicht mit dem ioBroker Sonoff Adapter, den ich für die Shellies nutze. Und ich will den ioBroker ja schlank halten. Ich ärgerte mich also kräftig, den Shelly nicht vor dem Einbau auf Tasmota umgestellt zu haben. Shelly ausbauen, flashen und wieder einbauen – das muss doch leichter gehen. Und: es geht.

Wie?

Ist der Shelly bereits eingerichtet und mit dem eigenen WLAN Shelly verbunden, geht es verboten einfach. Es gibt eine Mini-Firmware, welche kompatibel zu Mongoose OS (darauf basiert die Shelly-Firmware) ist, dann aber Tasmota (oder eine andere IOT-Firmware) installiert.

Die Firmware findet ihr hier: https://github.com/yaourdt/mgos-to-tasmota

Man benötigt die Shelly-IP und den zur Shelly-Variante passenden Link – welchen ihr auf github findet. Zum Beispiel:

http://shellyip/ota?url=http://dl.dasker.eu/firmware/mg2tasmota-Shelly25.zip 

Ist die Magie abgeschlossen, spannt das Tasmota wie immer ein eigenes WLAN auf und lässt sich darüber konfigurieren/mit dem eigenen WLAN verbinden. Installiert wird die englische Tasmota Version, was sich über ein OTA-Firmware-Upgrade-Funktion in Tasmota aber problemlos auch auf die deutsche oder jede andere Version umstellen lässt. (http://ota.tasmota.com/tasmota/)

Zugegeben: Ich war etwas aufgeregt, da die Erfahrungsberichte in den Issues nicht unbedingt so positiv sind. Bei mir hat es geklappt: ich drücke euch die Daumen.

Flot mit min / max / mittel nutzen

Ich schätze Flot als schlankes Tool um ansehnliche Diagramme zu zeichnen. Diese binde ich per iframe in Node-RED Dashboard ein. Bisher war es mir jedoch nicht gelungen, die Daten abseits der Glättung zu aggregieren und die Eingangsdaten-Arten min, max und mittel zu nutzen. Dabei ist es eigentlich einfach und logisch. Im Reiter „Zeit“ muss nur unter „Aggregation“ der Schritttyp auf Sekunden und die Sekunden entsprechend angepasst werden. Für eine tageweise Aggregation zum Beispiel 86400.

Mit Murphy im Urlaub

Genau wie es Murphys Gesetz verlangt, müssen technische Probleme mit dem Smart Home natürlich im Urlaub auftreten – dann, wenn man auf Automatiken und Überwachung eigentlich besonders Wert legt und die Reparaturmöglichkeiten begrenzt sind.

2019

Schon vor zwei Jahren hatte ich den Fall, dass nach der Hälfte des Urlaubs mein Smart Home nicht mehr erreichbar war. Weder die Weboberflächen von ioBroker und nodered noch das SSH des Raspberry Pi waren erreichbar und ich hatte damals keine Möglichkeit, den Pi neuzustarten. Seitdem hängt der Raspberry Pi an einer WLAN Steckdose, sodass ich diesen zur Not stromlos machen kann, um ihn hart neuzustarten. Der Status wird zudem inzwischen von einem zweiten Raspberry Pi überwacht, welcher nach einer gewissen Spanne der Unerreichbarkeit den Neustart auch selbst einleiten kann. (auf diesem läuft auch ein Node-RED, allerdings ohne iobroker)

Um dabei keine Probleme zu erzeugen, sollte die Konfiguration des Raspberry Pi und die Programmierung im Node-RED natürlich bootfest sein.

2021

Dieses Jahr begann es mit einem Shelly 2.5 zur Rolladensteuerung, der einfach Ausstieg und nicht mehr ansprechbar war. Mein integriertes Meldungssystem schickte brav die Fehlermeldung, dass beim Fahren des Rollos ein Fehler aufgetreten sei. Was genau mit dem Shelly los ist, muss ich noch untersuchen. Das Relais klackert ununterbrochen, wenn der Shelly am Netz ist.

Nach gut einer Woche kam es dann dazu, dass der schon vermutete langsame Tod der SD-Karte des Raspberry Pi unübersehbar wurde. Das Betriebssystem lief noch, doch der ioBroker wollte nicht mehr starten.

Dank WLAN Steckdose konnte ich den Raspberry PI dann immerhin abschalten, um die Relais, welche die Sensorwerte von Solarthermie-Steuergerät und Gastherme (eh gerade abgeschaltet) zur Steuerung „manipulieren“, sicher auf ihren Standard-„Notfallposition“ zu wissen.

Es zeigt sich, wie wichtig es ist, die Schaltung richtig aufzubauen, damit im Ernstfall (stromlos) das Relais den sicheren Kontakt herstellt.

Und nun?

Jeden Morgen wird ein vollständiges Backup gezogen, sodass keine Daten verloren gegangen sind und die Wiederherstellung nach Rückkehr aus dem Urlaub in rund einer Stunde durchgeführt war.

Dass SD-Karten in Smart Home Pi’s nicht das ewige Leben haben, ist ja bekannt. Ich vermute, dass die Raumtemperatur von bis zu 50 Grad (bedingt durch die Solarthermie) hier auch nicht unbedingt förderlich ist. Ich versuche es jetzt erstmal mit einer SanDisk Pro Karte, die angeblich mehr aushalten soll. (Aber auch mit diesen habe ich schon von ähnliche Vorfällen gehört.)

Hoffnungsvoll stimmt mich die Entwicklung bzgl. der besseren SATA-Unterstützung beim Raspberry Pi OS, was vielleicht/möglicherweise/bitte (!) auch ein Zeichen für einen SATA Port auf einem zukünftigen Raspberry PI Modells ist? Der 4B kam ja schließlich auch schon vor zwei Jahren heraus…

Man wird ja wohl noch träumen dürfen.

Update 20.08.2021:

Und schon wieder war er aus. Liegt es vielleicht doch am Netzteil? Zum Einsatz kommt ein Original Raspberry Pi 4 Netzteil – mhhh. Getauscht und im Test.

Update 31.08.2021:

Der Shelly scheint richtig kaputt zu sein. Alle Reset-Versuche sind fehlgeschlagen, auch bei meinen bisherigen Flash-Versuchen (von original Firmware auf Tasmota) zuckt er bisher nicht. Inzwischen ist ein Garantie-Ersatzgerät von Allterco Robotics unterwegs.

Nachdem der Raspberry Pi auch bei einem zweiten Original Raspberry Pi 4 Netzteil kaum zwei Tage durchhielt, verheißt der Test mit einem Dritthersteller-Netzteil gerade Besserung. Er läuft seit sieben Tagen durch – das hatte ich lange nicht mehr.

Update 21.10.2021

Das Problem ist trotz neuem Netzteil wieder akut geworden. Tägliche Aussetzer waren die Folge. Heute habe ich von Raspberry Pi 4b auf Raspberry Pi 3b+ downgegradet. Der 3b+ hatte ich noch da. Dank Abwärtskompatibilität musste ich nur sämtliche GPIO Kabel, Conbee II, microSD und LAN umstecken und auf ein Micro-USB Netzteil wechseln – in weniger als 10 Minuten war es erledigt. Mein SmartHome-Pi braucht im Mittel 700 MB RAM, sodass es auf dem 3b+ auch mit zufriedenstellender Performance läuft. Ich bin gespannt ob es tatsächlich am Raspberry Pi selbst liegt und der 3b+ jetzt durchläuft.

Update 13.12.2021

Der Raspberry Pi 3b+ läuft ohne Probleme durch. Scheinbar hat der ehemals eingesetzte 4b einen Sprung in der Schüssel – schade! Da der 3b+ gut läuft und auch die Raspi-Preise ordentlich gestiegen sind, werde ich mit einem „Upgrade“-Ersatzgerät warten.

Kaputt gespielt – Backup und Wiederherstellung

Was soll ich sagen, irgendwie habe ich mein Raspberry Pi OS (Raspbian) kaputt gespielt. Es fing damit an, dass ich nicht per VNC auf das System kam (für deCONZ). Zeitweise ging nicht mal raspi-config. Und: jedes mal ging nach ein paar Betriebsstunden die CPU Last massiv in die Höhe – ausgelöst durch einen Fehler mit oder durch kworker. Also fiel die Entscheidung: neu aufsetzen. Ein praktischer Präzedenzfall für Backup & Restore.

In meinem Setup waren drei, oder besser vier Dinge zu sichern und zu überspielen. Da ich noch einen Raspberry Pi 4 herumliegen hatte, konnte ich die Systeme parallel laufen lassen, und musste nicht ständig zwischen alt und neu wechseln, sofern mir noch Infos fehlten. Auch konnte ich so die Vollständigkeit der Daten gut prüfen.

Zum Kopieren der Daten zwischen den Raspberrys nutze ich immer WinSCP.

1. deCONZ/Phoscon

Bei Phoscon einfach über die Weboberfläche unter „Gateway“ ein Backup ziehen und an gleicher Stelle auf dem neuen System wieder einspielen. Das Einspielen des Backups habe ich jedoch erst gemacht, als die microSD-Karte mit dem neuen System auch im Raspberry Pi mit dem Conbee II steckte, um mögliche Probleme zu vermeiden.

2. InfluxDB

Hier sollte man zwingend mit den Backup & Restore Befehlen von influxd arbeiten, ein Kopieren der Datenordner führte (zumindest bei mir) nicht zum Erfolg.

Es müssen sowohl der META-STORE als auch die Datenbank(en) gesichert werden.

$ influxd backup <speicherort-fuer-backup>
$ influxd backup -database iobroker <speicherort-fuer-backup>

Das Wiederherstellen ist ähnlich leicht.

$ influxd restore -metadir /var/lib/influxdb/meta <speicherort-des-backups>
$ influxd restore -database iobroker -datadir /var/lib/influxdb/data <speicherort-des-backups>     

Anschließend muss man ggf. noch die Benutzerrechte des Ordners anpassen.

$ sudo chown -R influxdb:influxdb /var/lib/influxdb

3. ioBroker

Bei ioBroker kann man ein komplettes Backup sehr leicht über die Kommandozeile erstellen:

$ cd /opt/iobroker
$ sudo iobroker stop
$ sudo iobroker backup
$ sudo iobroker start

Das Backup liegt dann unter /opt/iobroker/backups/.

Ebenso einfach ist das Wiederherstellen. Das Backup-Archiv muss man dazu in den gleichen Ordner auf dem neuen System kopieren.

$ sudo iobroker stop 
$ sudo iobroker restore 0
$ sudo iobroker start all
$ sudo iobroker start
$ sudo iobroker upload all

(der Befehl „sudo iobroker upload all“ lädt die Webseiten aus den Ordnern „www“ und „admin“ aus den Adaptern in den ioBroker-Dateispeicher hoch)

Nun dauert es je nach Umfang der ioBroker-Installation einige Minuten, bis automatisch wieder alle Adapter installiert sind. Über die Weboberfläche – Instanzen kann man den Prozess rudimentär beobachten.

4. Node-RED

Die Flows werden beim ioBroker-Backup (3.) mitgesichert. Allerdings werden die zusätzlich installierten Node-Module (über „Palette verwalten“) beim Wiedereinspielen nicht automatisch installiert. Hier hilft ein Screenshot der Liste oder eine kurze Notiz der installierten Node-Module. Aber: zur Not lassen sich die auch anhand der Auflistung fehlender Nodes recherchieren und rekonstruieren.

Probleme

Probleme gab es eigentlich gar nicht. Einzig der ioBroker PING Adapter ändert den Objektpfad anhand des Hostnames – wählt man hier bei der neuen Installation einen anderen, muss man sämtliche Pfadangaben des PING Adapters z.B. im Node-RED korrigieren.

Nachtrag 23.06.2021

Inzwischen (?) kann man im PING Adapter einstellen, dass der Hostname nicht im Zustandsnamen verwendet werden soll. Wenn man bei der Einrichtung darauf achtet, kann man beim Backup & Restore dieses Problem umschiffen.

Warum ich meine Shelly 2.5 nicht mehr mit MQTT steuere

Bisher habe ich die Shelly 2.5, welche ich zur Rolladensteuerung einsetze, über iobroker + MQTT gesteuert. Ich nutze bei ihnen die original Firmware, weil ich die Positionskontrolle, die Kalibierierung und die Hindernis-Erkennung sehr schätze. Darum steuere ich jetzt nicht mehr per MQTT:

Scheinbar ein Firmware Bug

Disclaimer: dieser Artikel ist schon etwas älter. Ob es ein Bug war und ob es diesen potentiellen Bug noch gibt, weiß ich nicht. Ich komme mit der Nicht-MQTT Steuerung sehr gut klar, daher habe ich dies beibehalten.

Ab und zu kommt es bei meinen Shellys dazu, dass die WLAN Verbindung abbricht. Dies liegt einfach an der Reichweite des WLANs, die in mancher Wand im Grenzbereich liegt. Dies ist normalerweise kein Problem, da sich die Shellys recht zuverlässig wieder mit dem Router verbinden. Doch manchmal öffnen sich nach der Wiederverbindung wie von Geisterhand die Rollos – also sie fahren unvermittelt nach oben. Viele Tests später ist meine Theorie, dass dies am MQTT liegt, und es hier scheinbar einen Bug in der Firmware gibt.

MQTT + iobroker Objekte

Zweiter Grund: Von NodeRED kommt die Logik meines SmartHomes. So auch die Rolladensteuerung. Über das Setzen/Ändern von iobroker Objekten, sendet man die Befehle per MQTT. Ein Problem: hat das Objekt bereits den gleichen Wert, wie den, den man setzen will, wird der Befehl nicht übertragen. Wurde also zum Beispiel zuletzt das Rollo auf 60% gestellt, das Rollo danach per Wandtaster wieder hochgefahren, kann man es nicht erneut auf 60% einstellen, weil das Befehls-Objekt noch auf 60 steht. Man muss also umständlich auslesen, welcher Wert gerade im Objekt steht, und ggf. z.B. 61 übermitteln.

Darum nutze ich jetzt die HTTP API

Umgestiegen bin ich auf die HTTP API. Über sie rufe ich peridoisch den aktuellen Status ab (tags öfter als nachts) und sende Befehle. Die Vorteile:

  • Ich habe einen Adapter weniger im iobroker, spart Arbeitsspeicher.
  • Ich umgehe den möglichen Firmware Bug und habe (bisher) keine geisterhaft öffnenden Rollos mehr.
  • Ich kann Befehle senden, ohne diese vorher mit dem aktuellen Status abgleichen zu müssen.
  • Ich bekomme über den HTTP StatusCode (200) direktes Feedback, ob ein Befehl angekommen ist.

So mache ich es

Zum einen habe ich in Node-RED einen HTTP in-Node erstellt, bei dem sich die Shellys über die I/O URL Actions melden, wenn sie stoppen – also die Rollos eine neue Position eingenommen haben. Der dann angestoßene Abruf der Position hält den Wert im iobroker aktuell.

Zum anderen habe ich einen Subflow erstellt, welcher die Befehle an die Shellys übermitteln. Er benötigt als Argument die IP des betroffenen Shellys und einen Befehl. Dabei verarbeitet der Subflow sowohl Open, Close und Stop als Textbefehle als auch Integer-Werte – zwischen 0 und 100 – für die Position des Rollos in „Prozent geöffnet“. (100% = ganz offen)

Hier das Flow:

MQTT/Tasmota ALIVE?

Beim MQTT-Adapter und SONOFF-Adapter im ioBroker gibt es eigentlich bei jedem Gerät auch eine ALIVE/online Variable, die nach meinem Verständnis eigentlich darüber Auskunft geben sollte, ob das Gerät „am Leben“, also online und erreichbar ist. Irgendwie ist diese Anzeige aber sehr unzuverlässig/zeitverzögert.

Daher nutze ich den PING Adapter, um im Minutentakt zu erfahren, ob ein Gerät offline ist, und um dann entsprechende Warnungen im Dashboard ausgeben zu können, oder bei kritischen Aktoren eine Warnmeldung per E-Mail zu versenden.

Alle 60.000 ms – also eine Minute – reicht für meine Zwecke.