Einbindung von Modbus TCP

[Msinn]

Nein, wenn Du ein Plugin nach dem Neustart nicht starten möchtest, musst Du es in der etc/plugin.yaml disablen.

stop() und run() wirken bewusst nur auf aktuell geladene Plugins.

[ivande]

developer_mode:

wenn das plugin gestopt wird und daraufhin sh neu gestartet wird, wird die run-Funktion beim Start wieder ausgeführt. Sollte ein gestopptes Plugin nicht auch nach dem Neustart von SH gestoppt bleiben?

SH hab ich als master laufen,...

[Msinn]

Wenn Du für das Admin Modul den developer_mode auf True konfigurierst, hast Du in der Plugin Liste zu jedem Plugin zusätzliche Buttons, mit denen Du das Plugin stoppen und starten kannst.

developer_mode kannst Du entweder in der GUI (System/System Konfiguration) oder in der Datei etc/module.yaml konfigurieren. Anschließend neu starten.

[Morg]

Gut, danke!

Ähm... mit <plugin>.stop() bzw. <plugin>.start()? ;-)

Entweder aus einer Logik oder von der Konsole aus. In der UI ist das meines Wissens noch nicht implementiert...

[ivande]

guten morgen,

mir fällt jetzt nichts ein, was gegen stop und run spricht.
Gibt es jetzt schon eine Möglichkeit das Plugin zu stoppen und su starten? evtl. in der SH-debug-Version?

Gruß Ivan

[Morg]

Moin,

aufgrund von geplanten Änderungen am SmartPlugin überlegen wir, die suspend-Funktionalität anzupassen. Die Änderungen würden sich insoweit auswirken, dass das Plugin nicht "stummgeschaltet" wird (wie jetzt in suspend), sondern angehalten (über stop()) und entweder von Hand oder per Item mit run() wieder gestartet wird.

Das setzt voraus, dass das Plugin "restartable" ist, also bei stop() alles Notwendige aufräumt und bei run() alles Notwendige wieder startet, ohne dass init(), parse_item() o.ä. notwendig wäre.
Das heißt insbesondere, dass bei zusätzlichen Threads diese in run() neu erstellt werden müssen (und nicht gestartet), da Threads aufgrund eines Fehlers (?) in Python nicht neugestartet werden können.

Dazu wäre die Frage: gibt es Funktionen, die das Plugin bei suspend() ausführen (können) soll? Oder würde stop/run für euch den gleichen Zweck erfüllen?

Wenn wir das umsetzen, kann ich bei den ggf. notwendigen Änderungen gern unterstützen.

Gruß
Sebastian

[whe]

habs gerade getestet: enforce_update reicht.

2024-06-03  22:54:27 DEBUG    plugins.modbus_tcp_dev powerjames@: update_item:Charge-Target-State value:0 regToWrite: HoldingRegister.112.1
2024-06-03  22:54:27 INFO     plugins.modbus_tcp_dev powerjames@: connected to ModbusTcpClient 192.168.178.72:502
2024-06-03  22:54:27 DEBUG    plugins.modbus_tcp_dev powerjames@: write 0 to HoldingRegister.112.112 (address.slaveUnit) dataType:uint16
2024-06-03  22:54:55 DEBUG    plugins.modbus_tcp_dev powerjames@: update_item:Charge-Target-State value:0 regToWrite: HoldingRegister.112.1
2024-06-03  22:54:55 INFO     plugins.modbus_tcp_dev powerjames@: connected to ModbusTcpClient 192.168.178.72:502
2024-06-03  22:54:55 DEBUG    plugins.modbus_tcp_dev powerjames@: write 0 to HoldingRegister.112.112 (address.slaveUnit) dataType:uint16​

[ivande]

wie kann ich denn am einfachsten feststellen, ob Register in die Wallbox geschrieben werden.

wenn modbus_tcp im DEBUG, dann siehst du im log diese drei Einträge, wenn das Register geschrieben wird:

2024-06-03 21:58:45 CEST DEBUG    __init__          CP Server Thread-18 logomb@: update_item:VM0 value:20 regToWrite: HoldingRegister.0.1  --  (__init__.py:update_item:405)
2024-06-03 21:58:45 CEST DEBUG    __init__          CP Server Thread-18 logomb@: connected to ModbusTcpClient 192.168.0.80:502  --  (__init__.py:update_item:408)
2024-06-03 21:58:45 CEST DEBUG    __init__          CP Server Thread-18 logomb@: write 2000.0 to HoldingRegister.0.0 (address.slaveUnit) dataType:uint16  --  (__init__.py:__write_Registers:456)​

oder im admin-interface unter "registers to write" steht bei last_write die Uhrzeit wann das letze mal gesendet

[whe]

reicht enforce_update nicht aus dass SH auch ein nicht verändertes Item Triggert und das Register dann gesendet wird?

Danke, das hatte ich gerade auch überlegt.
in meinem log ist ja nur ein item-trigger, der beim zyklischen lesen wohl das item überschreibt.
ich versuche es morgen noch mal mit "enforce_update".
wie kann ich denn am einfachsten feststellen, ob Register in die Wallbox geschrieben werden.

Hast du einen log vom zyklischen Senden - dieser log stamm doch nur vom zyklischen Lesen?

ja, da stehen aber nicht die Werte drin, die gelesen werden.
vielleicht kann ich es auch im Webif über den Zeitstempel erkennen.

[ivande]

enforce_update reicht auch, dass SH auch ein nicht verändertes Item sendet.

hab enforce_change bei mir getestet:
das Item wird zyklisch mit dem gleichen Wert geschrieben (vom cyklischen-modbus-lesen) aber es wird dabei nicht erneut der selbe wert über den modbus gesendet, wenn das Item-Update vom pugin selber kommt.



Hast du einen log vom zyklischen Senden - dieser log stamm doch nur vom zyklischen Lesen?

items.carstate Item Change: Aussen.Garage.PowerJames.chargetargetstate = 0 - caller: modbus_tcp_dev_powerjames

[whe]

Jetzt habe ich doch noch ein Problem mit den Updates.
meine Wallbox hat ein Register "Charge-Target-State" mit dem ich Änderungen durchführen muss, je nach Inhalt ändert die Wallbox Werte, die ich über andere Register (vorher) übertrage. Wenn ich jetzt mehrfach den gleichen Wert ändern muss, enthält dieses Register mehrfach hintereinander den gleichen Wert.
Das scheint SHNG aber nur zu schreiben, wenn ich im item "enforce_change" angebe.
wenn ich das mache, schreibt das Plagin aber auch cyclisch dieses Register und nicht nur wenn ich das item ändere.

2024-06-03  19:39:16 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 0  -  caller: modbus_tcp_dev_powerjames
2024-06-03  19:40:16 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 0  -  caller: modbus_tcp_dev_powerjames
2024-06-03  19:41:17 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 0  -  caller: modbus_tcp_dev_powerjames
2024-06-03  19:42:17 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 0  -  caller: modbus_tcp_dev_powerjames
2024-06-03  19:43:17 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 0  -  caller: modbus_tcp_dev_powerjames
2024-06-03  19:44:18 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 0  -  caller: modbus_tcp_dev_powerjames

[Tom Bombadil]

Mir ist beim debuggen noch aufgefallen, dass bei jedem cycle ein connect gemacht wird.

Ich hatte damals im Trovis-Plugin das Connect anfangs auch nur beim Start - war unpraktisch.
Wann auch immer eines der beteiligten Geräte (Endgerät, Adapter, Router/DNS Server, Netzwerkschnittstelle) neu gestartet wurde, musste man einen connect() initiieren.
Die dazu notwendigen Routinen zur Prüfung waren mehr Aufwand, als ein regelmäßiges connect/disconnect.
Hab das dann entsprechend auch auf jeden Poll umgestellt - ist transparenter, kostet nicht wirklich Last, und ist ohne Neustart stabil, sobald alle Geräte wieder da sind ...

/tom

[whe]

Mir ist beim debuggen noch aufgefallen, dass bei jedem cycle ein connect gemacht wird.
würde es nicht reichen, nur bei der Initialisierung den connect zu machen.
schließlich wird ja regelmäßig gelesen, sodass die Verbindung erhalten bleibt.
allerdings müsste der connect wiederholt werden, wenn die Verbindung aus welchen Gründen auch immer verloren gaht.

[ivande]

In der Dokumentation steht dass: modBusObjectTyp: HoldingRegister der default sei, deshalb hatte ich das nicht angegeben.
wenn ich das spezifiziere werden auch die updates erkannt.

modBusObjectTyp ist per default HoldingRegister, jedoch wurde der update-Befehl ohne angabe von modBusObjectTyp abgebrochen. Ich werde das auch noch ins nächste Update einbauen.

Danke für die Hinweise und Fehlersuche!

habe für die letzten Änderungen einen PullRequest erstellt, vielleicht kann jemand die V1.0.12. auch schon im Vorfeld testen.

[whe]

kaum macht man's richtig, schon geht's.

In der Dokumentation steht dass: modBusObjectTyp: HoldingRegister der default sei, deshalb hatte ich das nicht angegeben.
wenn ich das spezifiziere werden auch die updates erkannt.