Core: Xiaomi IR Remote - Unable to send learned commands - Unable to discover a device at address error

[ferdydek]

Home Assistant release with the issue:
0.74.2

Last working Home Assistant release (if known):
NA

Operating environment (Hass.io/Docker/Windows/etc.):
HassOS > Hass.io

Component/platform:
remote.xiaomi_miio

Description of problem:
Unable to send learned commands. This not only does not work on saved setup, but also immidiatly after learning a command.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

remote:
  - platform: xiaomi_miio
    host: 192.168.4.53 
    name: living_room_remote
    token: !secret LV_chuangmi.ir.v2
    slot: 10
    timeout: 30
    hidden: true
    commands:
    ## Harman-Kardon AVR355
      harman_power_off: 
        command:
          - raw:Z6VXAC0CAAB9BgAAvwgAAKIRAABLIwAAkLAAAMh3AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAAAAAABAAAAAAEBAQABAQEBAQAAAQAAAAAAAQEABQJGAkYCRgJGAkAA==
...

Traceback (if applicable):

2018-07-28 21:55:00 ERROR (SyncWorker_10) [miio.device] Unable to discover a device at address 192.168.4.53
2018-07-28 21:55:00 ERROR (SyncWorker_10) [homeassistant.components.remote.xiaomi_miio] Transmit of IR command failed, raw:Z6VXAC0CAAB9BgAAvwgAAKIRAABLIwAAkLAAAMh3AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAAAAAABAAAAAAEBAQABAQEBAQAAAQAAAAAAAQEABQJGAkYCRgJGAkAA==, exception: Unable to discover the device 192.168.4.53
2018-07-28 21:55:01 ERROR (SyncWorker_3) [miio.device] Unable to discover a device at address 192.168.4.53
2018-07-28 21:55:01 ERROR (SyncWorker_3) [homeassistant.components.remote.xiaomi_miio] Transmit of IR command failed, raw:Z6VXAC0CAAB9BgAAvwgAAKIRAABLIwAAkLAAAMh3AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAAAAAABAAAAAAEBAQABAQEBAQAAAQAAAAAAAQEABQJGAkYCRgJGAkAA==, exception: Unable to discover the device 192.168.4.53

Additional information:

[ferdydek]

@rytilahti could you please take a look, I wonder if its hassio issue or general platform issue.
Other devices (vacuum, router, repeater) are working OK.

[rytilahti]

I don't know much about those remotes, @syssi knows probably more. What I can say is that "unable to discover" comes when the device is not answering to the initial handshake, reasons for that may be various.

[ferdydek]

Thanks for feedback.
Well I would assume handshake had to go well since the learning works perfectly. Or that is a different process?

[benleb]

Not a plattform issue. I also got two of them and they work as expected 👍Are you sure the devices are constantly online/reachable?

[ferdydek]

@benleb I'm sure, as I mentioned this error happens also immediately after the command is learned, its really copy-paste-time delay. Which OS/env are you on?

[benleb]

okay :/
Debian stretch 9.5
Python 3.7.0
Hass 0.74.2
Xiaomi Remotes 1.2.4_38

[ferdydek]

only noticed this now (maybe this shows because I did add :debug):

2018-07-29 18:05:55 INFO (MainThread) [homeassistant.components.remote.xiaomi_miio] Initializing with host 192.168.4.53 (token e2235...)
2018-07-29 18:05:56 INFO (MainThread) [homeassistant.components.remote.xiaomi_miio] chuangmi.ir.v2 1.2.4_38 MC200 detected

so it does connect and does discover it, just is not able to later transmit the command (same error).

[syssi]

Please capture the command again and update your configuration. Does it work now? The remote controller crashes on some captured commands.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[chimpy]

Hey @syssi I am encountering this issue.

I used the miio script to obtain a token. I can learn a command and resend it without problem.
However after a period of time x, my Xiaomi IR Remote simply stops responding to all learned IR commands (either sent with the name of the command or the raw). The light remains blue, and does not blink. It also responds to pings.

I then get the same error as @ferdydek :

2018-11-14 19:40:08 ERROR (SyncWorker_19) [miio.device] Unable to discover a device at address 192.168.1.47
2018-11-14 19:40:08 ERROR (SyncWorker_19) [homeassistant.components.remote.xiaomi_miio] Transmit of IR command failed, raw:Z6VHADcCAACKBgAAtwgAAKwRAAA6IwAAWCMAAHibAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAAAAAAAAQEBAQEBAQEAAAAAAAABAAEBAQEBAQABBgJQA, exception: Unable to discover the device 192.168.1.47

The only workaround I currently have is unplugging the device and then plugging it back in again. Not ideal :( Any ideas?

[reaper7]

I have exactly the same problem as @ferdydek & @chimpy :(
(xiaomi vacuum is discovered without problem)

[chimpy]

@reaper7 @ferdydek Do you still have the problem with 82.1 ? After installing the update mine has been responding for over 12 hours now.

[reaper7]

Yes :(
ir response on ping but ha shows:

Device unavailable or token incorrect: Unable to discover the device 192.168.0.149

after ir power on/off works some time and again becomes for ha as unavailable

[chimpy]

@reaper7 Looks like I spoke too soon, I still have the same issue. Unplugging only makes the issue go away temporarily.

@syssi Any ideas?

[syssi]

I cannot help here. It looks like a firmware issue of the hardware.

[reaper7]

my rpi sd card died but I tried
remote/xiaomi_miio.py from dev branch and looks promising
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/remote/xiaomi_miio.py

unfortunately I could not test it for long...

[michaelkleinhenz]

Same issue here with 0.82.1. After power cycle of the device the communication works for a while, then the issue appears again:

2018-11-24 16:04:16 INFO (MainThread) [homeassistant.components.remote] Setting up remote.xiaomi_miio
2018-11-24 16:04:16 INFO (MainThread) [homeassistant.components.remote.xiaomi_miio] Initializing with host 192.168.178.62 (token eb457...)
2018-11-24 16:04:21 ERROR (MainThread) [miio.device] Unable to discover a device at address 192.168.178.62
2018-11-24 16:04:21 ERROR (MainThread) [homeassistant.components.remote.xiaomi_miio] Device unavailable or token incorrect: Unable to discover the device 192.168.178.62

The issue appeared just recently and everything ewas working before. I did not do any firmware updates, updates on the MI Home app or HASS core updates. It just suddenly stopped working. I don't know if the remote does hidden fw updates though.

I don't know if it is related, I am not a networking expert, but while I can ping the miio device IP, hitting it with nmap reports the host as down, even when skipping the ping probe with -Pn. But when I power cycle the device and then start an nmap run again, it detects and scans the device fine. As far as I understand, this means the device does not respond to ARP queries, but again, I am not an expert there.

This actually looks like it is going in some kind of sleep mode after a while...

[rytilahti]

Are you blocking its access to the cloud (see issue https://github.com/rytilahti/python-miio/issues/407#issuecomment-439991319)? The device not being responsive to nmap scans (but working after a reboot) sounds like it has dropped from the network for a reason or another.

[michaelkleinhenz]

Are you blocking its access to the cloud (see issue rytilahti/python-miio#407 (comment))? The device not being responsive to nmap scans (but working after a reboot) sounds like it has dropped from the network for a reason or another.

No, there is no block or filter in place. Funny is that it worked for some time and just recently started showing the issue with no updates to any of the involved systems. Still, it could be that the miio device does silent updates though.

I even registered a remote using the Mi Home app to see if it may need at least one registered remote in the app to work properly, but it made no difference. I haven't tried if the app remote works when the issue is present. Will test that when it happens the next time. I also can't see any pattern on the delay until it happens. I've seen it working for hours then stop and I also have seen to crash just after a few minutes after a power cycle.

[michaelkleinhenz]

Just found another bit that may be related: every time an ir command is sent out, this happens on the log:

2018-11-25 03:30:00 DEBUG (SyncWorker_1) [homeassistant.components.remote.xiaomi_miio] Sending payload: 'raw:Z6VHADYCAACDBgAAwggAAJkRAAAiIwAACJ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAQAAAAAAAQEAAQEBAQEBAAABAAAAAAABAQABAQEBBQJAA='
2018-11-25 03:30:00 DEBUG (SyncWorker_1) [miio.protocol] Unable to decrypt, returning raw bytes: b''
2018-11-25 03:30:00 DEBUG (SyncWorker_1) [miio.device] Got a response: Container: 
    data = Container: 
        data = b'' (total 0)
        value = b'' (total 0)
        offset1 = 32
        offset2 = 32
        length = 0
    header = Container: 
        data = b'!1\x00 \x00\x00\x00\x00\x05Bj\x87\x00\x00\x00\xfd' (total 16)
        value = Container: 
            length = 32
            unknown = 0
            device_id = b'\x05Bj\x87' (total 4)
            ts = 1970-01-01 00:04:13
        offset1 = 0
        offset2 = 16
        length = 16
    checksum = b'\xebE{b\xb7$f\x158\xb6;,Pv\xbd\xd6' (total 16)
2018-11-25 03:30:00 DEBUG (SyncWorker_1) [miio.device] Discovered 05426a87 with ts: 1970-01-01 00:04:13, token: b'eb457b62b724661538b63b2c5076bdd6'
2018-11-25 03:30:00 DEBUG (SyncWorker_1) [miio.device] 192.168.178.62:54321 >>: {'id': 13, 'method': 'miIO.ir_play', 'params': {'freq': 38400, 'code': 'Z6VHADYCAACDBgAAwggAAJkRAAAiIwAACJ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAQAAAAAAAQEAAQEBAQEBAAABAAAAAAABAQABAQEBBQJAA='}}
2018-11-25 03:30:00 DEBUG (SyncWorker_1) [miio.device] 192.168.178.62:54321 (ts: 1970-01-01 00:04:13, id: 13) << {'result': 0, 'id': 13}

The command is successfully sent out and works while this is happening. I don't know if that Unable to decrypt is correct or not.

[reaper7]

@michaelkleinhenz - You tried to replace xiaomi_miio.py from official 0.82.1 with this from dev branch as I wrote above?
It helped me, 4 days without problem

[michaelkleinhenz]

@reaper7 not yet. But I potentially found a workaround. I've suspected that this has something to do with some sleep mode the device is going into after a while. I created an automation that sends out an ir command every minute to see if that prevents the issue to appear...and it is working. I havent had any problems for 12 hours now.

[cnrd]

Possibly related to: https://github.com/rytilahti/python-miio/issues/422

[chimpy]

@reaper7 I put the dev code in place last night and restarted Hass and the remote, but this morning the remote is unresponsive until being power cycled. :(

[reaper7]

@chimpy - my still works, without problems, without reset, almost 6 days

[michaelkleinhenz]

@reaper7 @chimpy looks like the workaround keeping the device alive works. I don't have issues now for 2 days with the current stable code. I have set up an automation that sends out an unused IR code every minute. I would now try to make the intervals larger.

[chimpy]

@michaelkleinhenz I tried setting mine to 10 minutes, but even that is too long. Just sucks that the device blinks all the time when set to 2 mins.

[chimpy]

2 minutes also eventually results in a timeout for me.

[syssi]

I've build a simple test setup to reproduce this issue (without success so far):

# configuration.yaml
logger:
  default: warn
  logs:
    miio: debug

remote:
  - platform: xiaomi_miio
    name: Xiaomi Remote
    host: 192.168.130.89
    token: 8f7537427792e82610162df211814ba8

automation:
  - alias: Send infrared command every 5 minutes
    trigger:
      platform: time
      minutes: '/1'
      seconds: '/2'
    action:
      service: remote.send_command
      entity_id: remote.xiaomi_remote
      data:
        command: raw:Z6WPAacBAADzBAAAoAYAADcNAADsJgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjAAAQABAAEAAAEAAAEBAAAAAAAAAAABAAEAAAABAAEAAAEBAQABAAABAQEBAQEAAAQCMAABAAEAAQAAAQAAAQEAAAAAAAAAAAEAAQAAAAEAAQAAAQEBAAEAAAEBAQEBAQAABAIwAAEAAQABAAABAAABAQAAAAAAAAAAAQABAAAAAQABAAABAQEAAQAAAQEBAQEBAAAEAjAAAQABAAEAAAEAAAEBAAAAAAAAAAABAAEAAAABAAEAAAEBAQABAAABAQEBAQEAAAAA==

My Xiaomi IR Remote sends a infrared command every 2 seconds now. I've setup lircd with a igorplugusb as infrared receiver reporting every two seconds a received command now:

Dec  8 13:45:18 wolowitz kernel: [15492.481619] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  8 13:45:20 wolowitz kernel: [15494.905907] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  8 13:45:22 wolowitz kernel: [15496.479626] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  8 13:45:24 wolowitz kernel: [15498.479095] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  8 13:45:26 wolowitz kernel: [15500.481662] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  8 13:45:28 wolowitz kernel: [15502.485930] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  8 13:45:30 wolowitz kernel: [15504.480968] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  8 13:45:32 wolowitz kernel: [15506.482623] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  8 13:45:34 wolowitz kernel: [15508.483344] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  8 13:45:36 wolowitz kernel: [15510.481932] igorplugusb 3-12:1.0: receive overflow, at least 3 lost

My lirc setup isn't nice / is a bit broken. A kernel message per infrared packet is fine for me ATM. I will decrease the frequency to one command per hour later the day.

[syssi]

Two days later the communication is still stable:

Dec  9 00:20:00 wolowitz kernel: [53573.818852] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 00:40:00 wolowitz kernel: [54773.804864] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 01:00:00 wolowitz kernel: [55973.791207] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 01:20:01 wolowitz kernel: [57174.595148] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 01:40:00 wolowitz kernel: [58373.736487] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 02:00:00 wolowitz kernel: [59573.719200] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 02:20:01 wolowitz kernel: [60774.501933] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 02:40:00 wolowitz kernel: [61973.672487] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 03:00:00 wolowitz kernel: [63173.656297] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 03:20:01 wolowitz kernel: [64374.508971] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 03:40:00 wolowitz kernel: [65573.620257] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 04:00:00 wolowitz kernel: [66773.595998] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 04:20:00 wolowitz kernel: [67973.574287] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 04:40:00 wolowitz kernel: [69173.545298] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 05:00:00 wolowitz kernel: [70373.526307] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 05:20:01 wolowitz kernel: [71574.343051] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 05:40:01 wolowitz kernel: [72774.353650] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 06:00:00 wolowitz kernel: [73973.467347] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 06:20:00 wolowitz kernel: [75173.852088] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 06:40:01 wolowitz kernel: [76374.313374] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 07:00:00 wolowitz kernel: [77573.412704] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 07:20:00 wolowitz kernel: [78773.380712] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 07:40:01 wolowitz kernel: [79974.275419] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 08:00:01 wolowitz kernel: [81174.191432] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 08:20:00 wolowitz kernel: [82373.813449] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 08:40:01 wolowitz kernel: [83574.133580] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 09:00:00 wolowitz kernel: [84773.282198] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 09:20:00 wolowitz kernel: [85973.258794] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 09:40:00 wolowitz kernel: [87173.240498] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 10:00:00 wolowitz kernel: [88373.222238] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 10:20:00 wolowitz kernel: [89573.199527] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 10:40:00 wolowitz kernel: [90773.183541] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 11:00:00 wolowitz kernel: [91973.160563] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 11:20:00 wolowitz kernel: [93173.140567] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 11:40:00 wolowitz kernel: [94373.120587] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 12:00:00 wolowitz kernel: [95573.099321] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 13:00:00 wolowitz kernel: [99173.414628] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 14:00:00 wolowitz kernel: [102773.352400] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 15:00:01 wolowitz kernel: [106374.125714] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 16:00:01 wolowitz kernel: [109974.386876] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 17:00:00 wolowitz kernel: [113573.161794] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 18:00:00 wolowitz kernel: [117173.099797] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 19:00:00 wolowitz kernel: [120773.039876] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 20:00:00 wolowitz kernel: [124372.977919] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 21:00:02 wolowitz kernel: [127974.803689] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 22:00:00 wolowitz kernel: [131572.856302] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec  9 23:00:00 wolowitz kernel: [135172.791344] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec 10 00:00:00 wolowitz kernel: [138772.735041] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec 10 01:00:00 wolowitz kernel: [142372.674427] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec 10 02:00:00 wolowitz kernel: [145972.606157] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec 10 03:00:00 wolowitz kernel: [149572.545199] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec 10 04:00:00 wolowitz kernel: [153172.483963] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec 10 05:00:00 wolowitz kernel: [156772.420275] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec 10 06:00:00 wolowitz kernel: [160372.362314] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec 10 07:00:00 wolowitz kernel: [163972.298355] igorplugusb 3-12:1.0: receive overflow, at least 3 lost
Dec 10 08:00:00 wolowitz kernel: [167572.237124] igorplugusb 3-12:1.0: receive overflow, at least 3 lost

I've reduced the interval from 2 seconds to 20 minutes to 60 minutes.

HA 0.83.3 (virtualenv), python-miio 0.4.3: HA <-> WiFi <-> AP <-> WiFi <-> Xioami IR

[chimpy]

Hey @syssi thanks for getting involved :) I have added the logger config to my configuration. My Xiaomi IR tends to fail every 24-48h. There is a Node Red flow that fires an IR command every two minutes as a sort of "keepalive" (which eventually fails).
I will keep you posted.
I am on 0.83.3 (virtualenv): HA <-> Ethernet <-> Switch <-> AP <-> Wifi <-> Xiaomi IR

[michaelkleinhenz]

I have the keepalive at 1 minute and it was stable for about two weeks. Today, it failed and I had to powercycle the device again. I think those keepalives are only a temporary solution. We need to find out how to wake up the device. The Xiaomi app works even with a "sleeping device". I will try to sniff the traffic over the holidays what the app is sending to the device.

[michaelkleinhenz]

Interesting, I just wanted to setup wireshark to check what the app is doing when the device is in sleep, and apparently, the app also fails and tells me the device is offline. This is really weird. Is this a firmware bug?

[michaelkleinhenz]

Ok, this is weird - or not, let's see: I got the issue again, even with 1 minute keepalive. I did not change anything. The firmwares are all the same as before, the issue just reappeared. The Xiaomi app also does not work when the issue is happening!

What I did change is the power setup where the miio device is plugged in. I had the device powered by the USB port of my router. It might be that this is just a power issue. I now put the device on a 2A adapter and so far, it is stable.

@chimpy @syssi @reaper7 can you try to see if your issue improves when putting the device on a reliable power source?

[reaper7]

@michaelarnauts - this may be the reason!
My IR works 27days without problem.
Before, it was powered from rpi but when my rpi sd-card died,
I thought it could be because too many devices powered by rpi
and I switched IR power to a separate 2A power supply.

[syssi]

My device is stable as always. I'm still unable to reproduce the issue.

[chimpy]

Mine was being powered by my USB 3 port on my NUC. I'd already tried deactivating any sort of power management on the ports and Ubuntu was reporting back that there was none activated.

Anyway, switched it over to a 5V 1A Chromecast Audio plug. I'll see whether it's still working tomorrow. Hopefully it's a power issue!

[michaelkleinhenz]

Ok, I think I can confirm it is indeed a power issue. I deactivated the keepalive and put the device on a 2A power supply. Works completely stable for the last 2 days for me.

[chimpy]

CCA plug is still causing dropouts. Managed to rummage around and find my old Pi 2A plug. Will report back.

[chimpy]

You guys are lucky. Mine still doesn't work even with new plug. Disconnects in less than a few hours.

[michaelkleinhenz]

@chimpy As several people solved it with a power supply, can you try another one just to be sure? I use an "official" Raspi3 supply.

Other question: this may also be caused by power frequencies. I had several issues with this when dealing with notebooks. Power voltage in China is 220V, 50HZ while in the US, it is 110/60. I am in Europe, so my voltage is matching China. Where are you? This is just a guess, but as I had issues with this before on other devices, maybe this might be an issue.

[chimpy]

Hey man,
Sure I appreciate that. I am actually using the official Raspi2 power supply.
I am also in the EU (France) so my AC is 220/50.
The only thing I can think of is that my Xiaomi hub has too many devices. I have 38 so I need a second hub.
However this IR device is supposed to be independent, so I don’t feel that should be a contributor.
I am ready to give up and just buy a Broadlink Mini.

On 3 Jan 2019, at 16:02, Michael Kleinhenz [e-mail] wrote:

@chimpy As several people solved it with a power supply, can you try another one just to be sure? I use an "official" Raspi3 supply.

Other question: this may also be caused by power frequencies. I had several issues with this when dealing with notebooks. Power voltage in China is 220V, 50HZ while in the US, it is 110/60. I am in Europe, so my voltage is matching China. Where are you? This is just a guess, but as I had issues with this before on other devices, maybe this might be an issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[michaelkleinhenz]

Yes, the miio ir device directly connects to Wifi and the Home Assistant is not using the xiaomi bridge to send commands.

[kroshilin]

Have the same problem with two Mi remotes. Tried few power adapters with no luck.

[michaelkleinhenz]

@kroshilin do you have 110v/60 or 220v/50? The whole thing has something to do with the power supply, I am pretty sure. I do get outages, but only every several weeks. I think about adding a zigbee power adapter to the ir remote so it automatically powercycles when HA is encountering an error.

[sjtuross]

Another possible cause is Wifi interference. I changed my 2.4G channel to another. It has been working fine so far. Need to pick the channel which doesn't overlap with other nearby APs with strong signal.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[frkos]

I understand this is an old tread, but... I've just set up my remote and faced the same issue "Unable to discover the device"... It works, but it's not stable and with this error appearing.

I tried different power adapters, but with no success. Until I allowed IR to access internet on my router. After that it's working as expected with any adapter.
If I block internet access, IR becomes unstable immediately. Does anyone see the same behavior?

BTW I have Xiaomi Mijia IR remote (with mijia logo on top, not MI)

[rytilahti]

@frkos could it be a similar problem as described in https://python-miio.readthedocs.io/en/latest/troubleshooting.html#intermittent-connection-issues-timeouts-xiaomi-vacuum ? If so, blocking the device with REJECT instead of DROP would help.

[frkos]

@rytilahti looks like you are right! Thank you
But I cant' test it as my router supports only "Allow" or "Prohibit" =(
So I decided to block TCP connections at least and leave UDP/8053 only... I guess it's being used for heartbeat only... not for data transferring. It sends a key and then receives the same key

UPD: I'm not right. Xiaomi still can control me... =)
https://github.com/OpenMiHome/mihome-binary-protocol/blob/master/doc/PROTOCOL.md

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[ykcheow]

Hi, just want to share another possible root cause for the timeout problem. Few days back i had the same issue of my Xiaomi IR remote controller and it does not get resolved even i changed to different adapter. Then, i recalled i have setup the static IP address for the device just before the timeout issue happen. The static IP address setting seems causing problem for Mi gateway also as it stopped working in the Mi Home app but HA still able to talk to the gateway. Everything back to normal after i removed the static IP setting in the router and so far no issue for the past 2 days.

Odd but seems that is the root cause.

[michaelkleinhenz]

The static IP address setting seems causing problem for Mi gateway

but HA is talking to the IR hub directly, not over the gateway. Only the app is using the gateway. So how can this interfere with the HA connection?

[ykcheow]

Hi, it turns out that by removing the static IP assignation does not resolve the intermittent connection issue with IR remote as I'm still encountering it.

So far, i have tried the following but still encountering the disconnection issues with HA,

1. Remove/assign static IP of the IR remote in my router.
2. Change to multiple power adapter/USB cable.

My IR remote is connected to the same network as my HA and it has access to the internet. I was wondering if it's hardware related issue.

Any advise/recommendation are welcome to resolve the intermittent disconnection issue.

[xianbinhuang]

I have the same issue.

2020-03-24 22:05:12 ERROR (SyncWorker_7) [miio.device] Unable to discover a device at address 192.168.31.111
2020-03-24 22:05:12 ERROR (SyncWorker_7) [homeassistant.components.xiaomi_miio.remote] Transmit of IR command failed, mU2mEsmM4mUwlgBBzecADlNJhLJxMAB/AH2YzgAQgOfAZ0ErwOtAQqYQAA==, exception: Unable to discover the device 192.168.31.111

I can use xiaomi_miio.remote_learn_command to learn the code

when i try to use remote.send_command, the problems come ,but the remote light can be blue

[wzwick]

just adding my 2 cents in here.
I have the same issue, device drops off network completely and stops responding to commands.
I added a smartplug behind it that power cycles every hour.
Works perfectly - my drop out rate was between 1 and 2 hours

I actually use the broadlink ones more in my house now, they are more stable IMO.

[sthorley]

I don't think this issue is related to Home Assistant but rather buggy firmware from Xiaomi, I've been having this issue for many month using only the official mihome app (china server). It shows offline after a while and only power cycle brings it back online. The whole time the light remains blue on the device even though it goes offline.

[march83]

The static IP address

Interestingly, I recently changed the address of my MI Universal IR remote to static and it stopped working (via Home Assistant). It appeared on the network intermittently, but I couldn't communicate with it via HA, mi app or command line tools.

I returned it to dynamic and it started working again. Weird.

[wzwick]

The static IP address

Interestingly, I recently changed the address of my MI Universal IR remote to static and it stopped working (via Home Assistant). It appeared on the network intermittently, but I couldn't communicate with it via HA, mi app or command line tools.

I returned it to dynamic and it started working again. Weird.

but in the config you need to specify the IP of the host device - how are you getting around that?

[march83]

By config, you mean HA config? Yeah, I have no solution for this - I just seem to be fortunate that my network is almost exclusively static IPs, the router isn't rebooted often and when it does the IR remote seems to almost always get allocated the same IP. The only reason I set the IP to static in my router was because the dynamic allocation gave me a new IP address when I recently restarted it - setting it static seemed smarter than changing HA config, but apparently not...

[wzwick]

ha ha - so it works but you are lucky that it does :)
I have an old sonoff that cycles power every 60mins, does the job :)