Tuya Devices constantly toggle between ONLINE and ONLINE: Waiting for device wake up after update to openHAB 5.1.0

21

Update on the Tuya binding issue in 5.1:

We’ve made some progress tracking down the regression. The issue has been narrowed down to PR #18829 in the GitHub repository.

@Nadahar kindly provided a test JAR with that PR reverted (GitHub - Nadahar/openhab-addons at 5.1.0_18829_reverted), which I’ve been testing:

Results:

  • :white_check_mark: String lights: Now work perfectly - no more constant ONLINE/offline cycling
  • :warning: Ceiling fans: Show as ONLINE but don’t respond to any commands (ON/OFF, speed changes)

The fans are a bit puzzling since they worked fine (including commands) in 5.0.3, just without full status feedback from the device.

We’re now waiting for the binding authors to review the findings. I’ll keep this thread updated once there’s more news.

For anyone else affected: The GitHub issue is being tracked here: [tuya] Constant status cycling ONLINE ↔ "Waiting for device wake up" in 5.1.0 for mains-powered devices · Issue #19880 · openhab/openhab-addons · GitHub

Edit: Link corrected - thx @lsiepel

1 Like
23

Quick update - some good progress!

Big thanks to @ccutrer over on GitHub who suggested re-discovering the devices, and to @Nadahar for creating the reverted JAR and helping track down the root cause!

Here’s what I found:

Standard 5.1.0 after re-discovery:

  • :white_check_mark: Ceiling fans: Working great now!
  • :cross_mark: String lights: Still cycling ONLINE/ Waiting for device wake up

With the reverted JAR from @Nadahar:

  • :white_check_mark: Everything works perfectly

So if you’re affected by this bug:

  1. First try removing and re-adding your Things - might be enough!
  2. If that doesn’t help, the reverted JAR is a solid workaround: GitHub - Nadahar/openhab-addons at 5.1.0_18829_reverted

Still being tracked on GitHub here: [tuya] Constant status cycling ONLINE ↔ "Waiting for device wake up" in 5.1.0 for mains-powered devices · Issue #19880 · openhab/openhab-addons · GitHub

Fingers crossed the devs can figure out a proper fix soon!

1 Like
24

Hi!

Just upgraded to 5.1.0 and also saw the same behavior with two of my tuya devices. They were working fine on 5.0.1 and now are not reliable - sometimes commands go through, but mostly not. Also in logs I can see same cycling between ONLINE and ONLINE: Waiting for device wake up.

Both devices are WiFi relays

25

Have you tried any of the remedies mentioned above?

26

Yes. As my thing definitions are in files I have tried to comment them out, update, then uncomment and update again. Unfortunately, even after that things are still looping every second spoiling logs. Even though they are still looping through states automation rules were able to update their state at midnight and today evening. Unfortunately, I don’t have time today to try reverted JAR, but will do it as soon as I get some spare time

1 Like
27

Hi!

Finally got some time to play around with this one.

So the bundle with reverted PR 19530 works like a charm.

I also found that there’s a fix merged into 5.1.x branch ([tuya] Avoid refresh if there are no measurables by mjagdis · Pull Request #19930 · openhab/openhab-addons · GitHub), but I have built that one and, unfortunately, that didn’t work for me - I still see cycling for same two devices after bundle update. So will stick with this reverted thing for now

28

Ok, I was too fast about “works like a charm” :sad_but_relieved_face:

Now when I used it for some time I see some more issues - items are often jumping from ONLINE to OFFLINE and back:

22:54:23.686 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:315327763c6105909943' changed from ONLINE to OFFLINE
22:54:24.605 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:bedroom_1_curtain' changed from OFFLINE to ONLINE
22:54:25.021 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:3153277670039f187c3d' changed from OFFLINE to ONLINE
22:54:25.033 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:3153277670039f187c3d' changed from ONLINE to OFFLINE
22:54:28.694 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:315327763c6105909943' changed from OFFLINE to ONLINE
22:54:28.700 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:315327763c6105909943' changed from ONLINE to OFFLINE
22:54:30.041 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tuya:tuyaDevice:3153277670039f187c3d' changed from OFFLINE to ONLINE

These devices with number ids are added after discovery from UI. The ones with “normal” named ids are added through file configuration.

All of these devices are mains-powered, so that’s not normal behavior for sure. Due to these cycling some devices do not respond to commands (apparently when they cycle to OFFLINE).

And just to confirm that it’s not about devices anyhow I tried to operate them with tuya application and that works without any issue and stable as a rock

29

Be aware that when replace a bundle, it might revert to the original if you restart OH or install/uninstall an add-on - depending on how you install the bundle. I think putting the bundle in the addons folder is “most resistant to reversal”.

If you do a bundle:list you might be able to tell which is in use from some of the details, bundle:list -l might also be worth a shot, since it shows the “source address” of the bundle, which is different from the original (mvn: address) and one you have installed yourself.

30

Yes, I know that. I prepared three versions - original, reverted and newest from 5.1.x branch. None of them work correctly now :confused:

Original - cycling between ONLINE - ONLINE: Waiting for device wake up
Reverted - cycling between ONLINE - OFFLINE
5.1.x - cycling between ONLINE - ONLINE: Waiting for device wake up

I’m now thinking on building tuya addon from 5.0.x for 5.1.0 as it’s a bit annoying…

31

I can understand that - but the reverted one worked OK for 5.1.0? But it doesn’t for 5.1.1? Or did I get that wrong?

It shoud be easy to just build the 5.0 version of the binding for 5.1 I would think, but a better solution would be if the binding was fixed.

32

Not really. I have OH 5.1.0 and at first after installation of reverted addon I thought it was working ok by just quick checking logs (right after installation I didn’t notice cycling, so decided that everything is fine now). But after some time I noticed that some devices have not executed commands they should by daily rules and checked logs again (no restarts were done between these two events, so I’m sure that it was correct addon) and in the logs I noticed these ONLINE ←→ OFFLINE cycling now. Then I tried to remove things, which were cycling from file declaration and added them through discovery, but still cycling was present.

After that I checked the original issue on Github and noticed it being mentioned in another discussion, so found that there’s another fix, which is in 5.1.x branch already, so I checked it out and built latest addon, but after installation of that one things again got to cycle between ONLINE and ONLINE: Waiting for device wake up

And yesterday just to confirm I haven’t done anything wrong I prepared three jars and was switching between them and checking behavior

1 Like
33

I just tried to reopen the ticket in Github, but I don’t have sufficient permissions. Therefore, I’ve asked the person who closed it to reopen it.
@san4esmc Perhaps you could also comment there accordingly.

34

Made PR ([tuya] Avoid refresh if no measurables on status update by san4esmc · Pull Request #20030 · openhab/openhab-addons · GitHub) with a fix now

35

In my case, after upgrading to OH version 5.1, my lamps started turning on and off (cycling) shortly after being switched on.

The problem doesn’t appear immediately. It only happens after OH has been restarted with version 5.1 and only when a lamp is switched on.

While the lamp is off, everything seems normal.

I reverted to OH version 5.0.3 and everything went back to normal.

So, it may be that the problem isn’t solely related to the Tuya devices, because in my case these lamps are controlled directly via MQTT.

Two lamps burned out after the cycling process.

The workflow is as follows:

  1. I have an RPi with an RF 433 module + NodeRed that “listens” to see if any transmitter has been activated.

  2. Based on the code received from the transmitter, an MQTT event is sent to OH.

  3. Using an OH rule, when I receive the MQTT event, I trigger the WiFi controller that controls the lamp in question.

This system has operated this way for several years, since everything was controlled through Node-RED.

36

This looks exactly like issue discussed in openHAB 5.1 Release discussion and has nothing to do with Tuya addon. You can check this comment openHAB 5.1 Release discussion - #282 by Udo_Hartmann and search whole topic for postCommand.

1 Like
37

@san4esmc thank you for the tip.

In my case, “postCommand” wasn’t set to “false” or “true” because the parameter didn’t exist in the configuration of most MQTT channels.

After entering the various channels and selecting and then removing the “Is Command” selection, I updated to OH 5.1.1 and everything seems normal.

So, when I configured the MQTT channels in version 4.X, the “postCommand” parameter simply wasn’t configured.

It seems that when OH version 5.1.X doesn’t find the “postCommand” parameter, it assumes it’s set to “true,” which wasn’t my case.

2 Likes
38

This is an important hint IMO. If there’s a default value for this field, and it shouldn’t usually be true, the default should certainly be false. Somebody should verify that it is.

1 Like