MODBUS binding works intermittently with WAGO 750-881 PLC

Add-ons Bindings
,
1

I’m checking out the MODBUS binding to command my Wago 750-881 PLC from openHAB2.
My home-brew light blocks use a NOVRAM variable to store state information (state 0 = light is off, state 10 = light is on)
I managed to get everything up and running (full configuration details below), reading from the PLC work flawless all the time, but writing from openHAB to the PLC only works intermittently. There’s no perceivable pattern when it works and when it doesn’t, it’s random about 1 out of 2 to 4 times.
Any ideas how I can investigate this further ?
One strange thing: the log mentions a ‘slave1’ modbusSlave which is not defined anywhere in my configuration files. I did a thorough check on this. I’m certain ‘slave1’ in not in the files.

I’m running openHAB2 version 2.2.0 on Ubuntu 16.04 on Intel x64 hardware

version of the modbus binding

237 │ Active │ 80 │ 1.11.0 │ openHAB ModbusTCP Master Binding

modbus.cfg (12288 is the start of the NOVRAM holding register address space on the Wago PLCs)

tcp.wago1.connection= 192.168.0.41:502
tcp.wago1.type=holding
tcp.wago1.start=12288
tcp.wago1.length=10
tcp.wago1.valuetype=int16

Item configuration

Switch inkom_spots (gVerlichtingBeneden) {modbus=“<[wago1:4], >[wago1:4:transformation=MAP(simpleRelay.map)]”}

Typical log output when toggling the item state from within openHAB

18:56:37.151 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘inkom_spots’ received command ON
18:56:37.157 [DEBUG] [inding.modbus.internal.Transformation] - transformed response is ‘10’
18:56:37.171 [DEBUG] [inding.modbus.internal.Transformation] - Transformed item command ‘ON’ to a command 10. Command as string ‘ON’, transformed string ‘10’, transformation ‘MAP(simpleRelay.map)’
18:56:37.181 [DEBUG] [b.binding.modbus.internal.ModbusSlave] - ModbusSlave (wago1): FC6 ref=12292 value=10
18:56:41.025 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘inkom_spots’ received command OFF
18:56:41.026 [DEBUG] [inding.modbus.internal.Transformation] - transformed response is ‘0’
18:56:41.038 [INFO ] [smarthome.event.ItemStateChangedEvent] - inkom_spots changed from ON to OFF
18:56:41.043 [DEBUG] [inding.modbus.internal.Transformation] - Transformed item command ‘OFF’ to a command 0. Command as string ‘OFF’, transformed string ‘0’, transformation ‘MAP(simpleRelay.map)’
18:56:41.058 [DEBUG] [b.binding.modbus.internal.ModbusSlave] - ModbusSlave (wago1): FC6 ref=12292 value=0
18:56:43.085 [INFO ] [smarthome.event.ItemStateChangedEvent] - collectorGarageRetour_temp changed from 39.5 to 39.8
18:56:43.374 [DEBUG] [inding.modbus.internal.Transformation] - transformed response is ‘10’
18:56:43.382 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘inkom_spots’ received command ON
18:56:43.386 [DEBUG] [inding.modbus.internal.Transformation] - Transformed item command ‘ON’ to a command 10. Command as string ‘ON’, transformed string ‘10’, transformation ‘MAP(simpleRelay.map)’
18:56:43.391 [INFO ] [smarthome.event.ItemStateChangedEvent] - inkom_spots changed from OFF to ON
18:56:43.406 [DEBUG] [b.binding.modbus.internal.ModbusSlave] - ModbusSlave (wago1): FC6 ref=12292 value=10
18:56:45.048 [INFO ] [smarthome.event.ItemStateChangedEvent] - collectorRetour_bureauLinks changed from 45.6 to 45.8
18:56:45.962 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘inkom_spots’ received command OFF
18:56:45.964 [DEBUG] [inding.modbus.internal.Transformation] - transformed response is ‘0’
18:56:45.971 [INFO ] [smarthome.event.ItemStateChangedEvent] - inkom_spots changed from ON to OFF
18:56:45.977 [DEBUG] [inding.modbus.internal.Transformation] - Transformed item command ‘OFF’ to a command 0. Command as string ‘OFF’, transformed string ‘0’, transformation ‘MAP(simpleRelay.map)’
18:56:45.991 [DEBUG] [b.binding.modbus.internal.ModbusSlave] - ModbusSlave (wago1): FC6 ref=12292 value=0

This is the log output after restarting the modbus binding

19:06:48.871 [DEBUG] [nding.modbus.internal.ModbusActivator] - Modbus binding has been stopped.
19:06:48.915 [DEBUG] [org.openhab.binding.modbus ] - BundleEvent STOPPED - org.openhab.binding.modbus
19:06:48.933 [DEBUG] [org.openhab.binding.modbus ] - BundleEvent STARTING - org.openhab.binding.modbus
19:06:48.947 [DEBUG] [nding.modbus.internal.ModbusActivator] - Modbus binding has been started.
19:06:48.970 [DEBUG] [g.modbus.internal.ModbusBindingConfig] - Since ‘[’ in item ‘inkom_spots’ config string ‘<[wago1:4], >[wago1:4:transformation=MAP(simpleRelay.map)]’, trying to parse it using extended parser
19:06:49.016 [DEBUG] [g.modbus.internal.ModbusBindingConfig] - Parsed IOConnection (read=true) for item ‘inkom_spots’: ItemIOConnection@3902a286[slaveName=wago1,index=4,type=STATE,trigger=default,transformation=Transformation@4e1f4cd0[tranformation=default,transformationServiceName=,transformationServiceParam=],valueType=default]
19:06:49.056 [INFO ] [ab.core.service.AbstractActiveService] - Modbus Polling Service has been shut down
19:06:49.089 [DEBUG] [g.modbus.internal.ModbusBindingConfig] - Parsed IOConnection (read=false) for item ‘inkom_spots’: ItemIOConnection@146aa47b[slaveName=wago1,index=4,type=COMMAND,trigger=default,transformation=Transformation@3914bd9[tranformation=MAP(simpleRelay.map),transformationServiceName=MAP,transformationServiceParam=simpleRelay.map],valueType=default]
19:06:49.172 [DEBUG] [g.modbus.internal.ModbusBindingConfig] - item ‘inkom_spots’ parsed
19:06:49.198 [DEBUG] [g.modbus.internal.ModbusBindingConfig] - Since no ‘[’ in item ‘modbusKeukenAanrecht’ config string ‘wago1:3’, trying to parse it using simple syntax parser
19:06:49.236 [DEBUG] [g.modbus.internal.ModbusBindingConfig] - item ‘modbusKeukenAanrecht’ parsed
19:06:49.267 [DEBUG] [org.openhab.binding.modbus ] - ServiceEvent REGISTERED - {org.osgi.service.cm.ManagedService, org.osgi.service.event.EventHandler}={event.topics=openhab/*, service.pid=org.openhab.modbus, component.name=org.openhab.binding.modbus, component.id=205, service.id=334, service.bundleid=237, service.scope=bundle} - org.openhab.binding.modbus
19:06:49.268 [DEBUG] [binding.modbus.internal.ModbusBinding] - modbusSlave ‘slave1’ instanciated
19:06:49.325 [DEBUG] [org.openhab.binding.modbus ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.modbus.ModbusBindingProvider}={component.name=org.openhab.binding.modbus.genericbindingprovider, component.id=206, service.id=332, service.bundleid=237, service.scope=bundle} - org.openhab.binding.modbus
19:06:49.333 [DEBUG] [binding.modbus.internal.ModbusBinding] - modbusSlave ‘wago1’ instanciated
19:06:49.383 [DEBUG] [org.openhab.binding.modbus ] - BundleEvent STARTED - org.openhab.binding.modbus
19:06:49.389 [DEBUG] [binding.modbus.internal.ModbusBinding] - Parsed the following slave->endpoint configurations: {wago1=EndpointPoolConfiguration@4e88a87b[passivateBorrowMinMillis=60,interConnectDelayMillis=0,connectMaxTries=3,reconnectAfterMillis=0,connectTimeoutMillis=0], slave1=EndpointPoolConfiguration@7e6d6ec3[passivateBorrowMinMillis=60,interConnectDelayMillis=0,connectMaxTries=3,reconnectAfterMillis=0,connectTimeoutMillis=0]}. If the endpoint is same, connections are shared between the instances.
19:06:49.445 [DEBUG] [binding.modbus.internal.ModbusBinding] - Parsed the following pool configurations: {ModbusTCPSlaveEndpoint@369a3cd3[address=192.168.0.41,port=502]=EndpointPoolConfiguration@7e6d6ec3[passivateBorrowMinMillis=60,interConnectDelayMillis=0,connectMaxTries=3,reconnectAfterMillis=0,connectTimeoutMillis=0]}
19:06:49.469 [DEBUG] [binding.modbus.internal.ModbusBinding] - config looked good
19:06:49.481 [INFO ] [ab.core.service.AbstractActiveService] - Modbus Polling Service has been started
19:06:52.719 [INFO ] [smarthome.event.ItemStateChangedEvent] - collectorLiftkokerAlle changed from 65.0 to 64.6

2

Hi!

Regarding the “slave1”, it sounds like you are suffering from issue #5084 which was due to larger issue in openHAB itself.

It seems that a suggestion is to have a “pid marker” in the config file, as described here. I am not sure of the exact syntax though…

Clearing the cache might help as well. Whole cache can be cleared like this, or just the modbus binding cache: config:del org.openhab.modbus.

Regarding your write errors: do you see any ERROR lines in the logs?

Best,
Sami

3

@ssalonen, no errors in the log file.
The problem seems to be in the Wago PLC itself. I’ve written a small test program that changes a NOVRAM register over MODBUS (FC6) and reads the same register back.
When the PLC program is not using the register, everything works fine. When however, the PLC program IS using the register (even when only reading it), the MODBUS FC6 write commands get dropped intermittently. Very strange.
I have raised an issue with the Wago Technical support.

4

@Stefaan_Vandevelde
Did you get an answer from Wago. I have more or less the same problem.
It looks like my Wago PLC stops or slows down executing its program as soon as I let openhab (2.4) read the NOVRAM. I configured the Modbus binding and things in Paper UI.
In the past I used the EDOM APP (https://play.google.com/store/apps/developer?id=edom-plc) using the same registers and this works perfect.

5

@StevenB,
Yes, I got the lastest firmware from them some time ago. I remember the update process failed on one of the PLCs and got me into bad trouble. Wago managed to help me out with that but it didn’t solve the problem with the openHAB binding.
In the end, I’ve written my own node.js app that bridges between the PLCs (MODBUS) and MQTT and I use the MQTT binding to get the PLC states into openhab. That works fine. If you like, I can send you the program, it’s not so complicates. Just send me a message with your email address and I’ll send it over.
Got one PLC behaving really badly lately, had to swap it out. Guess the legendary stability of Wago PLCs is somewhat exagerated after all. Rather unsettling when half of your is being controller by it !
Stefaan

6

@Stefaan_Vandevelde
Did you ever tested the EDOM APP ? This works great. That is why I am not really sure the Wago PLC is the problem. The developer made it for a WAGO 750-880 PLC and experimented with OpenHAB. The EDOM-PLC website is a bit chaotic but on their forum I see also questions about OPENHAB and WAGO. Unfortunally all in Polski.
I am just a beginner with openhab and more process automation oriented than IT.
My OpenHAB is installed on a Raspberry PI, where did you install the node.js app ?
How can I send you my email adress ?

7

Are any of you using the Modbus v2 binding (Things and channels, no modbus.cfg) with the Wago? It works rather different to v1.

8

@StevenB,
node.js should be standard on most rPi distributions. Just try node -v, if you get an answer, then node is there. You can install node programs anywhere you like, for service programs, I advise the PM2 service manager (there’s others, but PM2 is complete and popular).
I’ve had a look at the EDOM app, but can’t use it. I have information from between different openHAB bindings (MODBUS, mysensors, RFXcom, eBUS) and use the openHAB app to visualise and control. An app that only takes care of the Wago PLCs is not usefull to me.

@rossko57,
Thanks for that info, I’ll have a go at the MODBUS v2 binding. I saw the documentation is pretty extensive, thanks for that.