Sorry, haven’t found easy way to solve this:
I have created a Modbus TCP Binding, which polls my Slave every 200ms and reads some Coils.
The problem is that on each poll it generates state update event for each item, even if its state is not changed at all. This creates unnecessary events and also generates publish messages on my MQTT binding.
So the question is - is there any easy way to generate events from Modbus TCP only in case of state change?
It is normal for a binding to generate update events for items even when those items have the same state as before. There may be unwanted side effects, however, like the default logging of events in events.log, which in my opinion is not a good default. That’s why I set event logging to WARN in my logback.xml, so no events are logged.
A separate subject is, is polling 5 times a second a sensible thing to do? Obviously the developer thought so, but I don’t know anything about Modbus to independently evaluate that decision. Absent anything special about Modbus, polling 5 times a second seems way too frequent.
About MQTT publishing updates too often, I just provided a workaround to another user that uses a rule to only publish to MQTT when an item changes, instead of being updated, that uses openHAB 1.8 and the new MQTT action bundle:
rule MQTTPublishOnChange
when
Item YourModBusItem changed
then
publish(yourBroker, yourTopic, YourModbusItem.state.toString)
end
1 Like
I had a developer fix it:
I have 8 modbus board so I like it much better this way, but it is not the openhab way so it never was included in the source.
Since modbus normally does not latch contacts its a fairly standard poll interval.
IMHO 5 times a second is actually quite slow 
Me too. I have 15 clients running. Thanks for that fix btw 
So in the space of one second, a Contact item could generate the following updates: OPEN, OPEN, CLOSED, OPEN, OPEN. A rule would trigger on “changed to CLOSED” but the item would quickly return to OPEN without latching. Why should the poll be faster than 200ms? Are you saying that polling at 200ms loses changes?
I want to use a PLC as a rules and scenario engine, because of some of its benefits - also as a light control. Obviously I wanted to communicate using Modbus TCP as easiest way. With 200ms polling it’s already going to be significant reaction delay of 400ms in worse case, so yes - I planned to make polling faster in real application.
Also - Open, Open, Closed, Open, Open - yes, it can loose changes at all. For human-pressed switch, holding it pressed for 200ms is quite annoying - I have checked it before in another applications - a lot of people like to “punch” switches and buttons rather than press them slowly. In reality this results, that switch polling interwal should be 100ms or less to catch this event.
1 Like
Thanks for the explanation!
We were looking for some more feedback in the pull request… perhaps you could please comment on the pull request?
Many thanks
Hi, Did support for modbus.tcp.slaveid.updateunchangeditems go away? I’m polling my modbus tcp slave’s at 5s intervals but each poll generates state updates even though the polled slave register has not changed.
############################### Modbus Binding ########################################
#
# sets refresh interval to Modbus polling service.
# Value in milliseconds (optional, defaults to 200)
modbus:poll=5000
modbus:tcp.override_control.connection=localhost:5502
modbus:tcp.override_control.type=holding
modbus:tcp.override_control.id=1
modbus:tcp.override_control.start=6240
modbus:tcp.override_control.length=1
modbus:tcp.override_control.valuetype=uint16
modbus:tcp.override_control.updateunchangeditems=false
As far as I know, no changes have taken place.
Can you please follow the troubleshooting steps in the wiki and report back?
Best,
Sami
Thanks Sami,
All’s well. The updateunchangeditems feature works in 1.9.0.b3. I was running 1.8.3.
Great to hear it’s working! As mentioned in the wiki/manual, the feature was introduced in 1.9.0 so that makes sense 