OpenHAB Binding - Alle WlanThermo Geräte

C

CSchlipp

New member
Hallo zusammen,

mein WlanThermo ist diese Woche angekommen und als begeisterter OpenHAB Nutzer fehlte mir hierzu das Binding.
Nun ist ein ausgewachsenes WlanThermo-Binding herausgekommen, welches ich euch gerne vorstellen möchte!

Motivation:
Es gab zwar erste Ansätze das Thermometer mit den generischen MQTT/HTTP Bindings einzubinden, die waren mir aber zu kompliziert bzw. zu unschön...

Anleitung und Sourcecode:
Die Anleitung is in der OpenHAB Doku enthalten.
Der Sourcecode vom Binding kann im offiziellen OpenHAB Addons Repository eingesehen werden.

Funktionsumfang:
Das Binding greift lokal via HTTP auf das WlanThermo zu und unterstützt aktuell:

WlanThermo Nano V2/V3, Mini V2 (ESP32), Link V1:
Für alle 8 bzw. 24 Sonden:
  • Name (lesen/schreiben)
  • Typ (lesen)
  • aktuelle Temperatur (lesen)
  • Min. Temperatur (lesen/schreiben)
  • Max. Temperatur (lesen/schreiben)
  • Alarm Buzzer an/aus (lesen/schreiben)
  • Push Alarm an/aus (lesen/schreiben)
  • Openhab Alarm Item und Trigger für Min/Max Alarme
  • Farbe (lesen/schreiben)
Für Pitmaster Kanäle:
  • Status
  • Ziel-Temperatur
  • Duty Cycle
  • PID Profil
  • zugeordneter Messkanal
Darüber hinaus können folgende Daten vom Gerät abgerufen werden:
  • Batteriestand
  • Ladezustand (lädt/entlädt)
  • Signalstärke zum Wlan

WlanThermo Mini V1/V2:
Für alle 10 Sonden:
  • Name (lesen)
  • aktuelle Temperatur (lesen)
  • Min. Temperatur (lesen)
  • Max. Temperatur (lesen)
  • Alarm Buzzer an/aus (lesen)
  • Openhab Alarm Item und Trigger für Min/Max Alarme
  • Farbe (lesen)
Für beide Pitmaster Kanäle:
  • Status
  • Aktuelle Temperatur
  • Ziel-Temperatur
  • Duty Cycle
  • Lid-Open Erkennung
  • zugeordneter Messkanal
Darüber hinaus können folgende Daten vom Gerät abgerufen werden:
  • CPU Last
  • CPU Temperatur

Screenshots aus der OpenHAB BasicUI (exemplarisch für den Nano)
wlanthermo_oh_1.pngwlanthermo_oh_2.png

Wenn ihr den Benutzernamen/das Passwort nicht konfigurieren möchtet, sind alle Kanäle nur lesbar. Der Standard-Wert admin/admin ist voreingestellt. Beim WlanThermo Mini sind alle Kanäle nur lesbar.

Stabile Versionen:
OpenHAB 2:
  • Ab Version 2.5.9 direkt über Paper UI
OpenHAB 3:
  • Direkt über die MainUI
Beta (Test) Versionen:
OpenHAB 2:
  • 2.5.11-V1 via Dropbox
    - Support für ESP32-Geräte (Mini V2, Nano V2, Link V1)

Ich freue mich auf eure Rückmeldung!

Viele Grüße
Christian
 
Zuletzt bearbeitet:
C

CSchlipp

New member
Ich habe gerade durch Zufall gesehen, dass der HTTP Endpunkt beim Mini anders ist. HIer muss anscheinend über "/app.php" das aktuelle Json abgerufen werden.
Gibt es dazu auch irgendwo eine Dokumentation?
 
s.ochs

s.ochs

BOFH
Teammitglied
Zumindest bei den Minis mit Raspberry Pi. Soweit mir bekannt ist, müsstest du das entsprechende Skript durchgehen.
 
C

CSchlipp

New member
Hallo zusammen,

die aktuelle Version unterstützt nun auch das WlanThermo Mini inkl Pitmaster, der Link dazu ist im ersten Beitrag.
Ich würde mich über euer Feedback freuen!

Viele Grüße
Christian
 
C

CSchlipp

New member
Hallo zusammen,

es freut mich euch mitteilen zu können, dass das WlanThermo Binding ab sofort in den offiziellen OpenHab Releases enthalten ist!

Ab Version 2.5.9 kann das Binding direkt in Openhab mittels PaperUI installiert werden und muss nicht mehr separat heruntergeladen werden.
Die Dokumentation dazu ist nun auch über die Openhab-Webseite abrufbar: https://www.openhab.org/addons/bindings/wlanthermo/

Wie zuvor würde ich mich über euer Feedback freuen!
 
Zuletzt bearbeitet:
M

Martin Fischer

New member
Hallo,

habe ein Nano V3 angebunden, war mir nicht sich, ob er funktionieren würde, da das Binding wohl nur für V1 getestet ist. . Erhalte nachdem ich die Items angelegt habe, einmal Werte, danach funktioniert nur die Setpoints. Als Fehler bekomme ich nach der Initialisierung:

2020-10-13 10:31:59.219 [ERROR] [ome.core.thing.link.ThingLinkManager] - Exception occurred while informing handler: Index: 0, Size: 0
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:657) ~[?:1.8.0_252]
at java.util.ArrayList.get(ArrayList.java:433) ~[?:1.8.0_252]
at org.openhab.binding.wlanthermo.internal.api.nano.WlanThermoNanoCommandHandler.getState(WlanThermoNanoCommandHandler.java:76) ~[?:?]
at org.openhab.binding.wlanthermo.internal.WlanThermoNanoHandler.handleCommand(WlanThermoNanoHandler.java:119) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.channelLinked(BaseThingHandler.java:191) ~[?:?]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.lambda$0(ThingLinkManager.java:267) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_252]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

Muss ich etwas anderes einstellen, oder liegt es doch an der V3 Version?

Beste Grüße
Martin
 
C

CSchlipp

New member
Hallo Martin,

ich schätze es liegt am V3, hier habe ich bisher noch keine Informationen zu der API.
Ausgehend von der Fehlermeldung würde ich davon ausgehen, dass sich diese leicht verändert hat gegenüber der API vom V1+.

Vielleicht kann @s.ochs hier etwas Licht ins Dunkle bringen? Was hat sich im JSON geändert?

Die Ausgabe von http://<IP.vom.wlan.thermo>/data und http://<IP.vom.wlan.thermo>/settings würde mir möglicherweise helfen einen Unterschied zu finden - gerne auch per PN. Danke!
 
Zuletzt bearbeitet:
s.ochs

s.ochs

BOFH
Teammitglied
Viel hat sich bisher nicht geändert, nur ein paar Teile hinzugekommen. @CSchlipp falls du noch mehr Infos brauchst, sag einfach Bescheid.
 
C

CSchlipp

New member
Danke für die Info, ich gleiche die beiden APIs mal ab. Es sieht aktuell danach aus, als würde der Typ der Temperatursonde etwas anders zurückgegeben als beim V1+.
Ich melde mich sobald ich etwas herausgefunden habe!
 
C

CSchlipp

New member
Ich habe heute die die API vom Nano V1+ und V3 im Hinblick auf den Fehler verglichen. Hier gibt es tatsächlich einen Unterschied bei der Auflistung der Temperatursonden-Typen. Wo der V3 eine Liste mit Id und Name zurückgibt, lieferte der V1+ nur den Namen.
Hier tritt dann im Addon ein Fehler beim Verarbeiten der Daten auf. Das Addon muss damit um einen neuen "Thing"-Typ für den Nano V3 erweitert werden.

Das ist prinzipiell kein Problem, aber...:
Openhab ist gerade mitten im Umbruch von Version 2 auf Version 3, alle Addon-Repositories wurden meines Wissens nach bereits umgestellt.
Änderungen im Addon sind also nur für Openhab 3 machbar, das Plugin für Openhab 2 wird diesbezüglich leider kein Update mehr erhalten.

Gleichzeitig ist V3 noch nicht als stabile Version verfügbar, der erste Milestone Build ist erst vor wenigen Tagen veröffentlicht worden. Ich werde meine Entwicklungsumgebung in der nächsten Zeit entsprechend umstellen und mich mit OH3 beschäftigen - es wird daher leider ein wenig dauern bis ich eine neue Version vom Plugin erstellen kann.

Sobald ich eine erste Test-Version gebaut habe, werde ich sie hier zur Verfügung stellen!
 
Zuletzt bearbeitet:
s.ochs

s.ochs

BOFH
Teammitglied
Richtig, das hat sich geändert. Wobei du es vermutlich anders rum meinst. Beim V1/V1+ ist die Liste der möglichen Sensortypen ein einfaches String-Array, bei den ESP32-Modellen ist es ein Array mit einzelnen JSON Objekten, da wir nun neben dem Namen auch noch Infos zur Verarbeitung brauchen.
 
C

CSchlipp

New member
s.ochs schrieb:
Richtig, das hat sich geändert. Wobei du es vermutlich anders rum meinst. Beim V1/V1+ ist die Liste der möglichen Sensortypen ein einfaches String-Array, bei den ESP32-Modellen ist es ein Array mit einzelnen JSON Objekten, da wir nun neben dem Namen auch noch Infos zur Verarbeitung brauchen.
Zum Vergrößern anklicken....
Ja natürlich. Habe es in meinem Post angepasst! ;)
 
M

Martin Fischer

New member
Hallo Christian,

ist da mit OH 2.10 nichts zu machen, die Bindings sollen doch auch unter Openhab3 kompatibel sein. Würde mich freuen, wenn du da was anpassen könntest.

Viele Grüße
Martin
 
C

CSchlipp

New member
Martin Fischer schrieb:
Hallo Christian,

ist da mit OH 2.10 nichts zu machen, die Bindings sollen doch auch unter Openhab3 kompatibel sein. Würde mich freuen, wenn du da was anpassen könntest.

Viele Grüße
Martin
Zum Vergrößern anklicken....
Hallo Martin,

die technischen Unterschiede bei den Bindings sind zwar bei Weitem nicht so groß wie von OH1 -> OH2, aber ganz ohne Anpassungen sind sie leider auch nicht zwischen OH2 und OH3 kompatibel.

Ich versuche die beiden Versionen möglichst gleich zu halten und auch das 2.5 Binding zu aktualisieren, aber ich kann und möchte da aktuell noch nichts versprechen...
 
C

CSchlipp

New member
s.ochs schrieb:
Viel hat sich bisher nicht geändert, nur ein paar Teile hinzugekommen. @CSchlipp falls du noch mehr Infos brauchst, sag einfach Bescheid.
Zum Vergrößern anklicken....
Hallo Steffen,

ich habe ein paar Probleme mit dem Beispiel-JSON aus dem Wiki, das ist kein gültiger JSON String. Ich kann zwar raten woran es liegt, aber würde lieber auf Nummer sicher gehen.
Könntest du mir den Output von /data und /settings von einem "echten" Nano V3 zukommen lassen?

Vielen Dank!
 
C

CSchlipp

New member
Hallo zusammen,

Ich habe im ersten Post eine erste Beta-Version des Bindings mit Unterstützung für die neuen ESP32-Geräte (Mini V2, Nano V3, Link) verlinkt. Die jar-Datei aus dem .zip kommt ihr in das addons-Verzeichnis von Openhab, danach solltet ihr die neuen Modelle in PaperI hinzufügen können.
Die verlinkte Version sollte für alle Openhab 2.5 Releases, auch < 2.5.11, funktionieren.

Diese Version ist noch weit vom Soll-Zustand entfernt, aber da das Auslesen der Sensoren bereits funktioniert wollte ich es euch nicht vorenthalten.

Welche Änderungen gibt es?
Außer ein paar kleineren Bugfixes ist in dieser Version hauptsächlich die Unterstützung für die neuen Modelle hinzugekommen.

Was fehlt in dieser Version noch?
  • Pitmaster ist noch ungetestet.
  • Link ist noch ungetestet, sollte aber aufgrund der Ähnlichkeit zum Mini funktionieren.
  • Aktuell werden die Kanäle für eventuelle Bluetooth-Sensoren standardmäßig angezeigt, auch wenn keine verbunden sind. Diese Kanäle sollen später dynamisch erzeugt werden.
  • Gleiches gilt für die Kanäle zum Ladezustand, auch diese sollen später dynamisch je nach Gerät erzeugt werden.
  • Der Sensortyp kann noch nicht über OH geändert werden.
Ich freue mich über eure Rückmeldungen!
 
Um antworten zu können musst du eingeloggt sein.
Oben Unten