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!