Ankündigung

Einklappen
Keine Ankündigung bisher.

Viessmann Plugin Neuentwicklung Python Hilfe

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Viessmann Plugin Neuentwicklung Python Hilfe

    Hallo,

    ich beschäftige mich gerade mit einer Neuentwicklung des Viessmann Plugins, mit Lese- und Schreibfunktion und direktem Zugriff über die serielle Schnittstelle.
    Viele Funktionen sind bereits implementiert und getestet. Aktuell stehe die Timer (Schaltzeiten) an und dabei bräuchte ich Hilfe bei der Umsetzung in Python.

    Konkret:
    Die Abfrage der Schaltzeiten liefert ein Bytearray in dem die möglichen 4 An- und 4 Abschaltzeiten enthalten sind. diese möchte ich in ein dict übertragen.
    Das Dict soll so aussehen: {1{'AN':'Zeit1'; 'AUS':'Zeit2'};2{'AN':'Zeit3'; 'AUS':'Zeit4'};3{'AN':'Zeit5'; 'AUS':'Zeit6'};4{'AN':'Zeit7'; 'AUS':'Zeit8'}}

    Mein PythonCode zur Ermittelung der Zeit sieht so aus:
    Code:
    def decode_timer(self, rawdatabytes, valuebytecount, commandsignage):
    timer = {} while (len(rawdatabytes) > 0):
    # Ersten 2Byte zwischenspeichern leftbytes = rawdatabytes[:2] # Wert der Bytes ermitteln value = int(leftbytes, 16) # Ermitteln der Zeit if value != 255:
    hour = int(value>>3) minute = int((value-(hour<<3))*10)
    else:
    hour = 0 minute = 0
    zeit = time(hour, minute) # Bytestring um das erste Byte verkürzen rawdatabytes = rawdatabytes[2:]
    return timer

    Wie bekomme ich die Zeiten nur am besten in das Dict, wie ich es oben skizziert habe?
    Danke für Eure Hilfe

    #2
    Viele Wege führen nach Rom.
    Versuch mal so:

    Code:
    def decode_timer(self, rawdatabytes, valuebytecount, commandsignage):
    timer = {} sub_dict={} index = 0 while (len(rawdatabytes) > 0):
    # Ersten 2Byte zwischenspeichern leftbytes = rawdatabytes[:2] # Wert der Bytes ermitteln value = int(leftbytes, 16) # Ermitteln der Zeit if value != 255:
    hour = int(value>>3) minute = int((value-(hour<<3))*10)
    else:
    hour = 0 minute = 0
    zeit = time(hour, minute) if ( index % 2 == 1 or index == 0 ):
    sub_dict['AN'] = zeit
    else:
    sub_dict['AUS']= zeit my_dict[index/2]=sub_dict sub_dict={}
    index = index +1 # Bytestring um das erste Byte verkürzen rawdatabytes = rawdatabytes[2:
    return timer
    Zuletzt geändert von cmalo; 31.01.2020, 00:13.

    Kommentar


      #3
      Hallo,

      ich habe eine neue Version des Plugins zum Lesen und Schreiben von Werten bei einer Viessmann Heizung fertiggestellt und in ein GitHub Repo geladen.
      Hier ist es zu finden. Es ist angelehnt an die Version von loeserman beschrieben hier und an das Comfoair Plugin von SvStefan, das bereits im shNG Repo ist.

      Es ist flexible gestaltet und bedient aktuell das Protokoll P300 und die Heizung mit Steuerung KO1B. Erweiterungen sind einfach möglich. Man kann viele Werte auslesen und auch setzen. Die Anwendung ist in den entsprechenden Dateien beschrieben. Man benötigt einen Optolink Adapter.

      loeserman thesing psilo
      Ihr könnt das Plugin gern testen und mir evtl Erweiterungen mitgeben. Bei mir läuft es seit 3 Wochen stabil.

      Beste Grüße
      Michael

      Kommentar


        #4
        Kommt das Plugin auch mit einem USB-Reconnect klar? Ich hatte damals das Problem, dass alle paar Tage der USB-Stack auf dem Raspberry-Pi ein Reconnect erforderte.

        Kommentar


          #5
          thesing
          Der reconnect mit einem USB optolink klappt.

          Kommentar


            #6
            Hi, ich bin gerade dabei, das Plugin bei mir auf meine Heizung zu erweitern und zu testen.

            Was mir aufgefallen ist:

            __init.py__ :
            - in Zeile 207 weist du die Variable "ad" zu, die wird aber nirgendwo mehr verwendet. Ist das Absicht?
            - in Zeilen 573/574 definierst du noch weitere Variablen, die auch nicht verwendet werden
            - Zeile 546: es muss received_checksum heißen, nicht receivedchecksum
            - Zeile 628; errirquerytime wird zugewiesen, aber nicht verwendet
            - Zeile 892: data wird zugewiesen, aber nicht verwendet (und nicht zurückgegeben)

            commands.py:
            Du hast für den erkannten Bedarf entsprechende "units" definiert, das ist soweit auch nachvollziehbar. Hat es einen besonderen Grund, dass du für die signed/unsigned Typen "true" bzw. "false" in den Typnamen eingebaut hast? Ich fände das mit "" / "u" oder "s"/"u" verständlicher (weil eher an sonstigen Konventionen orientiert).
            Also, ich verstehe, dass "IT10" = int, signed=true, Konvertierung = /10, aber die Bennung mit "T"/"F" finde ich wenig eingängig... hattest du da einen speziellen Grund zu?

            Ich werde fürs Testen offensichtliche Fehler fixen und an manchen Stellen die Formatierung anpassen, damit mir mein Python-Linter nicht soviel Rot rauswirft Alles, was ich ändere und für meine Heizung ergänze, bekommst du in den nächsten Tagen als PR auf dein Repo; ob du das dann annimmst oder nicht, kannst du ja immer noch selbst entscheiden
            Wenn du mir zu den oben angesprochenen Punkten kurze Rückmeldung gibst, bau ich das gleich mit ein, ansonsten lasse ich es so, wie es ist.

            Ansonsten: super Arbeit, vielen Dank!

            Kommentar


              #7
              Morg


              Schön, daß das Plugin genutzt wird.
              Ich antworte dir morgen.

              Hilfe, Verbesserung, Korrektur ist natürlich willkommen.
              Ich habe mit Msinn besprochen, dass das Plugin dann auch ins offizielle Repo kommt.

              Kommentar


                #8
                So ... habe meine Produktiv-Konfiguration vcontrold - cronjob - networkplugin - sh.py mal um den vcontrold und den cronjob beschnitten, so dass ich mit dem USB-Interface spielen kann.

                In einem zweiten sh.py läuft nur das viessmann-Plugin (und http/admin-Modul). Läuft nach anfänglichen Problemen (es fehlte das systemscheme) gut, liest im eingestellten Zyklus und liefert alle gewünschten Werte - sehr fein

                Schreiben von einem Byte-Wert geht - nur leider macht die Heizung nicht, was sie soll, weil in der Viessmann-Doku wohl ein Fehler steckt

                Ich war erstaunt, dass Betriebsart "nur" den String zurückgibt und keinen Wert - fehlt da ein item oder ist das so vorgesehen? Besonders dies wäre für mich wichtig, da das einer der Parameter ist, den ich schreiben können möchte. Wenn ich den passenden String an das Item zuweise, kommt im Log "got a new write job", und das wars. Keine Änderung, keine Aktino an der Heizung.

                Bezüglich des fehlenden Systemschemas habe ich die Fehlermeldung soweit angepasst, dass er auch ausgibt, welches der drei Datenfelder für die jeweilige Heizung fehlt.

                Kommentar


                  #9
                  Noch'n Gedicht.. äh.. Update:

                  Wenn ich das Kommando für Betriebsart von Unit "BA" auf Unit "IFNON" (1 byte unsigned) ändere, dann funktioniert schreiben und lesen problemlos.
                  Wenn ich das Kommando Betriebsart ("BA") und BetriebsartNum ("IFNON") definiere, dann übernimmt er nur ein, weil er anscheinend die Adresse nur einmal vergeben kann.

                  Entweder müsste man damit leben (und die Wandlung in str ggf. in der Visu oder sonstwo machen), oder man ermöglicht die Nutzung derselben Adresse für zwei Kommandos, oder man ändert die Schreibroutine für BA, so dass ein Lesen einen String zurückgibt, und ein Update mit einem String vor dem Senden intern in einen Bytewert gewandelt wird.

                  Ich glaube, ich werde mal letzteres probieren...

                  Update:

                  So, geht Solange in der operation_modes nicht zweimal derselbe String als Wert angegeben ist, geht es problemlos; wenn mehrfach der gleiche String vorkommt (z.B. "undefined" oder "Abschaltbetrieb" oder so), dann wird der letzte Eintrag mit passendem Wert gewählt.

                  Ich bin zwar noch nicht sicher, ob es geschickt ist, hier mit quasi-Freitext-items zu arbeiten, aber machbar ist es; in einem Widget müsste man dann selber zusehen, dass nur die passenden Werte angeboten werden.

                  Einen item-Typ enum oder so gibt es hier nicht, oder?

                  Achso, was mir noch aufgefallen ist:
                  insbesondere in der update_item() bzw create_write_command()-Funktion hast du häufig Konstruktionen wie

                  ```
                  try:
                  ...
                  except:
                  raise Exception(bla)
                  ```

                  Während ich gut finde, die Fehler überhaupt erstmal einzufangen, hast du durch die manuelle Exception dann doch wieder die entsprechende Meldung im Log. Sowas würde ich vermeiden wollen. Ich schreibe das gern mal so um, dass dann die entsprechende Meldung als self.log_error() ins Log geht und die Funktion beendet wird.
                  Zuletzt geändert von Morg; 16.04.2020, 23:46.

                  Kommentar


                    #10
                    Morg

                    Hey,

                    ich versuche mal Deine Fragen zu beantworten:

                    __init.py__ :
                    Zitat von Morg Beitrag anzeigen
                    - in Zeile 207 weist du die Variable "ad" zu, die wird aber nirgendwo mehr verwendet. Ist das Absicht?
                    Die Zeile kann wahrscheinlich komplett gelöscht werden. Hier soll für die "Write" Items nur die Funktion "self.update_item" aufgerufen werden. "Damals" wusste ich es nicht besser.

                    Zitat von Morg Beitrag anzeigen
                    - in Zeilen 573/574 definierst du noch weitere Variablen, die auch nicht verwendet werden
                    Die beiden Zeilen können auch komplett raus. Ich hatte wahrscheinlich damals die komplette Unit-Definiton eingelesen. Bei den Units habe ich verschiedenen Anläufe braucht, bis es gepasst hat. Dazu später mehr.

                    Zitat von Morg Beitrag anzeigen
                    - Zeile 546: es muss received_checksum heißen, nicht receivedchecksum
                    Korrekt.

                    Zitat von Morg Beitrag anzeigen
                    - Zeile 628; errirquerytime wird zugewiesen, aber nicht verwendet
                    Das ist die Zeit, wann der Fehler gelesen wurde. Ich habe den dann nicht weiter verfolgt, da das Item, in dem das Fehler geschrieben wird, die Änderungszeit von Hause aus mirbringt. Könnte man auskommentiren.

                    Zitat von Morg Beitrag anzeigen
                    - Zeile 892: data wird zugewiesen, aber nicht verwendet (und nicht zurückgegeben)
                    Das ist das Web-Interface. Hier habe ich die Zusammenhänge noch nicht wirklich verstanden. Ehrlich gesagt, war ich froh, dass das WebIF funktioniert. Aber wahrscheinlich kann man die Zeile auch löschen.

                    commands.py:
                    Zitat von Morg Beitrag anzeigen
                    Du hast für den erkannten Bedarf entsprechende "units" definiert, das ist soweit auch nachvollziehbar. Hat es einen besonderen Grund, dass du für die signed/unsigned Typen "true" bzw. "false" in den Typnamen eingebaut hast? Ich fände das mit "" / "u" oder "s"/"u" verständlicher (weil eher an sonstigen Konventionen orientiert).
                    Du meinst das "False" bspw bei" INT False bool":
                    Code:
                    'IFBOOL': { 'unit_de': 'INT False bool', 'type': 'integer', 'signed': False, 'read_value_transform': 'bool' },
                    Das ich das so definiert habe, hat nur den Grund, dass mir nichts besseres eingefallen ist. Wenn es anders verständlicher ist bzw. üblichen Konventionen folgt, kann man das gern ändern.

                    Zitat von Morg Beitrag anzeigen
                    Also, ich verstehe, dass "IT10" = int, signed=true, Konvertierung = /10, aber die Bennung mit "T"/"F" finde ich wenig eingängig... hattest du da einen speziellen Grund zu?
                    Auch hier ist mir nichts besseres eingefallen. Es kann gern in "S"/"U" geändert werden.

                    Zitat von Morg Beitrag anzeigen
                    Ich werde fürs Testen offensichtliche Fehler fixen und an manchen Stellen die Formatierung anpassen, damit mir mein Python-Linter nicht soviel Rot rauswirft .Alles, was ich ändere und für meine Heizung ergänze, bekommst du in den nächsten Tagen als PR auf dein Repo; ob du das dann annimmst oder nicht, kannst du ja immer noch selbst entscheiden
                    Prima. Wie gesagt, Änderugen, Verbesserungen, Erweiterungen etc werden gern angenommen.
                    Frage: Kann man mit der Struktur in meinem Github mit myplugins/viessmann arbeiten oder sollte ich es als eigenes Repo anlegen?

                    Zitat von Morg Beitrag anzeigen
                    insbesondere in der update_item() bzw create_write_command()-Funktion hast du häufig Konstruktionen wie

                    ```
                    try:
                    ...
                    except:
                    raise Exception(bla)
                    ```

                    Während ich gut finde, die Fehler überhaupt erstmal einzufangen, hast du durch die manuelle Exception dann doch wieder die entsprechende Meldung im Log. Sowas würde ich vermeiden wollen. Ich schreibe das gern mal so um, dass dann die entsprechende Meldung als self.log_error() ins Log geht und die Funktion beendet wird.
                    Gern!

                    Zitat von Morg Beitrag anzeigen
                    Wenn ich das Kommando für Betriebsart von Unit "BA" auf Unit "IFNON" (1 byte unsigned) ändere, dann funktioniert schreiben und lesen problemlos.
                    Wenn ich das Kommando Betriebsart ("BA") und BetriebsartNum ("IFNON") definiere, dann übernimmt er nur ein, weil er anscheinend die Adresse nur einmal vergeben kann.

                    Entweder müsste man damit leben (und die Wandlung in str ggf. in der Visu oder sonstwo machen), oder man ermöglicht die Nutzung derselben Adresse für zwei Kommandos, oder man ändert die Schreibroutine für BA, so dass ein Lesen einen String zurückgibt, und ein Update mit einem String vor dem Senden intern in einen Bytewert gewandelt wird.

                    Ich glaube, ich werde mal letzteres probieren
                    Das Problem mit der BA habe ich noch nicht verstanden. Das Kommando "Aktuelle_Betriebsart_A1M1" mit er Unit "BA" ist read only.
                    Code:
                    'Aktuelle_Betriebsart_A1M1':                  { 'addr': '2301', 'len': 1, 'unit': 'BA',     'set': False }, #Aktuelle Betriebsart A1M1
                    Dafür steht das "set". Das ist zumindest in meiner Funktionsbeschreibung der KO1B auch so beschrieben.

                    Also der Viessmann Code "2301" ist read only, 2323 ist read /write.

                    Gesetzt wird die Betriebsart über das Kommando "Betriebsart_A1M1" bzw. "Betriebsart_M2".
                    Code:
                    'Betriebsart_A1M1':                           { 'addr': '2323', 'len': 1, 'unit': 'IFNON',  'set': True,  'min_value': 0, 'max_value': 4 }, #Betriebsart A1M1
                    Hier werden die Betriebsarten per Zahlen definiert. Die Enumaration habe ich als struct in der Plugin.yaml hinterlegt. Siehe auch die Itemstruktur hier:
                    Code:
                            betriebsart:
                                betriebsart_aktuell:
                                    name: Aktuelle_Betriebsart_A1M1
                                    type: str
                                    viess_read: Aktuelle_Betriebsart_A1M1
                                    viess_read_cycle: 3600
                                    viess_init: true
                                betriebsart:
                                    name: Betriebsart_A1M1
                                    type: num
                                    viess_read: Betriebsart_A1M1
                                    viess_send: true
                                    viess_read_afterwrite: 5
                                    viess_init: true
                                    cache: true
                                    enforce_updates: true
                                    viess_trigger:
                                      - Aktuelle_Betriebsart_A1M1
                                    struct: viessmann.betriebsart
                                    visu_acl: rw
                    Zitat von Morg Beitrag anzeigen
                    Einen item-Typ enum oder so gibt es hier nicht, oder?
                    Die Spezial-Units wie BA werden enumeriert. Dafür habe ich in der commands.py weiter unten auch entsprechende Sets angelegt. Bspw greift die Unit "BA" auf das folgende Set zu:

                    Code:
                    operatingmodes = {
                        'V200KW2': {
                            '0':    'Abschaltbetrieb',
                            '1':    'Warmwasserbetrieb',
                            '2':    'Heiz- und Warmwasserbetrieb',
                            '4':    'Dauerbetrieb, reduziert',
                            '5':    'Dauerbetrieb, normal',
                    },
                        'V200KO1B': {
                            '00':    'Warmwasser (Schaltzeiten)',
                            '01':    'reduziert Heizen (dauernd)',
                            '02':    'normal Heizen (dauernd)',
                            '04':    'Heizen und Warmwasser (FS)',
                            '03':    'Heizen und Warmwasser (Schaltzeiten)',
                            '05':    'Standby',
                        },
                        'aktuelle_Betriebsart': {
                            '00':   'Abschaltbetrieb',
                            '01':   'Reduzierter Betrieb',
                            '02':   'Normalbetrieb',
                            '03':   'Dauernd Normalbetrieb',
                        },
                    }
                    Ich hoffe, ich habe erstmal alle Fragen beantwortet.
                    Wenn Du zu den Schaltzeiten kommt, muss ich Dir noch kurz erklären, wie das funktioniert. Melde Dich dazu bitte nochmal.

                    Kommentar


                      #11
                      Hi,

                      wow, so viele Antworten, und das schon so früh, spotze

                      Das Meiste klingt für mich einfach - ich mal mal

                      Zum Repo: klar, das kannst du (erstmal) so lassen, wobei es günstiger wäre, das Repo z.B. viessmann zu nennen und das Plugin direkt in den Stammordner zu werfen. Dann kann man das Repo direkt in den Pluginordner legen. Aber das ist derzeit nichts wirklich relevantes. Und wenn das Plugin in develop geht, dann brauchst du das "kleine" Repo sowieso nicht mehr. Ich habe mein Repo vom yamahayxc-Plugin archiviert und mache mir für aktuelle Arbeiten am Plugin immer einen fork vom sh.py-plugins-Repo, da die Änderungen dann ja sowieso dorthin sollen.

                      Beim Thema Betriebsart habe ich wohl nicht ausführlich genug geschildert Ich habe ja eine andere Heizung, und bei mir gibt es nur eine Adresse "Betriebsart" auf 0x2300, Lesen und Schreiben. Die kann ich als Bytewert schreiben und lesen, und ich kann den Bytewert über das dict operatingmodes "übersetzen", das ist soweit alles kein Problem.

                      Wenn ich jetzt aber schreiben will, dann kann ich - in sh.py - nur im Itemtyp schreiben: str. Also übergebe ich z.B. "Abschaltbetrieb" an das Item, und sh.py versucht,den String zu schreiben, was natürlich nicht klappt. Entweder, weil es in P300 keinen String schreiben kann, oder, weil die Anlage auf der jew. Adresse nix mit 15 Bytes ASCII anfangen kann, sondern einen Wert zwischen 1 und 7 erwartet.

                      Was das verständlicher?

                      Was ich gestern noch gemacht habe, ist in create_write_command() eine Abfrage einzubauen. Wenn ein Item vom Typ "BA" geändert wird, versucht er, in operatingmodes "rückwärts" den passenden Index zu finden, in deinem Fall dann entweder '0' oder '00', und arbeitet dann mit dem Wert weiter. In beiden Fällen würde er dann den Bytewert 0 an die Heizung schreiben - was bei mir gestern auch problemlos geklappt hat.

                      Dafür muss ich in operatingmodes "rückwärts" suchen, ich habe ja einen Wert, der in der Definition rechts steht, und suche den passenden linken Wert.
                      Wenn ich jetzt einen falschen Wert übergebe, z.B. "Energiespare", dann existiert der in operatingmodes nicht, und die Heizung kann den Wert nicht umsetzen. Ich suche noch nach einem Weg, die Liste der gültigen Werte nicht nur - wie mit operatingmodes - im Plugin zu beschränken, sondern schon in sh.py. Es wäre doch toll, wenn man die gültigen Werte für das item einschränken könnte. Da wäre ein enum-Wert passend, dann "weiß" das Item (und sh.py) nämlich, dass "Energiesparen" ungültig ist und lässt den Versuch der Änderung erst gar nicht zu.

                      Ich verstehe - jetzt - allerdings auch, dass das bei deiner Heizung anders läuft. Das sehe ich mir gleich nochmal im Detail an. Wenn das mit meinen Ideen kollidiert, muss ich eben nochmal was ändern.

                      Ich melde mich

                      Kommentar


                        #12
                        Zitat von Morg Beitrag anzeigen
                        Was das verständlicher?
                        Ja, ist es.

                        Kannst Du dann nicht einfach die 'Betriebsart_A1M1' nutzen? Die ist mit Nummern und es wird auch bereits geprüft, ob die zu sendenden Zahlen erlaubt sind.
                        Ich habe dann ein Sub-Item angelegt, um das Item zu Enumerieren.

                        In der Visu geht das auch gut. Da habe ich mit ein Widget gebaut. Auswahl der Betriebsart als Text, setzt dann das Item auf die entsprechende Zahl.
                        Code:
                        /**
                         * Viessmann Betriebsartmenu
                         *
                         * @param       unique id for this widget
                         * @param       Headline
                         * @param       the gad/item for timer (parent item)
                         *
                         */
                        {% macro betriebsart(id, gad_betriebsart) %}
                            {% import "basic.html" as basic %}
                            {% set uid = uid(page, id) %}
                            <div id="{{ uid }}">        
                                {{ basic.select(id, gad_betriebsart, '', [0,1,2,3,4], '', ['Standby', 'Warmwasser (Schaltzeiten)', 'Heizen und Warmwasser (Schaltzeiten)', 'reduziert Heizen (dauernd)', 'normal Heizen (dauernd)']) }}
                            </div>
                        {% endmacro %}
                        Ich würde also keine Texte senden, sondern Zahlen und die zu Verständlichkeit an den entsprechenden Stellen in Text wandeln.

                        Kommentar


                          #13
                          Hm. Ich sehe, wie du das bei dir gemacht hast, und das ist nicht schlecht. Das war im Prinzip auch das, was ich bei mir im ersten Anlauf versucht habe - aber da bei mir das Schreiben der Betriebsart und das Auslesen der aktuellen Betriebsart über dieselbe Adresse erfolgt, kann ich keine zwei Items anlegen, das kann das Plugin nicht. Das akzeptiert nur ein Command pro Adresse.

                          Die Variante mit dem Subitem ist auch nicht schlecht, passt aber nur für deinen Heizungstyp. Meiner hat andere Betriebsarten, da müsste ich das selber definieren. Vielleicht sollte man das dann auch umgenennen, zB in struct BetriebsartKO1B oder so. Dann könnte man für jede Heizung ein eigenes Struct anlegen - was ich aber blöd fände, das müsste eigentlich automatisch gehen

                          Macht aber alles nix, mit der jetzigen Lösung funktionieren beide:

                          Du nutzt commandunit "BA" nur zum lesen - das funktioniert unverändert. Du schreibst (über BetriebsartA1M1) auf commandunit 'IFNON', das geht genauso.
                          Ich schreibe (jetzt) auf commandunit 'BA' und übergebe einen String -> das Plugin wandelt das intern automatisch in den passenden IFNON-Wert und sendet den.

                          Alle zufrieden... oder?

                          Ich teste das gleich nochmal, und wenn ich dann keine Fehler finde, schicke ich dir den PR. Bei Fragen -> gern!

                          Nachtrag: das passiert (jetzt), wenn du einen neuen String auf ein "Betriebsart"-Item sendest:

                          Code:
                          2020-04-17 09:35:06 DEBUG __init__ CP Server Thread-14 priv_viessmann: update_item was called with item 'd.heizung.betriebsart' from caller 'admin', source 'None' and dest 'None' -- __init__.py:log_debug:720
                          2020-04-17 09:35:06 DEBUG __init__ CP Server Thread-14 priv_viessmann: Got item value to be written: Warmwasser on command name Betriebsart. -- __init__.py:log_debug:720
                          2020-04-17 09:35:06 DEBUG __init__ CP Server Thread-14 priv_viessmann: Got a new write job: Command Betriebsart with value Warmwasser -- __init__.py:log_debug:720
                          2020-04-17 09:35:06 DEBUG __init__ CP Server Thread-14 priv_viessmann: Command config: {'addr': 'B000', 'len': 1, 'unit': 'BA', 'set': True} -- __init__.py:log_debug:720
                          2020-04-17 09:35:06 DEBUG __init__ CP Server Thread-14 priv_viessmann: Unit defined to IUNON with config{'unit_de': 'INT unsigned non', 'type': 'integer', 'signed': False, 'read_value_transform': 'non'}. -- __init__.py:log_debug:720
                          2020-04-17 09:35:06 DEBUG __init__ CP Server Thread-14 priv_viessmann: Created value bytes for type integer as hexstring: 01 and as bytes: b'\x01' -- __init__.py:log_debug:720
                          2020-04-17 09:35:06 DEBUG __init__ CP Server Thread-14 priv_viessmann: Payload length is: 6 bytes. -- __init__.py:log_debug:720
                          2020-04-17 09:35:06 DEBUG __init__ CP Server Thread-14 priv_viessmann: Preparing command Betriebsart with value 1 (transformed to value byte '01') to be sent as packet 41060002b0000101ba. -- __init__.py:log_debug:720
                          2020-04-17 09:35:06 DEBUG __init__ CP Server Thread-14 priv_viessmann: Successfully sent packet: 41060002b0000101ba -- __init__.py:log_debug:720
                          Zuletzt geändert von Morg; 17.04.2020, 09:38.

                          Kommentar


                            #14
                            Könntest dir vielleicht auch mal das drexel und weiß Plugin ansehen, ist ja eine ähnliche Gerätegruppe.

                            Über kurz oder lang schwebt mir übrigens ein generelles Plugin vor, das mit den verschiedensten Geräten wie AV Geräte, Squeezebox, Arduino, Wärmepumpen, etc. kommunizieren kann. So, dass die Grundkonfiguration für alle vom Konzept gleich bleibt und zB Werte solange gesendet werden, bis auch die korrekte Rückmeldung kommt, etc. Weiß aber nicht, ob das überhaupt sinnvoll umsetzbar ist und wie lange das dauert..

                            Kommentar


                              #15
                              Das klingt grundsätzlich nach keiner schlechten Idee. Ich weiß nur nicht, wieviel Aufwand es ist, die - teilweise sehr unterschiedlichen - Geräteinterfaces so zu abstrahieren, dass sowohl die Konfiguration quasi geräteunabhängig erfolgen kann als auch die Behandlung von Sonderfällen jeweils pro Gerätetyp/Gerätereihe funktioniert.

                              Hier ist ein simples Binärprotokoll mit poll-Verfahren; beim SML-Plugin (bzw. eHZ) hast du ja häufig schon nur eine push-Variante, und bei den Yamaha-Geräten hast du viele Parameter als poll-Werte, aber viele andere Werte bekommst du sekündlich im push und kannst sie nicht "anfordern".

                              Schwierig. Oder ich sehe noch nicht abstrakt genug

                              Kommentar

                              Lädt...
                              X