Plugin: BWT Aqua Anbindung Wasserenthärter

[Pezi]

Hallo zusammen,
Ich habe gerade die neue Version 2.0203 auf mein Gerät gesendet bekommen. Das Problem der Salzfüllstandsmessung ist behoben. Super Kunden-Support!

Laut BWT Schweiz sind die wesentlichen Änderungen im GUI:
- API ist im Menü an und ausschaltbar
- der Name des EnOcean Sensors wird in der Meldung angezeigt (entscheidend wenn mehrere eingesetzt werden)
- Ping wurde verbessert (echter Ping ins Internet anstatt Abfrage an BWT Cloud)
- im Menü ist zu sehen, wann die nächste Wartungen anstehen
- Filter und Enthärter lassen sich synchronisieren

Soweit ich dies mitbekommen habe, wird gerade nicht an weiteren Funktionen der API gearbeitet, da erst einmal andere Funktionen Priorität haben. Ich werde diesbezüglich aber dran bleiben.

[stefb]

sehr fein... vielen Dank fürs Update

[RHC]

Das sind gute Nachrichten - thx! Bleibt nur noch die Frage, wie man zu der neuen Firmware-Version kommt - muss man direkt mit BWT in Kontakt treten um diese zu erhalten?

[Pezi]

Ja, ich habe direkt mit BWT Kontakt aufgenommen.

[Hintertupfing]

Hab heute früh den Kundendienst angeschrieben wegen Firmware 2.0203.
Die Bestätigungsmail ist bereit eingetroffen und die Firmware ist auf meiner Perla aufgespielt.

[RHC]

ab heute früh den Kundendienst angeschrieben wegen Firmware 2.0203.
Die Bestätigungsmail ist bereit eingetroffen und die Firmware ist auf meiner Perla aufgespielt.

Bei mir genau gleich - gestern BWT angeschrieben und vorhin habe ich ein Mail erhalten, dass Version 2.0203 aufgespielt wurde. Über die BWT Home-App (welche ich momentan noch aktiviert habe) sehe ich auch, dass meine Anlage nun mit dieser Version läuft.

Mich irritiert nur, dass die App nun 0% Füllstand, aber einen Vorrat von 107 Tagen anzeigt. Ich muss mir dann am Abend zuhause ansehen, was direkt am Display steht bzw. ob das nur ein Fehler in der App ist. Da Pezi aber von einem Problem mit der Salzfüllstandsmessung in der vorherigen Version gesprochen hat, läuten bei mir schon wieder die Alarmglocken. Mal schauen, was dann tatsächlich auf der Anlage los ist...

[RHC]

Entwarnung - ich war vorhin kurz zuhause und hab mir mal die Werte am lokalen Display angesehen - dort war alles normal (auch der Füllstand). Ich habe dann nochmal auf die BWT App geschaut und dort wurde nun auch der korrekte Füllstand angezeigt - dürfte wohl nur eine Verzögerung der Aktualisierung nach dem Firmware-Update gewesen sein.

Ich habe auch den neuen Menü-Punkt für die Aktivierung der API gefunden und gleich mal aktiviert. Mir ist auch positiv aufgefallen, dass die Display-Bedienung am Gerät nun sehr flüssig funktioniert, was bei der alten Firmware nicht so war (es gab merkliche Latenz).

Ich habe auf Nachfrage von BWT nun auch die Doku zur aktuellen API bekommen. Was mir schon mal nicht gefällt ist, dass scheinbar keine Befehle für die Aktivierung des Urlaubsmodus vorgesehen sind (ich habe mir gerade Shelly Wassermelder bestellt und wollte bei Wasser-Detektion automatisch in den Urlaubsmodus = "Wasser aus" schalten). Ich habe disbezüglich nochmal beim Techniker nachgefragt und warte noch auf eine Antwort.

Ich weiß auch noch nicht, welchen Key man für die Authentifizierung verwenden muss - ist das derselbe den man für die Portal-API anfordern konnte?

[RHC]

Habe soeben folgende Infos von den Entwicklern erhalten:

API-Passwort:

Bei dem Passwort handelt es sich um das Customer Password bzw. Login Code, welches man bei der Registrierung per Mail mit dem WPA2 Key bekommt.

Auf die Frage, ob auch noch PUT-Befehle wie z.B. der Urlaubsmodus implementiert werden:

Wir starten jetzt im 1. Schritt nur mit GET-Befehlen, also man kann aktuell nur Daten in definierter Form auslesen. PUT-Befehle werden in Zukunft evtl. kommen, wir haben das bereits auf unserer Liste möglicher Neuerungen für kommende Firmware-Versionen. Eine Zeitschiene können wir aktuell noch nicht nennen.

[RHC]

So - habe jetzt mal in Loxone die entsprechenden virtuellen HTTP Eingangs-Befehle angelegt und kann nun sämtliche Daten aus meiner BWT-Anlage direkt auslesen.

Wenn der Befehl für den Urlaubsmodus noch irgendwann in der Firmware implementiert wird, bin ich glücklich...

[bazzman]

Hab die neue Version auch seit einigen Tagen. Das API ist OK und ein Schritt in die richtige Richtung, aber aus meiner Sicht gäbe es noch etwas Optimierungspotential. Im Vergleich zum alten API fehlen noch einige Werte und andere Werte sind im Namen resp. Format nicht richtig konsistent. Irgendwie merkt man der API an, dass der letzte Feinschliff fehlt. Ich hatte dazu eine Mail mit Vorschlägen an BWT gesendet aber leider keine Rückmeldung dazu erhalten.

Integration in Loxone ist OK bis auf die Werte welche als Text vorliegen, diese lassen sich nicht via HTTP Eingang einspielen. Dafür müsste man leider erneut den Weg via Loxberry Plugin gehen, ich weiss aber noch nicht ob ich mal dazu komme das Plugin entsprechend anzupassen.

Und ja, die POST Befehle fehlen mir auch noch - allerdings als Sicherheitsfunktion empfehle ich eher die BWT AquaStop (Enocean) Sensoren zu nutzen, damit läuft die Wasser-Sperre autonom ohne Loxone dazwischen zu schalten.

Mal sehen was seitens BWT noch kommt, immerhin gehts mit der lokalen API ohne Cloud Zwang in eine gute Richtung.

Grüsse
Paolo

[RHC]

Hab die neue Version auch seit einigen Tagen. Das API ist OK und ein Schritt in die richtige Richtung, aber aus meiner Sicht gäbe es noch etwas Optimierungspotential. Im Vergleich zum alten API fehlen noch einige Werte und andere Werte sind im Namen resp. Format nicht richtig konsistent. Irgendwie merkt man der API an, dass der letzte Feinschliff fehlt. Ich hatte dazu eine Mail mit Vorschlägen an BWT gesendet aber leider keine Rückmeldung dazu erhalten.

Die Bezeichnungen und Formate der einzelnen Elemente sind in der Tat nicht ganz konsistent. Aber welche Werte fehlen dir letztendlich? Für mich sind eigentlich nur die Verbräuche, der Füllstand vom Salz und die Störmeldung interessant und diese Werte bekomme ich - alle anderen Daten sind für mich entbehrlich.

Integration in Loxone ist OK bis auf die Werte welche als Text vorliegen, diese lassen sich nicht via HTTP Eingang einspielen. Dafür müsste man leider erneut den Weg via Loxberry Plugin gehen, ich weiss aber noch nicht ob ich mal dazu komme das Plugin entsprechend anzupassen.

Als Texte liegen eigentlich nur die Datumsangaben vom letztem Service und von letzter Regenerierung vor - diese Informationen sind für mich in der Loxone App auch untinteressant und zur Not könnte man sich die Texte auch aus den einzelnen ASCII-Zeichen zusammenbasteln.

Und ja, die POST Befehle fehlen mir auch noch - allerdings als Sicherheitsfunktion empfehle ich eher die BWT AquaStop (Enocean) Sensoren zu nutzen, damit läuft die Wasser-Sperre autonom ohne Loxone dazwischen zu schalten.

Zu dem Preis von einem Aqa Guard Sensor bekomme ich 5 Stk. Shelly Flood und da ich mehrere WLAN-APs im Haus habe, habe ich auch überallhin eine stabile Kommunikation. Mit EnOcean würde ich ohne zusätzlichen Repeater ziemlich sicher keine Anbindung von dem weitest entfernten Raum (ca. 20m über ein Geschoss und mehrere Wände hindurch) schaffen - einziger Vorteil wäre die Funktion ohne Batterie...
Ein POST-Befehl für den Urlaubsmodus wäre daher für mich noch sehr interessant.

[bazzman]

Die Bezeichnungen und Formate der einzelnen Elemente sind in der Tat nicht ganz konsistent. Aber welche Werte fehlen dir letztendlich? Für mich sind eigentlich nur die Verbräuche, der Füllstand vom Salz und die Störmeldung interessant und diese Werte bekomme ich - alle anderen Daten sind für mich entbehrlich.

Entbehrlich ja, aber trotzdem schade dass verfügbare Werte nicht exponiert werden.

Im Vergleich zu den bislang lokal abrufbaren Daten im alten API enthält das neue API die folgenden Werte nicht mehr:

• Aktuelle Leistung in Prozent (dieser Wert wird auf dem Gerät/im Browser auf der Startseite direkt unter Aktueller Durchfluss angezeigt)
• Restkapazität Säule 1 in Liter (dieser Wert wird auf dem Gerät/im Browser unter Gerätestatus angezeigt)
• Restkapazität Säule 2 in Liter (dieser Wert wird auf dem Gerät/im Browser unter Gerätestatus angezeigt)
• Regenerationsschritt Säule 1: "Betrieb" (dieser Wert wird auf dem Gerät/im Browser unter Gerätestatus angezeigt)
• Regenerationsschritt Säule 1: "Betrieb" (dieser Wert wird auf dem Gerät/im Browser unter Gerätestatus angezeigt)

Als Texte liegen eigentlich nur die Datumsangaben vom letztem Service und von letzter Regenerierung vor - diese Informationen sind für mich in der Loxone App auch untinteressant und zur Not könnte man sich die Texte auch aus den einzelnen ASCII-Zeichen zusammenbasteln.

Daten zur letzten Regenerierung und Service wären schon spannend auf einen Blick zu haben, aber natürlich entbehrlich und aktuell kein Grund mein Plugin zu reaktivieren.

Zu dem Preis von einem Aqa Guard Sensor bekomme ich 5 Stk. Shelly Flood und da ich mehrere WLAN-APs im Haus habe, habe ich auch überallhin eine stabile Kommunikation. Mit EnOcean würde ich ohne zusätzlichen Repeater ziemlich sicher keine Anbindung von dem weitest entfernten Raum (ca. 20m über ein Geschoss und mehrere Wände hindurch) schaffen - einziger Vorteil wäre die Funktion ohne Batterie...
Ein POST-Befehl für den Urlaubsmodus wäre daher für mich noch sehr interessant.

Ich hatte die Sensoren zusammen mit der Anlage günstig erhalten und daher nie Alternativen geprüft. Ein Wasser-Sensor (mit Kabel) ist bei mir auch direkt an der Anlage dran.
EnOcean nutze ich auch für Fenstersensoren und hier komme ich mit eine Empfänger im EG im ganzen Haus (EG/OG/DG) gut zurecht.

POST-Befehl für Urlaub: Wenn du das schon jetzt haben möchtest, die BWT Cloud API hat die Funktion mit drin: https://bwt-real-smarthome-backend.azurewebsites.net/
Da sind (gemäss Doc) zwei Endpunkte für enable/disable Holiday Mode verfügbar. Hatte die Cloud API mal getestet aber nur die GET Funktionen.

Grüsse
Paolo

[RHC]

POST-Befehl für Urlaub: Wenn du das schon jetzt haben möchtest, die BWT Cloud API hat die Funktion mit drin: https://bwt-real-smarthome-backend.azurewebsites.net/
Da sind (gemäss Doc) zwei Endpunkte für enable/disable Holiday Mode verfügbar. Hatte die Cloud API mal getestet aber nur die GET Funktionen.

Ich hatte die Cloud-API auch mal mit den GET Funktionen getestet (allerdings nur mit dem swagger). Allerdings ist die Cloud-Variante aus folgenden Gründen keine Alternative:

• Ich will möglichst keine Cloud-Verbindungen (ich habe an meinen Shellys auch sämtliche Cloud-Funktionalität deaktiviert und sperre für diese Geräte auch den Internetzugang in meiner Firewall
• Eine direkte Anbindung von Loxone an die Cloud-API ist wegen der Header-Authentifizierung gar nicht möglich
• Ich glaube auch irgendwo gelesen zu haben, dass die dokumentierten POST-Befehle in der Cloud-API gar nicht funktionieren

Ich habe gestern 3 Stk. Shelly Floods erhalten und diese sehr schnell in mein System eingebunden. Die Melder fangen wirklich ohne Verzögerung sofort an zu piepsen, wenn Wasserkontakt erfolgt (was auch ein Vorteil gegenüber EnOcean- oder Loxone-Meldern ist). Die Alarmierung an Loxone (über UDP eingerichtet) erfolgt auch unmittelbar danach.

Zusätzlich bekomme ich den Batteriestatus und die Fußbodentemperatur übermittelt. Für einen Stück-Preis von knapp über 20€ bin ich echt begeistert - vor allem nehmen die Melder im Gegensatz zu den Loxone Wassersensoren nach Wasserkontakt nicht gleich Schaden... Jetzt wäre es halt noch schön, wenn ich über meine BWT-Anlage die Wasserzufuhr abdrehen könnte und dazu müsste ich halt den Urlaubsmodus über die API aktivieren können... Leider gibt es auch keinen elektrischen Eingäng am Gerät, um diese Funktion auszulösen (sonst könnte ich es hart auf einen Loxone-Relaisausgang verdrahten).

[Paz]

Hola!

Ich möchte mich kurz über den Stand der Cloud-Version informieren, da ich im Git nix dazu gefunden habe. Ist das noch in Entwicklung oder kann man davon schon was nutzen?
Die lokale API ist ja einerseits direkt aus Loxone wegen der Authentifizierung nicht möglich (Juhuuu, Loxone?!), andererseits fehlen ja noch die Post Kommandos - insofern wäre das zumindest ein Ansatz...

Danke und viele Grüsse,
Patrick

[bazzman]

Hi Patrick

Ich möchte mich kurz über den Stand der Cloud-Version informieren, da ich im Git nix dazu gefunden habe. Ist das noch in Entwicklung oder kann man davon schon was nutzen?
Die lokale API ist ja einerseits direkt aus Loxone wegen der Authentifizierung nicht möglich (Juhuuu, Loxone?!), andererseits fehlen ja noch die Post Kommandos - insofern wäre das zumindest ein Ansatz...

Aktuell investiere ich keine weitere Zeit in die Cloud Version - ich bin bei Smarthome Anwendungen generell nicht wahnsinniger Cloud-Fan, sehe es nicht ein meine Daten via Cloud wieder abzuholen wenn es einen direkten Weg gibt. Nachdem BWT die neue lokale API verfügbar gemacht hat, habe ich bei mir lokal aktuell auf diese API umgestellt. Der Zugriff klappt dank geänderter Authentifizierung durch BWT auch direkt aus dem Miniserver ohne Loxberry. Was einzig fehlt ist die Aktivierung des Urlaubsmodus via POST Aufruf, ich gehe aber davon aus dass BWT diesen Aufruf irgendwann auch ins neue lokale API übernehmen wird. Da ich die BWT AquaStop Sensoren nutze, ist bei mir die Notfall-Sperre der Wasserzufuhr im Falle eines Wasserschadens direkt gelöst ohne Loxone.

Viele Grüsse
Paolo

[Paz]

Hi Patrick

Aktuell investiere ich keine weitere Zeit in die Cloud Version - ich bin bei Smarthome Anwendungen generell nicht wahnsinniger Cloud-Fan, sehe es nicht ein meine Daten via Cloud wieder abzuholen wenn es einen direkten Weg gibt. Nachdem BWT die neue lokale API verfügbar gemacht hat, habe ich bei mir lokal aktuell auf diese API umgestellt. Der Zugriff klappt dank geänderter Authentifizierung durch BWT auch direkt aus dem Miniserver ohne Loxberry. Was einzig fehlt ist die Aktivierung des Urlaubsmodus via POST Aufruf, ich gehe aber davon aus dass BWT diesen Aufruf irgendwann auch ins neue lokale API übernehmen wird. Da ich die BWT AquaStop Sensoren nutze, ist bei mir die Notfall-Sperre der Wasserzufuhr im Falle eines Wasserschadens direkt gelöst ohne Loxone.

Viele Grüsse
Paolo

Ja, kann ich verstehen. Geht mir grundsätzlich ähnlich. Ich würde halt nur gern den Urlaubsmodus automatisch nach x-Stunden Abwesenheit aktivieren.
Ich habe die Perla jetzt auch direkt eingebunden, um zumindest die Daten der API abzuholen.

Ein Spezi von mir ist bei BWT und er hat mir vorhin geschrieben, dass POST derzeit kein Thema ist. Nur App oder Cloud. Naja, wenn man die App nutzt (resp. die Perla ins Internet kann), ist es ohnehin schon Cloud, von daher nicht mehr so ein Unterschied.

Ciao,
Patrick

[bazzman]

Ein Spezi von mir ist bei BWT und er hat mir vorhin geschrieben, dass POST derzeit kein Thema ist. Nur App oder Cloud. Naja, wenn man die App nutzt (resp. die Perla ins Internet kann), ist es ohnehin schon Cloud, von daher nicht mehr so ein Unterschied.

Mein Ziel wäre es mittelfristig die ganzen Smarthome Geräte in ein VLAN zu packen welches keinen Zugang zum Internet hat (nur lokal), dann wäre zwar die App nicht mehr nutzbar aber via Loxone hätte ich meine Daten.

Aber wenn BWT hier die neue API wirklich nicht mit POST Befehlen ausstatten lassen möchte, muss ich mir das wohl doch nochmals fürs Plugin ansehen. Ich hatte den Cloud-Zugriff aus Loxberry ja als POC schon mal implementiert gehabt, wenn ich irgendwann mal einen Abend Zeit finde, fehlt wohl nicht allzuviel um das als Beta Release rauszugeben.

Grüsse
Paolo

[RHC]

Ich bekomme seit gestern keine Daten mehr über die lokale BWT-API in mein Loxone. Ich habe nun gesehen, dass zum Ausfalls-Zeitpunkt automatisch eine neue Firmware-Version eingespielt wurde (jetzt 2.0207 - zuvor 2.0203).

Ich befürchte, dass da einfach wieder mal was an der API geändert wurde… Ich habe mir das im Detail noch nicht angesehen - hat das Problem sonst noch jemand?