Some devices not responding across subnets.

[cnrd]

Hi

I'm trying to change around a couple of things in my HASS setup, which seems to have surfaced a bug in the communication with chuangmi_ir devices.

I can ping the device just fine:

ping 10.0.3.18
PING 10.0.3.18 (10.0.3.18) 56(84) bytes of data.
64 bytes from 10.0.3.18: icmp_seq=1 ttl=254 time=5.14 ms
64 bytes from 10.0.3.18: icmp_seq=2 ttl=254 time=6.86 ms
64 bytes from 10.0.3.18: icmp_seq=3 ttl=254 time=3.88 ms
64 bytes from 10.0.3.18: icmp_seq=4 ttl=254 time=2.10 ms
--- 10.0.3.18 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.107/4.502/6.866/1.742 ms

but if i try to get info:

mirobo --ip 10.0.3.18 --token [TOKEN] info
ERROR:miio.device:Unable to discover a device at address 10.0.3.18
Error: Unable to discover the device 10.0.3.18

doing the same thing with my Roborock Vacuum works fine:

mirobo --ip 10.0.3.17 --token [TOKEN]
State: Charging
Battery: 100 %
Fanspeed: 100 %
Cleaning since: 0:02:34
Cleaned area: 2.765 m

It does work fine if I have an IP in the same subnet:

mirobo --ip 10.0.3.18 --token [TOKEN] info
chuangmi.ir.v2 v1.2.4_38 ([MAC]) @ 10.0.3.18 - token: [TOKEN]

I have tested on 2 different physical machines in different subnets, so it shouldn't be a problem with my network configuration.

[hoppel118]

Yes, you are right. It works as expected here.

[MrHollowPS]

@dave-castle @hundehausen

So, for the UDM pro folks if you never figured this out, just ran into this myself earlier today trying to get my Roborock S7 set up. Unfortunately, the UDM pro doesn't really support this out of the box through the GUI, so you need to do it by hand. Furthermore, if you set the rule up manually, it will wipe it on reboots and firmware upgrades. Here is what you need to do:

1. SSH into the UDM pro. You may need turn on SSH if it isn't already. Go to setup.ui.com and click the settings at the very bottom of the page. Turn on ssh and add a password. Then you should be able to.
2. Add your rule as shown above: iptables -t nat -A POSTROUTING -s YOUR_HOMEASSISTANT_IP/24 -d YOUR_DEVICE_IP/24 -j MASQUERADE
3. Verify the rule is working and your device is functional. Mine still showed as disconnected until I rebooted homeassistant, and then it picked it up. However, you still aren't done, as this will get wiped out the moment the UDM Pro reboots.
4. Install the UDM pro boot script. Follow the instructions here: https://github.com/boostchicken/udm-utilities/blob/master/on-boot-script/README.md#steps
5. Make a script in /mnt/data/on_boot.d with contents like this:

#!/bin/sh
iptables -t nat -A POSTROUTING -s YOUR_HOMEASSISTANT_IP/24 -d YOUR_DEVICE_IP/24 -j MASQUERADE

6. Make it executable: chmod +x your-script.sh

That should do it.

you F-ING legend. THANK YOU! I tried manually setting firewall rules on the LAN but that didn't work. geez

[pellle87]

so im having similar error '[homeassistant.components.xiaomi_miio.remote] Device unavailable or token incorrect: Unable to discover the device 10.69.20.19'

I did this in opnsense and seems like it still doesn't work. i double checked the IP and token and its correct

Did you get this to work?! kinda in the same situation.

[k1ng440]

so im having similar error '[homeassistant.components.xiaomi_miio.remote] Device unavailable or token incorrect: Unable to discover the device 10.69.20.19'

I did this in opnsense and seems like it still doesn't work. i double checked the IP and token and its correct

wherever you have 10.69.20.19 should be the IP of the home assistant

[k1ng440]

Here is how my pfense outbound look like:

Home Assistant IP: 192.168.0.6/32 IOT network: 192.168.50.0/24

[rytilahti]

Feel free to create a PR to update the documentation (under troubleshooting) if you wish, even linking to the issue comment with a short explanation would suffice :-)

[Idan37S]

For those who use PfSense, there seems to be a bug when using Outbound NAT and PfBlockerNG, I had the same issue where the NAT Outbound would just not work, no matter what I did.

I discovered that for some reason the NAT rules aren't being updated when PfBlockerNGis enabled. The workaround is just to disable and then enable PfBlockerNG and it will reload\update the correct NAT rules. You should do this after every NAT Outbound configuration update.

I can confirm that using the NAT Outbound in PfSense works perfectly when IoT devices are on a different VLAN then my HA.

@domibarton Thanks a lot for your perfect detailed explanation of the problem and the solution, It solved so much problems with my other IoT devices as well using this method (Xiaomi, Samsung TV, LocalTuya).

[bigbangus]

Here is how my pfense outbound look like:

Home Assistant IP: 192.168.0.6/32 IOT network: 192.168.50.0/24

Is the second entry necessary? I am able to get my Roborock S7 to work in HA with just the IOT outbound rule

[Idan37S]

Here is how my pfense outbound look like: Home Assistant IP: 192.168.0.6/32 IOT network: 192.168.50.0/24

Is the second entry necessary? I am able to get my Roborock S7 to work in HA with just the IOT outbound rule

The 2nd rule isn't necessary, the 1st rule will do the trick.

[Ming-A]

so im having similar error '[homeassistant.components.xiaomi_miio.remote] Device unavailable or token incorrect: Unable to discover the device 10.69.20.19' I did this in opnsense and seems like it still doesn't work. i double checked the IP and token and its correct

wherever you have 10.69.20.19 should be the IP of the home assistant

Gave it a try again, didn't seem to work for me for some reason, and i also only have the main 'Remote: Learn Command' service instead of the xiaomi miot learn command.

Home assistant: 10.69.40.4 wifi network: 10.69.20.0

[L4rryFisherman]

Spent quite a while today replicating this solution in openwrt. This worked, for anyone finding it later:

HA LAN: 192.168.31.60 IoT subnet: 192.168.32.x HA SNAT: 192.168.32.60

Firewall rules to let HA talk with IoT (these might be looser than necessary):

NAT rule to solve the subnet issue (masquerading instead of SNAT also works):

[Loic691]

I tried on mikrotik router without success. SRC-NAT from HA IP to S7 with action MASQUERADE Is there a workaround for mikrotik ?

[al13nus]

For me it also doesn't work with OPNsense. Someone had more luck? Can someone post a screen from inside the rule?

Edit: yeah, working now. Wrong configuration of the rule.

[xanox1]

I tried on mikrotik router without success. SRC-NAT from HA IP to S7 with action MASQUERADE Is there a workaround for mikrotik ?

Yes sir, i have this working.

/ip firewall add action=masquerade chain=srcnat dst-address=10.0.20.213 out-interface=BR_IOT src-address=10.0.30.101

10.0.20.213 = L10 10.0.30.101 = HA

BR_IOT is my IOT vlan interface.

You could limit the port to UDP/54321 i suppose, but i couldn't be bothered.

[rwjack]

I run pfsense and even though my HassOS has multiple interfaces, it also has one in the IOT Subnet, and I'm still getting these connectivity blips.

I don't see how NAT is the solution to this problem. As far as I can tell everyone here has HASS and their IOT devices on the same home network, be it in the same subnet, or a separate one. Pfsense being a router, should route the packets to the destination subnet, no NAT required, nothing is leaving the home network.

[hoppel118]

I can confirm that setting up masquerading between vlans on dest port 54321 did indeed work and all miio-based libraries started working for me, so big thanks to @domibarton!

@fuomag9 can you give an example of the rule you implemented to do MASQUERADE with a specific port? Currently I have: iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.20.0/24 -j MASQUERADE is adding --dport 54321 enough before the -j?

I tried that, but it didn't work. How to pass the port 54321?

Hi,

the complete iptables command (for the udm-pro) is the following:

iptables -t nat -A POSTROUTING -s YOUR_HOMEASSISTANT_IP/24 -d YOUR_DEVICE_IP/24 -p UDP -j MASQUERADE --to-ports 54321

This works here for two Xiaomi Smart Fan models:

• Smartmi DC Pedestal Fan
• Smartmi Standing Fan 2S

A long standing „issue“ is solved for me. Thank you so much, guys. :D

Regards Hoppel

Hi,

I migrated from FHEM to Home Assistant and now my masquerading doesn't work with home assistant.

This is how it worked with FHEM:

iptables -t nat -A POSTROUTING -s YOUR_FHEM_IP/32 -d YOUR_DEVICE_IP/32 -p UDP -j MASQUERADE --to-ports 54321

and this is how it works with Home Assistant:

iptables -t nat -A POSTROUTING -s YOUR_HOMEASSISTANT_IP/32 -d YOUR_DEVICE_IP/32 -j MASQUERADE

But why? Which ports are needed by Home Assistant, that FHEM doesn't need?

Thanks Hoppel

[rwjack]

I wouldn't use masquerade or NAT-ing. You want HA to talk to another LOCAL device. If that device in another subnet then your router should do the talking for you.

[xanox1]

I wouldn't use masquerade or NAT-ing. You want HA to talk to another LOCAL device. If that device in another subnet then your router should do the talking for you.

The router still does the talking. The problem is that the robots wont accept traffic from addresses outside of their own subnet range. Hence the masquerade to pretend to be coming from the same subnet.

[rwjack]

Ah, I didn't fully understand the issue then.

The problem I'm having is just connectivity blips:

[hoppel118]

I wouldn't use masquerade or NAT-ing. You want HA to talk to another LOCAL device. If that device in another subnet then your router should do the talking for you.

The router still does the talking. The problem is that the robots wont accept traffic from addresses outside of their own subnet range. Hence the masquerade to pretend to be coming from the same subnet.

@rwjack Yes, the iptables rules are configured on my router (Unifi Dream Machine SE).

Your last post triggered me to investigate some time into this again.

After the migration from FHEM to Home Assistant, my iptables rules didn’t work any more. I described that in my last post.

So I configured a trunk port to my home assistant vm and connected the iot vlan to HA. Now, my Xiaomi devices were reachable, but I also had the „connectivity blips“. The devices were switching between available/unavailable constantly.

Now with the working iptables rules, the connectivity blips seem to be solved in my case. At least there was no unavailable log for the last 5 hours. Hurrah… 😃

EDIT: Did you see the „Note“ in the HA documentation under „Prerequisites“?

Note For more complex network setups (e.g. VLANs), reference the following documentation for additional information.

[csi-lk]

So, for the UDM pro folks if you never figured this out

@gespo89 this saved me a significant amount of time, thank you so much for writing this out, would suggest adding this to the documentation

[hoppel118]

Is here anybody who can help making iptables nat masquerading rules permanent on a Unifi Dram Machine (firmware 3.x)?

https://community.ui.com/questions/UDM-SE-Permanently-remove-change-iptables-rules-for-NAT-masquerading/243e20c5-8642-4929-8163-b075d5f4cc02

EDIT: Issue solved. You can find the solution in the link before.

Thanks and regards Hoppel

[JefferiesTube]

Any chance to get this done with a simple FritzBox (I don't have any nice pfSense oder DM setup yet)?