Same experience, except I have two roborocks, the older S5 shows up no problems, but the brand new S7 always shows unavailable.
hm… even while devices are in the same subnet maybe the following takes a role in here:
https://python-miio.readthedocs.io/en/latest/troubleshooting.html
miio.exceptions.DeviceException: Unable to discover the device x.x.x.x
This behaviour has been experienced on the following device types:
- Xiaomi Zhimi Humidifier (aka
zhimi.humidifier.v1)- Xiaomi Smartmi Evaporative Humidifier 2 (aka
zhimi.humidifier.ca1)- Xiaomi IR Remote (aka
chuangmi_ir)- RoboRock S7 (aka
roborock.vacuum.a15)It’s currently unclear if this is a bug or a security feature of the Xiaomi device.
Note
The root cause is the source address in the UDP packet. The device won’t react/respond to the miIO request, in case the source address of the UDP packet doesn’t belong to the subnet of the device itself. This behaviour was experienced and described in github issue #422.
Maybe if I have some time within the next days I will setup a wireshark listening on the Roborock Mac and investigate the source IP of UPD packages send…
Unfortunately at the moment short in time.
Just because it might help for future setps - which firmware versions are of Roborock S7 are you running? Mine is 4.1.5_1196
okay - could really narrow it down to the UDP restriction of Roborock.
Had both devices in a different VLAN.
Solved it by creating some Source NAT rules on my Unifi Secure Gateway.
Roborock S7 is now working as expected and entity is visible 
1 Like
Hey Martin,
I am running into the exact same problem (with the exact same setup). Could you PLEASE guide me through the NAT rule setup in Unify? (not too experienced with NAT rules).
Bob
Sure … but that will be some small text to read 
0 BACKUP YOUR UNIFI CONTROLLER CONFIGURATION
I will expect you to know how to do this …you really should do it in case of a faulty action within the following. - I cannot take any responsibility for breaks in your system
1 PREPARING THE ROBOROCK GROUP
First of all via GUI create firewall group ‘Roborock-NAT’, add your Roborock ip-address (or other affected MIIO device ip) and wait for provisioning to complete.
Then ssh to your USG (NOT your Unifi Controller!) and run:
mca-ctrl -t dump-cfg | grep -B10 “Roborock-NAT”
From this you should see something like:
},
"61214e23498a12adbfe37923 <THIS IS THE GROUP ID>": {
"address": [
"192.168.3.99 <THIS IS THE ROBOROCK IP>"
],
"description": "Roborock-NAT"
From this output note down the Unifi GROUP ID for your “Roborock-NAT” group.
In this example it is “61214e23498a12adbfe37923”
2 CONFIGURE TEMPORARY RULES VIA COMMAND LINE
Now we will configure the rule once through the command line, so you are able to test it and extract the “config.gateway.json” for your case.
As you are already within SSH session at your USG, execute:
ip addr
This prints your current ip configuration. Within there find the virtual interface name of the VLAN your Roborock is in (usually eht1.<vlan_id>) .
Still within ssh session at your USG execute the following commands:
#dump current configuration for later reference:
mca-ctrl -t dump-cfg > /tmp/config_ref.json
#create the source NAT rule:
configure
set service nat rule 5000 description 'source NAT HA->Roborock group'
set service nat rule 5000 type source
set service nat rule 5000 source address <YOUR HA SERVER IP - e.g. 192.168.1.10>
set service nat rule 5000 outside-address address <free IP to be used by HA within VLAN of your roborock - e.g. 192.168.3.10>
set service nat rule 5000 protocol all
#alternatively to the following "destination group address group..." rule you can apply the source-nat for a single address only and NOT use the firewall group..
#to do this replace the following line with:
# set service nat rule 5000 destination address 192.168.3.99
#in the following rule replace 61214e23498a12adbfe37923 with your appropriated group ID we identified previously
set service nat rule 5000 destination group address-group <YOUR ROBOROCK-NAT GROUP ID - e.g. 61214e23498a12adbfe37923>
#in the following rule replace eth1.3 with your appropriated interface name we identified in previous step via "ip addr"
set service nat rule 5000 outbound-interface <YOUR INTERFACE NAME - e.g. eth1.3>
commit
save
exit
#dump the new configuration:
mca-ctrl -t dump-cfg > /tmp/config_new.json
at this point your roborock should be already working until the next provisioning or restart of the Unifi Secure Gateway. - As said the rules created via command line are temporary only.
3 CREATE config.gateway.json FOR PERMANENT USAGE
To make your configuration permanent we have to create a config.gateway.json. This is a configuration file stored on your unifi controller, being merged into your GUI configuration during every provisioning, so your USG will receive it and create the NAT rules equally to above.
Again within your ssh session on USG execute:
diff /tmp/config_ref.json /tmp/config_new.json
This will output a difference of your previous configuration without and the new one with the Roborock rule set. At some point of the diff you should find something like:
...
@@ -1396,6 +1415,23 @@
},
"nat": {
"rule": {
+ "5000": {
+ "description": "source NAT HA->Roborock group",
+ "destination": {
+ "group": {
+ "address-group": "61214e23498a12adbfe37923"
+ }
+ },
+ "outbound-interface": "eth1.3",
+ "outside-address": {
+ "address": "192.168.3.10"
+ },
+ "protocol": "all",
+ "source": {
+ "address": "192.168.1.10"
+ },
+ "type": "source"
+ },
"6001": {
"description": "MASQ corporate_network to WAN",
...
This mainly is the content of your config.gateway.json. So copy & paste your output within a text editor, clean up the part with + and @ to have a clean JSON config. Then extend previously to the “nat”: { tag with “service”: { tag - the resulting file should look like the following - ensure you have closed all brakets :
{
"service": {
"nat": {
"rule": {
"5000": {
"description": "source NAT HA->Roborock group",
"destination": {
"group": {
"address-group": "61214e23498a12adbfe37923"
}
},
"outbound-interface": "eth1.3",
"outside-address": {
"address": "192.168.3.10"
},
"protocol": "all",
"source": {
"address": "192.168.1.10"
},
"type": "source"
}
}
}
}
}
Save this as “config.gateway.json” and use scp (for LINUX & MAC… not sure what to use best on windows… maybe winscp?) to copy the file to your UNIFI controller into: the path of /srv/unifi/data/sites/default/config.gateway.json
So a scp command would e.g. look something like:
scp config.gateway.json [email protected]:/srv/unifi/data/sites/default/
After this force a reprovisioning of your unifi secure gatway through your unifi GUI and you should be done 
1 Like
Wow! Thank you so much!
Unify Backup - check
Firewall Group - Check
Then I am stuck… No USG here (just UDM - so not exactly the same setup as you)… Any alternative? See: https://community.ui.com/questions/UDM-Pro-Confirm-no-config-gateway-json-allowed-possible/b451feeb-9e67-4cc4-8344-
hm… sorry for your but it seems unify does not support that kind of setup on UDM 
But THANK YOU ANYWAYS!
Hey!
I also faced the same issue on my UDM-P and solved it following https://community.ui.com/questions/UDM-Pro-Masquerade-NAT-Rule-via-iptables/4f39cf2a-ae8e-4681-8d0d-622c6af1d6dd
Basically, run the iptables command like shown. Replace source IP with your HASS IP (make it static) and destination IP with your Roborock’s IP (also make it static IP).
Once this works, follow this great guide to have your iptable command persist on reboot!
Cheers
2 Likes
Any S5 users experiencing same issues since this week ?
I updated to the currently latest version of HASS, HACS, Vacuum Card etc yesterday and since then I get unavailable on brushes, filter and sensor.
Listing the entities for Roborock show these with status Unavailable:
sensor.roborock_dnd_start, sensor.roborock_dnd_end, sensor.roborock_total_duration, sensor.roborock_total_clean_area, sensor.roborock_total_clean_count, sensor.roborock_main_brush_left, sensor.roborock_side_brush_left, sensor.roborock_filter_left, sensor.roborock_sensor_dirty_left
Hi @sedin and @elementoulis, I have S5 Max and I have the same issue. Those entities listed by @sedin are also Unavailable for me. Did you find any solution?
@jambuu I was unable to find a solution but restored an earlier backup and keeps fingers crossed that a fix is in the works
Hi @sedin, I raised this issue to home assistant here and it turns out it is not a bug, but a feature. You simply need to enable the disabled entities and voilà, everything works.
1 Like
That was an easy fix, maybe would have helped with a short notice about it on breaking changes. Great that it works again now. Thank you a lot for the info!
Having the connection issue with my S7 as well.
Problem for me is the following:
- I can’t assign a fixed IP to my vacuum as my ISP’s router doesn’t support it. Running a modem-only with my own router isn’t an option sadly…
- I don’t think I’m running HA in a different subnet. However I don’t know how to check this as I’m not experienced in that matter. I recently moved from an RPi to my M1 Mac via Docker. But the problem was existant on both devices.
Does someone know how I can fix this issue in my case? I rely on home assistant for some automations that aren’t supported by the Mi Home App. For now I’m removing and re-adding the vacuum daily but obviously this isn’t the way to go. I also don’t think you can automate the reinstallation of an integration on a daily basis?
I hope someone waay smarter than me will be able to figure this one out.
it worked perfectly here
Thanks
I try to implement this as you describe but this does not work for me. I have the same set up as you.
Can you help me pls.