Modbus per slave poll period

[nickma82 (NickMa)]

I’m polling a rather big amount of data from my modbus devices (instruments). Some of them are changing more frequently then others.
My question is: How about a per slave based (but a global one) poll interval/period setup capability? (@ssalonen)

That would omit unnecessary messages from the bus, with the effect of higher possible polling frequency for important ones.

A pre happy new year everyone.

[ssalonen]

I agree that this does make a lot of sense. It has been also discussed in other threads before, see this for example. My comment back then was that we should think whether this kind of change makes sense to combine with the openhab2 changes (splitting the modbus binding to transport bundle etc.). @rossko57 had also good comments regarding error handling with individual polling in place (e.g. this comment).

I must comment that pretty high polling rate is already possible with the 1.9.0 changes, @mbs38 managed to achieve ~1700 updates/minute using serial modbus slave. With the introduction of updateunchangeditems, the CPU usage remains low (issue previously due to the mere quantity of openhab events in the event bus). Naturally you are right and in a way we are wasting resources if some the slaves change less often…

Best,
Sami

[nickma82 (NickMa)]

Hi Sami,
thanks for your quick and competent answer.

@ssalonen

see this for example

That is a good idea, simple yet powerfull.

@ssalonen

we should think whether this kind of change makes sense to combine with the openhab2 changes

As I dont have any insight in the openhab2 module, that sounds more like a rather big change than a quick one to me?

@ssalonen

I must comment that pretty high polling rate is already possible with the 1.9.0 changes, @mbs38 managed to achieve ~1700 updates/minute using serial modbus slave.

The 1.9.0 modbus module works superb! Yet my maximum speed is limited by the instrument, which responds rather slow in my case.

Best, Nick

[mbs38]

@ssalonen

I must comment that pretty high polling rate is already possible with the 1.9.0 changes, @mbs38 managed to achieve ~1700 updates/minute using serial modbus slave.

@ssalonen: For the sake of completeness: During the last two months I’ve been constantly running my system with ~2600 updates/minute. Thx again for making this possible.

[Pirx (DaHome Solutions)]

thanks mbs38 for guiding me to this thread…

Guys, I don’t regard regular polling as the only one solution for getting data from a modbus device. I mean, there are very complex modbus devices like Inverters with hundreds of registers consisting tons of data which you need only ones (like serial number) or ones per day or when a device is booted (like SW version). Polling this data every second or minute doesn’t make sense at all. So I suggest to provide a functionality where the device is polled by an event, e.g. call from a rule.

[rossko57]

OH’s event-driven structure doesn’t lend itself well to a read-on-request strategy. If you issued a ‘read’ from a rule, I’m not sure its within OH philosophy to wait for a response (or failure) from the device before carrying on with the rule?
That could of course be circumvented by firing the ‘read’ and exiting that rule. Another rule can be triggered later upon the Item received update.

Individually configurable poll-rates of OH (logical) slaves would be a first step towards that, you could configure ‘interesting’ registers for frequent polls, and those of little interest for less frequent polls (on the same physical device)

The problem then becomes one of stale, out-of-date information held within OH.

@Pirx

Polling this data every second or minute doesn’t make sense at all.

It’s not terribly efficient - but for most of us, it doesn’t really “cost” anything either.

[mbs38]

@Pirx

thanks mbs38 for guiding me to this thread…

You are welcome.

For my needs this would be sufficient:

@rossko57

Individually configurable poll-rates of OH (logical) slaves would be a first step towards that, you could configure ‘interesting’ registers for frequent polls, and those of little interest for less frequent polls (on the same physical device)

[Pirx (DaHome Solutions)]

V[quote=“rossko57, post:6, topic:19168”]
OH’s event-driven structure doesn’t lend itself well to a read-on-request strategy. If you issued a ‘read’ from a rule, I’m not sure its within OH philosophy to wait for a response (or failure) from the device before carrying on with the rule?
[/quote]

i’m not talking about read-only requests nor about things which touches OH philosophy. What I’d like to suggest is very very simple. In the current implementation there is a function within the Modbus binding which periodically reads one or more registers from a Modbus slave. I’d like to use it as it is. So no change at all. But rather it is used by a timer, which e.g. is firing this function every second (poll=1000), to trigger it within a rule or a hubpanel script (e.g. after pressing a button). The execution should then be done asynchronously.
The definition could be done like this:
Modbus.cfg: … poll = 0 or NULL … which indicates a ‘manual’ firing
xyz.rule: … sendCmd (item, NULL) … which fires a call rather then send real command.

[rossko57]

Language clarification - read-on-request does not mean read-only.

Related discussion, different binding

Zwave Feature Needed : polling a zwave device from a rule

Hi, As There are fast dev for OH2, I wanted to know where could I ask this feature. On OH2 or zwave binding. It could be usefull when you wants to know if your zwave devices are functionnal. Example: someone try to use a jammer on your zwave sensor. As an alarm rule is on, 3 polls are done every minute on all listed devices. If a device don’t answer after 3 polls then do something. Another example ( a real): my zwave device which command my pool pump is offline, if not an interactive poll in …

I believe that can be summarized as -

There is not going to be a way to invoke a poll in OH1.

OH2 does provide a general way to invoke a poll from a rule by sending a “dummy” REFRESH command, but the particular binding needs to support the REFRESH action.

I would say; to be of much practical use in a Modbus environment, the per-slave poll setting would be very desirable.

Sounds like REFRESH ought to be added to OH2 Modbus issues list as an enhancement request?

[Pirx (DaHome Solutions)]

REFRESH sounds very practical. We then only need to set the poll time to something very big and then use REFRESH.

Who is developing OH2 Modbus binding?

[ssalonen]

I agree too that refresh makes sense in openhab2 land.

Regarding modbus as “native” openhab2 binding, not sure it is actively developed by anyone … See for example this community thread for more information.

I’m currently working on the transformation support for the modbus but after that I was planning to work on openhab2 support. Have some ideas already (regarding topics discussed in the pull request linked in the community thread. But still it will take months for sure since this is just a side project for me… Would be interested to share ideas if there are developers interested to tackle this.

Best
Sami

[Pirx (DaHome Solutions)]

Hi Sami,

that is pitty. Unfortunately I’m already overloaded with things I do and to develop a new binding version will be very time consuming.

But, who has done Version 1 ?

Regards
Pirx

[ssalonen]

I believe the binding version 1 has been done by many people, I believe most not active anymore. There is fortunately pretty smart guys contributing in terms of answering questions here in forums.

I contributed to the binding last year couple of features and bug fixes. But other than that there has been one or two improvements from others.

Like discussed in the somewhat obsolete PR, ideal way forward with openhab2 version would be to split current binding into different parts. The same parts could perhaps be used by both openhab and openhab2 version. So in a sense it’s not completely new binding, but more like restructuring the current one. But still probably takes time to get everything right…

Best
Sami