I have recurring problems with the Modbus protocol. I use it to control my heating circuit (WAGO 750-842, self-programmed).
Every few days or weeks, the connection breaks down (often without the items going into error). If I restart the Modbus protocol, everything is fine again.
Can this be due to my configuration or can someone help me solve the problem?
Youâll have to explain that. Each poll either works or it doesnât, failure will be reported in your openhab.log.
I donât know quite what Items going into error looks like, itâs usually the Things that are affected.
Quite a few Modbus-TCP devices can benefit from minor tweaks, like increasing the time between polls, or reducing connect-disconnect rates. For any given device, you have to experiment a bit.
I will try to explain that:
I get the current outside temperature from a weather service. I send this to the WAGO every 15 minutes. This recalculates the target temperatures of the water for the heating circuits in the WAGO. I read these values back out of the wago for display purposes.
In the event of a failure, the outside temperature is no longer taken over, and the target temperatures are also no longer reported back.
I had such an incident the last few days (see picture).
first failure
restart of the modbus binding via karaf console,
shortly afterwards, the values froze again.
reboot of the pi
blue (covering green): calculated target temperatures (Thing data md_soll_vl_eg / md_soll_vl_og)
pink : outside temperature (from weather service)
red : temperature of the modbus channel to the Wago (Thing data md_aussentemp)
I believe I have observed that the items sometimes do not show any malfunction - I am not sure about that now. The primary problem, however, is the freezing (unresponsiveness) of the modbus channel(s).
I notice it immediately on the chart for these items, but the other items are also affected. Whether all channels are affected or only the channels of a single âbridge pollerâ, I canât say at the moment.
Since the problem only occurs sporadically:
What things should I check the next time this happens in order to track down the problem? Then we could discuss it further based on that ?
So how does that happen? Guessing by sending commands to Items? Inspect your events.log to see if that continues to happen. If this part is carried out by rules, it should carry on regardless of any Modbus issue.
Looking at Items and Item states isnât going to enlighten you any further - they have little to do with Modbus, which is dealt with by the Things.
Look in your openhab.log for Modbus error messages.
You can do all that looking back at the recent incident youâve already shown in the chart.
At next incident, use the Admin part of your GUI to see what state Modbus Things are in.
Every Modbus data Thing has timestamping channels.
You might learn something by temporarily linking say the lastWriteError channel of one of your write thing, and the lastReadError channel of one of your sleepy read things. Link these to DateTime type Items - changes will be visible in your events.log even if you donât put them in your UI.
Also, the lastReadSuccess channel of a suspect read thing. Taken together, you will see errors or simply polling stopped.
Iâve never seen any instance of the binding âlosingâ a poller; but stuff just stopping has been a symptom of general performance bottlenecks, which may occur anywhere in your system.
Letâs see if you get actual errors first.
Certainly not going to suggest DEBUG logging when we have seen zero logs at all so far.
I would not recommend that. If it doesnât work after 2 or 3 goes, it is not going to work.
You should have a look at that performance guide I linked to.
I just saw that you use Modbus TCP. My comment was related to serial connection so probably it will haveno effect. Although connecting the ground terminal to your protective earth (green yellow wire) should be done (if not already connected).
In serial connection the Modbus device that polls is called master, and you can connect max 32 slaves. In Modbus TCP slaves are called servers.
The other end has stopped talking to us.
That may be because the query never got there; problems in your network, wonky wires, etc.
Or because the far end didnât understand the message (though it is considered polite to send a reject response, not just stay silent).
Or the far end was too busy doing something else to deal with us (it is possible to send a ânot nowâ response, but not common).
Or because a reply never made it back; problems in your network etc.
See how it goes, having reduced the TCP connect/disconnect churning effect considerably.
I would have expected problems in that area to manifest as a fairly steady error rate though, and not really as periods of âsleepâ.
Having said that, we donât know how well the WAGO manages its TCP connections, and once messed up it may be that you just have to wait for something to expire on a timeout.
This introduces another layer that might go wrong.
The binding will use a hostname like that, but of course it must look up the hostname to get a real IP. You are relying on that lookup being reliable.
If possible, try giving your WAGO a fixed IP and use that (like most binding users).
All right, thanks so far. I will now observe this for a while.
At the same time, I will try to better understand the modbus communication and itâs options.
The links have already helped me a lot
Good hint. Itâs already fixed but I use the dns.
But I donât want to change too much at once to get to the root of the problem.
Since I changed the rules.file, the items no longer have any errors. However, the temperature in the Wago is still not updated.
I connected to the Wago with CoDeSys and the temperature from this morning is still entered there (14.2°C). I tried to set the temperature to 17°C first and then to 15.4°C (current temperature) using a manipulated rule. The value of the channel is changed, but no information arrives at the Wago.
(I have also observed this behaviour before: At first the sending still seems to work - but in fact the information no longer arrives at the target system. If the system is then left to run for some time, the send channel also remains at the old value.)
The log shows a connection failure - but this was definitely connected to a modification of my LAN and a switch. Shortly afterwards (approx. 10 minutes) everything worked again, but modbus seems to have stopped in the error.
openhab.log
2022-10-01 14:28:33.660 [INFO ] [rt.modbus.internal.ModbusManagerImpl] - Modbus manager activated
2022-10-03 11:42:48.085 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_MULTIPLE_REGISTERS, start=12290, length=28, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 0f0a2065-c2cc-46b9-b599-2f3fb75f6f89]
2022-10-03 11:43:19.332 [WARN ] [ing.ModbusSlaveConnectionFactoryImpl] - Connect reached max tries 3, throwing last error: connect timed out. Connection TCPMasterConnection [m_Socket=Socket[unconnected], m_Timeout=3000, m_Connected=false, m_Address=heizung.fritz.box/192.168.178.201, m_Port=502, m_ModbusTransport=null, m_ConnectTimeoutMillis=10000, rtuEncoded=false]. Endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]
2022-10-03 11:43:19.334 [WARN ] [ing.ModbusSlaveConnectionFactoryImpl] - Error connecting connection TCPMasterConnection [m_Socket=Socket[unconnected], m_Timeout=3000, m_Connected=false, m_Address=heizung.fritz.box/192.168.178.201, m_Port=502, m_ModbusTransport=null, m_ConnectTimeoutMillis=10000, rtuEncoded=false] for endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]: connect timed out
2022-10-03 11:43:39.357 [WARN ] [ing.ModbusSlaveConnectionFactoryImpl] - KeyedPooledModbusSlaveConnectionFactory: Unknown host: heizung.fritz.box: TemporÀrer Fehler bei der Namensauflösung. Connection creation failed.
2022-10-03 11:43:39.359 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Could not connect to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502] -- aborting request ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=0, length=8, maxTries=3] [operation ID 19f4aa5c-3d9a-4519-a5ae-0d91f235af21]
2022-10-03 11:43:39.359 [WARN ] [ing.ModbusSlaveConnectionFactoryImpl] - Error connecting connection null for endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]: null
2022-10-03 11:43:39.360 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Could not connect to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502] -- aborting request ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=12288, length=5, maxTries=3] [operation ID ab9ef968-ae37-44eb-a2f1-c48b94715d52]
events.log:
2022-10-03 11:43:39.370 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:inputs_digital:di_not_used_03' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusConnectionException) with read. Request: ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=0, length=8, maxTries=3]. Description: ModbusConnectionException(Error connecting to endpoint=ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]). Message: Error connecting to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]
2022-10-03 11:43:39.372 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:io:steuerung_an' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusConnectionException) with read. Request: ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=12288, length=5, maxTries=3]. Description: ModbusConnectionException(Error connecting to endpoint=ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]). Message: Error connecting to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]
2022-10-03 11:43:39.374 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:io:regelung_og_an' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusConnectionException) with read. Request: ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=12288, length=5, maxTries=3]. Description: ModbusConnectionException(Error connecting to endpoint=ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]). Message: Error connecting to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]
2022-10-03 11:43:39.376 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:inputs_digital:warmwasserladung' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusConnectionException) with read. Request: ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=0, length=8, maxTries=3]. Description: ModbusConnectionException(Error connecting to endpoint=ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]). Message: Error connecting to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]
2022-10-03 11:43:39.378 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:io:heizkreis_eg_an' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusConnectionException) with read. Request: ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=12288, length=5, maxTries=3]. Description: ModbusConnectionException(Error connecting to endpoint=ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]). Message: Error connecting to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]
2022-10-03 11:43:39.379 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:inputs_digital:di_not_used_01' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusConnectionException) with read. Request: ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=0, length=8, maxTries=3]. Description: ModbusConnectionException(Error connecting to endpoint=ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]). Message: Error connecting to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]
2022-10-03 11:43:39.380 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:inputs_digital:di_not_used_02' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusConnectionException) with read. Request: ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=0, length=8, maxTries=3]. Description: ModbusConnectionException(Error connecting to endpoint=ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]). Message: Error connecting to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]
2022-10-03 11:43:39.381 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:io:regelung_eg_an' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusConnectionException) with read. Request: ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=12288, length=5, maxTries=3]. Description: ModbusConnectionException(Error connecting to endpoint=ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]). Message: Error connecting to endpoint ModbusIPSlaveEndpoint [address=heizung.fritz.box, port=502]
Because of this behaviour, I suspect at the moment that possibly temporary connection problems are leading to permanent problems in the modbus protocol.
After a few more attempts, the temperature is still not passed on to the Wago. So I have now restarted the modbus binding via the karaf console and immediately the old value (14.2°C) that was still in the Wago is reported back to the channel in the Openhab.
2022-10-03 18:22:09.699 [INFO ] [rt.modbus.internal.ModbusManagerImpl] - Modbus manager activated
...
...
...
2022-10-03 18:22:12.059 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:holdings:md_sttoleranz' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2022-10-03 18:22:12.065 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:tcp:wago_1' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
2022-10-03 18:22:12.078 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:tcp:wago_1' changed from INITIALIZING to ONLINE
....
2022-10-03 18:22:12.369 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:holdings:md_steilog' changed from INITIALIZING to ONLINE
2022-10-03 18:22:12.373 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:holdings:md_stfaktor2' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2022-10-03 18:22:12.375 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:holdings:md_aussentemp' changed from INITIALIZING to ONLINE
2022-10-03 18:22:12.377 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:holdings:md_stfaktor2' changed from INITIALIZING to ONLINE
2022-10-03 18:22:12.378 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'modbus:data:wago_1:holdings:md_steileg' changed from INITIALIZING to ONLINE
2022-10-03 18:22:17.463 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'IBBW_md_aussentemp' changed from 15.4 to 14.2
For me, this seems to indicate a binding-internal problem, doesnât it?
Update : now I getting permanent modbus warnings (all modbus items still green!):
==> /var/log/openhab/openhab.log <==
2022-10-03 19:57:20.371 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=12288, length=5, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID d8b24f11-1f6e-4861-a55a-f0e33c16be7a]
2022-10-03 19:57:28.718 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=0, length=8, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID b6607b14-d63e-4ee1-b705-1ea92b54abaf]
2022-10-03 19:57:32.986 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=512, length=8, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 8ff25c5e-cee1-4b9d-a56d-e644154603f9]
2022-10-03 19:57:38.684 [INFO ] [rnal.service.RemoteControllerService] - Using WebSocket interface
2022-10-03 19:57:39.110 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=0, length=8, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID b6607b14-d63e-4ee1-b705-1ea92b54abaf]
2022-10-03 19:57:41.696 [INFO ] [rnal.service.RemoteControllerService] - Using WebSocket interface
2022-10-03 19:57:41.788 [INFO ] [rnal.service.RemoteControllerService] - Using WebSocket interface
2022-10-03 19:57:49.320 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=512, length=8, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID ade51194-ce4b-401c-bc44-2890d2f0f5c2]
2022-10-03 19:58:05.062 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_MULTIPLE_REGISTERS, start=12290, length=28, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 39d2a203-5d2e-4511-964a-5bc376311ad6]
2022-10-03 19:58:13.158 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=0, length=8, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID dd44923f-2cc5-495f-a56f-9078553bdab8]
2022-10-03 19:58:32.346 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_COILS, start=12288, length=5, maxTries=3]). Will try again soon. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 99f761a5-a8c7-42bd-91bc-4b9fc9e1ce40]
....
Those are Things. I know the names can be confusing, but weâre all going to get in a big mess if we donât name the parts correctly, Items are something quite different in openHAB.
Still says the same err, thing. The other end has stopped talking to us (or never started).
No. (Also bear in mind there are many other users of this binding)
Errors are still
other end not talking to us.
The binding will re-try a failed transaction a few times (3 by default)
Failing on the first or second attempt generates a WARN, only the last attempt would be an error.
So a bunch of these tells you itâs struggling, but getting by.
Try 2 out of 3 is struggling more.
Try 3 out of 3 failing will generate a terminal error.
So, although we are shouting into the void to determine what went wrong, and getting no response âŠ
We can characterize your problem as âworks sometimesâ.
openHAB does nothing different between a transaction that works and one that doesnât.
So itâs probably about timing.
If youâve configured say 4 poller Things, then openHAB can hit the WAGO quite hard. openHAB expects it to keep up.
Example
OH sends poll request A
OH waits for reply
WAGO responds in a while, sends reply.
OH immediately sends poll request B
WAGO doing something else, canât handle it that quickly.
Youâve already reduced the TCP disconnect/reconnect thrashing, using reconnectAfterMillis=600000, thatâs good leave that in place.
timeBetweenReconnectMillis=100 just gives a little pause between disconnect/reconnect, so it shouldnât even happen very often. Leave that in place too.
timeBetweenTransactionsMillis allows you to set a little pause between every transaction, so itâll give the WAGO a chance to catch its breath before being hit with the next poll.
Set timeBetweenTransactionsMillis=150 and see.
Basic questions, to which I have not yet found an answer:
Why does a restart of the binding cause the connection to be restored (even if not completely) without other components involved (LAN/Wago) being restarted/reinitialised (here the temperature was suddenly transferred back from the Wago)?
Why does restarting the Raspi restore the connection completely without restarting/re-initialising other components involved (LAN/Wago)?
Because it works sometimes.
When you restart the binding or openHAB, all the Things get reinitialized and attempt their âfirstâ read poll.
Some might work, ta-da.
Some might work after a retry, ta-da.
Some might not.
When one of the read polls fails badly enough (3 out of 3) the associated Thing will throw an error and give up.
Other read polls might carry on, until/unless they too fail badly enough.
Note also that restarting the binding gives the WAGO a pause for breath. If something is getting screwed up at that end, say hanging on to a stale TCP session, thereâs time for that to be tidied away as well.
Weâre not going to able to reason this out with no idea what is going on inside the WAGO, so itâs a case of try some things that have successfully circumvented bad behaviour of other devices.
Any other factors here, like some other app talking to WAGO at the same time? Other people seem to use WAGO albeit not identical model without these communication issues (search ot6her threads about basic config and programming queries)
Do I understand this correctly: If the connection on a channel has failed completely, then this connection will not be repaired by itself, even if the fault has been eliminated? Or is the assumption wrong?
A little background of this Wago: We use exactly this type of Wago (I think more than 50 devices over years now) in our company and work very similarly with it. Permanent polling and, if necessary, writing via modbus-tcp. However, the remote station is not Openhab, but self-written C# programmes. Often even several tcp connections from different PCs at the same time !
I am not aware that we have ever had similar incidents with it in the form of connection problems.
No - itâs only OpenHAB whichâs connected to it.
PS:
The Wago I am using here is already the second one, as the first one had a defect and could no longer be booted. Both the old and the new Wago showed the same behaviour with regard to the connection problem.
âConnectionâ is a vague term here. Several modbus pollers trying to use the same remote slave will share one TCP connection. Effectively, thatâs what the shared TCP bridge Thing represents. Itâs not at channel (or data Thing) level.
TCP connection is routinely broken and made again anew. Normal operation. You get some control over how often the work of breaking/making is performed with the reconnectAfterMillis= stuff.
Error situation; if an error happens to be connection related - as yours are, âhey youâ asks openHAB, but gets no response - then part of the recovery attempt is to close the (shared) TCP connection and re-establish a new one.
Might not work of course - the target device might simply be turned off.
More likely, in a real error situation, it could go wrong again because we have no idea what the other end is doing. Will it recognise that old TCP connection has been abandoned? Will it eventualy timeout that old TCP session? Will it refuse to start a new one while the old one lingers? Iâve no idea, WAGO business.
The point here is that connection troubles first encountered by one openHAB poller Thing quickly multiply across them all, because itâs a shared connection.
So far as I know, openHAB will continue to re-try read polls periodically until you configure a poller thing OFFLINE, even if the poller Thing has been flagged with some other error condition. Each scheduled poll is considered as new business, to be individually tried, retried, or failed.
So far as I know, openHAB will re-try a failed write the configured number of times (say 3) and then abandon it. Again, the Thing being in some error state will not stop a later attempt to write by Item command.
Sure. As Iâve pointed out, others do use WAGO with openHAB without noticeable connection issues too.
Weâre not looking for something broken here, weâre looking for something that is a little sick, but doesnât recover very well. And its pretty unique to you, somehow. (Remember host system is in charge of e.g. TCP timeout periods)
Thereâs two approaches - find the sickness, or improve recovery until it doesnât matter. Either might be more or less effective in practice. Weâre hampered by having only end of a conversation in view, the WAGO remains a black box. Maybe you have the skills to find out what it thinks is going on.
