Sonoff DW2 WiFi door sensor not working when using Pi-hole DHCP server

Help Community Help
1

Hi,

I have been using the DHCP server in my pi-hole (running on a Ubuntu 22.04 VM using VMware Workstation installed on a windows 7 "server") for a few months and all was good, I love it.

A couple weeks ago I bought a couple Sonoff DW2 WiFi door/window sensors, and even though they connect to the WiFi network just fine and they get a DHCP IP, they no longer work after connecting them to the network. They just show as offline in eWeLink.

If I switch the DHCP to the ISP router, they work just fine and without issues or disconnects, so it is clearly the pi-hole DHCP.

Has anyone had a similar issue or know how can I resolve this?

Thanks!

1 Like
2

When a client uses Pi-hole's DHCP, Pi-hole tells the client to use the Pi-hole for DNS.

When a client uses your router for DHCP, does the router still tell the client to use Pi-hole for DNS or does it use something else (eg Google or the ISP DNS)?

If the latter, then could Pi-hole simply be blocking a domain that the sensors need in order to determine that they are online or work properly? In otherwords, when using Pi-hole they use P-hole and get blocked, and when using the router they don't touch Pi-hole and so they work normally.

3

My router is also configured to use the pihole IP for DNS.
I also tried to disable blocking in the pihole and the same thing happens.

4

Might be worth doing a Pi-hole debug log for analysis. It's pihole -d or Tools > Generate debug log and then post the token URL here.

5

This is the token URL for the debug log: https://tricorder.pi-hole.net/EkcW77i0/
But bear in mind I have added the 4 devices I have of the DW2 sensor to the ignore list, so pihole's DHCP is not assigning an IP to them. Their MACs are "d0:27:03:xx:xx:xx"
I cannot assign a static IP to those devices either, they don't have any config that can be changed.

6

Your debug log looks normal, apart from a unusual network interface (altname enp2s1 for ens33, but that's likely due to VMware) and an unusual local domain (lan or home.arpa would be more common). An unusual name wouldn't be an issue by itself, as long as all your clients would be aware of the same local domain.

Just to be sure:
Assuming eWeLink is some kind of hub software for Sonoff equipment, would it run in Sonoff's cloud or locally in your network?
If the latter, would it have acquired its DHCP lease from Pi-hole, so it would be aware of your local domain name?

I'm not familiar with that equipment.
Could you detail that a bit?

In particular, why do they 'no longer work'?
That seems to imply that they have been working before?
But how, if you already had been running Pi-hole's DHCP server when they arrived?

For that eWeLink software to show the devices as offline, it would seem that eWeLink has to be already aware of them.

Assuming you'd have to register them with that eWeLink software:
If they would first have joined your network via your router's DHCP and registered them with eWeLink, they would have been registered with a specific name (like door-1.lan) and IP (like 192.168.1.101).
When later joining via Pi-hole's DHCP, they would go by a different name (e.g. door-1.P36) and IP (e.g. 192.168.1.57) - especially if your router would be still providing DHCP for some devices alongside Pi-hole's DHCP (which ignoring their MACs seems to suggest).

Did you try removing them from eWeLink and reregistering them?

7

Thanks for your reply Bucking_Horn

Yes, ens33 is because pihole is running on a VM on VMware Workstation.

eWeLink is the app for Sonoff devices, so I use the eWeLink app to pair the door sensor via Bluetooth, then configure my WiFi network SSID and password and those details are saved into the sensor so the device can connect to the Wifi network. This all runs on the cloud, I don't run anything Sonoff-related locally.

I have many (80+) Sonoff devices that use the eWeLink app and have no issues with any of them, just these sensors (4 of them, all have the same issue).

What I mean is that after I configure my WiFi details via the app they are saved on to the device and the device gets an IP from pihole's DHCP, but it shows as "offline" on the app all the time, so they don't send open/closed status, battery level or anything. They never worked on the pihole's DHCP.

If I switch DHCP to my ISP's router, they work fine: they get an IP and show as "online" on the eWeLink app, they send open/closed status updates, battery level... all is as it should be.

Even if I add them to the network using my ISP's router DHCP server, then switch to the pihole DHCP, they work while they have an IP lease from the ISP's router, as soon as I remove the batteries from the device and put them back in, they don't work any more, since they now have to get an IP from pihole's DHCP.

I tried removing them from eWeLink and re-adding them many many times, while testing and trying to see what's going on here. I left them on the ISP's router DHCP server for a week, no issues. Left them on the pihole's DHCP for a week, they never showed online.

And yes, right now I have the ISP's router DHCP server enabled as well, with just a 4-IP range and the 4 devices' MAC addresses manually assigned to an IP within the DHCP's range, they work fine, but I don't like having 2 DHCP servers on the network, and I would like everything to work off the pihole's DHCP server. I cannot configure a static IP for these devices.

Thanks!

8

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.