Modbus binding: resend values to device after power down

[RobbeM (Robbe)]

Thanks alot for all of your ideas and thoughts! I’m thinking this through before writing any code.
I’ll share my thoughts below.

@rossko57

Is this what the mb_stat_output0 data Things are about? If so, you can combine your read and write into one data Thing.

In the Wago PLC I set the outputs via the modbus bits “mb_con_bit_x”.
I copy the actual state of the output to “mb_stat_bit_x”. So I always know if an output is actually set or not. This is a good thing, now I need to figure out how to make good use of this.

By the way: I can set the mb_con_bits to RETAIN in the PLC. This way they keep the value when the power is cycled. If modbus turned them ON before the PLC is powered down, those bits will still be TRUE in the PLC after it is turned on again.
This might be the easiest way to solve this… But we still have a problem when a user keeps trying to turn something on while the PLC is offline.
(This might be part of a solution that could work for me, however it wouldn’t be generic for all modbus devices…)

@rossko57

A really quick and dirty way is to set up what you already accidentally had; write-only openHAB Items, with autoupdate true.
These Items would track UI or rules triggered commands, and pass to PLC.
The restore part would require a rule triggered from device coming online, and simple read the Item state and resend the same command to itself.
It’s a dirty method because openHAB Items will NOT track any changes the PLC might make e.g. timers or wallswitches etc.

This would probably be a good solution. I need to read your great topic about modbus error management more in detail to write something to do this.
Could you explain to me what autoupdate=true/false exactly means? I don’t know what it does.
If I change it to autoupdate=true, will the poller write the coils again and again and again without any user/rule interaction?

@rossko57

Set up a rule to trigger from the Modbus poller bridge Thing changing status.

If it goes offline (because a read poll failed), we iterate through our group of Items and call persist on each one.
Optionally, we could also set the Item’s states to UNDEF for use in rules or UI display. Probably best to do that after some delay.

If it goes online (which would only happen after a failure), we iterate through the group, fetch the previousState from persistence, and use that to send a new command to the Item (which will also go out on Modbus)

Here you have indeed the issue that changes to the mb_con_bit aren’t tracked. I think the previous idea would be better.
Just resend the status (openhab status) of mb_con_bit to the PLC.
I probably first have to turn off the bit before i send the ON command again. I’ll try it out.

Do you agree that the second idea (resending the actual openhab status to PLC) is the best solution?

Would there be any way to program this in the binding? To keep all the config files clean.
Not sure if I would even be able to do this, only got some classes on Java, no real coding experience with Java.

Is there any better solution to get everything working 100% perfect and stable?
This seems to be a lot of trouble to get it working stable.
Don’t have any experience with MQTT or http requests, but it might be better to use these?
Both can be used on Codesys V2.3.