Closed owl770 closed 1 year ago
I think raising the log level to INFO (which should be the default) is enough to prevent flooding your logs. IMO the binding is behaving correctly here: the connection is broken for at least three retries, i.e. at least 30s. If this is timespan is increased, you'll probably experience issues with proper response from the device.
The log level was only at TRACE whilst I investigated why the switches were dropping OFFLINE intermittently. It is back at DEFAULT now. I agree that increasing the number of pings is probably a bad idea. I need to find out the root cause of why they are dropping off the network for > 30 seconds.
Regarding the other issue Connection reset by peer
(perhaps I shouldn't have combined them in the one post) - given the device is re-discovered within 0.056 seconds (in this example), would it make sense for the binding to at least have one go at reconnecting before taking the device OFFLINE? Would that be possible and is it a good idea?
I’m seeing the same things with a Tuya device:
2022-07-24 14:47:23.152 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from OFFLINE to ONLINE 2022-07-24 14:47:23.161 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from ONLINE to OFFLINE 2022-07-24 14:47:28.173 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from OFFLINE to ONLINE 2022-07-24 14:47:28.181 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from ONLINE to OFFLINE 2022-07-24 14:47:30.596 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LocalTime_Date' changed from 2022-07-24T14:48:50.686-0500 to 2022-07-24T14:49:50.688-0500 2022-07-24 14:47:33.193 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from OFFLINE to ONLINE 2022-07-24 14:47:33.203 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from ONLINE to OFFLINE 2022-07-24 14:47:38.222 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from OFFLINE to ONLINE 2022-07-24 14:47:38.233 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from ONLINE to OFFLINE 2022-07-24 14:47:43.240 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from OFFLINE to ONLINE 2022-07-24 14:47:43.248 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from ONLINE to OFFLINE 2022-07-24 14:47:48.263 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from OFFLINE to ONLINE 2022-07-24 14:47:48.268 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from ONLINE to OFFLINE 2022-07-24 14:47:54.356 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from OFFLINE to ONLINE 2022-07-24 14:47:54.377 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:800061668caab5005de9' changed from ONLINE to OFFLINE
I have seen it with a different device from time to time.
@BigGeorgeTx I saw something similar in #366. I worked around it by forcing the switch to have a fixed IP address in my router (the problem appeared when, for some reason, the switch changed its IP address). Might be worth a try.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Hi. I am using version 3.2.12 of the SmartHome/J Tuya Binding and am seeing some weird behaviour on a fairly regular basis where tuya devices go
OFFLINE
and then about 5 seconds later they come back online. I have three examples available from three different tuyaDevices (MAC address portion080c
,aaa1
and3b6d
). The log entries (below) are merged OH3events.log
andopenhab.log
files and only contain log entries for the one device (I deleted the 'noise' around it).080c
andaaa1
are very similar whereby the binding pings the switch and then gets anIOException (Connection reset by peer)
. The tuyaDevice then goes OFFLINE. Sometime later, theudpListener
rediscovers the switch OK and the switch goes backONLINE
. Of course there are many (external) reasons why we might receive theConnection reset by peer
message, which is out of your control but is it possible to build more resilience into the binding to handle these temporary situations?3b6d
is different in that it didn't respond to pings 3 times in a row (reason is unknown) and the tuyaDevice is forcedOFFLINE
. About 5 seconds later,TuyaEncoder
sends aDP_QUERY
that gets responded to and the tuyaDevice goes backONLINE
. Please note that in this environment, internet access is turned off at 23:00 and gets turned back on at 07:00 the next morning, hence the messages about the tuyaProject getting a DNS timeout. Would it be possible to perhaps do the DP_QUERY after a ping timeout to see if that 'wakes it up' or could you increase the number of pings (or make it configurable per device) to make the binding more resilient (I doubt this is a good fix)?Logs for
080c
:Logs for
aaa1
:Logs for
3b6d
:Thanks for any assistance you can provide.