Test Adapter Bayernluft 2.0.x

[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