Viessmann Plugin Neuentwicklung Python Hilfe

[Morg]

So, ich hab zwar kein weiteres Feedback bekommen, aber ich wollte doch noch mal...

Die neue Version 1.2.0 hat jetzt folgende Funktionen:

• für das KW-Protokoll scheint das Syncing nochmal stabiler geworden zu sein (jedenfalls bei mir); durchgängig teils im ersten, immer im zweiten Versuch
• für das KW-Protokoll habe ich den Code ergänzt um Routinen zum "bulk"-Lesen von Werten. Die habe ich für den initial_read und den cyclic_read entsprechend eingebaut. Die Lesezeiten im cyclic sind von vorher ca. 40 Sekunden für 21 Items auf ca. 2 Sekunden für 21 Items gesunken und damit in der Größenordnung von P300. Wenn ein Lesefehler auftritt, wird allerdings der gesamte "Zyklus" verworfen, weil sich das nur in einem Rutsch lesen lässt.
• Der cyclic_read-Code reagiert jetzt schneller darauf, wenn shng beendet wird und hängt sich nicht mehr auf (und startet sich auch nicht selbst wieder neu...)
• Das Locking habe ich nochmal überarbeitet und etwas "sicherer" gemacht
• Die Codeanteile, die "normale" Werte in die binären Unit-Werte konvertieren und die aus dem Kommandonamen den entsprechenden Byte-String erzeugen, habe ich ausgelagert und etwas angepasst, damit ich die für die KW-Routinen wiederverwenden kann
• Das Web-Interface habe ich mal komplett überarbeitet, vereinfacht, Lücken geschlossen und komplett einheitlich de/en übersetzt. Es kann allerdings immer noch nur anzeigen

Mehr habe ich (noch) nicht geschafft - bzw. vergessen, was ich noch getan hätte Bei mir läuft es sowohl in P300 als auch in KW fehlerfrei.

Der Code ist im Repo, probiert bitte nochmal aus, insbesondere die KW-Guys

[Morg]

Nachtrag:

Ich habe eine neue Einheit "IUPR" eingefügt, die den passenden Werteumfang abbildet und diese für den Mischer gesetzt. Wenn du die aktuelle Version nochmal von github holst, kannst du das probieren.

[Morg]

ne, das kam schon von Anfang an und immer wieder.

Wenn es sich wieder fängt, dann ist es nicht so schlimm. Schöner wärs, wenn der Sync stabiler wäre, aber das kann ich hier eben nicht testen.

Kann da auch gerne mal ein Debug Log über X Minuten laufen lassen und anhängen. Gibt mir kurz nochmal bescheid wie lange für dich interessant/nützlich ist.

Ne, ich bräuchte mal ein Debuglog, wenn er den Mischerwert liest.

Aber in deiner jetzigen Konfiguration kann das nicht klappen. IU100 mit Länge 1 ist ein Byte, also 0-255, und das wird durch 100 geteilt. Also kann er Werte von 0 bis 2,55 ausgeben, das funktioniert nicht für Prozent.

Im Original (in deiner vcontrold-Konfiguration) ist das ein skaliertes Byte, also Werte der Heizung zwischen 0 und 255 müssen auf 0..100 umgerechnet werden. Das ist derzeit als Unit noch nicht vorhanden, dafür muss ich nochmal den Code anpassen.

Aus dem Debuglog sollte sich aber ergeben, ob das halbwegs passt. Teile die Werte einfach durch 2.5 (bzw. 2.55), dann hast du die Prozentwerte.

Gibt mal bitte Bescheid, ob das passt.

[TCr82]

Wie ist das bei dir, sporadisch einzeln, sporadisch in Rudeln oder ständig dazwischen? Vielleicht müssen wir dann das Timing noch etwas verbessern... und ist das von Anfang an so, oder passiert das "irgendwann" (nach einer bestimmten Zeit?)

ne, das kam schon von Anfang an und immer wieder.

Kann da auch gerne mal ein Debug Log über X Minuten laufen lassen und anhängen. Gibt mir kurz nochmal bescheid wie lange für dich interessant/nützlich ist.

... also längere Zeit im cycle lassen, oder weniger Werte abfragen.

Ich kann das gerne mal hochdrehen. Aber er bekommt ja alle.

Zu der commands.py: kannst du mir einfach die neue Datei schicken? Oder einen PR auf mein Repo machen?

Ja, kann ich gerne machen. Wobei es ja so noch nicht fertig ist.

Die angehängte Datei lässt sich nicht herunterladen, da ist wohl was schiefgelaufen...

Ja, ich hatte es nochmal umbenannt und deswegen gelöscht und nochmal neu hochgeladen - das muss sich bestimmt überschnitten haben.

[Morg]

Hi,

erstmal danke fürs Testen. Da du anscheinend derzeit der Einzige mit einer "echten" (Nur-)KW-Anlage bist, muss das eben alles bei dir gegengeprüft werden

Die "Sync not acquired..." heißen nur, dass er innerhalb von 5x (1,5 + 1) Sekunden immer noch keine 0x05 identifizieren konnte. Wenn das mal vorkommt, ist das total unproblematisch (allerdings überspringt er dann den einzelnen Wert, der wird verworfen). Wenn das dauerhaft auftritt, dann müsste man mal schauen, was oder ob da was anderes schief läuft. Dann gibts aber auch keine Daten mehr...

Wie ist das bei dir, sporadisch einzeln, sporadisch in Rudeln oder ständig dazwischen? Vielleicht müssen wir dann das Timing noch etwas verbessern... und ist das von Anfang an so, oder passiert das "irgendwann" (nach einer bestimmten Zeit?)

Der zweite Punkt sind die "cyclic"-Meldungen. Die heißen, dass die letzte periodische Abfrage noch nicht abgeschlossen ist, während die nächste schon angestoßen wird. Da die alte noch läuft, verwirft er die "neue".

Dass die alte noch läuft, kann mehrere Gründe haben. Bei dir im Log ist der Grund offensichtlich, dass er sich zu Tode wartet, weil er keine Sync-Signale findet. Dann dauert das natürlich.

Ansonsten kann es sein, dass er die Verbindung verloren hat und es dauert, bis er das merkt. Oder es sind einfach zu viele Items in einer zu kurzen Schleifenzeit angegeben.

Bei mir (allerdings P300) sind es 21 Items, für die er "normalerweise" ca. 4,5 Sekunden braucht; nur so als Referenz. Beim KW-Protokoll musst du pro Wert mindestens 1,5 Sekunden rechnen, also längere Zeit im cycle lassen, oder weniger Werte abfragen.


Zu der commands.py: kannst du mir einfach die neue Datei schicken? Oder einen PR auf mein Repo machen?


Die angehängte Datei lässt sich nicht herunterladen, da ist wohl was schiefgelaufen...

Hast du mal ein Debug-Log, wo er die %-Werte ausliest?

Gruß
Sebastian

PS: das hat aus meiner Sicht her keine Eile. Wenn wir mit dir mit Testen so weit sind, dass wir alle zufrieden schauen, dann gebe ich das ans shng-Repo weiter für den nächsten Releasezyklus oder so

Vielleicht gehe ich aber noch hin und baue eine Routine ein, dass er die cyclic-Werte nicht "einzeln" abfragt, sondern alle hintereinander weg. Dafür muss aber die normale Abfrage erstmal zuverlässig laufen...

[TCr82]

Hi,
hier mal ein kleines Update:

Es kommt immer wieder folgendes im Logfile:

2020-12-17 16:44:32 ERROR plugins.viessmann Sync not acquired after 5 attempts.
2020-12-17 16:44:32 ERROR plugins.viessmann Not connected, trying to reconnect.
2020-12-17 16:44:32 WARNING plugins.viessmann Triggered cyclic command read, but previous cyclic run is still active. Check device and cyclic configuration (too much/too short?)
2020-12-17 16:47:43 ERROR plugins.viessmann Sync not acquired after 5 attempts.
2020-12-17 16:47:43 ERROR plugins.viessmann Not connected, trying to reconnect.
2020-12-17 16:47:43 WARNING plugins.viessmann Triggered cyclic command read, but previous cyclic run is still active. Check device and cyclic configuration (too much/too short?)
2020-12-17 17:02:54 ERROR plugins.viessmann Sync not acquired after 5 attempts.
2020-12-17 17:02:54 ERROR plugins.viessmann Not connected, trying to reconnect.
2020-12-17 17:02:54 WARNING plugins.viessmann Triggered cyclic command read, but previous cyclic run is still active. Check device and cyclic configuration (too much/too short?)
2020-12-17 17:06:05 ERROR plugins.viessmann Sync not acquired after 5 attempts.
2020-12-17 17:06:05 ERROR plugins.viessmann Not connected, trying to reconnect.
2020-12-17 17:06:05 WARNING plugins.viessmann Triggered cyclic command read, but previous cyclic run is still active. Check device and cyclic configuration (too much/too short?)
2020-12-17 17:31:46 ERROR plugins.viessmann Sync not acquired after 5 attempts.
2020-12-17 17:31:46 ERROR plugins.viessmann Not connected, trying to reconnect.
2020-12-17 17:31:46 WARNING plugins.viessmann Triggered cyclic command read, but previous cyclic run is still active. Check device and cyclic configuration (too much/too short?)

Ich habe jetzt meine Items wie folgt ergänzt:

technik:
    heizung:
        last_read:
            type: str
        ATyp:
            type: str
            viess_read: Anlagentyp
            viess_init: true
        BetriebsartM1:
            type: str
            viess_read: BetriebsartM1
            viess_init: true
            viess_read_cycle: 300
        BetriebsartM2:
            type: str
            viess_read: BetriebsartM2
            viess_init: true
            viess_read_cycle: 300
        Brennerstufe:
            type: bool
            viess_read: Brennerstufe
            viess_read_cycle: 180
            viess_init: true
        Brennerstarts:
            type: num
            viess_read: Brennerstarts
            viess_read_cycle: 180
            viess_init: true
        Brennerstoerung:
            type: bool
            viess_read: Brennerstoerung
            viess_read_cycle: 180
            viess_init: true
        ATemp:
            type: num
            viess_read: Aussentemperatur
            viess_read_cycle: 300
            viess_init: true
        KIstTemp:
            type: num
            viess_read: Kesseltemperatur
            viess_read_cycle: 180
            viess_init: true
        KsollTemp:
            type: num
            viess_read: Kesselsolltemperatur
            viess_read_cycle: 300
            viess_init: true
        WWIstTemp:
            type: num
            viess_read: Warmwasser_Temperatur
            viess_read_cycle: 180
            viess_init: true
        WWSollTemp:
            type: num
            viess_read: Warmwasser_Solltemperatur
            viess_read_cycle: 300
            viess_init: true
        HK2VLIstTemp:
            type: num
            viess_read: Vorlauftemperatur_M2
            viess_read_cycle: 180
            viess_init: true
        HK2VLSollTemp:
            type: num
            viess_read: Vorlauftemperatur_Soll_M2
            viess_read_cycle: 300
            viess_init: true
        WWPumpe:
            type: bool
            viess_read: Speicherladepumpe
            viess_read_cycle: 180
            viess_init: true
        HK1Pumpe:
            type: bool
            viess_read: Heizkreispumpe_A1M1
            viess_read_cycle: 180
            viess_init: true
        HK2Pumpe:
            type: bool
            viess_read: Heizkreispumpe_M2
            viess_read_cycle: 180
            viess_init: true
        HK2Mischer:
            type: num
            viess_read: MischerM2
            viess_read_cycle: 180
            viess_init: true
        StatusKlemme2:
            type: num
            viess_read: StatusKlemme2
            viess_read_cycle: 300
            viess_init: true

Und die commands.py

diff --git a/commands.py b/commands.py
index 2b1f251..39d430e 100755
--- a/commands.py
+++ b/commands.py
@@ -290,9 +290,11 @@ commandset = {
         # Allgemein
         'Anlagentyp':                      {'addr': '00f8', 'len': 2, 'unit': 'DT',     'set': False},                                        # Ermittle Device Typ der Anlage
         'Aussentemperatur':                {'addr': '0800', 'len': 2, 'unit': 'IU10',   'set': False},                                        # Aussentemperatur_tiefpass
+        'Aussentemperatur_TP':             {'addr': '2053', 'len': 2, 'unit': 'IU10',   'set': False},                                        # Aussentemperatur_tiefpass
+        'Aussentemperatur_Dp':             {'addr': '5527', 'len': 2, 'unit': 'IU10',   'set': False},                                        # Aussentemperatur in Grad C (Gedaempft)
         # Kessel
-        'Kesseltemperatur':                {'addr': '0802', 'len': 2, 'unit': 'IU10',   'set': False},                                        # Kesseltemperatur_tiefpass
-        'Kesselsolltemperatur':            {'addr': '5502', 'len': 2, 'unit': 'IU10',   'set': True},                                        # Kesselsolltemperatur
+        'Kesseltemperatur':                {'addr': '0802', 'len': 2, 'unit': 'IU10',   'set': False},                                        # Kesseltemperatur
+        'Kesselsolltemperatur':            {'addr': '5502', 'len': 2, 'unit': 'IU10',   'set': True},                                         # Kesselsolltemperatur
         # Fehler
         'Sammelstoerung':                  {'addr': '0847', 'len': 1, 'unit': 'RT',     'set': False},                                        # Sammelstörung
         'Brennerstoerung':                 {'addr': '0883', 'len': 1, 'unit': 'RT',     'set': False},
@@ -312,12 +314,22 @@ commandset = {
         'Heizkreispumpe_A1M1':             {'addr': '2906', 'len': 1, 'unit': 'IUBOOL', 'set': False},                                        # Heizkreispumpe A1
         'Heizkreispumpe_M2':               {'addr': '3906', 'len': 1, 'unit': 'IUINT',  'set': False},                                        # Heizkreispumpe M2
         # Brenner
+        'Brennerstarts':                   {'addr': '088A', 'len': 2, 'unit': 'ISNON',  'set': True, 'min_value': 0, 'max_value': 1193045},   # Brennerstarts
+        'Brennerstatus_1':                 {'addr': '55D3', 'len': 1, 'unit': 'IUBOOL', 'set': False},                                        # Brennerstatus Stufe1
+        'Brennerstatus_2':                 {'addr': '0849', 'len': 1, 'unit': 'IUBOOL', 'set': False},                                        # Brennerstatus Stufe2
+        'Brenner_BetriebsstundenStufe1':   {'addr': '0886', 'len': 4, 'unit': 'IU3600', 'set': True, 'min_value': 0, 'max_value': 1193045},   # Brenner-Betriebsstunden
         'BrennerStufe':                    {'addr': '551e', 'len': 1, 'unit': 'RT',     'set': False},                                        # Ermittle den Brennerstatus aktuelle Stufe
-        'Heizleistung':                    {'addr': '55e3', 'len': 1, 'unit': 'IU2',    'set': False},                                        
+#      'Brennertyp':                      {'addr': 'A30B', 'len': 1, 'unit': 'BT',     'set': True},                                        # Brennertyp: 1=Einstufig, 2=Zweistufig, 3=Modulierend
+        'Heizleistung':                    {'addr': '55e3', 'len': 1, 'unit': 'IU2',    'set': False},
         # Heizkreis M2
-        'MischerM2':                       {'addr': '354c', 'len': 2, 'unit': 'IUINT',  'set': False},                                        # Ermittle Mischerposition M2
+        'Betriebsart':                     {'addr': '2301', 'len': 1, 'unit': 'BA',     'set': True},                                         # Betriebsart A1M1
+        'BetriebsartA1':                   {'addr': '2301', 'len': 1, 'unit': 'BA',     'set': True},                                         # Betriebsart A1
+        'BetriebsartM2':                   {'addr': '3301', 'len': 1, 'unit': 'BA',     'set': True},                                         # Betriebsart M2
+        'MischerM2':                       {'addr': '354C', 'len': 1, 'unit': 'IU100',  'set': False},                                        # Ermittle Mischerposition M2
         'Vorlauftemperatur_Soll_M2':       {'addr': '3544', 'len': 2, 'unit': 'IU10',   'set': True, 'min_value': 10, 'max_value': 80},       # Vorlauftemperatur Soll
         'Vorlauftemperatur_M2':            {'addr': '080c', 'len': 2, 'unit': 'IU10',   'set': False},                                        # Vorlauftemperatur Ist
+       'StatusKlemme2':                   {'addr': '3904', 'len': 1, 'unit': 'IUINT',  'set': False},
+       'StatusKlemme17':                  {'addr': '3905', 'len': 1, 'unit': 'IUINT',  'set': False},
         # Warmwasser
         'Warmwasser_Temperatur':           {'addr': '0804', 'len': 2, 'unit': 'IU10',   'set': False},                                        # Warmwassertemperatur in Grad C
         'Warmwasser_Solltemperatur':       {'addr': '6300', 'len': 1, 'unit': 'ISNON',  'set': True, 'min_value': 10, 'max_value': 80},       # Warmwasser-Solltemperatur
@@ -425,6 +437,7 @@ unitset = {
         'IS1000':  {'unit_de': 'INT signed 1000',   'type': 'integer',  'signed': True,  'read_value_transform': '1000'},       # vito unit:
         'ISNON':   {'unit_de': 'INT signed non',    'type': 'integer',  'signed': True,  'read_value_transform': 'non'},        # vito unit:
         'RT':      {'unit_de': 'ReturnStatus',      'type': 'list',     'signed': False, 'read_value_transform': 'non'},        # vito unit: ST, RT
+        'BT':      {'unit_de': 'Brennertyp',        'type': 'list',     'signed': False, 'read_value_transform': 'non'},        # vito unit:
         'SC':      {'unit_de': 'SystemScheme',      'type': 'list',     'signed': False, 'read_value_transform': 'non'},        # vito unit:
         'SN':      {'unit_de': 'Sachnummer',        'type': 'serial',   'signed': False, 'read_value_transform': 'non'},        # vito unit:
         'SR':      {'unit_de': 'SetReturnStatus',   'type': 'list',     'signed': False, 'read_value_transform': 'non'},        # vito unit:
@@ -636,11 +649,12 @@ errorset = {
 
 operatingmodes = {
     'V200KW2': {
-        '0': 'Abschaltbetrieb',
-        '1': 'Warmwasserbetrieb',
-        '2': 'Heiz- und Warmwasserbetrieb',
-        '4': 'Dauerbetrieb, reduziert',
-        '5': 'Dauerbetrieb, normal',
+        '00': 'Warmwasser (Schaltzeiten)',
+        '01': 'reduziert Heizen (dauernd)',
+        '02': 'normal Heizen (dauernd)',
+        '04': 'Heizen und Warmwasser (FS)',
+        '03': 'Heizen und Warmwasser (Schaltzeiten)',
+        '05': 'Standby',
     },
     'V200KO1B': {
         '00': 'Warmwasser (Schaltzeiten)',
@@ -676,6 +690,14 @@ operatingmodes = {
 }
 
 systemschemes = {
+    'V200KW2': {
+        '01': 'A1',
+        '02': 'A1 + WW',
+        '04': 'M2',
+        '03': 'M2 + WW',
+        '05': 'A1 + M2',
+        '06': 'A1 + M2 + WW'
+    },
     'V200KO1B': {
         '01': 'A1',
         '02': 'A1 + WW',

Problem ist aber leider immer noch, dass der Wert für Vorlauftemperatur_Soll_M2 und MischerM2 nicht nicht richtig raus kommen, obwohl ich die Adressen auch gegen die DB von Viessman gegengeprüft habe. Ich denke die Berechnung für % fehlt noch komplett.

Hab mal die Daten aus meiner DB Abfrage hier als CSV ran gehängt. Das ist nur von den zwei fehlerhaften Adressen, kann gerne auch mehr liefern. Hab mir da ne spezial Abfrage zusammen gebaut.

Hab jetzt auch schon die zwei shNG Instanzen per mqtt miteinander verbunden. Aber bis jetzt auch nur lesend...
Naja, leider bin ich bis jetzt wegen Zeitmangel noch nicht weiter gekommen.

[Morg]

Das macht aber nix. Vorher hat er das mit try/except abgefangen, und ich hatte das except: durch except ValueError: ersetzt, damit der AttributeError-Fehler nicht mehr abgefangen worden.

Jetzt habe ich den mit aufgenommen, da tritt der Fehler nicht mehr auf.

Es fehlt nicht strftime, sondern das zurückgegebene Item ist kein Objekt, und hat deshalb keine Methode strftime. Warum das sunset() nicht ausgewertet wird, weiß ich nicht. Bei mir ist der Fehler so oder so nicht aufgetaucht. Vielleicht stimmt bei ihm irgendwas anderes nicht in der Umgebung...

[Sisamiwe]

File "/usr/local/smarthome/plugins/viessmann/__init__.py", line 1120, in _viess_dict_to_uzsu_dict sunset = shitems.return_item('env.location.sunset')().strft ime("%H:%M") AttributeError: 'NoneType' object has no attribute 'strftime'

Morg


Den meinte ich. Es scheint strftime zu fehlen

[Morg]

Du meinst wegen "import time"? Ne, das gehört zu Python dazu.

Den Fehler hab ich verursacht, habe ich ja oben geschrieben. Die aktuelle Version sollte den nicht mehr haben.

[Sisamiwe]

Habe ich aber in glaube in den Griff bekommen, als ich noch uzsu nachinstalliert habe.

Achso, hast du UZSU nur wegen des Fehlers installiert? Dann hat sich die Abhängigkeit erledigt...

Das hat nur indirekt mit der UZSU zu tun.
Die von mir eingebaute Funktion wandelt den Inhalt der Viessmann Timer Datenpunkte welches das UZSU-Format um.
Dafür muss aber das UZSU-Plugin nicht installiert sein.

Morg

Müssen wir ggf. nur das pyhton time "module" noch laden?

[Morg]

Die Frage müsstest du an Michael richten, der hat das eingebaut ich nutze es UZSU selbst nicht, könnte aber nicht sagen, ob es installiert ist oder nicht...

Ansonsten - freut mich, dass es erstmal läuft.

Der erste Fehler ist trivial und den habe ich verursacht. Ich habe an ein paar Stellen "except: " in "except <Ausnahme>:" geändert, und an der Stelle habe ich den AttributeError nicht abgefangen. Update ist online.

Achso, hast du UZSU nur wegen des Fehlers installiert? Dann hat sich die Abhängigkeit erledigt...

[TCr82]

Hi, Morg! Vielen dank, teste es gleich.

das erste was jetzt mal kam ist:

[FONT=monospace][COLOR=#000000]2020-12-15  16:03:52 ERROR    lib.plugin          Plugin 'viessmann' exception in run() method: 'NoneType' object has no attribute 'strftime' [/COLOR]
Traceback (most recent call last):
 File "/usr/local/smarthome/lib/plugin.py", line 675, in run
   self.plugin.run()
 File "/usr/local/smarthome/plugins/viessmann/__init__.py", line 140, in run
   self._read_timers()
 File "/usr/local/smarthome/plugins/viessmann/__init__.py", line 519, in _read_timers
   self._viess_dict_to_uzsu_dict()
 File "/usr/local/smarthome/plugins/viessmann/__init__.py", line 1120, in _viess_dict_to_uzsu_dict
   sunset = shitems.return_item('env.location.sunset')().strft ime("%H:%M")
AttributeError: 'NoneType' object has no attribute 'strftime'[/FONT]

Habe ich aber in glaube in den Griff bekommen, als ich noch uzsu nachinstalliert habe. Und ich hatte auch noch vergessen die systemschemes für V200KW2 wieder zu ergänzen.

Auf jeden Fall scheint es jetzt alle Daten richtig abzufragen. Dann kann ich ja mal anfangen Adressen zu ergänzen und das nochmal weiter zu testen (auch mal schreiben).

Kann man die Abhängigkeit zu uzsu irgendwie in der plugin.yaml festlegen (ist eher an Msinn / Onkelandy gerichtet)?

Gruß

[Morg]

Ich habe den Code für die Synchronisation mit den KW-0x05-Paketen komplett überarbeitet:

- das ganze passiert (schon vorher) in einer threading-lock-Klammer, damit sich "reguläre" und "cycle"-Kommandos nicht in die Quere kommen. De facto blockieren die sich gegenseitig.
- erstmal die Empfangsschlage löschen, damit nur aktuelle Daten genutzt werden.
- ein Byte lesen -> hier hat die pyserial-Lib einen Timeout von 1 Sek.
- wenn das Byte 0x05 ist -> weiter zum "alten" Code (Kommando senden, Antwort lesen)
- wenn nicht 0x05 - 1 Sekunde warten, nochmal probieren
- wenn nach dem 5. Versuch kein Sync, dann Verbindung trennen und Kommando ignorieren

Das läuft im Großen und Ganzen ... "ganz ok", ich bekomme in den meisten Fällen alle Daten aus dem Cycle (21 Datenpunkte). Nach einigem Tüfteln mit den Timeouts in pyserial und in get_KW_sync klappt das ganz gut.

_Bei mir_ liest er alle Daten problemlos - aber meine Steuerung "kann" auch P300, insofern weiß ich nicht, ob die sich anders verhält als z.B. eine ältere, die das nicht kann.

Speziell TCr82: bitte teste mal die neue Version:

- ob sie überhaupt läuft
- ob sie im Log "zuverlässig" den Sync bekommt und danach Werte liest
- ob die gelesenen Werte plausibel sind
- ob jetzt noch Adresspunkte da sind, wo es keine Werte gibt.

Wenn bei Punkt 2 Probleme auftauchen, dann kannst du mal etwas mit dem timeout-Wert in get_KW_sync() (in time.sleep(...)) und mit dem timeout in connect() rumspielen. Ohne den sleep-Timeout habe ich überhaupt keine Verbindung bekommen, egal ob der serial-Timeout bei 0.5 oder 1.5 Sekunden lag. Im worst-cast brauchte er für 21 items fast 90 Sekunden, und da waren nicht alle Werte zuverlässig gelesen...

Ich nehme auch gern wieder Logs und schau sie durch

[TCr82]

Guten Appetit

Das mögliche Problem mit nicht bekannten Adressen müssen wir dann mal prüfen

Die Adressen von den paar Items die ich Abfrage habe ich nochmal geprüft, die stimmen mit meiner vito.xml überein.

[Morg]

Sicher.

Das Problem ist, den Zeitpunkt zu finden, wenn die 0x05 gesendet wird, und dann möglichst sofort weiterzumachen. Da muss ich nochmal reinschauen, möglicherweise wird das read_bytes dann doch geteilt je nach Protokoll.

Wenn ich das hinbekommen habe, sollte hoffentlich der Rest "von allein" laufen. Das mögliche Problem mit nicht bekannten Adressen müssen wir dann mal prüfen

Wenn ich es schaffe, mache ich das heute abend. Gleich gibts erstmal zwei Stunden Küche und dann schönes Lammcurry... ganz ohne Python