Viessmann Plugin Neuentwicklung Python Hilfe

[TCr82]

Ja, ist auch kein Wunder. /dev/ttyUSB0 fällt ab, nach dem Neuverbinden ist es /dev/ttyUSB1. Das kann das Plugin nicht wissen.

doch, deswegen verbinde ich ja schon lange auf den Symlink /dev/ttyOptolink der immer per Udev aktuell gehalten wird.

root@heizung:/usr/local/smarthome# dir /dev/ttyOptolink
lrwxrwxrwx 1 root root 7 Dec 31 18:04 /dev/ttyOptolink -> ttyUSB1
root@heizung:/usr/local/smarthome# cat /etc/udev/rules.d/20-Optolink.rules
SUBSYSTEM=="tty",ATTRS{idProduct}=="ea60",ATTRS{id Vendor}=="10c4",SYMLINK+="ttyOptolink"

Nach dem Restart von shNG (ohne irgend was anderes zu machen) lief es dann auch wieder.

Jo, das ist in der commands.py für die Anlage V200KO1B definiert, aber nicht für die V200KW2. Oder hast du das bei dir zugefügt? Kennt deine Anlage das?

Ja, habe ich, Adresse der Viessmann DB entnommen (siehe meine Tabelle oben). Wie dem grep Kommando zu entnehmen, ist das auch nirgends wo anders in der Datei (also nur einmal) und ich habe es nicht bei der V200KO1B gelöscht.

Wenn das eine Temperatur sein soll, dann ist 1 Byte wenig.

Aber es ist doch mit len: 2 definiert?

Aber ich denke das mit der Adresse 2500 & 3500 hat sich erstmal erledigt, denn die ist in der Viessmann DB zu meiner Heizung Doppelt definiert... nämlich z.B. auch in der Betriebsart, weswegen der von mir genannte Fehler auch passt und nicht verwundern sollte!

Siehe

Name	Addresse	Conversion	Unit	DataType	Stepping	ValuePrecision	LowerBorder	UpperBorder
HK_AktuelleBetriebsartA1M1	0x2500	NoConversion		VarChar
HK_AufheiztimerA1M1	0x2500	Div10	Sekunden	Float
HK_Frostgefahr_aktivA1M1	0x2500	NoConversion		VarChar
HK_PumpenbefehlA1M1	0x2500	NoConversion		VarChar
HK_RaumsolltemperaturaktuellA1M1	0x2500	Div10	Grad C	Float			0	127
HK_RSWSBetriebA1M1	0x2500	NoConversion		VarChar
HK_WW_Freigabe_vonA1M1	0x2500	NoConversion		VarChar

Was auch immer da nicht ganz stimmt, ich werde die DB wohl noch weiter aufdöseln bzgl Bedingungen usw. Vielleicht muss man da ja auch erst was anderes vorher aufrufen oder dazu rechnen.. wer weiss wie Viessmann das abfrägt.. hoffe das ich das noch herausbekomme.

Ist nebenbei auch bei anderen Anlagen so, zB bei der V200KO2B

Gruß

[Morg]

doch, deswegen verbinde ich ja schon lange auf den Symlink /dev/ttyOptolink der immer per Udev aktuell gehalten wird.

root@heizung:/usr/local/smarthome# dir /dev/ttyOptolink
lrwxrwxrwx 1 root root 7 Dec 31 18:04 /dev/ttyOptolink -> ttyUSB1
root@heizung:/usr/local/smarthome# cat /etc/udev/rules.d/20-Optolink.rules
SUBSYSTEM=="tty",ATTRS{idProduct}=="ea60",ATTRS{id Vendor}=="10c4",SYMLINK+="ttyOptolink"

Nach dem Restart von shNG (ohne irgend was anderes zu machen) lief es dann auch wieder.

Dann wäre es echt hilfreich, das auch dazuzuschreiben. Für mich hat sich das so gelesen, als wäre er ausgestiegen und nicht wieder reingekommen. Die einzigen Informationen waren im Log, dass der Lesekopf jetzt auf einem anderen tty liegt...

Ja, habe ich, Adresse der Viessmann DB entnommen (siehe meine Tabelle oben). Wie dem grep Kommando zu entnehmen, ist das auch nirgends wo anders in der Datei (also nur einmal) und ich habe es nicht bei der V200KO1B gelöscht.

Dann hast du eine andere commands.py als ich. Meine ist immer im github-Repo verfügbar. Wenn du deine nicht entsprechend aktuell dazupackst, kann ich da ggf. nicht ausreichend was zu sagen.

Aber es ist doch mit len: 2 definiert?

Manchmal ist es echt schwer, mit dir zu reden, sorry.

Die Definition mit 2 Bytes steht in deinem Auszug zu

[code]
root@heizung:/usr/local/smarthome/plugins/viessmann# grep Raumtemperatur_Soll_Aktuell_M2 commands.py 'Raumtemperatur_Soll_Aktuell_M2': {'addr': '3500', 'len': 2, 'unit': 'IU10', 'set': False},[/quote],

was nach meinen bisherigen Informationen für deine Anlage gar nicht definiert ist. Oder nutzt du auf einmal einen anderen Kommandosatz? Oder eine andere Anlage?

Und mein Hinweis auf die zwei Bytes steht nach der Einleitung "zum float": und bezieht sich auf deine Floatproblematik. Und in deinem Log

2021-01-01 13:23:01 DEBUG __init__ CP Server Thread-17 Trying to receive 1 bytes of the response -- (__init__.py:_send_command_packet:869)

steht eindeutig, dass das Plugin nur ein Byte angefordert hat.


Und zur Viessmann-Db habe ich schon was gesagt. Die kenne ich schon recht lange, und die war leider noch nie verlässlich in dem Sinne, dass man "einfach" die Adressen für alle Heizungen auslesen könnte. Sonst wäre das openV-Projekt schon seit Jahren erheblich weiter.

Ich weiß jetzt zB auch nicht, was du alles in deine commands.py geschrieben hast. Du kannst die gern mal hier einstellen, dann schaue ich mir die an. Wenn da doppelte Befehlsadressen für eine Anlage vergeben sind, macht das Plugin nämlich alles, aber nicht, was man erwartet.
Die Bedingung, dass die commands.py bestimmten formalen Ansprüchen genügt, ließe sich zwar auflösen, aber dann wird der Code erheblich komplexer, ohne dass man wirklich etwas dazu gewinnt. Dafür gibts die commands.py ja auch aus dem shng-Repo, damit zumindest solche Sachen nach Möglichkeit nicht drin vorkommen.







(der Leerraum ist extra - neuer Gedanke...)


Ich möchte dich wirklich bitten, hier entweder nur ein Thema gleichzeitig anzufragen, oder dir etwas mehr Mühe zu geben, die mehreren Themen auseinander zu halten. Ich investiere viel Zeit in das Plugin, und das mache ich gerne, versteh mich da bitte nicht falsch. Aber dann mehr Zeit damit zuzbringen, die unterschiedlichen Themen auseinanderzufusseln und zu versuchen zu verstehen, mit welcher Anlage und welchem Kommando du was versucht hat und was wie nicht geklappt hat, ist ziemlich anstrengend.

Ich möchte gerne weiter helfen, aber dafür brauche ich auch deine Unterstützung.

Gruß
Sebastian

[Morg]

So, Michael...

so langsam verzieht sich der Qualm aus meinen Ohren (Augen...) und ich kann wieder den Monitor sehen

Also, ich gehe mal der Reihe nach durch, was da passiert: (ich lasse die Bezüge ins Log weg; mit "got a new read/write job" findest du die meisten Einstiege selbst...

- Schreibanforderung Partybetrieb_M2 = True
-> wird geschrieben, Rückmeldung "Schreiben OK"

- Leseanforderung Partybetrieb_M2 "read after write"
-> wird gelesen, Rückmeldung Partybetrieb_M2 = False

==> die Anlage hat das Schreiben erfolgreich quittiert, aber anscheinend nicht umgeschaltet (oder noch nicht?)

- Leseanforderung Betrieb_M2 "trigger after write"
-> wird gelesen, Rückmeldung 0x02, "Normalbetrieb"
(btw - es gibt im Betriebsmodus keinen Eintrag für Partybetrieb, das ist so richtig?)
-> beim Zuweisen wird "trigger after write" angestoßen für Aktuelle_Betriebsart_M2

bevor der loslaufen kann (hat ja (default) ein 5 Sek. Delay), kommt der Scheduler:

- Leseanforderungen cyclic command read:

Das Problem - für das Logfile - ist hier, dass zwei Threads parallel mit der Anlage sprechen und die Logmeldungen sich verschränken. Das Plugin arbeitet also nicht alle Kommunikation in der Reihenfolge im Logfile ab, sondern teilweise parallel, wobei Anfrage und Antwort garantiert unmittelbar hintereinander laufen, weil ein Schreibvorgang und der dazugehörige Lesevorgang für die Antwort in einem Lock-Block sind. Währenddessen kann auch der cyclic nicht lesen/schreiben, er wartet dann auf das Lock. Das wird freigegeben, sobald die Antwort verarbeitet wurde.

Da beim P300-Protokoll das Kommando in der Antwort steht, wäre es auch sonst kein Problem, die Antwort zuzuordnen, bei KW schon. Kann aber - s.o. nicht passieren.

---

Was mich hier irritiert:
- cyclic liest erst Aussentemperatur (2,8) -> item Aussentemperatur
- cyclic liest dann Aussentemperatur_TP (2,8) -> item Aussentemperatur ...?

Wieso lässt du denn zwei Werte ins selbe Item schreiben?

---

So, nachdem Sammelstörung vorbereitet wurde, kommt die Antwort auf Aktuelle_Betriebsart_M2 = 03 "Heizen + WW Schaltzeiten".

Der Wert 0x03 wird decodiert und in String umgewandelt, und jetzt sucht er in self._params nach dem Commandcode und findet ihn nicht -> Fehlermeldung

Hast du dafür (Aktuelle_Betriebsart_M2, command code 3301) ein eigenes Item definiert? Oder wird das nur über trigger_afterwrite angestoßen (so steht es ja im Log) und er weiß jetzt nicht, wo er das hinschreiben soll?

Normalerweise kommt ja eine Leseanforderungen über einen read_after_write oder einen cyclic, der an ein Item gebunden ist, also ist das in self._params hinterlegt. Genauso bei initial_read oder read_all_items (oder so).

Nur bei trigger_afterwrite kannst du Befehle angeben, die kein Item brauchen

Anders kann ich mir das hier derzeit nicht erklären.

Wenn es das nicht ist, dann müsste ich dir nochmal eine modifizierte __init__.py schicken, in der noch mehr Logausgaben erzeugt werden.


Achso, und ich warte bei sowas mit den Vorgängen immer, bis der cyclic gerade durch ist, dann ist das Log einfacher zu lesen

[TCr82]

Dann wäre es echt hilfreich, das auch dazuzuschreiben. Für mich hat sich das so gelesen, als wäre er ausgestiegen und nicht wieder reingekommen. Die einzigen Informationen waren im Log, dass der Lesekopf jetzt auf einem anderen tty liegt...

Sorry, hatte ich schonmal vorher erwähnt. Löst jetzt aber so nicht das Problem. Normal sollte er sich doch neu verbinden.. scheinbar hat er das auch "einmal" versucht - dann aber nicht wieder.

Dann hast du eine andere commands.py als ich.

Klaro, ich schieb ja, dass ich gerade dabei bin die Adressen durchzutesten und in meine commands.py einzupflegen. Und aktualisieren tue ich eigentlich auch regelmäßig.

Aber auch in deiner aktuellen Onlineversion gibt es keinen Datenpunkt "Raumtemperatur_Soll_Aktuell_M2" wie du meintest dass dieser schon in der V200KO1B definiert wäre. Sorry da bist du einfach durcheinander geraten - dachte ich habe das ausreichend dargelegt - sorry.

Manchmal ist es echt schwer, mit dir zu reden, sorry.

Die Definition mit 2 Bytes steht in deinem Auszug zu

Auch wenn es sich ja jetzt erstmal wegen dem Adress-Desaster erledigt hat, was ja wohl der eigentliche Fehler ist:
Der Datenpunkt war soweit ich das gesehen habe mit len: 2 definiert - sind doch die byte oder nicht? Deswegen hatte ich ja auch die Definition dazu geschrieben, damit man das nachvollziehen kann. Aber wenn das Log sagt dass es nur ein Byte gelesen hat, gehe ich dann wohl davon aus,, dass ich es durcheinander gebracht habe (vorher auf len: 1 hatte).

Oder bin ich komplett auf den Holzweg und das len hat nichts damit zu tun?

Und zur Viessmann-Db habe ich schon was gesagt. Die kenne ich schon recht lange, und die war leider noch nie verlässlich in dem Sinne...

Das sieht man der DB eigentlich schon gleich an, dass die schon etwas advanced ist

Ich habe mir ein Tool gebaut, um die Daten dort einfach abzufragen (mit entsprechenden JOIN'S) ... aber ich vermute mittlerweile wirklich, dass die Software noch vorher den Modus (zb. Codier-Modus oder was auch immer) wechselt für bestimmte Adressen oder was ähnliches. Aber ich bin noch an der sehr komplexen Analyse dran.

Wenn da doppelte Befehlsadressen für eine Anlage vergeben sind, macht das Plugin nämlich alles, aber nicht, was man erwartet

Das war natürlich keine Absicht - bin ja aber dank der Meldung im Log letztendlich selbst darauf gekommen. Wenn ich die Adressen soweit getestet habe werde ich dir das auch gerne zukommen lassen. Um jetzt nicht ständig das Board mit langen Listen zu Überschwemmen poste ich halt nur das relevante.

Ich möchte dich wirklich bitten, hier entweder nur ein Thema gleichzeitig anzufragen, oder dir etwas mehr Mühe zu geben, die mehreren Themen auseinander zu halten.

Ich versuche es, aber das sich das Float Thema und der Fehler im Logfile bzgl des falschen Datentyps des Items überschnitten haben, lag ja letztendlich an der doppelten Adresse aus der DB (es ging ja dabei die ganze Zeit um den selben Datenpunkt, den ich ja auch immer genannt hatte). Verstehe dass das verwirrend und anstrengend war.

[Morg]

Normal sollte er sich doch neu verbinden.. scheinbar hat er das auch "einmal" versucht.

Normalerweise sollte er das immer wieder versuchen, wenn ein neuer Lese-/Schreibauftrag kommt. Wird jedesmal geprüft - wenn nicht verbunden, dann neu verbinden.

Dein Plugin versucht auch, das udev-Device zu lesen? Das wird auch neu wieder angelegt?

Aber auch in deiner aktuellen Onlineversion gibt es keinen Datenpunkt "Raumtemperatur_Soll_Aktuell_M2" wie du meintest dass dieser schon in der V200KO1B definiert wäre.

Dann bin ich da anscheinend tatsächlich über die Bezeichnungen gestolpert, sorry. Das war aber der Fehler mit commandcode 3500, der mehrfach belegt war? Die Fehlermeldung klingt für mich, als hätte er den commandcode aus einer Definition mit Typ "BA" gelesen, die wird nämlich in einen Klartextstring übersetzt. So wars ja auch im Log.

Der Datenpunkt war soweit ich das gesehen habe mit len: 2 definiert - sind doch die byte oder nicht? Deswegen hatte ich ja auch die Definition dazu geschrieben, damit man das nachvollziehen kann. Aber wenn das Log sagt dass es nur ein Byte gelesen hat, gehe ich dann wohl davon aus,, dass ich es durcheinander gebracht habe (vorher auf len: 1 hatte).

Ich denke, das hängt zusammen und du hast irgendwo noch ein "Betriebsart"-Command definiert. Die arbeiten nämlich mit einem Byte. Aus der Anfrage in deinem Log geht auch hervor, dass er Adresse 3500 mit 1 Byte abgefragt hat. Wenn du die Adresse nochmal definiert hast mit 2 Bytes, dann reagiert das Plugin nicht unbedingt vorhersehbar.

Am besten prüfst du da nochmal deine commands.py auf Dubletten in der Definition für deine Heizung.

Ich habe mir ein Tool gebaut, um die Daten dort einfach abzufragen (mit entsprechenden JOIN'S)

Egal wie fortgeschritten du das abfragst - wenn die Quelldaten nicht sauber definiert sind, wird das nix. Wie gesagt, an den Daten sitzen die bei openV seit Jahren dran, aber etwas wirklich vernünftiges (im Sinne von - für x Typen vollständige und korrekte Befehlssätze) ist dabei nicht rausgekommen.

Wenn du es schaffen solltest - sehr gut.

Dass sich da mehrere Sachen überschnitten haben, wurde dann ja auch erst ein Post später ersichtlich. Das zeigt aber wieder, wie wichtig eben doch umfassende Informationen gleich zu Beginn sind. Pack deine Definition und ggf. ein Log in eine ZIP-Datei und häng die an den Beitrag an. Dann bleibt der Beitrag kurz, aber es ist (hoffentlich) alles dabei, was man braucht. Wenn du dich auf einzelne Fehlermeldungen beziehen willst, kannst du die ja kurz zitieren - bzw. besser als Code einfügen; wenn jemand dir antwortet mit Zitat, bleibt der Code erhalten, aber Zitate verschwinden (nur eine Ebene).

Wenn ich dann merke, dass noch was fehlt, kann ich auch gezielt nachfragen. Siehst du ja bei Michael, wenn mir das nicht reicht, wirft er mir halt ne Seite Logs an den Kopf

[TCr82]

Ich denke, das hängt zusammen und du hast irgendwo noch ein "Betriebsart"-Command definiert. Die arbeiten nämlich mit einem Byte. Aus der Anfrage in deinem Log geht auch hervor, dass er Adresse 3500 mit 1 Byte abgefragt hat. Wenn du die Adresse nochmal definiert hast mit 2 Bytes, dann reagiert das Plugin nicht unbedingt vorhersehbar.

Am besten prüfst du da nochmal deine commands.py auf Dubletten in der Definition für deine Heizung.

Ja, genau das war es - daran hatte ich eben auch wieder nicht gedacht. Aber klar, die falsche Länge kam auch von der doppelt definierten Adresse.
Hab die doppelte Adresse mittlerweile auch schon auskommentiert, bis ich dahinter gestiegen bin wie die das Auswerten.

Egal wie fortgeschritten du das abfragst - wenn die Quelldaten nicht sauber definiert sind, wird das nix. Wie gesagt, an den Daten sitzen die bei openV seit Jahren dran, aber etwas wirklich vernünftiges (im Sinne von - für x Typen vollständige und korrekte Befehlssätze) ist dabei nicht rausgekommen.

Naja, die Software von Viessmann bekommt es ja auch anhand dieser Daten hin die Heizungsanlage zu Programmieren / Abzufragen
Da die DB sehr komplex ist ist es auch nicht so einfach da durchzusteigen. Viele nutzen außerdem auch nur die XML Daten aus der DPDefinitions.xml.
Da hat man auch gar keine Bezüge zum rest der DB. Aber wie gesagt, ich versuche da durchzusteigen, will jetzt auch nicht zu viel versprechen, sage nur dass ich gute Chancen sehe...

Gruß

[TCr82]

Dein Plugin versucht auch, das udev-Device zu lesen? Das wird auch neu wieder angelegt?

Dein Plugin - vermute ich doch, dass es das tut? Und ja, das ganze ist immer aktuell, ich schrieb ja, dass shNG nach dem Neustart ganz normal darauf zugreifen kann.
Aber ich vermute, dass das Plugin nur einmal versucht... ich versuch das nochmal zu Simulieren und melde mich mit den Erkenntnissen.

[TCr82]

Ok, ich habe das nochmal Simuliert mit dem Reconnect des Serial Ports - das Problem ist, dass du in _disconnect auch den Cycle Scheduler löschen tust, denke deswegen kommt es niemals zu dem wiederverbinden. Sieht auf jeden Fall so im Logfile aus, nach diesen Einträgen kommt einfach nix mehr.

2021-01-02 00:09:46 ERROR __init__ plugins.viessmann.cyclic KW_send_multiple_read_commands failed with IO error: write failed: [Errno 5] Input/output error -- (__init__.py:_KW_send_multiple_read_c
ommands:786)
2021-01-02 00:09:46 ERROR __init__ plugins.viessmann.cyclic Trying to reconnect (disconnecting, connecting -- (__init__.py:_KW_send_multiple_read_commands:787)
2021-01-02 00:09:46 DEBUG smartplugin plugins.viessmann.cyclic scheduler_get: name = plugins.viessmann.cyclic -- (smartplugin.py:scheduler_get:675)
2021-01-02 00:09:46 DEBUG smartplugin plugins.viessmann.cyclic scheduler_remove: name = plugins.viessmann.cyclic -- (smartplugin.py:scheduler_remove:660)
2021-01-02 00:09:46 INFO __init__ plugins.viessmann.cyclic Disconnected -- (__init__.py:_disconnect:524)
2021-01-02 00:09:46 DEBUG __init__ plugins.viessmann.cyclic cyclic command read took 0.0 seconds for 10 items -- (__init__.py:send_cyclic_cmds:367)

Als ich das damals Simuliert hatte, habe ich es wohl manuell über das Webinterface abgefragt....

[Morg]

Ja, da sollte unterschieden werden, ob disconnect eigentlich reconnect werden sollte oder ob das Plugin sich beendet... das kann ich anpassen.

[Sisamiwe]

Hallo,

danke Dir erstmal!

Was mich hier irritiert:
- cyclic liest erst Aussentemperatur (2,8) -> item Aussentemperatur
- cyclic liest dann Aussentemperatur_TP (2,8) -> item Aussentemperatur ...?

Wieso lässt du denn zwei Werte ins selbe Item schreiben?

Es sind 2 Items definiert, und die werden auch brav befüllt.

    allgemein:
        aussentemp:
            name: Aussentemperatur
            type: num
            viess_read: Aussentemperatur
            viess_read_cycle: 300
            viess_init: true
            database: true
        aussentemp_gedaempft:
            name: Aussentemperatur
            type: num
            viess_read: Aussentemperatur_TP
            viess_read_cycle: 300
            viess_init: true
            database: true

Hast du dafür (Aktuelle_Betriebsart_M2, command code 3301) ein eigenes Item definiert? Oder wird das nur über trigger_afterwrite angestoßen (so steht es ja im Log) und er weiß jetzt nicht, wo er das hinschreiben soll?

Das war noch ein Überbleibsel. Ich hatte basierend auf unserer vorherigen Diskussion das Item "Aktuelle Betriebsart" in shNG deaktiviert, aber die viess_trigger nicht beachtet. Ist korrigiert.

(btw - es gibt im Betriebsmodus keinen Eintrag für Partybetrieb, das ist so richtig?)

Ja, das ist so richtig. Der Betriebsmodus bezieht sich auf die grundlegende Einstellung (Heizung, Warmwasser, Schaltzeiten). Mit Partybetrieb (nichts anderes als dauerhaft Komfortemp) und Sparbetrieb (nicht anderes als dauerhalt Nachttemp) kann man das überlagern.

- Schreibanforderung Partybetrieb_M2 = True
-> wird geschrieben, Rückmeldung "Schreiben OK"

- Leseanforderung Partybetrieb_M2 "read after write"
-> wird gelesen, Rückmeldung Partybetrieb_M2 = False

==> die Anlage hat das Schreiben erfolgreich quittiert, aber anscheinend nicht umgeschaltet (oder noch nicht?)

Ja, so ist es. Der Schreibvorgang wird quittiert, aber es erfolgt kein Setzen und damit auch kein Umschalten.

ABER!

Hab den Fehler gefunden. Er liegt in der commands.py, denn auch hier gibt es mal wieder 2 Datenpunkte pro Eintrage (Partybetrieb, Sparbetrieb). Eines readonly und eines r/w. Beispiel:

Zustand Partybetrieb A1M1 0x2330 R/W     1.001 0=Aus,1=Ein Zustand Partybetrieb
Partybetrieb A1M1         0x2303 R       1.001 0=Aus,1=Ein Partybetrieb fuer Heizkreis A1M1

Erklärung: (1. Heizkreis)Im Partybetrieb wird unabhaengig von eingestellten Betriebs- und Zeitprogrammen geheizt und die Trinkwassererwaermung wird freigegen: die Zirkulationspumpe wird eingeschaltet. Der Partybetrieb wird automatisch beendet mit der naechsten Umschaltung (Schaltuhr) auf "Normale Raumtemperatur".

Somit muss ich die commands.py für KO1B anpassen.

[Morg]

Es sind 2 Items definiert, und die werden auch brav befüllt.

 allgemein:
aussentemp:
name: Aussentemperatur
type: num
viess_read: Aussentemperatur
viess_read_cycle: 300
viess_init: true
database: true
aussentemp_gedaempft:
name: Aussentemperatur
type: num
viess_read: Aussentemperatur_TP
viess_read_cycle: 300
viess_init: true
database: true

Dann ist entweder das Logging kaputt oder irgendwas stimmt bei dir nicht (also, bei deinem shng ) --

send_cyclic_cmds Triggering cyclic read command: Aussentemperatur
_build_command_packet Created command Aussentemperatur to be sent as hexstring: 4105000108000210 and as bytes: bytearray(b'A\x05\x00\x01\x08\x00\x02\x10')
_parse_response Response decoded to: commandcode: 0800, responsedatacode: 1, valuebytecount: 2, responsetypecode: 1
_parse_response Matched command Aussentemperatur and read transformed value 2.8 (integer raw value was 28) and byte length 2
_process_response Corresponding item Aussentemperatur for command Aussentemperatur
_process_response Updating item Aussentemperatur with value 2.8

send_cyclic_cmds Triggering cyclic read command: Aussentemperatur_TP
_build_command_packet Created command Aussentemperatur_TP to be sent as hexstring: 4105000155250282 and as bytes: bytearray(b'A\x05\x00\x01U%\x02\x82')
_parse_response Response decoded to: commandcode: 5525, responsedatacode: 1, valuebytecount: 2, responsetypecode: 1
_parse_response Matched command Aussentemperatur_TP and read transformed value 2.8 (integer raw value was 28) and byte length 2
_process_response Corresponding item Aussentemperatur for command Aussentemperatur_TP
_process_response Updating item Aussentemperatur with value 2.8

Schau mal in beiden Blöcken jeweils auf die vorletzte und die letzte Zeile...

---

Gut, wenn das noch ein Rest war, dann ist ja fein. Dann erklärt das deine Fehlermeldung.

---

Ja, so ist es. Der Schreibvorgang wird quittiert, aber es erfolgt kein Setzen und damit auch kein Umschalten.

ABER!

Hab den Fehler gefunden. Er liegt in der commands.py, denn auch hier gibt es mal wieder 2 Datenpunkte pro Eintrage (Partybetrieb, Sparbetrieb). Eines readonly und eines r/w.

Was mich dann irritiert ist, dass die Anlage den Schreibversuch auf ein readonly-Item eigentlich mit Fehler quittieren müsste, und nicht mit OK.

Aber gut...

Somit muss ich die commands.py für KO1B anpassen.

Schickst du mir dann bitte die Änderungen?

[Sisamiwe]

Schau mal in beiden Blöcken jeweils auf die vorletzte und die letzte Zeile...

Das kann ich erklären: Die beiden Items (wie oben gezeigt) hatten von mir den gleichen Wert beim Attribut "name" und damit in dict des Plugin auch die gleiche Bezeichnung; und in dem Moment hatten auch beide den gleichen Wert. (2.8) Funktioniert hat es trotzdem.
Nichtsdestotrotz habe ich den Wert eines Attributes angepasst.

Was mich dann irritiert ist, dass die Anlage den Schreibversuch auf ein readonly-Item eigentlich mit Fehler quittieren müsste, und nicht mit OK.

Das ist schon verwunderlich, aber gut. Mit den Änderungen in der Kommandos für die KO1B geht es nun.
Die commands.py mit den Änderungen ist im Anhang.

Beste Grüße

[Morg]

So, jetzt habe ich auch noch was -

ich habe dem Plugin mal einen Standalone-Modus verpasst. Heißt: das Plugin kann in seinem Ordner auf der Kommandozeile aufgerufen werden, z.B. mit

./__init__.py /dev/optolink

Dann versucht es, die angeschlossene Heizung zu identifizieren, erst mit P300, danach mit KW. Wenn es klappt, wird der Devicetyp, die Bezeichnung und das passende Protokoll ausgegeben.

Wenn ihr testen wollt, gibts die aktuelle Version unter https://github.com/Morg42/viessmann. Ihr braucht auf jeden Fall das Plugin. Ich habe die Liste der Gerätetypen angepasst, aber mit der alten commands.py geht es auch. Die Doku ist auch aktualisiert.

---

@Michael:
Dann hoffe ich, dass das Plugin trotzdem das richtige Item getroffen hat

Danke für die commands.py, das arbeite ich gleich ein.

[Sisamiwe]

Danke für die commands.py, das arbeite ich gleich ein.

Prima. Gib Bescheid, wenn Du fertig bist, dann ziehe ich mir die aktuelle Version und nehme sie produktiv

[Morg]

Ist schon drin.