MOES UFO-R11 stops responding after 15-30 minutes and does not recover

[insleys]

What happened?

Roughly 4-5 weeks ago, I noticed that my UFO-R11 IR devices stopped working reliably. I have determined that somewhere between 15-30 minutes after a UFO-R11 is added, it no longer responds to any published topics to enable/disable learning or to send an IR code. If a topic is published to send an IR code every 10-15 minutes, the devices continue to work - this is my workaround at present, but I have concerns that this will affect battery life.

The only way to recover is to re-join the device or to trigger an interview. As this wasn't happening when I first bought the devices 6+ months ago, I can only assume this is a regression. I have tested multiple devices.

What did you expect to happen?

Regardless of how much time elapses between interactions with the device, it should respond and work as expected.

How to reproduce it (minimal and precise)

1. Join a UFO-R11 to the network
2. Do not use the device for 15-30 minutes
3. Try to send an IR code, which will silently fail

Zigbee2MQTT version

1.39.1

Adapter firmware version

20211217

Adapter

Silicon Sonoff Zigbee 3.0 USB Dongle Plus

Setup

Plan add-on on HA OS running on a VMWare ESXi VM on Intel

Debug log

No response

[Pel1can111]

Glad I'm not the only one to notice this. Device was working great but something changed recently and the device no longer sends IR signals when commands are pushed over MQTT. Manually turning on the learn new code within zigbee2mqtt seems to work fine.

[insleys]

UPDATE: After more testing, it seems that my old method of just pushing the message of MQTT doesn't work predictably, however setting the text.device_name_ir_code_to_send value to '0' and then setting it to the code I want to send does work. I mainly was sending the exact same IR code repeatedly and it would not work after the first send. I noticed if I sent a different code every time that it continued to work.

Not sure sure what's changed, but this is the workaround. Send a '0' and then send the actual code. I put a 100ms wait delay in between sends which seems to make it even more reliable. 100ms delay is no big deal for me but YMMV.

[Pel1can111]

Hmm... thats interesting as I also only send the same code over and over (to turn off an AVR). I have tried what you suggested and it does have some success but does not seem to be perfect for me. I will have a poke around and see what I can learn, thanks for the tip

[insleys]

My workaround seems to have stopped working after updating to 1.40.0. Now, the device stops responding to any messages after 5-10 minutes of a restart of z2m.

[adamlc]

This must be intermittent as I have a UFO-R11 that works perfectly still. I even have the same adapter, but I do have a newer firmware that was released recently, 20240710. Maybe updating that to see if it helps?

I say working perfectly. It does respond to commands, but it sometimes shows as offline if it's not been used for a few days. But as soon as you send a command it responds and shows online again.

[Pel1can111]

interesting that someone is not experiencing this. I'm running the latest firmware on my sonoff dongle and its still failing after a short period of time.

[insleys]

I do have a newer firmware that was released recently, 20240710. Maybe updating that to see if it helps?

I didn't realise there was later firmware. I probably ought to update and see what impact it has, both in general and for this specific issue.

[zinserjan]

I had the same problem last year. I was able to solve it by changing the reporting settings.

Original settings:

Improved settings:

With this setting, the device reports the battery level every minute and thus remains responsive. I haven't had a single problem since I started using these settings.

Maybe it's possible to use larger reporting intervals, but I don't know. Stability was more important for me than battery drain :satisfied:

[adamlc]

Awesome! I tweaked my settings to be half the default and that seems to keep the device online!

[insleys]

Thanks for the responses. I tried setting the reporting interval as suggested, but while it seemed to help at first, after 3 hours the device became unresponsive again. I haven't found anything to fully resolve this. It's like the device just goes into some low power mode or something and never responds until you take the batteries out and put them back in again, or you repair the device.

I have bought an alternative device that seems to be based on the same chipset and code as the Moes device. It presents exactly the same way in z2m. The only difference is the new device is USB powered, not battery powered. Five days in and it's still working perfectly. All I had to do was change my HA scripts to use the new device topic, learn the codes for my end devices again, and update those codes in the script.

Actually, that's an interesting observation. The codes learned by the new IR device were about 3x to 4x the length of the codes learned by the Moes IR device. Same remote. Same button.

Something changed to stopped the Moes UFO working. Not sure what, but there doesn't seem to be a dev on here that will look into it, so I guess I replace my devices with the new model I bought. It's a bit of a pain that they need USB power as it limits placements somewhat, but at least they work.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days

[DanielKinsman]

Mine seems to get into a state where it is spamming updates several times a second despite the reporting being set to nothing like that. While it is in this state it doesn't send out any codes, and removing the batteries is the only way to snap it out of it.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

[kingp0dd]

were you able to fix this?

[DanielKinsman]

Mine can run for months now without getting into the funky spam state. That may or may not be because I have changed my home assistant automations to wait a little between sending consecutive IR codes 🤷

[kingp0dd]

Mine can run for months now without getting into the funky spam state. That may or may not be because I have changed my home assistant automations to wait a little between sending consecutive IR codes 🤷

your issue only happens when doing consecutive send? i guess mine's different. even if just single send, it sometimes doesn't work. i need to retry 3-5times

[insleys]

I haven’t tested for a long time because I abandoned the devices and bought an alternative that is more reliable and stable. The new ones I bought are USB powered, so not quite what I wanted, but they work.

[lorisbc]

Hello, I have this issue with 3 UFO-R11, sometimes it works for 3-4 days, sometimes only for 1-2 hours. All my other ZigBee devices (25) are working well. The only way to recover is to remove the battery and sync again.

Does anyone know a fix or a hack still working ? Thanks !