Viessmann Plugin Neuentwicklung Python Hilfe

[Sisamiwe]

viess_update fehlte übrigens auch noch in der plugin.yaml, ich habs mal mit aufgenommen (dann allerdings logischerweise mit bool)

Wie meinst Du das?

Mit dem Log kann ich nicht wirklich was anfangen. Der letzte genannte Timer ist ein anderer (WW_Mi / A1M1_Mo) als der vorher berechnete, aber ich kann nicht sehe, woher das kommt. Dafür brauche ich das Logging aus der Datei, die ich oben angehängt habe.

Was ich damit sagen wollte, ist, dass alle Timer gelesen werden und auch dem entsprechenden Item zugewiesen werden

2020-12-23 06:39:56 DEBUG plugins.viessmann _process_response Updating item Timer_Warmwasser_Mi with value [{'An': '04:00', 'Aus': '04:40'}, {'An': '16:30', 'Aus': '17:10'}, {'An': '00:00', 'Aus': '00:00'}, {'An': '00:00', 'Aus': '00:00'}]

Dort aber nichts ankommt.

Ich mach dann nochmal ein anderes Log

DANKE soweit

[Morg]

Michael:

viess_update:

das ist seltsam. 1. ist im Plugin schon (immer) eine Abfrage drin gewesen "if item(): ...", also eine boolesche Prüfung, die auf 1, True, 'X' reagieren sollte und auf 0, False, '' nicht. Geht bei mir auch genau so mit True/False und 1/0. Jede Änderungen kommt im Zweig "elif self.has_iattr(...)" an, aber die Prüfung lässt nur True/1 durch.

Wieso das bei dir so nicht geht, weiß ich nicht. Du könntest in der Zeile vor dem "if item():" (bei mir 311) Folgendes einfügen:

self.logger.debug(f'{item} called as viess_update with value {item()}')

Dann schreibt er dir immer ins Log, wenn das Item geändert wurde, und wenn er dann das Lesen anstößt, kommt die nächste Logzeile 'Reading of all values/items has been requested'. Dann könnte man nochmal untersuchen, ob oder was da genau passiert.

viess_update fehlte übrigens auch noch in der plugin.yaml, ich habs mal mit aufgenommen (dann allerdings logischerweise mit bool)

Ansonsten kannst du auch im item enforce_updates = True setzen und den autotimer rauslassen. Ob das Item auf True bleibt oder nicht, ist ja letztlich egal.

Timer:

Mit dem Log kann ich nicht wirklich was anfangen. Der letzte genannte Timer ist ein anderer (WW_Mi / A1M1_Mo) als der vorher berechnete, aber ich kann nicht sehe, woher das kommt. Dafür brauche ich das Logging aus der Datei, die ich oben angehängt habe.

[Sisamiwe]

Morg

ich habe noch ein zwei Dinge gefunden:

viess_update:

Das Attribut kann genutzt werden, um alle Items neu aus der Heizung auszulesen, d.h. wenn das Item geändert wird, wird ein Update-Zyklus angestoßen.
Ich nutze es mit autotimer: 1 = 0, um das Item wieder auf 0 zu setzten. Dadurch wird aber ein zweiter Lesezyklus angestoßen. Kannst Du das im Plugin noch abfangen, dass der Lesezyklus nur gestartet wird, wenn der Wert des Items == 1 ist?

Timer:

Bei den Timern soll es 2 Varianten geben.

A) Alle Timer einer Applikation in einem DICT im UZSU-Format
Das Attribut im Item ist "viess_timer" mit der Wert der jeweiligen Applikation ("Timer_A1M1"). Das Plugin sich sich anhand des Wertes die Datenpunkte (alle, die so beginnen, wieder Wert ist) aus der command zusammen, sortiert das Mo - So und fragt dann dieses DICT nach einander ab.
Das funktioniert.

B) Alle Viessmann-Timer einzeln (Applikation und Tage einzeln)
Das Attribut hier ist das normale "viess-read" mit dem Wert des Namen des Datenpunktes aus der command. Hier erfolgt ein normales Auslesen und über die Unit die entsprechende Formatierung.

Nach meinem DEBUG Log wird der Wert aus gelesen, formatiert und in das Item geschrieben. Nur dort kommt er nicht an.

Hier mal ein Log:

2020-12-23  06:39:56 DEBUG    plugins.viessmann _send_command    Got a new read job: Command Timer_Warmwasser_Mi
2020-12-23  06:39:56 DEBUG    plugins.viessmann _build_command_packet Build read packet for command Timer_Warmwasser_Mi
2020-12-23  06:39:56 DEBUG    plugins.viessmann _build_command_packet Created command Timer_Warmwasser_Mi to be sent as hexstring: 410500012110083f and as bytes: bytearray(b'A\x05\x00\x01!\x10\x08?')
2020-12-23  06:39:56 DEBUG    plugins.viessmann _send_command_packet Successfully sent packet: 410500012110083f
2020-12-23  06:39:56 DEBUG    plugins.viessmann _send_command_packet Trying to receive 17 bytes of the response
2020-12-23  06:39:56 DEBUG    plugins.viessmann _send_command_packet Received 17 bytes chunk of response as hexstring 06410d010121100820248389ffffffff94 and as bytes b'\x06A\r\x01\x01!\x10\x08 $\x83\x89\xff\xff\xff\xff\x94'
2020-12-23  06:39:56 DEBUG    plugins.viessmann _parse_response  Response decoded to: commandcode: 2110, responsedatacode: 1, valuebytecount: 8, responsetypecode: 1
2020-12-23  06:39:56 DEBUG    plugins.viessmann _parse_response  Rawdatabytes formatted: 20248389ffffffff and unformatted: bytearray(b' $\x83\x89\xff\xff\xff\xff')
2020-12-23  06:39:56 DEBUG    plugins.viessmann _parse_response  Matched command Timer_Warmwasser_Mi and read transformed timer [{'An': '04:00', 'Aus': '04:40'}, {'An': '16:30', 'Aus': '17:10'}, {'An': '00:00', 'Aus': '00:00'}, {'An': '00:00', 'Aus': '00:00'}] and byte length 8
2020-12-23  06:39:56 DEBUG    plugins.viessmann _process_response Corresponding item Timer_Warmwasser_Mi for command Timer_Warmwasser_Mi
2020-12-23  06:39:56 DEBUG    plugins.viessmann _process_response Updating item Timer_Warmwasser_Mi with value [{'An': '04:00', 'Aus': '04:40'}, {'An': '16:30', 'Aus': '17:10'}, {'An': '00:00', 'Aus': '00:00'}, {'An': '00:00', 'Aus': '00:00'}]
2020-12-23  06:39:56 DEBUG    plugins.viessmann _process_response process_response_timer: 2110
2020-12-23  06:39:56 DEBUG    plugins.viessmann _process_response Viessmann timer dict: {'Timer_A1M1': {'Timer_A1M1_Mo': [{'An': '06:00', 'Aus': '07:30'}, {'An': '18:30', 'Aus': '19:30'}, {'An': '00:00', 'Aus': '00:00'}, {'An': '00:00', 'Aus': '00:00'}], 'T

Hilft Dir das?

[Morg]

Michael hatte mir Feedback gegeben, dass die Timer nicht so in die Items übertragen werden, wie er das wollte; es war aber nicht sicher, ob das ggf. schon vorher nicht geklappt hatte...

Also, ich habe jetzt den Codelauf nochmal detailliert und gründlich parallel verfolgt (aktuelle Version und die, bevor ich parse_response() zerlegt habe) --

Wenn nicht bei der Über- und Rückgabe von Variablen, Werten, Dicts und Items etwas verändert wird, ohne dass ich das jetzt erkennen konnte, sollten beide Varianten dasselbe tun. Ergo müsste das Verhalten "nach außen" unverändert sein.

Ich habe mal eine Version angehängt, die etwas aggressiver loggt - vorsicht, bewusst alles zusätzliche Logging auf ERROR und beginnt mit '#####'. Bitte nicht für was anderes benutzen; die ist ansonsten identisch mit der aktuellen von GitHub.

Vielleicht fällt die ja schon selber was auf, wenn du ins Log schaust, ansonsten poste mir das hier rein, dann schau ich das mal durch. Wär' doch gelacht, wenn wir das nicht bis Weihnachten geklärt kriegen

[stoepf]

Die dritte Seite ist schon genial.
Allerdings ist finde ich die Plugin-Funktionen fast noch genialer. Da kann ich jetzt per Script einfach mal schauen, auf welche Adressen meine Heizung noch so reagiert.

Danke für das tolle Plugin.

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

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

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]

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

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

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

[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

[Morg]

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

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

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!