Broadlink RM Mini 4 - "no longer reachable"

[JasonGoldenDDT]

Describe the bug I've seen this come up in past issues, and have researched the behavior online, it's unclear what the cause is. However the behavior is breaking automation for me.

I have several Broadlink RM devices installed that control Dyson fans and a LG Window AC. I use the Broadlink RM Mini 4 (V62092) to control the AC and capture temperatures that trigger HomeKit automations to maintain the climate in our bedroom overnight.

This works 90% of the time, however I continue to see failure as a result of this device disconnecting from Wifi. I extracted the debug data to see if a pattern emerged. The RM 4 (12) disconnects more than the RM 3 (10,17,18).

I've tried various adjustments to update frequency. Anything less than 200ms breaks my automation as the temperature doesn't trigger automation quickly enough and the room gets warm, the AC runs longer. I adjusted this to 1 to 3 seconds to see if it would resolve this disconnects... It did not.

{ "name": "Broadlink Temperature", "type": "temperatureSensor", "disabled": false, "host": "xx:xx:xx:xx:xx:xx", "temperatureUpdateFrequency": 150, "logLevel": "trace" }

I only send On/Off Commands to the AC with the automation. I don't rely on the plugin's auto features as I don't know how to build them out. The AC has a simple remote without a screen or discreet hex for temperatures. The RM 4 is only driving the AC and temperature readings. { "name": "Air Con RM", "type": "air-conditioner", "disabled": false, "host": "xx:xx:xx:xx:xx:xx", "units": "F", "temperatureUpdateFrequency": 60000, "ignoreTemperatureWhenOff": true, "defaultCoolTemperature": 15.5556, "sendTemperatureOnlyWhenOff": true, "minTemperature": 15.5556, "maxTemperature": 30, "replaceAutoMode": "cool", "minimumAutoOnOffDuration": 300, "turnOnWhenOff": true, "preventResendHex": true, "coolOnly": true, "noHumidity": true, "noHistory": true, "logLevel": "trace", "data": { "off": "26004800000121931336131213121212131213111312133613121336133613121312133613361312133613121212131213121311131213361312133613361337123713361336131213000d050000000000000000000000000000", "on": [ { "data": "26004800000121931336131213121212131213111312133613121336133613121312133613361312133613121212131213121311131213361312133613361337123713361336131213000d050000000000000000000000000000", "pause": 0.5 }, { "data": "2600480000011f951237121312121114111411131114113812131138123810141213123711391113113811391113113911381114101411391113111411381114111410391138121311000d050000000000000000000000000000" } ], "cool15.5556": { "pseudo-mode": "cool", "data": "260058000001209411371313111411141014121311141138121211391237111411131238113812131014113911131138111411141114113811381213113811141039113812371114110005700001244d12000c4a0001264b11000d050000000000000000000000000000", "sendCount": 2, "interval": 0.5 } } },

I've tuned my wifi to account for a crowded radio environment. My IOT devices are connected to a 2.5 SSID and the AP is less than 10 feet from the AP in line of sight. Its connection quality generally floats between 80 and 85% on channel 6.

I have Amplifi Alien routers in a mesh config with a wired backbone, a headless AppleTV 4k wired to the primary router and all devices are configured with a static IP.

I've confirmed the power supply is adequate and all of the troubleshooting steps I've found thus far around resetting, power cycle, and such have not improved the behavior. The device can reach the internet, as I noticed blocking it would increase its disconnect frequency.

I use a manual discovery config for broadlink in hopes it would shorten the reconnect times.

When this device disconnects the automation is triggered and home app falls out of sync with the devices actual status. This keeps the automation from working correctly and the AC can either remain off or on longer than needed. I use the LG ThinQ plugin as a fall back, however the AWS severs have not been reliable enough to make it the primary method of control. Instead my automation checks to see if the LG Plugin device status is aligns with the Broadlink action taken. Did the device report as off when the broadlink sent the "off" command , if not send the OFF command from the LG ThinQ plugin.

This backup has improved the performance from 80% to 90% accurate, but like I mentioned the LG servers are still failures prone, reducing these disconnections or incorporating recovery code would improve reliability and save us money.

I've noticed this behavior over several versions of this plugin, and other branches have also mentioned this behavior but I have yet to see a resolution. The threads go dark and close without any indication of resolution.

To Reproduce Steps to reproduce the behavior:

1. Configure Broadlink RM mini 4 with Trace Debug enabled.
2. Create Temperature Trigger Automations
3. Connect Device to 2.5 ghz wifi network with a static IP address.
4. Observe connection status in homebridge debug log.

Expected behavior Minimal disconnects. Ideally software can recover from disconnects by resending missed commands.

Screenshots I've tried beta 4, I just installed this version and noticed the behavior continues.

Desktop (please complete the following information):

• OS: 15.1
• Browser [safari]

Smartphone (please complete the following information):

• Device: [iPhone 13 mini]
• OS: [iOS8.1]
• Browser [safari]