Viessmann Plugin Neuentwicklung Python Hilfe

[TCr82]

Vielleicht hat sich auch nur eine Komponente zwischen Plugin und serieller Schnittstelle verschluckt

hab eben nochmal im Log nachgesehen und das hier gefunden:

zgrep -e cp210x -e usb /var/log/syslog.2.gz
Dec 19 03:52:26 heizung kernel: [719849.478843] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Dec 19 03:52:26 heizung kernel: [719849.487125] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Dec 19 03:52:26 heizung kernel: [719849.621867] usb 1-1.5: USB disconnect, device number 8
Dec 19 03:52:26 heizung kernel: [719849.622760] cp210x ttyUSB0: failed set request 0x12 status: -19
Dec 19 03:52:26 heizung kernel: [719849.629190] cp210x ttyUSB0: failed set request 0x0 status: -19
Dec 19 03:52:26 heizung kernel: [719849.637579] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
Dec 19 03:52:26 heizung kernel: [719849.637709] cp210x 1-1.5:1.0: device disconnected
Dec 19 03:52:27 heizung kernel: [719849.862086] usb 1-1.5: new full-speed USB device number 9 using dwc_otg
Dec 19 03:52:27 heizung kernel: [719849.966891] usb 1-1.5: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
Dec 19 03:52:27 heizung kernel: [719849.966919] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 19 03:52:27 heizung kernel: [719849.966938] usb 1-1.5: Product: CP2102 USB to UART Bridge Controller
Dec 19 03:52:27 heizung kernel: [719849.966956] usb 1-1.5: Manufacturer: Silicon Labs
Dec 19 03:52:27 heizung kernel: [719849.966974] usb 1-1.5: SerialNumber: 0001
Dec 19 03:52:27 heizung kernel: [719849.980912] cp210x 1-1.5:1.0: cp210x converter detected
Dec 19 03:52:27 heizung kernel: [719849.986434] usb 1-1.5: cp210x converter now attached to ttyUSB1
Dec 19 07:08:14 heizung kernel: [731597.205886] usb 1-1.5: USB disconnect, device number 9
Dec 19 07:08:14 heizung kernel: [731597.208884] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
Dec 19 07:08:14 heizung kernel: [731597.209093] cp210x 1-1.5:1.0: device disconnected
Dec 19 07:08:14 heizung kernel: [731597.433508] usb 1-1.5: new full-speed USB device number 10 using dwc_otg
Dec 19 07:08:14 heizung kernel: [731597.543550] usb 1-1.5: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
Dec 19 07:08:14 heizung kernel: [731597.543575] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 19 07:08:14 heizung kernel: [731597.543593] usb 1-1.5: Product: CP2102 USB to UART Bridge Controller
Dec 19 07:08:14 heizung kernel: [731597.543611] usb 1-1.5: Manufacturer: Silicon Labs
Dec 19 07:08:14 heizung kernel: [731597.543629] usb 1-1.5: SerialNumber: 0001
Dec 19 07:08:14 heizung kernel: [731597.547268] cp210x 1-1.5:1.0: cp210x converter detected
Dec 19 07:08:14 heizung kernel: [731597.552039] usb 1-1.5: cp210x converter now attached to ttyUSB1

das könnte vom Zeitpunkt hinkommen, denn er zeigte seit ca 2 Tagen keine Daten mehr an... Gibt es da eine Möglichkeit das im Plugin zu erkennen? Vielleicht einfach auf den I/O Error reagieren und den Serialport neu öffnen?

Krass ist, dass er zur Neuerkennung von 4 bis 7 Uhr gebraucht hat.

[Morg]

Da ist aber irgendwas faul. Da hat sich der USB-Lesekopf bzw. so wie es aussieht der USB-Treiber aufgehängt. Warum, kann ich nicht sagen. Fehler im Treiber oder Fehler im Kopf. Das Kabel war dran, aber der PC konnte nicht mehr mit dem Kopf sprechen. Man sieht ja auch, dass der immer wieder ausgeworfen wurde (oder "rausgefallen" ist) und neu verbunden wurde.

Er hat für die Neuerkennung nicht von 4 bis 7 gebraucht. Um 3:52 (erste Meldung) hängt der Treiber, der USB-Stack hat das Gerät rausgeworfen und wieder neu verbunden, gem. Log soll er wieder da gewesen sein.
Um 7:08 war er auf einmal wieder weg und danach gleich wieder da.

Solche Abbrüche sind aber vom Plugin aus kaum in den Griff zu bekommen. Erstens ist das Problem eines außerhalb der Reichweite von shng (weder kann shng den Stecker neu raus und reinstecken, noch einen Treiber ent- und neuladen). Solange der nicht stabil ist, wartet sich das Plugin tot; im schlimmsten Fall wartet er auf einen blocking call und bleibt "hängen".

Probier doch mal nen anderen USB-Port, ggf. ein anderes Kabel, wenn das nicht fest am Lesekopf ist.

[stoepf]

Hab heute auch mal ein Update auf die letzte Version gemacht. Seitdem geht das zyklische Update nicht mehr richtig.
Laut Debugausgaben wird nur noch ein Item gelesen.

Meine Plugin-Konfiguration

viessmann:
protocol: P300
plugin_name: viessmann
heating_type: V200KO1B
serialport: /dev/ttyUSB0

Und hier das Log:

2020-12-21 22:58:47 INFO plugins.viessmann Triggering cyclic command read
2020-12-21 22:58:47 DEBUG plugins.viessmann Triggering cyclic read command: Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Got a new read job: Command Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Build read packet for command Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Created command Warmwasser_Temperatur to be sent as hexstring: 4105000108040214 and as bytes: bytearray(b'A\x05\x00\x01\x08\x04\x02\x14')
2020-12-21 22:58:47 DEBUG plugins.viessmann Successfully sent packet: 4105000108040214
2020-12-21 22:58:47 DEBUG plugins.viessmann Trying to receive 11 bytes of the response.
2020-12-21 22:58:47 DEBUG plugins.viessmann Received 11 bytes chunk of response as hexstring 064107010108040201021a and as bytes b'\x06A\x07\x01\x01\x08\x04\x02\x01\x02\x1a'
2020-12-21 22:58:47 DEBUG plugins.viessmann Response decoded to: commandcode: 0804, responsedatacode: 1, valuebytecount: 2, responsetypecode: 1
2020-12-21 22:58:47 DEBUG plugins.viessmann Rawdatabytes formatted: 0102 and unformatted: bytearray(b'\x01\x02')
2020-12-21 22:58:47 DEBUG plugins.viessmann Corresponding Item: viessmann.Warmwasser.Temperatur; Corresponding commandname: Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Unit defined to IU10 with config {'unit_de': 'INT unsigned 10', 'type': 'integer', 'signed': False, 'read_value_transform': '10'}.
2020-12-21 22:58:47 DEBUG plugins.viessmann Matched command Warmwasser_Temperatur and read transformed value 51.3 (integer raw value was 513) and byte length 2.
2020-12-21 22:58:47 DEBUG plugins.viessmann Updating item viessmann.Warmwasser.Temperatur with value 51.3
2020-12-21 22:58:47 DEBUG plugins.viessmann Triggering cyclic read command: Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Got a new read job: Command Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Build read packet for command Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Created command Warmwasser_Temperatur to be sent as hexstring: 4105000108040214 and as bytes: bytearray(b'A\x05\x00\x01\x08\x04\x02\x14')
2020-12-21 22:58:47 DEBUG plugins.viessmann Successfully sent packet: 4105000108040214
2020-12-21 22:58:47 DEBUG plugins.viessmann Trying to receive 11 bytes of the response.
2020-12-21 22:58:47 DEBUG plugins.viessmann Received 11 bytes chunk of response as hexstring 064107010108040201021a and as bytes b'\x06A\x07\x01\x01\x08\x04\x02\x01\x02\x1a'
2020-12-21 22:58:47 DEBUG plugins.viessmann Response decoded to: commandcode: 0804, responsedatacode: 1, valuebytecount: 2, responsetypecode: 1
2020-12-21 22:58:47 DEBUG plugins.viessmann Rawdatabytes formatted: 0102 and unformatted: bytearray(b'\x01\x02')
2020-12-21 22:58:47 DEBUG plugins.viessmann Corresponding Item: viessmann.Warmwasser.Temperatur; Corresponding commandname: Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Unit defined to IU10 with config {'unit_de': 'INT unsigned 10', 'type': 'integer', 'signed': False, 'read_value_transform': '10'}.
2020-12-21 22:58:47 DEBUG plugins.viessmann Matched command Warmwasser_Temperatur and read transformed value 51.3 (integer raw value was 513) and byte length 2.
2020-12-21 22:58:47 DEBUG plugins.viessmann Updating item viessmann.Warmwasser.Temperatur with value 51.3
2020-12-21 22:58:47 DEBUG plugins.viessmann Triggering cyclic read command: Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Got a new read job: Command Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Build read packet for command Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Created command Warmwasser_Temperatur to be sent as hexstring: 4105000108040214 and as bytes: bytearray(b'A\x05\x00\x01\x08\x04\x02\x14')
2020-12-21 22:58:47 DEBUG plugins.viessmann Successfully sent packet: 4105000108040214
2020-12-21 22:58:47 DEBUG plugins.viessmann Trying to receive 11 bytes of the response.
2020-12-21 22:58:47 DEBUG plugins.viessmann Received 11 bytes chunk of response as hexstring 064107010108040201021a and as bytes b'\x06A\x07\x01\x01\x08\x04\x02\x01\x02\x1a'
2020-12-21 22:58:47 DEBUG plugins.viessmann Response decoded to: commandcode: 0804, responsedatacode: 1, valuebytecount: 2, responsetypecode: 1
2020-12-21 22:58:47 DEBUG plugins.viessmann Rawdatabytes formatted: 0102 and unformatted: bytearray(b'\x01\x02')
2020-12-21 22:58:47 DEBUG plugins.viessmann Corresponding Item: viessmann.Warmwasser.Temperatur; Corresponding commandname: Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Unit defined to IU10 with config {'unit_de': 'INT unsigned 10', 'type': 'integer', 'signed': False, 'read_value_transform': '10'}.
2020-12-21 22:58:47 DEBUG plugins.viessmann Matched command Warmwasser_Temperatur and read transformed value 51.3 (integer raw value was 513) and byte length 2.
2020-12-21 22:58:47 DEBUG plugins.viessmann Updating item viessmann.Warmwasser.Temperatur with value 51.3
2020-12-21 22:58:47 DEBUG plugins.viessmann Triggering cyclic read command: Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Got a new read job: Command Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Build read packet for command Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Created command Warmwasser_Temperatur to be sent as hexstring: 4105000108040214 and as bytes: bytearray(b'A\x05\x00\x01\x08\x04\x02\x14')
2020-12-21 22:58:47 DEBUG plugins.viessmann Successfully sent packet: 4105000108040214
2020-12-21 22:58:47 DEBUG plugins.viessmann Trying to receive 11 bytes of the response.
2020-12-21 22:58:47 DEBUG plugins.viessmann Received 11 bytes chunk of response as hexstring 064107010108040201021a and as bytes b'\x06A\x07\x01\x01\x08\x04\x02\x01\x02\x1a'
2020-12-21 22:58:47 DEBUG plugins.viessmann Response decoded to: commandcode: 0804, responsedatacode: 1, valuebytecount: 2, responsetypecode: 1
2020-12-21 22:58:47 DEBUG plugins.viessmann Rawdatabytes formatted: 0102 and unformatted: bytearray(b'\x01\x02')
2020-12-21 22:58:47 DEBUG plugins.viessmann Corresponding Item: viessmann.Warmwasser.Temperatur; Corresponding commandname: Warmwasser_Temperatur
2020-12-21 22:58:47 DEBUG plugins.viessmann Unit defined to IU10 with config {'unit_de': 'INT unsigned 10', 'type': 'integer', 'signed': False, 'read_value_transform': '10'}.
2020-12-21 22:58:47 DEBUG plugins.viessmann Matched command Warmwasser_Temperatur and read transformed value 51.3 (integer raw value was 513) and byte length 2.
2020-12-21 22:58:47 DEBUG plugins.viessmann Updating item viessmann.Warmwasser.Temperatur with value 51.3
2020-12-21 22:58:47 DEBUG plugins.viessmann cyclic command read took 0.3 seconds for 4 items

[Morg]

Stimmt. Mea culpa, kommt davon, wenn man die Schleifenvariable in der for-Anweisung ändert, aber nicht im Innern der Schleife..

ist in github gefixt. Ansonsten Zeile 351 in _send_cyclic_cmds(), statt _commandname_by_commandcode(commandcode) muss es _commandname_by_commandcode(addr) heißen.

[Morg]

So, Weihnachten ist nahe, ich will heute schonmal ein paar Geschenke verteilen:

• Webinterface ist aktualisiert mit dritter Seite: alle (für Protokoll und Anlage) bekannten Adressen mit Definition und der Möglichkeit, jeweils einzeln manuell auszulesen. Das Ergebnis wird im WebIf angezeigt, aber nicht in die Items übernommen (nicht alle Adressen sind ja Items zugewiesen). Da das zum Testen gedacht ist, schreibt er gar nicht in die Items.
• Die Plugin-Funktion 'read_addr(addr)' stößt das Lesen der (definierten) Adresse manuell an und gibt das Ergebnis als Rückgabewert zurück, None bei Fehler. Das wird intern vom WebIf für die o.g. Funktion genutzt, kann aber auch manuell verwendet werden.
• Die Plugin-Funktion 'read_temp_addr(addr, len, unit)' stößt das Lesen beliebiger und v.a. nicht definierter Adressen an. addr ist die vierstellige Hex-Adresse, len ist die erwartete Länge der Antwort in Bytes (1-8) und unit ist das Unitkürzel für die Einheitenumwandlung. unit muss im unitset für das aktuelle Protokoll definiert sein, im Zweifelsfall erstmal 'IUNON' oder 'IUINT'.
  Wenn die Adresse bekannt ist, wird wie gehabt verfahren, wenn die Adresse nicht bekannt ist, wird ein temporärer Eintrag im commandset erzeugt und versucht, die Adresse zu lesen. Das Ergebnis wird zurückgegeben.

Für die Plugin-Funktionen kann z.B. die folgende Logik verwendet werden:

#!/usr/bin/env python3
# viess_test.py

plug = sh.plugins.return_plugin('viessmann')

if plug is not None:
    value = plug.read_temp_addr('0802', 2, 'IUINT')
    print(f'Wert: {value}')

Die Daten müssen manuell eingetragen werden (Admin-UI...), das Ergebnis wird auf der Konsole ausgegeben. Sobald der Wert in value vorliegt, könnt ihr damit machen, was ihr wollt. Loggen, zuweisen, an andere Plugins senden, oder einfach ignorieren.

Aktuelle Version ist in github

[Morg]

Michael, bitte teste mal, ob bei dir die ganzen Timer-Funktionen gehen; nicht, dass ich da was kaputt gemacht habe.

Es geht dabei nicht um (Langzeit-)Stabilität, sondern nur darum, dass es (noch) geht.... danke!

[Sisamiwe]

Michael, bitte teste mal, ob bei dir die ganzen Timer-Funktionen gehen; nicht, dass ich da was kaputt gemacht habe.

Guten Morgen,

aktuell funktioniert das Plug in nicht, da ich scheinbar noch auf Python 3.5 bin.

test_pythoncompatibility plugin 'viessmann': The Python version 3.5 is too old for this plugin. It requires at least version v3.6. The plugin was not loaded.

???

[Morg]

Oh, blöd. Schade, dann muss ich das nochmal umstellen... du wolltest nicht zufällig aktualisieren?

[Morg]

Probier noch mal, ich hab die Version von gestern in den Branch '3.6' geschoben und den Master wieder für Python 3.5 kompatibel gemacht...

Ich hatte gestern mit msinn gesprochen, und das nächste Release soll wohl generell mindestens Python 3.6 benötigen, 3.5 ist schon end-of-life und wird nicht mehr aktualisiert. Aktuell ist derzeit wohl 3.9...

Insofern hoffe ich, dass der Luxus von zwei parallelen Versionen nicht zu lange auszuhalten ist

[stoepf]

Danke für den schnellen Fix. Hatte schon an meiner Konfiguration gezweifelt, man sollte halt nicht zu viel auf einmal ändern.

Du hast aber leider einen neuen Fehler eingebaut.
Zeile 1384: "devicetypebytes" muss durch "serialnummerbytes" ersetzt werden.

Meine Heizung meldet sich übrigens als Anlagentyp "20CB". Bin bisher mit meine Konfiguration als "V200KO1B" ganz gut gefahren.
Leider blick ich mit den Typen nicht so ganz durch, laut vcontrold heißt die "VScotHO1". Macht es Sinn da noch nen neuen Typ anzulegen? Würde ich dann liefern, wenn es bei mir läuft.

[TCr82]

Solche Abbrüche sind aber vom Plugin aus kaum in den Griff zu bekommen. Erstens ist das Problem eines außerhalb der Reichweite von shng (weder kann shng den Stecker neu raus und reinstecken, noch einen Treiber ent- und neuladen). Solange der nicht stabil ist, wartet sich das Plugin tot; im schlimmsten Fall wartet er auf einen blocking call und bleibt "hängen".

Naja, dass das Plugin den Treiber neu läd - dass meine ich ja auch nicht. Nur im falle des I/O Fehler versuchen den Port neu zu öffnen. Wenn ich das richtig sehe, hast du das zb auch schon in _KW_send_multiple_read_commands eingebaut?! Nur in _send_command_packet reagierst du nicht mit einem reconnect auf die IOError Exception.

Außerdem kann das auch noch eine eigene Exception sein, vom Typ serial.SerialException, erst ab 3.5 ist es von Typ IOError

Probier doch mal nen anderen USB-Port, ggf. ein anderes Kabel, wenn das nicht fest am Lesekopf ist.

Evtl hat es ja auch generell was mit dem Raspi zu tun... das Kabel ist fest am Kopf verbunden.

Das Problem scheint auch nicht ganz unbekannt zu sein.

Dort war es letztendlich die Leuchtstoffröhre, was bei mir Prizipiell auch in frage käme...

Aber auf jeden Fall tritt das wohl sehr selten auf, mir ist es bis jetzt nie vorher aufgefallen.

EDIT: ach und ein fettes Danke, für die neuste Änderung, werde ich gleich mal testen.

[Morg]

stoepf : danke, das war ja zum Glück nur im Logging...

Zum Devicetype:

wenn die Konfiguration der V200KO1B bei dir gut läuft, dann lass es doch so. Wenn dir Werte fehlen, dann kopiere den Commandset für die V200KO1B und mach' den neu für VScotHO1. DT 20CB ist in der commands.py auch als VScotHO1 definiert.

Letztlich sagst du dem Plugin, mit welcher Befehlsdefinition es arbeiten soll. Solange das für dich funktioniert, ist alles fein.
Ansonsten nehme ich PRs für neue Typen (oder die Ausschnitte aus der commands.py) gern an.

Fix ist online

[Morg]

TCr82

Doch, auch _send_command_packet hat die "if not connected: connect()"- Schleife drin. Beide Funktionen arbeiten ja mehr oder weniger auf der selben Ebene. Die KW-Routine muss dabei einige "high level"-Methoden umgehen, um den Besonderheiten (alle Kommandos hintereinander weg, keine erneute Synchronisation, kein Start-Byte) umsetzen zu können.

edit: jetzt sehe ich, was du meinst - bei IOError im Handler noch disconnect() aufrufen. Ja, das kann ich noch nachpflegen.

Das "reconnecten" ist eigentlich vor jedem Schreibvorgang vorhanden. Es gibt nur keine verlässliche Möglichkeit, eine abgebrochene serielle Verbindung zu erkennen, ohne zu schreiben. Insofern kann ich den Fehler möglicherweise gar nicht ohne weiteres "vorher" abfangen. Vielleicht fällt mir da aber noch was zu ein.

Die SerialException gibt es immer noch, aber seit 2.5 (nicht 3.5) ist die von IOError abgeleitet, nicht mehr direkt von Exception. Damit erbt sie die Möglichkeiten von IOError. Und wenn ich IOError abfange, bleibt die SerialException eben auch hängen. Das ändert aber nichts daran, ob oder wann ich den Fehler erkenne.

Hast du Leuchtstoffröhren?

[Morg]

So, jetzt nochmal langsam:

Die Kernroutinen in _send_command_packet() und _KW_send_multiple_read_command() sind eigentlich größtenteils identisch, von der Struktur her sowieso.

Vor Start wird mit if not self._connected: [...] self._connect() die Verbindung neu aufgebaut - wenn er weiß, dass sie weg ist. (s. letzter Beitrag).

Der innere Block reagiert auf Fehler nur mit einem "raise", gibt die Exception also weiter, und der äußere try-Block fängt die dann ab. Beide Routinen haben "ganz unten" dann den Block mit

except IOError as io:
    self._disconnect()

so dass hier auf einen IOError immer der Verbindungsabbruch (auch logisch) erzwungen wird und beim nächsten Verbindungsversuch dann self._connected == False ist und self._connect() aufgerufen wird.

Da sehe ich jetzt keine Lücke - außer, dass er den IOError eben erst erkennt, wenn er zu schreiben versucht. Aber da wüsste ich noch nicht, wie ich das anders lösen sollte.

[Morg]

Und noch einer - ich habe es endlich geschafft, das Webinterface mit Ajax zu bestücken. Schaut euch mal die dritte Seite an, danke für die Idee an TCr82 !

Aus meiner Sicht wäre das jetzt erstmal genug fürs Release.

Habt ihr noch Ideen, gibt es noch offene Probleme oder Fehler?