Viessmann Plugin Neuentwicklung Python Hilfe

[TCr82]

Ich habe da noch ein Problem beim schreiben - hab aber bis jetzt nur eine Adresse versucht zu schreiben:

Fehlermeldung:

2021-01-02 21:20:09 ERROR lib.item.item Item technik.heizung.HK1.Partybetrieb: problem running <bound method Viessmann.update_item of <plugins.viessmann.Viessmann object at 0xb2efe8e0>>: 'Command_bytes_write'
Traceback (most recent call last):
File "/usr/local/smarthome/lib/item/item.py", line 1349, in __update
method(self, caller, source, dest)
File "/usr/local/smarthome/plugins/viessmann/__init__.py", line 306, in update_item
if not self._send_command(commandname, value):
File "/usr/local/smarthome/plugins/viessmann/__init__.py", line 695, in _send_command
(packet, responselen) = self._build_command_packet(commandname, value)
File "/usr/local/smarthome/plugins/viessmann/__init__.py", line 1255, in _build_command_packet
payloadlength = int(self._controlset['Command_bytes_write']) + int(commandvaluebytes)
KeyError: 'Command_bytes_write'

Item Definition:

technik:
    heizung:
        HK1:
            Partybetrieb:
                name: HK1 Partybetrieb
                type: bool
                viess_read: Partybetrieb_A1M1
                viess_read_cycle: 60
                viess_init: true
                viess_send: true
                mqtt_topic: Heizung/HK1/Party
                mqtt_retain: true

commandset Definition:

        'Partybetrieb_A1M1':                          {'addr': '2303', 'len': 1, 'unit': 'IUBOOL',  'set': True, 'min_value': 0,   'max_value': 1},         # Partybetrieb A1M1

Lesen scheint aber zu funktionieren.

[TCr82]

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.

Funktioniert, denke ich:

root@heizung:/usr/local/smarthome/plugins/viessmann# ./__init__.py /dev/ttyOptolink
This is Viessmann plugin running in standalone mode
================================================== =
Trying protocol P300 on device /dev/ttyOptolink
Communication could not be established using protocol P300.
Trying protocol KW on device /dev/ttyOptolink
Device ID is 2098, device type is V200KW2 using protocol KW
Done.

[Morg]

Sorry für die Verzögerung, war anderweitig beschäftigt.

n f''-Strings kann ich keine einfachen Anführungszeichen benutzen, da müssen doppelte hin (bei res, 'unknown').

Auf github gefixt.

[Sisamiwe]

Morg
Hab die aktuelle Version des Plugins testen wollen und bekomme beim Start schon einen Fehler:

2021-01-02 19:37:57 ERROR lib.plugin __init__ Plugin 'viessmann' exception during import of __init__.py: invalid syntax (__init__.py, line 2067)
Traceback (most recent call last):
File "/usr/local/smarthome/lib/plugin.py", line 531, in __init__
exec("import {0}".format(classpath))
File "<string>", line 1, in <module>
File "/usr/local/smarthome/plugins/viessmann/__init__.py", line 2067
print(f'Device ID is {res}, device type is {commands.devicetypes.get(res, 'unknown')} using protocol {proto}')
^
SyntaxError: invalid syntax

Schaust Du bitte nochmal?

Ach ja:

2021-01-02 19:37:32 WARNING __main__ __init__ -------------------- Init SmartHomeNG 1.7.2.master (3828810e) --------------------
2021-01-02 19:37:32 WARNING __main__ __init__ Running in Python interpreter 'v3.7.3 final' on Linux-4.14.86-v7+-armv7l-with-debian-10.7 (pid=6741)

[Morg]

Nur zur Sicherheit: in "meinem" Repo ist im Moment immer die Version mit allen aktuellen Erweiterungen. Ich versuche, die möglichst alle vor dem Release noch "rein" zu bekommen, dann sollte im Idealfall nach dem Release die master-Version gleichzeitig (erstmal) die aktuellste.

Ob ihr dann "meine" Version als priv_viessmann nutzt oder die aus dem Release, ist dann ja euch überlassen. Ich habe teilweise beides

[Morg]

Ist schon drin.

[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]

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]

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]

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]

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]

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

[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....

[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]

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ß