Schlagwort: debug

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.

zigbee-batterie-flowHerunterladen

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.

Gefrorener Raspberry Pi

Nein, in diesem Beitrag geht es leider nicht um ein leckeres Dessert. Es geht um ein Problem, welches ich in letzter Zeit immer wieder beobachtet habe: der Raspberry Pi, der mein Smart Home steuert, hängt sich auf.

Das Phänomen

Manchmal, wenn ich einen drahtlosen Zigbee Schalter (Xiaomi/Aqara) betätigt habe, war in der Folge der Raspberry Pi nicht mehr erreichbar, hatte sich aufgehängt – weder über die verschiedenen Ports (1880, 8081, 8082) noch per Ping gab er ein Lebenszeichen von sich.

Die Analyse

Die Problemanalyse lief tatsächlich recht schleppend, tröstete ich mich damit, dass ich das System wohl mal neu aufsetzen muss. Irgendwann fiel mir dann aber ein Muster auf.

Das Muster

Das Problem trat nur auf, wenn ein Zigbee Schalter einen Zigbee Aktor schalten sollte. (Logik via Node-RED) Sollte der Zigbee Schalter einen WLAN Aktor schalten, trat das Problem nicht auf. Sprich: wenn der Conbee II (Phoscon, Dresden Elektronik) zuerst ein Signal empfangen und Sekundenbruchteile später ein Signal senden sollte.

Die (vorläufige) Lösung

Die vorläufige Lösung, die seit zwei Wochen Ausfälle wirkungsvoll verhindert hat, ist ein Verzögerung (delay) zwischen Empfang und Senden des Signals. Aktuell experimentiere ich mit einer halben Sekunden – ist nicht unbedingt schön, aber scheinbar wirkungsvoll.

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.

Verflixte GPIOs

Über die GPIOs des Raspberry Pi habe ich ein Relais-Board angeschlossen. Es manipuliert den Temperatursensor des Solar-Steuerung, um eine automatische Abkühlung des Warmwasserspeichers in der Nacht zu ermöglichen. So versuche ich auch in Hitze-Phasen eine Stagnation in der Solaranlage zu verhindern.

Zur Steuerung kam der ioBroker-Adapter RPI-Monitor (rpi2) zum Einsatz. Nach irgendeinem Update bekam ich diesen aber nicht mehr zum Laufen.

Ständig nur folgender Log-Eintrag:

GPIO is not initialized!

(Das Problem scheint nicht nur bei mir aufzutreten, ein Bug-Report findet sich bei GitHub.)

Einige Stunden Recherche und Probieren später, war ich es leid, und da ein Neuaufsetzen aktuell nicht zur Debatte steht, suchte ich eine andere Möglichkeit. Diese fand ich im exec-Node und wiringPi.

Hinweis: wiringPi wird leider nicht mehr weiterentwickelt, sodass diese Lösung nur mit Raspberry Pi’s bis Modell 3B+ funktioniert. Eine weiter Lösung gibts unter Verflixte GPIOs (2)

Nicht die schönste Variante, aber einfach und wirkungsvoll.

Über die Kommandozeile habe ich einmalig den Modus des entsprechenden GPIO auf „out“ gesetzt.

gpio -g mode 23 out

Nun kann ich über den exec-Node den Status des GPIO auslesen und auch setzen.

Fehlersuche in NodeRED

Macht man seine ersten – oder auch schon etwas intensivere – Schritte im NodeRED, geht nicht alles sofort glatt. Bei mir zumindest.

Häufige Fehler bei mir:

1. Ich baue Endlosschleifen – und nichts geht mehr.

Gerade im Zusammenhang mit NodeRED Dashboard ist es mir immer wieder passiert, dass ich Endlosschleifen gebaut habe.

Allein dieser Aufbau birgt schon das Risiko einer Endlosschleife.

Abhilfe ist einfach. Beim Laden des Variablenwertes den Modus auf „block unless value changes“ setzen.

An anderer Stelle kann auch der report-by-exception – Node (rbe) hilfreich sein. Hier wird jede msg aufgehalten, bis der payload sich unterscheidet.

2. Ich setze statt change ein switch

Eigentlich sind switch und change sehr leicht auseinanderzuhalten. Nur liegen sie in der Palette halt direkt nebeneinander, haben ähnliche Symbole, die gleich Farbe, und möchte man ein Change (ich ändere den Wert einer Variable) einsetzen und setzt stattdessen ein Switch (if then else) fällt auch das Properties Menü kaum negativ auf, sofern man nur kurz die payload verändern will. Mir schon mehrmals passiert – hier lohnt sich ein genauer Blick.

3. Datentypen

Im ioBroker-Adapter NodeRED ist standardmäßig eingestellt, dass alle aus dem ioBroker gelesen Werte in String (Text) umgewandelt werden.

Versucht man dann mit den Werten zu arbeiten, zu rechnen, true und false zu vergleichen, merkt man schnell, entweder muss die Option im Adapter umgestellt werden, oder man muss mit Datentypen jonglieren. In diesem Fall wird der JavaScript function-Node dein Freund.

Zum Beispiel zum Umwandeln einer Zahl (string) in eine „wirkliche“ Zahl (float).

msg.payload=parseFloat(msg.payload);

Wird sicher fortgesetzt …