Nextcloud CalDAV Error 500

Neben SmartHome Themen, gibt es jetzt vielleicht ab und zu auch ein paar Beiträge zu Nextcloud, zum Beispiel diesen Tipp.

Bei meinem Sohn ging die CalDAV-Synchronisation via DAVx5 nicht mehr. Die App warf immer einen Error 500 (PUT /remote.php/dav/calendars/ […]) aus. Alle anderen Nutzer und Kalender hatten diesen Problem nicht, sodass ein generelles Problem ausgeschlossen werden konnte.

Nach einigem hin und her, konnte das Problem auf einen defekten Serientermin eingegrenzt werden. Nach Löschen & Neuanlegen der Serientermine ging es wieder.

(verwendete Nextcloud Version 21.0.5)

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.

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: