Einbindung von Modbus TCP

[bmx]

Ich vermute in Deiner Heizung wird es eine Reihenfolge der Aktualisierung geben die sich nicht ändert.
Je nachdem wie die Abfragezeit ist, kannst Du Dich vermutlich auch nicht darauf verlassen das D auf 0 gesetzt wurde obwohl man zur Nacht hin vermuten sollte das sich dann nichts mit PV tut. Es sei denn es ist Sommer und Du wohnst in Norwegen oder so...

Die Abfrage der Modbus Adressen erfolgt vermutlich in der Reihenfolge wie die Item aus den Yaml Dateien gelesen werden aber das ich nicht als sicher anzunehmen.

Ich würde also den Wert der Heizung nicht durch ein eval ermitteln sonder mir eine Logik bauen die durch beide Items getriggert wird.
Dann kannst Du beim Aufruf prüfen ob die Items gerade eben also z.B. innerhalb der letzten 2-3 Sekunden beide aktualisiert wurden oder nur eines davon. Im letzteren Fall kannst Du die Logik schlicht verlassen, im ersteren Fall kannst Du die Summe beider Itemwerte bilden wie vorgesehen und an Heizung zuweisen.

[aldaris]

Einmal muss ich noch nachfragen, hier gibt es vielleicht einen Trick, den ich noch nicht kenne:

Ich habe zwei Modbus Adressen. Eine liefert den Tagesverbrauch ab 0:00 Uhr und der andere der Gesamtverbrauch seit erstem Start bis 0:00 Uhr. Warum auch immer.

Ich will jedenfall die Gesamtenergie, also addiere ich beide Werte:

      HeizungD:
            name: HeizungD
            modBusObjectType@wpl: InputRegister
            modBusAddress@wpl: 3510
            modBusDataType@wpl: int16
            modBusFactor@wpl: 1
            modBusUnit@wpl: 3
            type: num
            database: init
            database_maxage: 31
          HeizungTotalK:
            name: HeizungTotalK
            modBusObjectType@wpl: InputRegister
            modBusAddress@wpl: 3511
            modBusDataType@wpl: int16
            modBusFactor@wpl: 1
            modBusUnit@wpl: 3
            type: num
            database: init
            database_maxage: 31
          Heizung:
            name: Heizung
            eval_trigger: Haus.Zentral.Zentral.PhotovoltaikEnergy.Raw.HeizungD|Haus.Zentral.Zentral.PhotovoltaikEnergy.Raw.HeizungTotalK
            eval: (sh...HeizungD() + sh...HeizungTotalK())
            type: num
            database: init
            database_maxage: 31​

Das Problem ist hier, dass im um 00:00 ein "flackern" kriege, je nachdem welcher Wert zuerst aktualisiert wird.
Also
D: 20, Total 100 => 120
D: 0, Total 100 => 100
D: 0, Total 120 => 120
Oder
D: 20, Total 100 => 120
D: 20, Total 120 => 140
D: 0, Total 120 => 120

Beides ist schlecht, weil ich über Min / Max auf dem Item auswertungen machen will.

Ich hatte schon mal den Plan auf Monotonie zu gehen, dann muss ich aber sicherstellen, 3510 zuerst gesetzt wird.
eval: (sh...HeizungD() + sh...HeizungTotalK()) if (sh...HeizungD() + sh...HeizungTotalK()) >= sh..() else None
=> Ist die Reihenfolge irgendwie deterministisch oder zufällig?
=> Kann man die beeinflussen?
=> Oder habe ich einfach ein Brett vor dem Kopf und es geht leicher?

[aldaris]

Naja, der Trick war ja jetzt zu wissen, dass es diesen Offset gibt und der "Ok" ist. Die Werte anzupassen nicht jetzt nicht der Aufwand. Also nicht viel mehr als es zentral einzustellen => Ich brauche es nicht

[bmx]

Theoretisch könnte man ins Plugin einbauen das er zu jeder Adresse erst noch einen Offset addiert oder subtrahiert damit man nicht alle Adressen ändern muss wenn man sie irgendwoher genommen hat. Ich brauche das Feature aber nicht und weiß nicht ob es allgemeine Verwendung dafür gibt?

[bmx]

Ja, weil Modbus Adressen eigentlich 0 basiert sind aber das unterschiedliche Geräte und Clients anders aufbereiten. Der Unterschied ist nur ein Offset von 1 bei allen Adressen mit absoluten Registerangaben

[aldaris]

Hi,

ich versuche gerade meine neue Wärmepumpe auszulesen. Irgendwie habe ich einen Register Offset. Vermutlich mache ich was falsch, aber ich sehe es einfach nicht.

Ziel: Die Leistungsaufnahme der berechnen. Das sieht in der UI so aus:
grafik.png

Laut Stiebel sind das die Register 3511, 3512 und 3513
grafik.png

Wenn ich die über einen ModbusClient am Handy auslese erreiche ich:
3511: 20
3512: 8
3513: 0

Ich lese Input Register.

Bis auf die fehlenden Nachkommastellen stimmt das. Jetzt das ganze schnell in smarthomeng:

StiebelA:
            name: StiebelA
            modBusObjectType@wpl: InputRegister
            modBusAddress@wpl: 3511
            modBusDataType@wpl: int16
            modBusUnit@wpl: 3
            type: num
            database: init
            database_maxage: 31
        StiebelB:
            name: StiebelB
            modBusObjectType@wpl: InputRegister
            modBusAddress@wpl: 3512
            modBusDataType@wpl: int16
            modBusUnit@wpl: 3
            type: num
            database: init
            database_maxage: 31        
        StiebelC:
            name: StiebelC
            modBusObjectType@wpl: InputRegister
            modBusAddress@wpl: 3513
            modBusDataType@wpl: int16
            modBusUnit@wpl: 3
            type: num
            database: init
            database_maxage: 31
        StiebelD:
            name: StiebelD
            modBusObjectType@wpl: InputRegister
            modBusAddress@wpl: 3510
            modBusDataType@wpl: int16
            modBusUnit@wpl: 3
            type: num
            database: init
            database_maxage: 31​

Gibt e sirgendeine sinnvolle Erklärung, warum die Register scheinbar verschoben sind?
grafik.png

[aldaris]

Danke. Die Lösung war: Ich hatte die falsche unitId. Mit der richtigen geht's dann wie erwartet

[whe]

Hol Dir mal qModMaster: https://sourceforge.net/projects/qmodmaster/
ist eine einfache .exe für Windows, die nicht installiert werden muss (nur downloaden und anklicken)
damit kannst die Register die Du brauchst testen bevor Du sie als Items in SHNG einbaust.

[whe]

das sieht doch nach 0xFFFF FFFF aus, dass diese Werte gar nicht vorhanden sind "NaN"
versuche es doch mal mit Registern, deren Inhalt Du kennst.

[aldaris]

Hi,
so ähnlich habe ich das auch:
Items:

Test:
  A:
    type: num
    name: TestIR
    enforce_updates: True
    modBusAddress: 31393
    modBusDataType:  uint32
  B:
    type: num
    name: TestHR
    enforce_updates: True
    modBusAddress: 31395
    modBusDataType: uint32​

Doku SMA z.B.
grafik.png

Beide Items haben aber dann einen seltsamen (gleichen) Wert
grafik.png

[whe]

was heißt denn "komisch" ?
es gelten zwar default Werte, aber oft muss Du natürlich bei den items mehr vorgeben:
z.B den "modbusDataType" und manchmal auch mit dem "modbusFactor" den Wert anpassen.
hast Du mal in die Doku geschaut, was man da alles spezifizieren kann.
und hast Du eine SMA Doku zu den Modbus Registern ?

Beispiel:

            grid:
                name: Netz Wirkleistung
                type: num
                modBusFactor@fenecon: -1
                modBusAddress@fenecon: 315
                modBusDataType@fenecon: 'float32'​

[aldaris]

Hallo,

Ich versuche mich gerade an diesem Plugin versucht, um mit meinem Wechselrichter zu sprechen. Plugin läuft, Status connected.

Die Werte die ich kriege sind aber komisch, ich vermute, das RegisterFormat ist falsch. Hat schonmal jemand eine SMA WR zum laufen bekommen und ein Demo Item?

[Morg]

suspend wird in der bisherigen Art nicht implementiert bleiben. Da Plugins sowieso idealerweise neustartbar sind, nutzen wir stattdessen stop() und run().

Dass das Plugin bei aktivem Item nicht startet, ist derzeit nicht implementiert; das ließe sich bei entsprechendem Bedarf aber ohne großen Aufwand nachrüsten.

[Msinn]

Suspend ist neu und ich kenne die gensue Funktion nicht.
run() und stop() tun seit Anbeginn von smarthome.py genau das, was Du beschrieben hast. Diverse Plugins haben das aber nicht sauber implementiert. Bei denen ist ein Teil des Codes, der in run() gehört in der init Routine. Diese lassen sich ohne neustart von SmartHomeNG nicht neu starten.

[ivande]

mit suspend() kann ich das Plugin anhalten und es bleibt während der Laufzeit von SH und bei einem Neustart von SH suspendet.

Mi stop() kann ich das plugin anhalten und es startet bei Neustart von SH (oder mit run()) wieder?


oder sollte stop() und suspend() das selbe bewirken - Plugin wird angehalten - und wenn ein suspend_item definiert ist bleibt das plugin auch nach dem SH-Neustart suspendet?