Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[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 :-D
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

[boriswerner]

Hi zusammen, nur mal ein kleines Update.
Ich hab beim Hersteller nachgefragt und der hat die Werte bestätigt. An dieser Stelle nochmal: wirklich toller Support vom Hersteller!
Gerade bin ich dabei den Adapter komplett rundzuerneuern. D.h. es wird aber auch nochmal Änderungen an der export.txt auf den Lüftern geben und an der Datenpunkt-Struktur. Die export.txt werde ich, sobald fertig auch an den Hersteller geben können, sodass dieser diese direkt bei Auslieferung auf den Geräten mitliefern wird und so für neue Lüfter keine Anpassung auf dem Gerät selbst notwendig sein wird.
Allerdings ist die Zeit gerade etwas knapp, da ich letzte Woche erstmal den Lüfter bei mir zuhause eingebaut hab und noch mit anderen Sanierungsmaßnahmen beschäftigt bin. Da ich auch noch 2 größere Lüftungsanlagen (Meltem M-WRG-II) eingebaut hab und ich die gerade im iobroker nicht wirklich zum Laufen bekomme, haben die Priorität. Bayernlüfter läuft ja erstmal ;-)
Wird aber definitiv im Februar eine neue Version zum Testen geben. Wenn was ist, gerne melden

[Wildbill]

@boriswerner Hört sich gut an, und insbesondere, dass da die Zusammenarbeit mit dem Hersteller so gut läuft. Ich hatte mit Herr Akontz auch schon ein paarmal Kontakt per E-ail und Telefon, sehr kompetent und man merkt, er steht hinter seinen Produkten.

Schau mal bitte, bei Gelegenheit, ob der PR den ich gestern erstellt habe, so passt. War mei erstes Mal überhaupt. Damit kommen bei einigen Datenpunkten dann auch die Nachkommawerte mit rein.

Gruss, Jürgen

[boriswerner]

@wildbill Hi, sieht für mich soweit gut aus. Auf das community-Repo hab ich keinen Zugriff, das macht bisher ja mcm1957. Ich übernehme es aber auf jeden Fall in meine Überarbeitung für die ich dann wie beschrieben einen größeren PR stellen werde.

[boriswerner]

@Wildbill ich überlege gerade, ob es mehr Sinn ergibt den generellen Aufruf auf Dezimalpunkt umzustellen (siehe https://www.bayernluft.de/de/wlan32_changelist.html) :

WS32234901

Sowohl die Anzeige im Live-Schema, als auch die Export-Funktion für Smarthome-Systeme wurde auf vielfachen Wunsch um die Möglichkeit erweitert, als Dezimaltrennzeichen zwischen Punkt und Komma wählen zu können. Ohne weiteren Befehl werden die Werte weiterhin mit einem Komma ausgegeben. Möchte man als Trennzeichen einen Punkt, so hängt man den Befehl hinter den Aufruf.

Beispiel: http://192.168.178.190/index.html?decimal=point

oder

http://192.168.178.190/index.html?export=1&decimal=point

[Wildbill]

@boriswerner Das hatte ich sogar mal irgendwann gelesen und erfolgreich wieder verdrängt. :blush:
Ja, da parseFloat ja eh den Punkt als Dezimaltrenner erwartet, macht das vermutlich noch mehr Sinn. Dann kommt es gleich so, wie es soll und mein PR zum Umwandeln von Komma in Punkt wäre hinfällig. Wird wohl die bessere Lösung sein. :+1:

Gruss, Jürgen

[Wildbill]

@boriswerner Hab es bei mir lokal geändert und dann gleich einen PR erstellt und meinen alten geschlossen. Funktioniert einwandfrei.

[Negalein]

@boriswerner sagte in Test Adapter Bayernluft 2.0.x:

so für neue Lüfter

Hallo

welche neue Lüfter?
hab ich da was verpasst?

[Wildbill]

@negalein Wenn Du einen neuen Lüfter bei Bayernluft bestellst, dann wird da gleich die passende export.txt drauf sein. So habe ich es zumindest verstanden. :flushed:

[boriswerner]

@wildbill said in Test Adapter Bayernluft 2.0.x:

@negalein Wenn Du einen neuen Lüfter bei Bayernluft bestellst, dann wird da gleich die passende export.txt drauf sein. So habe ich es zumindest verstanden. :flushed:

So wird es sein. Für bestehende Geräte ändert sich da nicht viel (außer, dass es eine fertige Datei zum hochladen geben wird) Es gibt die Funktion direkt eine bestimmte export.txt anzusprechen. Die wird dann export_iobroker.txt heißen und der interne Aufruf an die API wird dann export=iobroker lauten.
Damit fällt für neue Käufer der Schritt weg, dass man erst im Dateibrowser jedes einzelnen Geräts die txt-Datei hochladen muss. Super Sache wie ich finde.
Für euch (bzw. alle, die bereits Lüfter haben) bedeutet das dann sobald die neue Version da ist, einmalig eine neue Datei auf jeden Lüfter hochladen.

[Negalein]

@wildbill sagte in Test Adapter Bayernluft 2.0.x:

neuen Lüfter

ahhhh, das ganze Gerät ist gemeint.
Ich hab an Ersatzlüfter (im Gerät) gedacht. :joy: