Viessmann Plugin Neuentwicklung Python Hilfe

[Morg]

Dann überleg doch mal, ob es nicht einfacher ist, sich auf die "schreibbare" zu beschränken. Entweder mit Unit 'BA' und entsprechender Konfiguration (s.o.), oder mit Zahl, dann musst du den Rest selber machen.

Aber wie gesagt, du musst glücklich werden

[Sisamiwe]

Kannst du denn beide Adressen für Betriebsart lesen? Und nur eine schreiben? Dann würde ich das (für mich) auf eine beschränken.

Genau so ist es.

[Morg]

Ich nutze es aus dem AdminIF nur im Ausnahmefall, deshalt stört mich die "offene" Belegung nicht. In der Visu habe ich es wie du; ich probiere mal, ob man die Liste auch als Item übergeben kann, dann wäre es noch flexibler.

Du kannst aber für das Item eine "valid list" definieren, mit den Strings, die das Item annehmen kann, oder nicht? Dann wäre das auch entsprechend eingeschränkt. Ob du dann im AdminIF eine Auswahl bekommst, weiß ich allerdings nicht.

Kannst du denn beide Adressen für Betriebsart lesen? Und nur eine schreiben? Dann würde ich das (für mich) auf eine beschränken.

Aber das musst du letztlich selbst wissen. Ich habe gestern durch einen Fehler in der Konverterroutine (ist behoben ) als Betriebsart "11" geschrieben, da war die Heizung etwas überrascht. Gab keinen Fehler, aber sie war im Modus "Externe Steuerung", bis ich sie aus- und wieder eingeschaltet habe

[Sisamiwe]

Morg

Hallo,
erstmal vielen Dank für die schnelle Antwort und den Fix.

Das habe ich gefixt; in 'meinem' Repo ist es online. Mit dem PR möchte ich warten, bis ein Feedback von dir habe.

Das Schreiben der Betriebsart funktioniert nun wieder.
DANKE.

Warum schreibst du denn numerische Werte in eine zweite Konfiguration? Bzw. - wozu hat deine Heizung zwei Adressen für die Betriebsart, bist du sicher, dass das so passt? Intern (in der Heizung) werden doch beide nur als Ein-Byte-Wert gelesen/geschrieben.

Die Steuerung hat 2 Datenpunkte für die Betriebsart. Davon heißt eine "aktuelle Betriebsart" mit der Unit "BA" und die andere nur "Betriebsart" mit der Unit "IUINT". Nur die zweite lässt sich auch schreiben und so mache ich es auch. Warum es von seiten Viessmann 2 gibt, kann ich die nicht sagen.

Man könnte sogar überlegen, die BA-Werte als Liste per Funktion auszugeben, so dass die Visu die in einem Item bekommt...?

Ich habe in der Visu die Liste hinterlegt und habe darüber dann auch ein Auswahlmenü.
Mein Widget dazu:

/**
 * 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 %}

In shNG habe ich auch die Liste nochmal hinterlegt bzw. ist das struct beim Plugin dabei, so dass ich im AdminIF auch den Klartext habe.

viessmann.betriebsart:
    name: Betriebsart in string wandeln

    betriebsart_str:
        type: str
        eval: "'Neustart' if value == '' else ['Standby', 'Warmwasser (Schaltzeiten)', 'Heizen und Warmwasser (Schaltzeiten)', 'reduziert Heizen (dauernd)', 'normal Heizen (dauernd)'][int(value)]"
        eval_trigger: ..

Solange man im AdminIF die zulässigen Werte per Liste nicht einschränken kann bzw eine DropDown hat (wie bei bool), finde ich die Verwendung von Zahlen einfachen. Sicher Geschmacksache.

Beste Grüße

[Morg]

Ja.

Zwei Dinge:
- du hast deine Betriebsart zum Schreiben nicht mit 'BA' konfiguriert (und per String beschrieben)
- Fehler in der Unit-Konfiguration und dem Konfigurations-Handling

Zu Letzterem:

Aus einem mir nicht bekannten Grund (wahrscheinlich, weil ich es nicht benutzt habe?) ist die Implementation von IUINT kaputt. Er versucht, den übergebenen Wert mit dem 'transform'-Wert zu multiplizieren. Bei IUINT ist als Multiplikator aber 'int' angegeben, was a) Unsinn ist (die Heizung kennt nur INT) und b) natürlich nicht funktioniert, weil ein int('int') nicht funktionieren kann.

Das habe ich gefixt; in 'meinem' Repo ist es online. Mit dem PR möchte ich warten, bis ein Feedback von dir habe.

Zu Ersterem:

Warum schreibst du denn numerische Werte in eine zweite Konfiguration? Bzw. - wozu hat deine Heizung zwei Adressen für die Betriebsart, bist du sicher, dass das so passt? Intern (in der Heizung) werden doch beide nur als Ein-Byte-Wert gelesen/geschrieben.

Bei mir beschreibe ich die (eine) Adresse 'Betriebsart' auf Itemebene mit String, und das Plugin baut das auf Basis der Konfiguration in einen Bytewert zum Schreiben. Schreiben per String geht einwandfrei, wenn du die Werte in der Visu hinterlegst.

Man könnte sogar überlegen, die BA-Werte als Liste per Funktion auszugeben, so dass die Visu die in einem Item bekommt...?

So oder so, jetzt sollte es wieder gehen, probier mal bitte und gib mir Bescheid.

[Sisamiwe]

Morg

Du, ich habe noch etwas gefunden....

Ich wollte die Betriebsart schreiben und bekomme einen Fehler. Das Debug-Log zeigt:

2020-12-27 19:14:57 INFO plugins.viessmann update_item Update item: heizung.heizkreis_a1m1.betriebsart.betriebsart, item has been changed outside this plugin
2020-12-27 19:14:57 DEBUG plugins.viessmann update_item update_item was called with item Betriebsart_A1M1 from caller admin, source None and dest None
2020-12-27 19:14:57 DEBUG plugins.viessmann update_item Got item value to be written: 2 on command name Betriebsart_A1M1
2020-12-27 19:14:57 DEBUG plugins.viessmann _send_command Got a new write job: Command Betriebsart_A1M1 with value 2
2020-12-27 19:14:57 DEBUG plugins.viessmann _build_command_packet Build write packet for command Betriebsart_A1M1
2020-12-27 19:14:57 DEBUG plugins.viessmann _build_valuebytes_from_value Unit defined to IUINT with config{'unit_de': 'INT unsigned int', 'type': 'integer', 'signed': False, 'read_value_transform': 'int'}
2020-12-27 19:14:57 DEBUG plugins.viessmann _build_valuebytes_from_value _build_valuebytes_from_value failed with unexpected error: invalid literal for int() with base 10: 'int'
2020-12-27 19:14:57 DEBUG plugins.viessmann update_item Write for Betriebsart_A1M1 with value 2 failed, reverting value, canceling followup actions

Sagt Dir das was?

[Morg]

Falls jemand versuchen möchte, das Plugin zu verstehen:

viessmann-Plugin: Hauptroutinen

viessmann-Plugin: Details

[Morg]

Okay, dann sehe ich dein Problem. Das ist mir tatsächlich durchgerutsch. Gefixt auf github.

[Sisamiwe]

Morg

Ich mach dann nochmal ein anderes Log

Bzgl der Timer:

Meine Konfig:

heizung:
    heizkreis_a1m1:
        schaltzeiten:
            type: foo
            
            schaltuhr:
                name: Schaltzeiten im UZSU dict Format
                type: dict  
                visu_acl: rw  
                cache: yes
                viess_timer: Timer_A1M1
            montag:
                name: Timer_A1M1_Mo
                type: list
                viess_read: Timer_A1M1_Mo
                viess_send: true
                viess_read_afterwrite: 5
                viess_init: true
                #struct: viessmann.timer
                visu_acl: rw
            dienstag:
                name: Timer_A1M1_Di
                type: list
                viess_read: Timer_A1M1_Di
                viess_send: true
                viess_read_afterwrite: 5
                viess_init: true
                #struct: viessmann.timer
                visu_acl: rw
            mittwoch:
                name: Timer_A1M1_Mi
                type: list
                viess_read: Timer_A1M1_Mi
                viess_send: true
                viess_read_afterwrite: 5
                viess_init: true
                #struct: viessmann.timer
                visu_acl: rw
            donnerstag:
                name: Timer_A1M1_Do
                type: list
                viess_read: Timer_A1M1_Do
                viess_send: true
                viess_read_afterwrite: 5
                viess_init: true
                #struct: viessmann.timer
                visu_acl: rw
            freitag:
                name: Timer_A1M1_Fr
                type: list
                viess_read: Timer_A1M1_Fr
                viess_send: true
                viess_read_afterwrite: 5
                viess_init: true
                #struct: viessmann.timer
                visu_acl: rw
            samstag:
                name: Timer_A1M1_Sa
                type: list
                viess_read: Timer_A1M1_Sa
                viess_send: true
                viess_read_afterwrite: 5
                viess_init: true
                #struct: viessmann.timer
                visu_acl: rw
            sonntag:
                name: Timer_A1M1_So
                type: list
                viess_read: Timer_A1M1_So
                viess_send: true
                viess_read_afterwrite: 5
                viess_init: true
                #struct: viessmann.timer
                visu_acl: rw

und das Spezial-Log im Anhang.

So wie ich das sehe, nimmer alle Timer mit in das Dict zu abzufragenden Datenpunkte mit auf, führt auch die Abfrage durch.
Dann scheint es aber so, dass er den Wert nicht dem Item also bspw "heizung.heizkreis_m2.schaltzeiten.montag" zuweist, sondern es im timer_dict hinterlegt.

Es sollte so sein, dass beides parallel gefüllt wird. Könntest Du dir das nochmal anschauen?

DANKE

[Sisamiwe]

Hat wer das mit den Timern (zb: Timer_A1M1_Mo) irgendwie umgesetzt und ist Bereit das mal zu teilen.

Das kann ich gern machen. Die Implementierung ist auch von mir.

Zur Erklärung:
Es gibt prinzipiell 2 Möglichkeiten, die Timer auszulesen.

A) Jeden Timer einzeln, also den Datenpunkten entsprechend. D.h. Es gibt Einen Datenpunkt pro Timer-Anwendung und Tag. Dort sind die bis zu 4 Schaltzeiten hinterlegt. Dies funktioniert normal mit viess_read für jeden Datenpunkt. Zusätzlich kann man noch das mitgelieferte struct für den timer anwenden. Dann werden die Timer noch in einzelne Zeiten (AN1, AUS1, AN2, AUS2, ....) zerlegt jede Zeit einem Items zugewiesen.


B) Alle Timer einer Anwendung werden zusammengefasst und in das UZSU-Format umgesetzt. Dafür gibt es das Attribut viess_timer. Diesem wird in der item.yaml der "Oberbegriff" der entsprechenden Timer aus der command.py zugewiesen. Sind die Datenpunkte für den Timer in der command.py mit Timer_A1M1_Mo, Timer_A1M1_DI, Timer_A1M1_MI etc beschrieben, ist der Oberbegriff Timer_A1M1 und damit der Wert für das Attribut.

Hier wird aber nur die UZSU als Ein- und Ausgabemaske benutzt. Deswegen ist der Zustand der UZSU (Aktiv oder oder aus) auch egel. Es werden nur die Timer ausgelesen und angezeigt und bei Änderung in shNG wieder in die Heizung geschrieben.

Meine Konfig:

heizung:
    heizkreis_a1m1:
        schaltzeiten:
            type: foo
            
            schaltuhr:
                name: Schaltzeiten im UZSU dict Format
                type: dict  
                visu_acl: rw  
                cache: yes
                viess_timer: Timer_A1M1

In der Visu nutze ich das das UZSU-Widget, einmal als icon und einmal als table:

{{ device.uzsuicon('', 'heizung.heizkreis_a1m1.schaltzeiten.schaltuhr', 'HK_A1 Timer') }}
{{ device.uzsutable('','heizung.heizkreis_a1m1.schaltzeiten.schaltuhr','HK_A1','1','0','limegreen','red','','',true,'10m','solid',true,true,true,true,2,'','','') }}

Das stimmt aber so nicht ganz... erstens ist der Timer ja aktiv, was er hier nicht anzeigt:

Erklärung siehe oben

Und zweites waren es soweit ich mich erinnere am WE andere Schaltzeiten...

Ein Fehler ist mir noch nicht aufgefallen. Was zeigt denn die Heizung am Display direkt an?

Ich habe auch den Log-Level mal auf INFO gestellt. Da kannst du das Auslesen der Datenpunkte mit beobachten.

Beste Grüße
Michael

[TCr82]

Hi, mal was anderes:

Hat wer das mit den Timern (zb: Timer_A1M1_Mo) irgendwie umgesetzt und ist Bereit das mal zu teilen.
Also wie er das in SHNG und Visu umgsetzt hat.

Ich habe das mal wie hier beschrieben eingebaut:

technik:
    heizung:
        WW:
            Schaltzeiten:  
                type: bool
                struct: uzsu.child
                uzsu:
                    name: Schaltzeiten im UZSU dict Format
                    viess_timer: Timer_Warmwasser

Dabei hat das Objekt nun folgenden Wert (laut Backend Webinterface):

{'interpolation': {'type': 'none', 'initialized': False, 'itemtype': 'bool'}, 'list': [{'time': '04:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '1', 'active': True}, {'time': '04:30', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '0', 'active': True}, {'time': '07:30', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '1', 'active': True}, {'time': '09:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '0', 'active': True}, {'time': '14:30', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '1', 'active': True}, {'time': '15:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '0', 'active': True}, {'time': '17:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '1', 'active': True}, {'time': '22:00', 'rrule': 'FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU', 'value': '0', 'active': True}], 'active': False, 'lastvalue': None, 'sunrise': '08:22', 'sunset': '16:31'}

Das stimmt aber so nicht ganz... erstens ist der Timer ja aktiv, was er hier nicht anzeigt:

Screenshot_20201224_002726.png
Und zweites waren es soweit ich mich erinnere am WE andere Schaltzeiten...

[Morg]

Das würde doch so reichen. Solange der Filter auf IOError reicht? Denn ich nutze zB. noch nicht Version 3.5 von pyserial die so wie ich das verstanden habe keine Exception vom Typ IOError wirft, sondern SerialException wirft.

Nä.

1. Die Vererbung war "früher" Exception -> SerialException, "jetzt" Exception -> IOError -> SerialException. Aber: das ist nicht "erst" seit 3.5, sondern 2.5 (ZWEI-Fünf), also schon eine ganze Weile her. Halte ich daher für unerheblich. btw - ich weiß gar nicht, ob es 3.5 schon gibt; ich habe selbst noch 3.4 drauf.

2. Mit IOError fange ich SerialException auch ein, weil die von IOError abgeleitet ist. Jede SerialException IST auch ein IOError. (steht übrigens auch auf der von dir verlinkten Seite, an der gleichen Stelle )

Und was der OSError da jetzt soll, verstehe ich nicht ganz.

Ich sehe das derzeit auch nicht als Problem - wenn meinetwegen beim Schreiben oder auch in "Leerlaufzeiten" die serielle Verbindung abraucht, dann ist mit das - im Prinzip - egal, weil ich es eh erst beim nächsten Schreiben feststellen kann. Und wenn ich dann feststelle, dass es nicht geht, verbinde ich neu. Wenn das nicht klappt (weil das device noch nicht wieder da ist zB), dann kann ich es eh nicht ändern.

Wenn du in der Kette noch Verbesseungsmöglichkeiten siehst, dann immer her damit.

Was ja bedeutet, dass er nicht in den disconnect Code rein läuft... oder irre ich mich da?

Du irrst, s.o.

Die Plugin Funktion zum testen von nicht definierten Adressen könnte man auch noch ins WebIF einbauen, falls du das nicht schon drin hast (habe noch nicht die aktuelle Änderung getestet).

Ach und schreiben ist auch untergegangen im WebIF

Die ist schon drin, ist nur noch nicht hochgeladen. Und Schreiben vom WebIf sehe ich jetzt nicht so als vordringliche Geschichte an. Schreiben würde ich sowieso erst, wenn ich sicher bin, was die Datenpunkte tun und welche Werte es da gibt. Und dann hätte ich sie - hoffentlich - sowieso schon in der commands.py und könnte (notfalls) übers AdminUI schreiben, wenns denn sein muss. Die Heizung ist ja nu kein Teil, auf das ich - mal eben, spontan - willkürliche Werte werfen wollte. Bei nem Lichtschalter oder meinetwegen einem RGB-Dimmer wäre das was anderes.

Ich schreibe zweimal im Jahr auf meine Heizung - einmal im Frühjahr (Heizung aus) und einmal im Herbst (Heizung an). Meistens geht es aber schneller, das per Hand am Gerät zu machen, als erst irgenwo ein Item zu schreiben. Und das sind auch Fälle, die ich nicht algorithmisch lösen kann. Kein SciPy kann ermitteln, ob mir schon zu kühl an den Füßen ist oder nicht

Vielleicht bau ich das Schreiben später mal ein, wenn alle danach schreien und ansonsten kannst du mir gern jederzeit nen PR dazu schicken

[TCr82]

Hmm.. ich hab es einfach mal getestet, in dem ich das USB-Gerät mit dem Skript von hier kurz neu gestartet habe.

Dec 23 17:04:29 heizung kernel: [159019.164772] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
Dec 23 17:04:29 heizung kernel: [159019.164895] cp210x 1-1.5:1.0: device disconnected
Dec 23 17:04:30 heizung kernel: [159019.693706] cp210x 1-1.5:1.0: cp210x converter detected
Dec 23 17:04:30 heizung kernel: [159019.698356] usb 1-1.5: cp210x converter now attached to ttyUSB0
Dec 23 17:04:30 heizung kernel: [159019.698991] usb 1-1.5: authorized to connect

2020-12-23 17:04:38 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:774)
2020-12-23 17:04:38 ERROR __init__ plugins.viessmann.cyclic Trying to reconnect (disconnecting, connecting -- (__init__.py:_KW_send_multiple_read_commands:775)
2020-12-23 17:04:38 DEBUG smartplugin plugins.viessmann.cyclic scheduler_get: name = plugins.viessmann.cyclic -- (smartplugin.py:scheduler_get:675)
2020-12-23 17:04:38 DEBUG smartplugin plugins.viessmann.cyclic scheduler_remove: name = plugins.viessmann.cyclic -- (smartplugin.py:scheduler_remove:660)
2020-12-23 17:04:38 INFO __init__ plugins.viessmann.cyclic Disconnected -- (__init__.py:_disconnect:517)
2020-12-23 17:04:38 DEBUG __init__ plugins.viessmann.cyclic cyclic command read took 0.0 seconds for 2 items -- (__init__.py:send_cyclic_cmds:360)

Schein also zu funktionieren, soweit ich das sehen kann... Hoffe zumindest dass der nächste Cycle wieder verbindet...

EDIT: Japp, funtioniert 1A

[TCr82]

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.

Das würde doch so reichen. Solange der Filter auf IOError reicht? Denn ich nutze zB. noch nicht Version 3.5 von pyserial die so wie ich das verstanden habe keine Exception vom Typ IOError wirft, sondern SerialException wirft.

EDIT:

Hier nochmal ein alternatives Beispiel:
https://www.programcreek.com/python/...erialException

Sollte das nicht dann so aussehen, um einfach auf jeden Fehler zu reagieren?

except (OSError, serial.SerialException):

Oder wie hier:

except (serial.SerialException, IOError) as error:

EDIT END

root@heizung:/usr/local/smarthome/plugins/viessmann# sudo -Hu smarthome pip3 freeze | grep pyserial
pyserial==3.4

Was ja bedeutet, dass er nicht in den disconnect Code rein läuft... oder irre ich mich da?

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

Die Plugin Funktion zum testen von nicht definierten Adressen könnte man auch noch ins WebIF einbauen, falls du das nicht schon drin hast (habe noch nicht die aktuelle Änderung getestet).

Ach und schreiben ist auch untergegangen im WebIF

[Morg]

In der plugin.yaml war viess_update nicht beschrieben. Damit weiß niemand, dass es das gibt, und shng kann die Syntax nicht prüfen. Also habe ich es aufgenommen.

Allerdings habe ich es mit Typ "bool" aufgenommen, also viess_update möchte mit True / False gefüttert werden, nicht mit 1/0. Das müsste innerhalb shng relativ egal sein, weil sich jetzt Zahl != 0 in True und 0 in False wandeln lässt. Ich wollte nur drauf hinweisen, weil du geschrieben hast, dass du "1" und "0" zuweist

Was mir aber gerade einfällt: welche autotimer-Kompatibilität ist bei dir eingestellt? Die alte Variante weist nicht 0 zu (also die Zahl), sondern "0", einen String. Und str(0) ist nicht False, sondern True, also würde deshalb neu gelesen.

Probier mal

autotimer: 10 = 0 = latest

, damit könnte es dann gehen. (Dann kannst du den auch gleich auf eine Sekunde, setzen )