openHAB 3.2.0 ist auf dem Weg …

Aktuell bin ich noch in bei uns zu Hause auf openHAB 3.0. Die Version 3.1 konnte ich noch nicht testen und implementieren.

Parallel sind die openHAB-Verantwortlichen aber fleißig und erstellen die Version 3.2.0:

Zum 10.10.2021 war der Milestone 3 veröffentlicht. Ich denke eine Release-Version ist von den Entwickler wieder grob Ende 2021 geplant.

Es gibt natürlich wieder viele Neuerungen, Bugfixes und neue Add-Ons. Ich denke der Community Marketplace als Add-on Service ist die größte Neuerung des Systems.

Welche Neuerungen sind für euch in openHAB 3.2.0 wichtig? Auf welche Anpassungen freut Ihr euch schon?

Smart Meter in openHAB integrieren

Im Januar 2021 haben wir eine Moderne Messeinrichtung von bayernwerk, also einen intelligenten Zähler bekommen. Das Thema hatte ich hier kurz dargestellt: „Intelligenter Zähler“ jetzt auch bei uns 🙂

Es handelt sich hier um den Smart Meter Gateway (SMGW) von Itron / PPC. In den letzten Monaten habe ich versucht den SMGW in unser Smart Home einzubinden. 

Mit den Stichworten „TRuDI“ und „HAN“ kommt man im openHAB-Universum leider nicht weit. Im openHAB-Forum habe ich dann diesen Hinweis bekommen – LINK. Hier wird als Smart Home Integration ein Beispiel für openHAB verwendet. Leider ist für mich nicht ersichtlich welche Bindings dort verwendet wurden. Eine Integration in openHAB ist somit aktuell noch etwas weit weg.

Ich habe aktuell auch noch Probleme in der Verwendung mit dem bayernwerk-Portal. Ein Excel-Export der zurückgemeldeten Daten funktioniert aber schon. Im nächsten Schritt werden ich versuchen durch Rückfragen bei bayernwerk das System auch Extern ansprechen zu können. Dann kann ich mir weitere Gedanken über die openHAB-Integration machen.

Habt Ihr euren Smart Meter schon in openHAB integriert? Gibt es dazu Praxisbeispiele und Informationen?

openHAB 3.1 – Was ist neu?

Beim openHAB 3.0 Release-Blog wurde die Version 3.1 für den Sommer 2021 angekündigt.

Am 28.06.2021 wurde dann die finale Version veröffentlicht. Die Version ist komplett kompatibel zum 3.0 Release.

Anfang Juni 2021 wurde auch bereits der openHAB 3.1.0 Milestone 5 veröffentlicht. Der 3.1 GA Release ist für den Ende Juni 2021 geplant. 

Im Juni waren noch wenige Neuerungen bekannt, außer man ließt alle Milestone-Changes durch:

Hier gibt es im Forum über die Milestones ein paar weiterführende Diskussionen: LINK.

Wie ich gesehen habe, gibt es viele neue Addons: Ich habe ca. 50 Stück in den Milestone-Builds grob gesehen. Bei den Add-ons gab es hauptsächlich Erweiterungen und Fehlerbehebungen (hier habe ich am meisten Änderungen gesehen, das muss man sich für seine eigene Umgebung ansehen). In der Runtime gab es auch diverse Erweiterungen und Fehlerbehebungen. Auch das User Interfaces wurde erweitert und entsprechend gefixt. 

Außerdem gab es 3 Breaking Changes in bestimmten Add-ons d.h. das bitte genau anschauen. 

Aus meiner Sicht sind sehr viele und gute Detailverbesserungen vorhanden. 

Welche Verbesserungen in openHAB 3.1 sind für eure Umgebung interessant? Auf was wartet ihr ganz gespannt?

 

 

Routinen mit openHAB und Amazon Alexa

Per Zufall bin ich in der Amazon Alexa App auf die Funktionalität der Routinen gestoßen. Eigentlich bilde ich die gesamte Logik unseres SmartHome in openHAB ab, aber wegen der vereinfachten Befehlskette wollte ich es auch einmal direkt per Alexa testen.

Zum St. Patricks Day gab es ein paar „Dekorationsanforderungen“ bei uns im Haus, die eine manuelle Aktivierung notwendig gemacht haben.

Items

Im ersten Schritt werden „virtuelle Items“ in openHAB konfiguriert, damit diese auch in der Alexa App verwendet werden können. Die Konfiguration führe ich (wie immer) in der textuellen Konfiguration durch.

// St. Patricks Beleuchtung per Alexa Routine, 07.03.2021
Switch Koboldbeleuchtung_Ein "Ich bin ein Kobold" [ "Lighting" ]
Switch Koboldbeleuchtung_Aus "Ich bin kein Kobold" [ "Lighting" ]

Rules

Die Aktivierung und die Deaktivierung möchte ich dann über eine Regel in openHAB steuern und die notwendigen Geräte aktivieren / deaktivieren.

rule "Kobold Routine Ein"
    when
        Item Koboldbeleuchtung_Ein received command
    then
        if (receivedCommand == ON) {
            // Gewünschte Aktionen durchführen
            logInfo("INFO","Koboldroutine eingeschalten")
        }   
end

rule "Kobold Routine Aus"
    when
        Item Koboldbeleuchtung_Aus received command
    then
        if (receivedCommand == ON) {
            // Gewünschte Aktionen durchführen
            logInfo("INFO","Koboldroutine ausgeschalten")
        }
end

Amazon Alexa App

Im letzten Schritt wird dann die Alexa-Konfiguration in der App wie folgt vorgenommen:

  • Alexa App – Mehr – Routinen – Routine erstellen
  • Wenn (der Satz gesprochen wird): Alexa, Ich bin ein Kobold
  • Aktion ausführen: Smart Home – Alle Geräte – „Virtuelles Item“: Ich bin ein Kobold – AN schalten

Das sieht graphisch wie folgt aus:

Zusammenfassung

Die Alexa Routinen sind sehr schnell und einfach eingerichtet. Ob sich der Aufwand lohnt, um nur das „schalte“ Aktivierungswort zu umgehen, muss jeder selbst entscheiden.

Es gibt aber interessante Routinen-Vorschläge, die man sich einmal ansehen kann.

Da ich meine Logiken alle eher zentral in openHAB, anstatt verteilt auf diverse Systeme abbilden möchte, ist es eher nicht für meinen Anwendungsfall geeignet. Aber ein netter Versuch war es auf alle Fälle. 🙂

DWD Unwetter Anbindung mit openHAB

In diesem Artikel habe ich beschrieben, wie man die Unwetterdaten vom DWD in openHAB per Scripting-Lösung integriert:

Beim Umstieg auf openHAB 3 wollte ich anstatt der eigenen Scripting-Lösung auf die integrierte Binding-Variante wechseln.

Ich musste aber Anfang Januar 2021 (openHAB 3.0) und im Mai 2021 (openHAB 3.0.2) feststellen, dass die Variante mit dem Binding bei mir nicht funktioniert und keine Unwetterdaten visualisiert.

Auch wenn ich  mit der richtigen WARNCELLID Unwetterwarnungen bekommen sollten, werden diese (aus meiner Sicht) trotz korrekter Konfiguration nicht in openHAB angezeigt. Leider habe ich im openHAB-Forum dazu auch keine Lösung gefunden. Auch in den DEBUG-Meldungen ist leider nichts weiterführendes an Informationen ersichtlich. 

Hat jemand das DWD Unwetter Binding in openHAB 3 schon einmal erfolgreich eingerichtet? Kann jemand dazu Erfahrungswerte teilen?

Speedtest der Internetverbindung mit openHAB regelmäßig durchführen

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:

SpeedTest.items

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"

SpeedTest.rules

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

Sitemap

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]
            }
        }

Fazit

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?

openHAB 3.0.2 veröffentlicht

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.

Update 3.0.1 auf 3.0.2

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

Fazit

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?  

Amazon Fire Tablet mit Google Play Store

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?

 

Direkter Aufruf von Items in openHAB 3 (ohne Classic-UI)

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?

Umstellung openHAB 2 auf 3.0.1 – Tipps & Tricks

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.

Übernahme unserer Funktionen

  1. Die Persistence ist jetzt im Standard dabei d.h. alle Items werden langfristig in der rrd4j Round-Robin-Database gespeichert. Die Übernahme der gespeicherten Datenbankdateien geht einfach per Copy & Paste.
  2. Die KNW-Umstellung von 1.x auf 3.x hat am meisten Zeit benötigt. Wir haben im eine KNX-Installation vorhanden. Da hier etwas mehr Aufwand in der Umstellung notwendig war, habe ich das etwas länger vor mir hergeschoben. Mit ruhigen 2 Std. und etwas Konzentration war es aber dann doch nicht so aufwändig. Ich habe mich an diesen Umstellungspfad gehalten.
  3. Das Amazon Echo Control Binding verwenden wir recht intensiv. Hier hatten wir wegen diverser Umstellungen immer noch den SnapShot von 2.x im Einsatz. Jetzt hat der Wechsel auf die Release Version einfach funktioniert.
  4. Die Hue Emulation mit openHAB 3.x ist für Alexa / Amazon zwingend notwendig. Das hier jetzt NGINX auf Port 80 benötigt wird war mir unklar. Da hab ich etwas länger gesucht 🙂
  5. MQTT musste ich nur von 2.x auf 3.x umziehen. Aber man benötigt jetzt einen externen MQTT-Broker. Ich habe also auf Mosquitto gewechselt, da der „Embedded“ nicht mehr vorhanden ist.
  6. Das Weather-Binding gab es auch nicht mehr. Hier habe ich auf  Darksky-Binding umgestellt.
  7. Das FritzBox-Binding war auch noch aus alter Welt. In der neuen Welt benötigt man jetzt das TR-064-Binding und AVM FRITZ! Binding.
  8. Das CalDAV-Binding aus 1.x ist auch nicht mehr vorhanden – auf iCalendar-Binding kann man einfach umstellen

Fazit der Umstellung

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:

  • Tankerkönig mit Telgram-Anbindung
  • Speedtest des Glasfaseranschlusses im Up- und Download

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?