Test Adapter Bayernluft 2.0.x

[mcm1957]

Aktuelle Test Version	2.0.1
Veröffentlichungsdatum	16.1.2025
Github Link	https://github.com/iobroker-community-adapters/ioBroker.bayernluft

Beschreibung
Der Adapter bayernluft wurde vor einiger Zeit in die iobroker-community-adapters Orga übernommen. Leider funktionierte dieser bisher nicht (oder zumindest nicht volsltändig. Dank der Arbeit von boriswerner (GitHub Name) wurde der Adapetr an die aktuelle Api des Herstelelrs angepasst sodass nun eine Funktionalität gegeben sein sollte.

An dieser Stelle ein GANZ HERZLICHES DANKE für Adapter und die aufgewendete Zeit an den Entwickler der ersten Versionen Marco15452 (https://github.com/Marco15453) und natürlich boriswerner(https://github.com/boriswerner).

Der Adapter benötigt noch ein detaillierteres Review und ev. ein paar Anpassungen bevor ich ihn ins das Lates Repository stellen werde. Er ist daher derzeit nur von npm (als url einfach iobroker.bayernluft eintippen) sowie Github (nicht empfohlen) installierbar.

Allfällige Anmerkungen bitte hier im Forum, offensichtliche Fehler bitte als Issue im Repostory https://github.com/iobroker-community-adapters/ioBroker.bayernluft.

Natürlich sind auch positive Rückmeldung ("funktioniert") gerne gesehen.

Changelog etc.

2.0.0 (2025-01-14)

• (mcm1957) Adapter requires node.js 20, js-controller 6 and and admin 6 now.
• (boriswerner) Corrected the API calls to match the new API (rev 2.0 version WS32231301, see: https://www.bayernluft.de/de/wlan32_changelist.html)
• (boriswerner) Corrected the ACK-handling in onStateChange
• (mcm1957) Adapter has been move to iobroker-community-adapters organization
• (mcm1957) Dependencies have been updated

2.0.1 (2025-01-16)

• (mcm1957) AdminUI and translations have been fixed.

[mcm1957]

• Eine Diskussion zu den Versionen 1.x.x findet sich hier:
  <https://forum.iobroker.net/topic/59517/test-adapter-bayernlüfter-v1-0-2-github-latest

• Die Diskussionen zur 2.0.0 alpha gibts hier:
  https://forum.iobroker.net/topic/68777/bayernlüfter-und-iobroker

[mcm1957]

Known Problems

- Das Admin UI ist unsauber und muss in Bezug auf responvide Design nochmal korrigiert werden. fixed 2.0.1

[Wildbill]

@mcm1957 @boriswerner Ich habe bei mir 8 Bayernlüfter in Vollbestückung (also inklusive aller Feuchtesensoren). Vielen Dank für die Arbeit, die Grundfunktionalität scheint fehlerfrei gegeben. Alle Befehle unter commands kommen korrekt an, ohne irgendwelche Logmeldungen, und werden auch korrekt umgesetzt. Ebenso alle Daten unter Parameter. Die sind deckungsgleich mit den Daten, die mir in Home assistant angezeigt werden (dort laufen die BL schon länger bei mir).
Was mir momentan in iobroker noch fehlt, ist das einzelne Ansteuern der Lüfermotoren, wenn der Bayernlüfter ausgeschaltet ist. Das ist hier im Changelog bei Bayernluft bei Firmware WS32240427 beschrieben. Nutze ich ab und an, um die Luftströmung im Haus nach meinen Wünschen zu steuern. Wenn ich bei ausgeschaltetem Gerät unter commands die setspeed ändere, dann bleibt der Lüfter zwar "ausgeschaltet", die Lüfter in und out werden eingeschaltet, aber eben beide mit gleicher Stufe. Wäre schön, wenn man die getrennt steuern könnte. Wenn ich in HA den Lüfter ausschalte und dann manuell nur einen der Lüfter setze, sehe ich das korrekt in iobroker. systemon bleibt auf 0, die jeweilige Lüferspeed wird korrekt angezeigt, die andere bleibt auf 0.

Die Datenpunkte unter states scheinen zwar beschreibbar, aber das ist wohl ein kleiner Bug und nicht so vorgesehen, die werden wieder vom Gerät überschrieben, ohne etwas zu bewirken. Sollten also readonly sein IMHO.

Gruss, Jürgen

[mcm1957]

@wildbill
Bitte sei so nett und erstell für den Feature request und dne (wahrscheinlichen) Anzeigebug Issues. Hier geht das wahrscheinlich unter.

Ich hoffe @boriswerner hat Zeizt sich das anzusehen. (Wenn du Support brauchst, bitte melden.)

[Wildbill]

@mcm1957 Erledigt:

States not changeable
Fan speed set

[boriswerner]

Schau ich mir beides zeitnah an. Kleine Nachfrage: die individuellen "Fan speed set" funktionieren wirklich nur, wenn das device ausgeschaltet ist, richtig? Setze ich die Kommandos bei eingeschaltetem Gerät ab, passiert nichts. (Das ack wird leider trotzdem gesetzt, da derzeit nicht geschaut wird, ob sich das dann wirklich im speed wiederspiegelt)

[Wildbill]

@boriswerner Ja, bei eingeschaltetem Gerät ändert sich durch das individuelle Setzen von SpeedOut, SpeedIn und SpeedAntifreeze nichts am Gerät. Da geht es nur über Setspeed, was dann, je nachdem ob AutoAdapt aktiviert ist oder nicht, beide auf die gleiche Stufe stellt und den Antifreeze bei Bedarf aktiviert.

Gruss, Jürgen

Als Ergänzung: In Homeassistant sind die Eingaben für die drei Einzellüfter dann gesperrt und lassen sich bei eingeschaltetem Gerät gar nicht ändern. Ich habe es aber eben vie WebIF getestet. Eingeschaltetes Gerät und Eingabe von

http://192.168.100.232/index.html?speedIn=5

bewirkt gar nix. Beim ausgeschalteten Gerät geht dann der In-Lüfter auf 5. Das Gerät bleibt aber weiterhin ausgeschaltet bzw. zeigt eben ausgeschaltet an.

[boriswerner]

@wildbill okay, danke für die Info. Ich glaube Sperren der Datenpunkte auf Basis von Konditionen geht im iobroker nicht (@mcm1957 ?) soweit ich weiß. Ich glaube das erwartete Verhalten wäre dann höchstens, dass man zwar einen Wert setzen kann, aber kein ack gesetzt wird. Aber selbst da wäre ich mir nicht sicher, weil das Gerät die Anfrage ja acknowledged (nur ignoriert...). Ich würde mal einen Hinweis in die Readme über das Verhalten aufnehmen.

[mcm1957]

@boriswerner

Im Prinzip kann man das auch in ioBroker implementieren. Mittels extendObject kann man das Attribute write:true/false ja zur Laufzeit ändern. Allerdings ist mir kein Adapter bekannt, der das macht und zumindest der Browser in der Objectview wird wohl eine Refresh brauchen um den neuen Wert anzuzeigen.

In einer VIS kann man das aber ziemlich sicher implementieren. Kenn mich da aber nur sehr rudimentär aus.

[mcm1957]

@boriswerner said in Test Adapter Bayernluft 2.0.x:

Schau ich mir beides zeitnah an. Kleine Nachfrage: die individuellen "Fan speed set" funktionieren wirklich nur, wenn das device ausgeschaltet ist, richtig? Setze ich die Kommandos bei eingeschaltetem Gerät ab, passiert nichts. (Das ack wird leider trotzdem gesetzt, da derzeit nicht geschaut wird, ob sich das dann wirklich im speed wiederspiegelt)

ack bedeutet nur dass der Wert im Object steht der vom Gerät geleifert wurde. Wenn das Gerät etwas zurückliefert muss ack und der gelieferte Wert gesetzt werden.

Nur ack alleine ohne Kommunikation mit dem Gerät zu setzen wäre eher falsch.

[boriswerner]

@mcm1957 said in Test Adapter Bayernluft 2.0.x:

@boriswerner

Im Prinzip kann man das auch in ioBroker implementieren. Mittels extendObject kann man das Attribute write:true/false ja zur Laufzeit ändern. Allerdings ist mir kein Adapter bekannt, der das macht und zumindest der Browser in der Objectview wird wohl eine Refresh brauchen um den neuen Wert anzuzeigen.

Würde ich dann mangels Wissen aber nicht machen.

In einer VIS kann man das aber ziemlich sicher implementieren. Kenn mich da aber nur sehr rudimentär aus.

Da, oder als Logik in einem Skript/Blockly würde ich das auch eher sehen, da es so erstmal das gleiche Verhalten hat, wie der Aufruf per URL. Man bekommt keinen Fehler, aber es tut sich halt nichts.

ack bedeutet nur dass der Wert im Object steht der vom Gerät geleifert wurde. Wenn das Gerät etwas zurückliefert muss ack und der gelieferte Wert gesetzt werden.

Nur ack alleine ohne Kommunikation mit dem Gerät zu setzen wäre eher falsch.

Das ist im Adapter ja eh bisher nicht implementiert. Ein Sync zwischen den Werten in den commands mit denen in states passiert nicht. (D.h. setzt man einen Wert über z.B. das Geräte-eigene Webinterface, wird es zwar in dem jeweiligen Datenpunkt unter states aktualisiert, der Wert im commands-Datenpunkt bleibt jedoch beim zuletzt gesetzten. Das wäre ein größerer Umbau und auch von der Logik her dann nicht so einfach darzustellen. Daher lasse ich es mal beim jetzigen Modus. Ich schau später nochmal drauf und mache dann zeitnah commit und PR.

[mcm1957]

@boriswerner
OK passt so. Wenn commands nur als inpout dienen und eh extra states als feedback existieren ist das OK. Und dann ist es auch ok das ACK zu setzen sobald der Adapetrcode den Änderungswunsch zur Kenntnis genommen hat.

[mcm1957]

Denkbar wär ev. eine Warning (od. Info) zu loggen, wenn die Bedingenen für die Änderung nicht vorhanden sind. Dann würd sich der User ev. nicht wundern und schrein dass der Adapetr nicht funktioniert.

[Wildbill]

Ich hab nochmal ein Issue/feature request erstellt. Vielleicht lässt es sich ja implementieren, dass, sobald man in iobroker einen Wert ändert, die Daten vom Gerät einmalig extra gepollt werden. Je nach gesetztem setpollintervall wartet man sonst eine Zeit, bis man sieht, dass die Änderung auch umgesetzt wurde, was bei Bedienung mit vis etwas verwirend sein kann.

Gruss, Jürgen

[boriswerner]

@wildbill Ist mir beim Test auch schon aufgefallen. Schau ich mir an.
Mal noch eine generelle Rückfrage: ich würde die folgenden States

systemon, Antifreeze, fixed_speed, defrosting, landlord_mode, cross_ventilation, timer_active

gerne in Booleans umwandeln, konnte aber nicht 100%ig erkennen, ob es nicht doch noch Werte außer 0 und 1 aus dem Web-Export geben kann. Hast du (oder jemand anders) da Erfahrungen? Wenn nicht würde ich den Hersteller mal anschreiben, der war vor dem Kauf auf jeden Fall sehr hilfsbereit.

Dabei werde ich übrigens auch die Namenskonvention mal einheitlich in camelCase umstellen und die Namen und Beschreibungen anpassen. Das wird alles vielleicht noch eine oder zwei Wochen dauern, aber dann würde ich das auch gleich mal ordentlich machen
Wenn also noch Wünsche oder Ideen da sind, gerne in github einstellen oder hier Fragen.

[Wildbill]

@boriswerner Die genannten States können, soweit mir bekannt nur true oder false sein. Auch in HA habe ich da nie etwas Anderes gesehen.

Danke fürs Kümmern.

Gruss, Jürgen