

Ich wollte in unserem SmartHome einen regelmäßigen Speedtest unserer Internetverbindung regelmäßig durchführen lassen. Damit wollte ich herausfinden, ob die zugesicherten Bandbreiten unseres Glasfaser-Anschlusses immer eingehalten werden. Da in openHAB 3 automatisch alle Items persistiert werden, war das nach der Umstellung eine gute Möglichkeit.
Die Erste Idee für die Geschwindigkeitsmessung war das Network Binding. Das habe ich aber dann nicht verwendet, da dies eine ISO-Datei für den Test benötigt (das wollte ich so nicht umsetzen).
Im openHAB-Forum habe ich dann eine individuelle Scripting-Lösung auf Basis Speedtest CLI by Ookla gefunden.
Die Umsetzung war dort sehr gut dort beschrieben. Man muss nur die Systemvoraussetzungen beachten, nicht das hier etwas auf dem eigenen System fehlt (das kann zum Teil im Debugging des Scripts etwas aufwändiger sein).
Die Scripte stellen für mich eine sehr runde Lösung dar, die alle Informationen incl. graphischer Aufbereitung / Icons enthält. In openHAB 3.x werden die Daten automatisch persistiert und damit dann auch längerfristig auswertbar gespeichert.
Ein paar Anpassungen für openHAB 3.x mussten durchgeführt werden:
Die Items werden wie folgt definiert:
Group gSpeedtest <"speedtest"> Group gSpeedChart String SpeedtestCharts String SpeedtestSummary "Speedtest [%s]" <"speedtest_summary"> (gSpeedtest, gPersist) Number SpeedtestResultPing "Ping [%.3f ms]" <"speedtest_ping"> (gSpeedtest, gSpeedChart) Number SpeedtestResultDown "Download [%.2f Mbit/s]" <"speedtest_download"> (gSpeedtest, gSpeedChart) Number SpeedtestResultUp "Upload [%.2f Mbit/s]" <"speedtest_upload"> (gSpeedtest, gSpeedChart) String SpeedtestRunning "Speedtest läuft ... [%s]" <"speedtest_run"> (gSpeedtest) Switch SpeedtestRerun "Manuell starten" <"speedtest_reload"> (gSpeedtest) DateTime SpeedtestResultDate "Letzte Ausführung [%1$td.%1$tm.%1$tY, %1$tH:%1$tM]" <"speedtest_date"> (gSpeedtest, gPersist) String SpeedtestResultError "Fehlermeldung [%s]" <"speedtest_error"> (gSpeedtest, gPersist) String SpeedtestResultImage "Bild"
Die Regel steuert dann die gesamte Logik an (hier ist eine automatischer und eine manueller Start möglich). Hier habe ich meine Anpassungen im Kommentar erfasst:
val String ruleId = "Speedtest" val Number calc = 125000 // Converting from bits to Mbits rule "Speedtest init" when System started then createTimer(now.plusSeconds(195)) [| if(SpeedtestRerun.state == NULL) { SpeedtestRerun.postUpdate(OFF) } if(SpeedtestRunning.state == NULL) { SpeedtestRunning.postUpdate("-") } if(SpeedtestSummary.state == NULL || SpeedtestSummary.state == "") { SpeedtestSummary.postUpdate("⁉ (unbekannt)") } ] end rule "Speedtest" when // 1 x am Tag 4 Uhr früh Time cron "0 0 4 * * ?" or //Time cron "0 0/15 * * * ?" or // alle 15 Minuten Item SpeedtestRerun changed from OFF to ON or Item SpeedtestRerun received command ON then //logInfo(ruleId, "--> speedtest executed...") SpeedtestRunning.postUpdate("Messung läuft...") // execute the script, you may have to change the path depending on your system // Please use -f json and not -f json-pretty //val speedtestExecute = "speedtest -f json" // 13.02.2021 - Anpassung damit Lizenz akzeptiert wird //val speedtestExecute = "sudo -u openhab /usr/bin/speedtest -f json --accept-license --accept-gdpr" //val speedtestExecute = "speedtest -f json" //var speedtestCliOutput = executeCommandLine(speedtestExecute, 120*1000) // 13.02.2021 - Anpassung für openHAB 3 var speedtestCliOutput = executeCommandLine(Duration.ofSeconds(120), "speedtest", "-f", "json") // for debugging: //var String speedtestCliOutput = "Ping: 43.32 ms\nDownload: 21.64 Mbit/s\nUpload: 4.27 Mbit/s" logInfo(ruleId, "--> speedtest output:\n" + speedtestCliOutput + "\n\n") SpeedtestRunning.postUpdate("Datenauswertung...") // starts off with a fairly simple error check, should be enough to catch all problems I can think of // 13.02.2021 - Anpassung notwendig zum Beispiel //if (speedtestCliOutput.startsWith("{\"type\":\"result\",") && speedtestCliOutput.endsWith("}}")) if (speedtestCliOutput.startsWith("{\"type\":\"result\",")) { var ping = Float::parseFloat(transform("JSONPATH", "$.ping.latency", speedtestCliOutput)) SpeedtestResultPing.postUpdate(ping) var float down = Float::parseFloat(transform("JSONPATH", "$.download.bandwidth", speedtestCliOutput)) down = (down / calc) SpeedtestResultDown.postUpdate(down) var float up = Float::parseFloat(transform("JSONPATH", "$.upload.bandwidth", speedtestCliOutput)) up = (up / calc) SpeedtestResultUp.postUpdate(up) var String url = transform("JSONPATH", "$.result.url", speedtestCliOutput) val img = url + ".png" SpeedtestResultImage.postUpdate(img) SpeedtestSummary.postUpdate(String::format("ᐁ %.1f Mbit/s ᐃ %.1f Mbit/s (%.0f ms)", down, up, ping)) SpeedtestRunning.postUpdate("-") // update timestamp for last execution val DateTimeType ResultDate = DateTimeType.valueOf(transform("JSONPATH", "$.timestamp", speedtestCliOutput)) SpeedtestResultDate.postUpdate(ResultDate) } else { SpeedtestResultPing.postUpdate(0) SpeedtestResultDown.postUpdate(0) SpeedtestResultUp.postUpdate(0) SpeedtestSummary.postUpdate("(unbekannt)") SpeedtestRunning.postUpdate("Fehler") logError(ruleId, "--> speedtest failed. Output:\n" + speedtestCliOutput + "\n\n") } SpeedtestRerun.postUpdate(OFF) end
Die Visualisierung erfolgt dann in der Sitemap wie folgt:
Text item=SpeedtestSummary icon="speedtest" { Frame label="Ergebnisse" { Text item=SpeedtestResultDown Text item=SpeedtestResultUp Text item=SpeedtestResultPing } Frame label="Steuerung" { Text item=SpeedtestResultDate Text item=SpeedtestRunning label="Speedtest [%s]" visibility=[SpeedtestRunning != "-"] Text item=SpeedtestResultError visibility=[SpeedtestRunning == "Fehler"] Switch item=SpeedtestRerun mappings=[ON="Start"] } Frame label="Statistik" { Switch item=Chart_Zeitraum_D_W_M_Y label="" mappings=[0="Woche", 1="Monat", 2="Jahr"] Chart item=gSpeedtest service="rrd4j" period=W refresh=15000 visibility=[Chart_Zeitraum_D_W_M_Y==0, Chart_Zeitraum_D_W_M_Y=="Uninitialized"] Chart item=gSpeedtest service="rrd4j" period=M refresh=15000 visibility=[Chart_Zeitraum_D_W_M_Y==1] Chart item=gSpeedtest service="rrd4j" period=Y refresh=15000 visibility=[Chart_Zeitraum_D_W_M_Y==2] } }
Damit konnte ich recht einfach die Messung der Bandbreite bei uns zu Hause in openHAB integrieren. Eine schöne Erweiterung wäre noch die Verfügbarkeit des Internetzugangs regelmäßig zu protokollieren.
Wie messt Ihr in eurem SmartHome die Bandbreite eurer Internetverbindung? Habt Ihr eine bessere Variante als diese manuelle Scripting-Lösung?
Am 23.04.2021 wurde ein neues Update für openHAB veröffentlicht. Die Version 3.0.2 ist notwendig da Bintray zum 01.05.2021 nicht mehr zur Verfügung steht und ein Wechsel auf Artifactory notwendig ist.
Die Version 3.0.2 ist wieder komplett kompatibel zu den vorherigen 3.0.x Versionen.
Es gab mit der neuen Version ca. 25 Bugfixes im System und den bestehenden Plugins. In den Release Notes werden die Änderungen kurz und im GitHub dann im Detail beschrieben.
Ich habe mein System von 3.0.1 auf 3.0.2 ohne weitere Probleme wie folgt umgestellt. Integriertes Backup durchführen und zusätzlich noch eine manuelle Datensicherung ausführen:
sudo $OPENHAB_RUNTIME/bin/backup /var/lib/openhab/backups/
Danach dann das eigentliche Update durchführen:
sudo systemctl stop openhab.service sudo apt-get update sudo apt-get upgrade
Und im Nachgang noch den Cache leeren und das System wieder starten:
sudo systemctl stop openhab.service sudo openhab-cli clean-cache sudo shutdown -r now
Wenn man sich auf dem aktuellen 3er-Releasezweig befindet, ist ein Update recht einfach möglich. Es handelt sich aus meiner Sicht um ein reines Bugfix-Release und Instrastruktur-Update. In meinem Fall ging es ohne unvorhergesehene Probleme und manuellen Anpassungen vor sich. Wie liefen eure Updates auf openHAB 3.0.2? Gibt es Anpassungen auf die Ihr gewartet habt?
Als Ersatzgerät für unser „Esszimmer-Tablet“ haben wir uns ein Amazon Fire HD10 in der 9. Generation gekauft. Bei den Oster-Angeboten gab es da einen guten „Schnapper“. 🙂
Mit der Fire Toolbox ist es recht einfach möglich, den Google Play Store und weitere Services auf dem Gerät zu installieren.
Welche Funktionen nutzt Ihr aus der Fire Toolbox?
Ich habe einen Anwendungsfall in unserem SmartHome, der scheinbar nicht so gängig ist. 🙂
Wenn mein BEDDI-Wecker beim Aufstehen klingelt, soll das Licht langsam gedimmt werden. Das hat mit dem Smarten Wecker und openHAB 2.x mit der Classic-UI per HTTP-Aufruf gut funktioniert. In openHAB 3.x ist die Classic-UI nun nicht mehr dabei. Der BEDDI-Wecker kann nur HTTP-Aufrufe direkt durchführen und hat sonst keine andere Schnittstelle zur Verfügung.
Ich wollte also mit openHAB 3.x wieder Items direkt per HTTP steuern und integrieren (ja mir ist das „Sicherheitsrisiko“ bewusst).
Die erste Idee habe ich hier gefunden: https://community.openhab.org/t/external-link-towards-openhab-item/48227/4. Das hat auch im Browser gut funktioniert, aber nicht auf dem BEDDI.
Dann habe ich eine Lösung auf Basis NGINX gefunden (den hatte ich wegen der HueEmulation + Alexa schon installiert). Die Lösung wird hier im Forum beschrieben: https://community.openhab.org/t/how-to-change-an-openhab-switch-with-http-commands/35063/8.
Die Lösung war aber noch auf Basis openHAB 2 und hat mit 3.x nicht direkt funktioniert. Hier ist die Lösung die ich bei mir nun im Einsatz habe:
location ~ /statechanger/POST/([^/]+)/([^/]+) { proxy_pass http://IP:PORT/rest/items/$1; proxy_set_header content-type "text/plain"; proxy_set_header accept "application/json"; proxy_method POST; proxy_set_body $2; } location ~ /statechanger/PUT/([^/]+)/([^/]+) { proxy_pass http://IP:PORT/rest/items/$1/state; proxy_set_header content-type "text/plain"; proxy_set_header accept "application/json"; proxy_method PUT; proxy_set_body $2; }
Für die Verwendung mit openHAB 3.x musste ich noch die Header entsprechend anpssen. Hier waren der content-type und das accept wichtig.
So konnte man mit den vorhandenen bereits installierten Komponenten auch direkt eine HTTP-Steuerung von außen der openHAB-Items wieder reaktivieren.
Habt Ihr das Szenario bei euch im SmartHome auch? Oder bin ich der Einzige der openHAB-Items außerhalb des Systems aktivieren möchte?
Pünktlich zur Saison-Zulassung am 01.04.2021 gibt es neue Zulassungszahlen des VW Corrado. Covid-bedingt gibt es aktuell aber nur die Zahlen aus 2020, die 2021er Zahlen sind noch nicht verfügbar. Hier sind im VW Corrado Forum die Zahlen des Kraftfahrt-Bundesamts (KBA) veröffentlicht worden.
Zum Stichtag 01.01.2020 haben sich die Zulassungen in Deutschland wie folgt verteilt:
Der Gesamtbestand sinkt also von 5.111 Corrados (2019) auf 5.022 Corrados (2020). Das ist ein Verlust von -1,75% oder 89 Fahrzeugen.
Zum Glück steht unser Corrado noch gut da und hat es nicht mehr lang bis zum H-Kennzeichen. Wer hat mit dem Oldtimer-Kennzeichen bereits Erfahrungen gesammelt?
Die letzten Wochen habe ich mich mit der Umstellung auf openHAB 3.x beschäftigt. Die erste Idee war eine „schleichende Umstellung“ per Remote openHAB Binding. Diesen Pfad habe ich dann wegen der Gesamtumstellung und dem Hardwarwechsel auf einem neuen Raspberry Pi 4 doch ausgeschlossen. Es war für mich einfacher beide Systeme parallel zu betreiben und Schritt für Schritt die notwendigen Konfigurationen zu übernehmen.
Den Aufwand der kompletten Übernahme und des kompletten Refactorings unserer eingesetzten Systeme habe ich dann doch etwas unterschätzt. Wir hatten noch viele openHAB 1.x Elemente im Betrieb, die nicht mehr mit der neuen Version kompatibel sind.
Der erste große Tipp: Im Idealfall gleich vorab die openHAB 2.x Systeme um die 1.x Bindings „bereinigen“.
Ich habe dann gleich auf auf openHAB 3.0.1 aktualisiert. Die Release Notes zur 3.0.1 findet ihr hier.
Ich hatte erst openHAB 3.0 im Testbetrieb und habe dann ca. 6 Wochen eine Testphase für die Umstellung aller Funktionen aus openHAB 2.x immer mal Abends und nebenbei vollzogen. Es wurden alle bestehenden Funktionen noch einmal kontrolliert und vor der Übernahme auf Notwendigkeit bzw. Weiterverwendung geprüft. Über die Jahre sammeln sich doch einige Altlasten an. 🙂
Der zweite große Tipp: Aufräumen wo es geht und nicht genutzte Funktionen aus dem Gesamtsystem entfernen.
Für die Umstellung hatte ich viele kleine Zwischenschritte und aufwändige Tests wegen meinem Umzug und dem kompletten Refactoring geplant. Für die meisten sollte das Update ohne Hardwarewechsel direkt und einfach möglich sein.
Viele Bindings und Funktionen die ich nicht explizit erwähne gingen sehr schnell und einfach bei der Umstellung.
Beim Einsatz von alten 1.x-Funktionen (Legacy-Bindings) sollte man auf alle Fälle vorab den Aufwand beim Wechsel auf openHAB 3.x investieren.
Mittlerweile auch schon wieder neue Erweiterungen eingebaut:
Von den neuen openHAB 3.x Funktionen habe ich noch wenig genutzt. Mich interessiert sehr das neue „Model“ und die verbesserte Visualisierung. Habt Ihr das schon im Einsatz?
Unser openHAB-System ist im SmartHome schon etwas „länger am Start“. Aufgrund der Datensicherheit wäre ein Wechsel der integrierten SD-Karte bald an der Reihe gewesen. Aus diesem Grund wollte ich das gesamte System auf eine neue Hardware-Basis bringen. Außerdem soll dem openHAB 3 System nach dem Wechsel auch mehr Arbeitsspeicher zur Verfügung stehen.
Als Basis wurde ein Raspberry Pi 4 Modell B mit 4 GB Arbeitsspeicher und 32 GB SD-Karte verwendet. Das verwendete Paket kann man sich bei Amazon bestellen.
Nach dem manueller Zusammenbau der Hardware sieht das Ergebnis wie folgt aus:
Für openHAB 3.x verwende ich ein Raspberry Pi OS Lite und führe einen manuellen Neuaufbau des Systems durch.
Ich habe mich dabei für eine komplette Neuinstallation als Migrationspfad von openHAB entschieden. Da das System schon etwas länger benutzt wird, möchte ich in diesem Schritt das System bereinigen und aussortieren. Ich habe noch viele alte 1.x-Bindings im Einsatz und diese funktionieren mit openHAB 3.x nicht mehr. Bis alles umgezogen und getestet ist, wird ein Parallelbetrieb von beiden Systemen durchgeführt.
Ich werde in den nächsten Blog-Beiträgen den Umzug etwas genauer beschreiben. Welche Informationen wären hierbei für euch interessant und wichtig?
Am 21.12.2020 wurde die neue Version 3.0 von openHAB als kleines „Weihnachtsgeschenk“ veröffentlicht. Ich habe mich seit Ende Dezember 2020 etwas intensiver mit dem System beschäftigt (in meinem konkreten Szenario ist der Umstieg etwas aufwändiger).
Die Ankündigung im Blog zur Version findet Ihr hier und im Community-Forum gab es auch einen schönen Beitrag dazu „openHAB 3.0 is out!“. Hier könnt Ihr die aktuelle Version beziehen. Die Release Notes mit allen Details findet man im GitHub. Bitte beachtet in der Dokumentation folgende Punkte: „structural changes, new features, enhanhancements and bug fixes“ und die Breaking Changes.
Folgende Funktionen werden in der Ankündigung als „Highlights“ benannt:
Die 2.5.x Versionen werden für sicherheitskritische Punkte in den nächsten Monaten noch mit Updates versorgt. Alle 6 Monate soll ein Major-Release der 3.x-Linie erfolgen d.h. Sommer 2021 grob eine Version 3.1.
Ich habe mich entschieden die Hardware-Plattform von einem Raspberry Pi 3 auf 4 zu wechseln und damit das System komplett neu aufzusetzen. Über das „openHAB Remote Binding“ möchte ich meine alte 2.5.x Installation anbinden und schleichend die Konfigurationen übernehmen und testen. Das ist zwar mehr Aufwand, aber ich habe noch einige alte Konfigurationen und Bindings vor der Umstellung entsprechend testen. Außerdem „Never change a running system!“ bzw. auf das erste „Service Pack“ würde ich bei einem Major-Release immer abwarten. 🙂
Wie sehen eure Migrationspfade aus? Welche Neuerungen helfen euch in openHAB 3 weiter?