Closed xannor closed 4 months ago
So Home Assistant auto discover can use DHCP since it is a standard protocol, but there is now way of doing out of the box discovery with a custom protocol. If HA would implement such protocols my network would be flooded with the thousands of diffrent discovery requests from diffrent brands I don't even own.
Indeed WiFi vs LAN has a diffrent MAC, but if you connect a cam over LAN there is really no point in having a wifi connection. Besides even your router will see that as two seperate devices and will assign two seperate IPs.
If DHCP broadcast is comming in correctly to HA, it will update the IP, however if you for example have the CAMs and HA in diffrent subnets often DHCP does not make it accross the subnet (although the integration can still work just fine if the IP is supplied manually). Also DHCP broadcast will only be identified as beeing a reolink cam if: the hostname starts with "reolink" or the MAC is in range "EC71DB*", or the MAC is already setup as a reolink camera in HA (for IP updates). However it is adviced to use static IPs (DHCP reservation) in the router, as documented in the HA Reolink docs.
Simple reason to use MAC is because it is always available and can be used accross integrations to identify a device (such as a ping integration pinging a reolink cam).
However because of your post I have looked again at the DHCP discovery code in HA and found a bug. Therefore currently updating the IP if it changes is not working, I fixed this in PR: https://github.com/home-assistant/core/pull/103654
What is the MAC address of the wifi cam that is never detected?
68:39:43:
its the "snowflake" 511W
On a side note, I went and reworked my discovery integration, and just tested it in my live setup and it picked up the 511 and pushed the dhcp info to your integration without a problem.
68:39:43 is from ittim, looks like a company selling wifi chips. So that mac range is not owned by Reolink like EC71DB is.
Maybe it was one of the early prototypes or just so old that it was before they started using their own OUI
Quite possible, it was the second camera of theirs I bought, the first was a Lumus, but its cable was damaged recently and I haven't had time to try to repair it, plus it is a client app only camera. I still suggest looking into the UUID, since it would also mean being able to detect a camera that moved interfaces, or from NVR and back, or even allow talking through a proxy, where the MAC is obscured.
As of HA 2024.7.0 the UID will be used as unique identifier for both the Host (NVR/camera) and the channels (IPC camera's). At least when the UID is available, when the UID is not available it will fall back to MAC/channel index instead.
There will be a automatic migration of the unique IDs, so users will not even notice this.
I was wondering if you looked into using the cameras UUID as an identifier instead of relying only on MAC.
I ask, because I have run into two issues relying on MAC/DHCP.
1) Wifi enabled cameras, also usually have an ethernet port as well, but the integration will detect them as separate devices if both are connected. Not a big issue, but also I have one wifi camera that is never detected by DHCP (maybe because its wifi mac is in a different range.)
2) Sometimes my cameras will shift IP addresses and the integration does not pickup the change. I dont know if it just missed the DHCP broadcast or if for some reason it is ignoring the new IP. The only way I can resolve this is to either manually edit the config with the new IP or add/remove the integration.
The reason I ask is because I have a custom integration I built when I was writing my own ReoLink component, and this integration uses the broadcast UDP packets/protocol of the client app. https://github.com/xannor/ha_reolink_discovery
I am thinking of modifying this to push the equivalent of a dhcp notification to the reolink integeration, however there is a limitation of at that level, I cannot decipher if the device is IPC or non-IPC so it can push reolink devices that the integration cannot talk to. Through the protocol it is possible to discover the IP, MAC, name, and UUID of a device, though not necessarily all of that info.
UUID is nice since it is unique per device, though possibly not always present, but I believe anything that supports the remote access functionality requires one, and it is available even if the functions are disabled.