Refoss EM16 and VLAN

rwlove · November 5, 2025, 10:57pm

Does anyone have a workaround or a solution to get a Refoss EM16, on a IOT VLAN, enabled in Home Assistant. HA has an interface on the IOT VLAN that it connects to plenty of other devices on, but the Refoss (not Refoss RPC) integration cannot discover the EM16.

I cannot use Refoss RPC because the EM16 doesn’t support it.

I just filed a ticket against what I think is the repo. EM16 on a VLAN · Issue #19 · Refoss/refoss-homeassistant · GitHub

tmjpugh · November 6, 2025, 12:31am

Mdns discover or ip search

Can you ping device from HA?
What is your install method?

Does IOT vlan have internet access?

Does em16 connect local or remote?
How do you know this?

There is no magic. If it’s mdns you may need to get mdns working in the vlan if it is not already. Mdns…not dns.

If IP, you can try ping.
Then try nmap if ping work to check open port.

EDIT
Just in case
You didn’t ignore warning did you


Refoss LAN and Refoss(core integration) cannot be used simultaneously. If you plan to use Refoss LAN, please remove Refoss first.

rwlove · November 6, 2025, 12:53am

Mdns discover or ip search

I assume it’s MDNS, since I don’t have an option to enter an IP.

Can you ping device from HA?
What is your install method?

Install is a container running in a kubernetes cluster, so it’s probably a bit more complicated than a more common install.

ping seems to fail from within the container

➜ home-ops git:(main) ✗ kubectl -n home exec -it home-assistant-0 – bash
Defaulted container “main” out of: main, init-db (init), k8tz (init)
home-assistant-0:~$ ping 10.10.20.17
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?

Does IOT vlan have internet access?

No, but I’ve poked a hole in my firewall so that the refosss EM16 device does.

Does em16 connect local or remote?
How do you know this?

My understanding is that the Refoss integration is a local connection. I’m not sure what you’re referring to with local or remote.

There is no magic. If it’s mdns you may need to get mdns working in the vlan if it is not already. Mdns…not dns.

Ack, yeah, maybe MDNS isn’t configured or not configured correctly. I’ll look into it.

If IP, you can try ping.
Then try nmap if ping work to check open port.

I can check this. I’m not sure what port the EM16 uses, but I can look into it.

EDIT
Just in case
You didn’t ignore warning did you

Refoss LAN and Refoss(core integration) cannot be used simultaneously. If you plan to use Refoss LAN, please remove Refoss first.

From what I can tell the EM16 does not support Refoss LAN (which seems to be renamed Refoss RPC). I am only using Refoss, since I believe that to be the only available integration for this device.

Thanks for your suggestions. I will poke around on my MDNS configuration first.

tmjpugh · November 6, 2025, 1:00am

Containers and mdns require host network or macvlan. Thats docker, not sure what equivalent is in kubernetes

Vlan throws another wrench into the mdns bucket

If there is no ip it’s using mdns.

On Linux avahi-browse -a shows mdns advertisements. Can remember if that works inside HA container but you can use it to test network using PC or host server

rwlove · November 6, 2025, 2:32pm

[quote=“tmjpugh, post:4, topic:947963, full:true”]

I have a secondary interface on HA using a kubernetes construct called multus and it’s using macvlan to assign the IOT VLAN IP to HA as a secondary IP. I have many other IOT devices on the IOT VLAN that HA can communicate with.

I have mdns enabled on my VLANs, although I don’t find the Omada SDN configuration that I’m using very intuitive, so there could be a mistake there.

My router is a linux box with firewalld as the firewall. Interestingly, I can see quite a few mdns advertisements, but I don’t see any when I trigger the Refoss Integration discovery. (enp6s0f0.20 is the VLAN interface on the router)

+ enp6s0f0 IPv4 LG webOS TV 1B4C                              _hap._tcp            local
+ enp6s0f0.20 IPv4 esp8266-239b91                                _arduino._tcp        local
+ enp6s0f0.20 IPv6 Presence-Sensor-FP2-2582                      _aqara-setup._tcp    local
+ enp6s0f0.20 IPv6 Presence-Sensor-FP2-FB64                      _aqara-setup._tcp    local
+ enp6s0f0.20 IPv6 Presence-Sensor-FP2-E631                      _aqara-setup._tcp    local
+ enp6s0f0.20 IPv4 Presence-Sensor-FP2-FB64                      _aqara-setup._tcp    local
+ enp6s0f0.20 IPv4 Presence-Sensor-FP2-E631                      _aqara-setup._tcp    local
+ enp6s0f0.20 IPv4 esp32-244cab051b78                            _arduino._tcp        local
+ enp6s0f0.20 IPv4 Aqara-FP2-FB64                                _Aqara-FP2._tcp      local
+ enp6s0f0.20 IPv4 Presence-Sensor-FP2-2582                      _aqara-setup._tcp    local
+ enp6s0f0.20 IPv6 Home                                          _home-assistant._tcp local
+ enp6s0f0.20 IPv4 Home                                          _home-assistant._tcp local
+ enp6s0f0.20 IPv6 Aqara-FP2-FB64                                _Aqara-FP2._tcp      local

rwlove · November 6, 2025, 2:54pm

I captured a tcpdump for port 5353 and looked at in wireshark, but I can’t tell which packets are the Refoss discovery packets.

I can see some packets from my VLAN gateway 10.10.20.1 on port 5353 broadcast to 224.0.0.251, but I’m not sure they’re the Refoss discovery packets. It seems like I have a lot of mDNS traffic on my network, so they very well could be something else.

I wish I could follow the Python a bit better to see what field to look for in the packets.

rwlove · November 6, 2025, 3:45pm

Now I think that the Refoss integration is not using mDNS.

I believe that it’s opening a port on 9989.

github.com/Refoss/refoss_ha

refoss_ha/discovery.py

8b699c62f


      
                  """Called any time a new (unique) device is found on the network."""
          
              async def device_update(self, device_info: DeviceInfo) -> None:
                  """Called any time an up address for a device has changed on the network."""
          
          
          def socket_init() -> socket.socket:
              """socket_init."""
              sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
              sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
              sock.bind(("", 9989))
              return sock
          
          
          class Discovery(asyncio.DatagramProtocol, Listener):
              """Socket server."""
          
              def __init__(self) -> None:
                  self._device_infos = {}
                  self._listeners = []
                  self._tasks = []

and then sending a broadcast on port 9988. I don’t think the broadcast will will extend to my IOT VLAN and I’m not sure how to make that work.

github.com/Refoss/refoss_ha

refoss_ha/discovery.py

8b699c62f


      
              self.transport = transport
          
          async def initialize(self) -> None:
              """Initialize socket server."""
              self.sock = socket_init()
          
              await self._loop.create_datagram_endpoint(lambda: self, sock=self.sock)
          
          async def broadcast_msg(self, wait_for: int = 0) -> List[DeviceInfo]:
              """Broadcast."""
              address = ("255.255.255.255", 9988)
              msg = json.dumps(
                  {"id": "48cbd88f969eb3c486085cfe7b5eb1e4", "devName": "*"}
              ).encode("utf-8")
              try:
                  self.transport.sendto(msg, address)
                  if wait_for:
                      await asyncio.sleep(wait_for)
                      await asyncio.gather(*self.tasks, return_exceptions=True)
              except Exception as err:
                  _LOGGER.debug(

rwlove · November 6, 2025, 4:06pm

I created some iptables rules and the broadcast is being forwarded to the EM16 device, but I can’t quite figure out the rules to allow the response to get back to HA.

iptables -t nat -A PREROUTING -p udp -i enp6s0f0 --dport 9988 -j DNAT --to-destination 10.10.20.17:9988
iptables -A FORWARD -p udp -d 255.255.255.255 --dport 9988 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

The problem is that the HA IP might change since it’s in a K8S cluster, so I probably need something like conntracker, which I have no experience with, to route back. I’m not sure.

I wish this integration was just using mDNS or even better just allowed my to provide the IP of the EM16 device. The device is definitely spamming it’s cloud IP so I want to keep it on a restricted VLAN.

tmjpugh · November 6, 2025, 10:12pm

Can you use hostname instead of IP
This is generally best for docker. Not sure about k8S

rwlove · November 6, 2025, 10:28pm

I meant that I can’t write a iptables rule that forwards the response back to the HA instance since the HA ip can change. iptables won’t work on hostnames AFAIK.

I wonder if I can hack it to get past discovery. I’m not sure if I’d need persistent iptables rules.

If that doesn’t work, I’m pretty sure the iptables route won’t work.

tmjpugh · November 6, 2025, 10:31pm

You can write rule to addresss range HA will use or is this not possible?

rwlove · November 6, 2025, 11:19pm

I hacked iptables enough to get discovery to work. Basically I DNAT’ed the discovery requests from VLAN 1, through the gateway (10.10.20.1) and directly to the EM16’s static IP (10.10.20.17), based on the discovery port (9988). Then I DNAT’ed the discovery response (port 9989) back to the IOT VLAN IP of Home Assistant (10.10.20.101).

Discovery worked, but I’ll have to remove the rules to see if it continues to work. My hope is that the Refoss integration just caches the IOT VLAN IP (10.10.20.17) and then just uses normal routing for normal operation since there’s no more need for broadcasting. I think there is an extra rule or two in the tables.

Now to remove it all and see if it’s still working.

  # iptables -L -n -t nat                                                                                                                                              !10030
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:9988 to:10.10.20.17:9988
DNAT       udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:9989 to:10.10.20.101:9989
DNAT       udp  --  10.10.20.17          10.10.20.1           udp dpt:9989 to:10.10.20.101:9989

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0

  # iptables -L                                                                                                                                                        !10031
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:9989 state NEW,RELATED,ESTABLISHED
ACCEPT     udp  --  anywhere             anywhere             udp dpt:9989
ACCEPT     udp  --  anywhere             anywhere             udp dpt:9988

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

tcpdump -nnvvi enp6s0f0.20 -i enp6s0f0 -w vlan20.pcap --print port 9988 or port 9989

18:14:21.584726 IP (tos 0x0, ttl 63, id 19705, offset 0, flags [DF], proto UDP (17), length 86)
    192.168.1.21.53091 > 255.255.255.255.9988: [udp sum ok] UDP, length 58
18:14:21.584773 IP (tos 0x0, ttl 62, id 19705, offset 0, flags [DF], proto UDP (17), length 86)
    10.10.20.1.53091 > 10.10.20.17.9988: [udp sum ok] UDP, length 58
18:14:21.988638 IP (tos 0x0, ttl 64, id 6533, offset 0, flags [none], proto UDP (17), length 283)
    10.10.20.17.52921 > 10.10.20.1.9989: [udp sum ok] UDP, length 255
18:14:21.988696 IP (tos 0x0, ttl 63, id 6533, offset 0, flags [none], proto UDP (17), length 283)
    10.10.20.1.52921 > 10.10.20.101.9989: [udp sum ok] UDP, length 255

rwlove · November 7, 2025, 12:01pm

Final reply.

It looks like it’s continuing to work, so it can run on a VLAN, but you have to seriously hack the discovery process to get it discovered.

I filed a few tickets in GitHub to try to get this fixed, but as per this comment it doesn’t look like the developer will take any action.

I’m likely going to switch to Vue 3 when I want to expand the number of circuits I’m monitoring.

rwlove · November 8, 2025, 6:48pm

No longer working after a restart resulting from a Home Assistant upgrade.

proggaras · November 24, 2025, 10:48am

@rwlove Thx for the debugging. I ordered one EM06 last week and have to same issue. So I will send it back and stay with Shelly