Ankündigung

**ivande** · 15.05.2024, 10:19

Zitat von Sipple Beitrag anzeigen

War da weiter oben nicht die Rede von einem bool Item?

in der plugin.yaml wird der Item-Pfad zum boolschen-Item übergeben - der Item pfad ist str

**ivande** · 15.05.2024, 18:37

Einbau von super().parse_item(item) brauchte auch nicht den Erfolg. Das plugin erkennt nicht, dass das unter suspend_item angegebene Item geändert wurde.

SH v1.10.0-master, python 3.9.2

Code:

def parse_item(self, item):
        """
        Default plugin parse_item method. Is called when the plugin is initialized.
        The plugin can, corresponding to its attribute keywords, decide what to do with
        the item in future, like adding it to an internal array for future reference
        :param item:    The item to process.
        """
        super().parse_item(item)
        ....

**Morg** · 16.05.2024, 06:33

Zitat von Morg Beitrag anzeigen

Außerdem in update_item:

Code:

# check for suspend item
if item is self._suspend_item:
  if caller != self.get_shortname():
    self.logger.debug(f'Suspend item changed to {item()}')
    self.set_suspend(by=f'suspend item {item.property.path}')
  return

Er soll ja auch auf die Änderung reagieren

ist leider nicht einfacher zu implementieren...

**ivande** · 16.05.2024, 11:21

mit super().parse_item(item) in parse_item und den Änderung in update_item:

das Item wird registriert, jedoch reagiert das Plugin nicht auf Änderungen - toggeln von Testweb.Bool1:

Code:

2024-05-16  11:57:03 INFO     plugins.priv_modbus_tcp Init modbus_tcp plugin
2024-05-16  11:57:07 DEBUG    plugins.priv_modbus_tcp suspend item Testweb.Bool1 registered
2024-05-16  11:57:08 DEBUG    plugins.priv_modbus_tcp Plugin 'priv_modbus_tcp': run method called
2024-05-16  11:57:08 DEBUG    plugins.priv_modbus_tcp scheduler_add: name = plugins.priv_modbus_tcp.poll_device_10.67.67.51, parameters: prio=5, cycle=20
2024-05-16  11:57:08 DEBUG    plugins.priv_modbus_tcp Plugin 'priv_modbus_tcp': run method finished
2024-05-16  11:57:24 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-16  11:57:24 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 1
2024-05-16  11:57:44 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-16  11:57:44 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 2
2024-05-16  11:58:05 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-16  11:58:05 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 3
2024-05-16  11:58:25 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-16  11:58:25 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 4

def parse_item(self, item):
        """
        Default plugin parse_item method. Is called when the plugin is initialized.
        The plugin can, corresponding to its attribute keywords, decide what to do with
        the item in future, like adding it to an internal array for future reference

        :param item:    The item to process.
        """
        
        super().parse_item(item)

def set_suspend(self, suspend_mode, by):
        """
        enable / disable suspend mode: open/close connections, schedulers
        """
        self.suspended = suspend_mode
        if self.suspended:
            self.logger.debug(f"Plugin '{self.get_fullname()}': Suspend mode enabled by:{by}")
        else:
            self.logger.debug(f"Plugin '{self.get_fullname()}': Suspend mode disabled by:{by}")

def update_item(self, item, caller=None, source=None, dest=None):
              
        # check for suspend item
        if item is self._suspend_item:
            if caller != self.get_shortname():
                self.logger.debug(f'Suspend item changed to {item()}')
                self.set_suspend(item(), by=f'suspend item {item.property.path}')
            return

        if self.suspended:
            if self.suspend_log_update is None or self.suspend_log_update is False:   # debug - Nachricht nur 1x ausgeben
                self.logger.info('Plugin is suspended, data will not be written')
                self.suspend_log_update = True
            return
        else:
            self.suspend_log_update = False

ohne super().parse_item(item) funktioniert das suspenden mit Ausnahme: wenn das Item schon bei start von SH aktiv ist läuft das Plugin trotz suspend.
Ich muss dann das Item 1xFalse und dann wieder auf True setzen damit der das plugin stoppt...

Code:

2024-05-16  12:06:46 INFO     plugins.priv_modbus_tcp Init modbus_tcp plugin
2024-05-16  12:06:51 DEBUG    plugins.priv_modbus_tcp suspend item Testweb.Bool1 registered
2024-05-16  12:06:51 DEBUG    plugins.priv_modbus_tcp add_item called with existing item Testweb.Bool1, updating stored data: is_updating enabled
2024-05-16  12:06:51 DEBUG    plugins.priv_modbus_tcp Plugin 'priv_modbus_tcp': run method called
2024-05-16  12:06:51 DEBUG    plugins.priv_modbus_tcp scheduler_add: name = plugins.priv_modbus_tcp.poll_device_10.67.67.51, parameters: prio=5, cycle=20
2024-05-16  12:06:51 DEBUG    plugins.priv_modbus_tcp Plugin 'priv_modbus_tcp': run method finished
2024-05-16  12:07:07 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-16  12:07:07 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 1
2024-05-16  12:07:23 DEBUG    plugins.priv_modbus_tcp Suspend item changed to False
2024-05-16  12:07:23 DEBUG    plugins.priv_modbus_tcp Plugin 'priv_modbus_tcp': Suspend mode disabled by:suspend item Testweb.Bool1
2024-05-16  12:07:28 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-16  12:07:28 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 2
2024-05-16  12:07:38 DEBUG    plugins.priv_modbus_tcp Suspend item changed to True
2024-05-16  12:07:38 DEBUG    plugins.priv_modbus_tcp Plugin 'priv_modbus_tcp': Suspend mode enabled by:suspend item Testweb.Bool1
2024-05-16  12:07:45 INFO     plugins.priv_modbus_tcp poll suspended

def parse_item(self, item):
        #super().parse_item(item)
        #check for suspend item
        if item.property.path == self._suspend_item_path:
            self.logger.debug(f'suspend item {item.property.path} registered')
            self._suspend_item = item
            self.add_item(item, updating=True)
            return self.update_item

Angehängte Dateien

priv_modbus_tcp_1.0.12_suspend.zip (273,5 KB, 1 Hit)

**Morg** · 17.05.2024, 12:25

So, sorry, da hatte ich tatsächlich Quark im Kopf...

Ich habe das Plugin mal angepasst, kann es aber leider nicht testen, also...

Die Änderungen habe ich schonmal für das SmartPlugin, das MQTTPlugin und v.a. die Beispiel-Plugins vorbereitet; wenn das im SmartPlugin "drin" ist, könnte hier einiges wieder raus. Es schadet aber auch erstmal nicht, wenn es drin bleibt...

Insofern viel Spaß beim Testen und - hoffentlich

- Verwenden.

Angehängte Dateien

__init__.py.zip (6,0 KB, 1 Hit)

**ivande** · 18.05.2024, 08:58

Funktioniert eben bis auf der Ausnahme: wenn das suspend-Item beim Starten von SH bereits auf True steht (da cache:True), sollte das Plugin doch erst gar nicht starten - macht es aber. Damit das Plugin stoppt darf das Item erst nach dem Start von SH gesetzt werden,...

Code:

##### suspend - Item beim Start von SH auf True - plugin läuft trotzdem an!! #####
2024-05-18  09:34:31 INFO     plugins.priv_modbus_tcp Init modbus_tcp plugin
2024-05-18  09:34:35 DEBUG    plugins.priv_modbus_tcp suspend item Testweb.Bool1 registered
2024-05-18  09:34:35 DEBUG    plugins.priv_modbus_tcp add_item called with existing item Testweb.Bool1, updating stored data: is_updating enabled
2024-05-18  09:34:36 DEBUG    plugins.priv_modbus_tcp Plugin 'priv_modbus_tcp': run method called
2024-05-18  09:34:36 DEBUG    plugins.priv_modbus_tcp scheduler_add: name = plugins.priv_modbus_tcp.poll_device_10.67.67.51, parameters: prio=5, cycle=20
2024-05-18  09:34:36 DEBUG    plugins.priv_modbus_tcp Plugin 'priv_modbus_tcp': run method finished
2024-05-18  09:34:54 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-18  09:34:54 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 1
2024-05-18  09:35:15 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-18  09:35:15 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 2
2024-05-18  09:35:35 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-18  09:35:35 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 3
2024-05-18  09:35:56 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-18  09:35:56 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 4
2024-05-18  09:36:16 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-18  09:36:16 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 5
##### suspend - Item wird nun auf False gesetzt - plugin läuft weiter #####
2024-05-18  09:36:23 DEBUG    plugins.priv_modbus_tcp Suspend item changed to False
2024-05-18  09:36:23 DEBUG    plugins.priv_modbus_tcp Suspend mode disabled (set by suspend item Testweb.Bool1)
2024-05-18  09:36:23 INFO     plugins.priv_modbus_tcp plugin resumed by suspend item Testweb.Bool1, connections will be resumed
2024-05-18  09:36:23 DEBUG    plugins.priv_modbus_tcp scheduler_add: name = plugins.priv_modbus_tcp.poll_device_10.67.67.51, parameters: prio=5, cycle=20
2024-05-18  09:36:37 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-18  09:36:37 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 6
2024-05-18  09:36:58 ERROR    pymodbus.logging    Connection to (10.67.67.51, 502) failed: timed out
2024-05-18  09:36:58 ERROR    plugins.priv_modbus_tcp could not connect to 10.67.67.51:502, connection_attempts: 7
2024-05-18  09:37:02 DEBUG    plugins.priv_modbus_tcp Suspend item changed to True
##### erst ein weiteres Setzten des suspend - Item bringt das plugin nun zum Anhalten #####
2024-05-18  09:37:02 DEBUG    plugins.priv_modbus_tcp Suspend mode enabled (set by suspend item Testweb.Bool1)
2024-05-18  09:37:02 INFO     plugins.priv_modbus_tcp plugin suspended by suspend item Testweb.Bool1, connections will be closed
2024-05-18  09:37:02 DEBUG    plugins.priv_modbus_tcp scheduler_remove: name = plugins.priv_modbus_tcp.poll_device_10.67.67.51

**Morg** · 18.05.2024, 22:00

Ah - das habe ich tatsächlich übersehen. Aus dem sdp-Code:

Code:

    def run(self):
        """
        Run method for the plugin
        """
        self.logger.dbghigh(self.translate("Methode '{method}' aufgerufen", {'method': 'run()'}))

        if self.alive:
            return

        # start the devices
        self.alive = True
        self.set_suspend(by='run()')

        if self._connection.connected():
            self._read_initial_values()

Du musst also in run() noch einmal self.set_suspend() aufrufen; ohne Parameter versucht der, den Wert aus dem Item zu holen. Wenn das Item nicht definiert ist, läuft er ganz normal weiter

**whe** · 30.05.2024, 11:44

Zurzeit versuche ich meine Wallbox mit dem Plugin zu steuern und habe ein paar Verständnis-Fragen:
- erfolgt die Kommunikation nur anhand der "cycle" Angabe ? .d.h. default alle 60 sec
- wann und wie werden die WRITEs ausgeführt ? nur im cycle oder sofort ?
- wenn mehrere Register verändert werden, werden die Register einzeln geschrieben ?

Kann das leider aus dem Code nicht erkennen.
Muss bei meiner PowerJames 3 Register setzen: Phasen, Leistung, Status

Habe SHNG v1.10.0-master (4b25822a0) im Einsatz aber die dev Version vom Modbus_tcp plugin 1.0.11
das auslesen der Register funktioniert einwandfrei, aber beim Schreiben habe ich Probleme.

**ivande** · 30.05.2024, 21:26

Zitat von whe Beitrag anzeigen

- erfolgt die Kommunikation nur anhand der "cycle" Angabe ? .d.h. default alle 60 sec

das lesen erfolgt Zyklisch - z.B. alle 60sec

Zitat von whe Beitrag anzeigen

wann und wie werden die WRITEs ausgeführt ? nur im cycle oder sofort ?
- wenn mehrere Register verändert werden, werden die Register einzeln geschrieben ?

sofort wenn das entsprechende SH-Item verändert wird und jedes veränderte Item dann einzeln

das auslesen der Register funktioniert einwandfrei, aber beim Schreiben habe ich Probleme.

welche Probleme wären das? dev Version vom Modbus_tcp plugin 1.0.11 sollte eigentlich scheiben,..
Ich kann das Schreiben soweit nur an meiner Siemens-Logo testen,..

**whe** · 31.05.2024, 09:50

ich glaube ich muss den debugger mal bemühen. logge zurzeit wenig.

Code:

2024-05-31  10:12:59 INFO     logics.fenecon      Idle: Leistung: 1173.0
2024-05-31  10:15:00 INFO     logics.fenecon      Idle: Leistung: 1650.0
2024-05-31  10:15:00 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.phases = 9  -  caller: Logic
2024-05-31  10:15:07 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.current = 6000  -  caller: Logic
2024-05-31  10:15:14 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 2  -  caller: Logic
2024-05-31  10:15:14 INFO     logics.fenecon      Laden Starten: 1650.0
2024-05-31  10:15:55 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.phases = 0  -  caller: modbus_tcp_dev_powerjames
2024-05-31  10:15:55 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.current = 16000  -  caller: modbus_tcp_dev_powerjames
2024-05-31  10:15:55 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 0  -  caller: modbus_tcp_dev_powerjames
2024-05-31  10:17:00 INFO     logics.fenecon      Idle: Leistung: 699.0
2024-05-31  10:19:01 INFO     logics.fenecon      Idle: Leistung: -48.0

habe schon ein time.sleep eingebaut, dass die Register zeitverzögert geschrieben werden.
nachdem ich die Werte gesetzt habe meldet das plugin andere Werte zurück.

**whe** · 31.05.2024, 11:38

kann leider nicht erkennen, dass irgend etwas geschrieben wird im plugin, wenn ich ein item ändere:

Code:

2024-05-31  12:32:28 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 2  -  caller: admin
2024-05-31  12:32:31 INFO     plugins.modbus_tcp_dev powerjames@: connected to ModbusTcpClient 192.168.178.72:502
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.109.1 (address.slaveUnit) regCount:1 result:ReadInputRegistersResponse (1)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read HoldingRegister.110.1 (address.slaveUnit) regCount:1 result:ReadHoldingRegistersResponse (1)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read HoldingRegister.111.1 (address.slaveUnit) regCount:1 result:ReadHoldingRegistersResponse (1)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read HoldingRegister.112.1 (address.slaveUnit) regCount:1 result:ReadHoldingRegistersResponse (1)
2024-05-31  12:32:31 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.chargetargetstate = 0  -  caller: modbus_tcp_dev_powerjames
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.161.1 (address.slaveUnit) regCount:1 result:ReadInputRegistersResponse (1)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.163.1 (address.slaveUnit) regCount:1 result:ReadInputRegistersResponse (1)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.166.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.168.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.170.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.172.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.174.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.176.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.178.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.180.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:31 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.182.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:32 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.192.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:32 DEBUG    plugins.modbus_tcp_dev powerjames@: read InputRegister.196.1 (address.slaveUnit) regCount:2 result:ReadInputRegistersResponse (2)
2024-05-31  12:32:32 DEBUG    plugins.modbus_tcp_dev powerjames@: poll_device: 17 register read required 0:00:00.885416 seconds

das item ist aber m.E. korrekt definiert:

Code:

           chargetargetstate:
                name: Charge-Target-State
                type: num
                enforce_updates: True
                modBusAddress@powerjames: 112
                modBusDirection@powerjames: 'read_write'
                log_change: carstate
                cache: True

**ivande** · 01.06.2024, 05:00

im Plugin-Admin-Interface kannst du die Register sehen welche und wann gelesen und geschrieben wurden. Wird das Register unter "registers to write" überhaupt aufgelistet?

Code:

2024-06-01 06:15:40 CEST DEBUG    __init__          CP Server Thread-18 logomb@: update_item:VM0 value:100 regToWrite: HoldingRegister.0.1  --  (__init__.py:update_item:405)
2024-06-01 06:15:40 CEST DEBUG    __init__          CP Server Thread-18 logomb@: connected to ModbusTcpClient 192.168.0.80:502  --  (__init__.py:update_item:408)
2024-06-01 06:15:40 CEST DEBUG    __init__          CP Server Thread-18 logomb@: write 10000.0 to HoldingRegister.0.0 (address.slaveUnit) dataType:uint16  --  (__init__.py:__write_Registers:456)

Code:

   VM0:
        type: num
        name: VM0
        modBusObjectType@logomb: HoldingRegister
        modBusAddress@logomb: 0
        modBusDirection@logomb: read_write
        modBusFactor@logomb: 0.01

beim Starten vom Plugin (Starten vom SH)

Code:

logomb@: parse item: VM0 Attributes {'regAddr': 0, 'slaveUnit': 1, 'dataType': 'uint16', 'factor': 0.01, 'byteOrder': <Endian.BIG: '>'>, 'wordOrder': <Endian.BIG: '>'>, 'item': Item: logo_modbus.VM0, 'value': 0, 'objectType': 'HoldingRegister', 'dataDir': 'read_write'}  --  (__init__.py:parse_item:246)

**whe** · 01.06.2024, 12:04

ja, die 3 Register werden dort angezeigt.
wenn ich ein Item ändere sehe ich auch via item logging, dass ich das item geändert habe:

Code:

2024-06-01  12:57:06 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.phases = 9  -  caller: admin
2024-06-01  12:57:08 INFO     items.carstate      Item Change: Aussen.Garage.PowerJames.phases = 0  -  caller: modbus_tcp_dev_powerjames

dass ein anderer Wert zurück kommt, kann natürlich auch an der Wallbox liegen; das kläre ich zurzeit noch ab.
im WebIF sehe ich von der Änderung nichts:
image.png

**whe** · 01.06.2024, 14:56

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.

**ivande** · 02.06.2024, 05:18

Zitat von whe Beitrag anzeigen

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.

Angehängte Dateien

modbus_tcp_v1.0.12.zip (265,1 KB, 3x aufgerufen)

Ankündigung

Einbindung von Modbus TCP

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar