Hi,
I’m interested in your device discovery concept. It seems you’re moving towards an auto-discovery only philosophy for nymea. Is this correct? This means it will not be possible to add devices manually via IP or MAC.
If this is correct I see some pitfalls with this strategy:
MAC address vendor lookup is used to pre-filter discovery results.
e.g. Mennekes discovery: if (networkDeviceInfo.macAddressManufacturer() != "GIGA-BYTE TECHNOLOGY CO.,LTD.")
Is it really reasonable to assume that all Mennekes Wallbox devices can be identified like this? Network adapters used in these devices might change or might even vary in already circulating devices.
There seems to be no option for adding devices manually if the pre-defined and hard coded discovery does not work. In these cases nymea can not be used at all with the device even though the integration plugin would work with the device. (e.g. Mennekes Wallbox vendor != GIGA-BYTE TECHNOLOGY CO.,LTD. because of different network adapter used by manufacturer)
Maintaining these – often hardcoded – discovery rules is a tedious job. There could be lots of issues à la “Why is my new XY wallbox not detected even though you say it is supported”. I think it is important to give these users a quick workaround in the form of manually adding a device via MAC or IP.
Looking forward to hear your opinions on the mentioned issues.
Yeah, perhaps that line could just go away. Seems like a leftover from development. Comparing the MAC address manufacturer isn’t a very reliable thing to do indeed.
The thing with IP addresses is that they will change over time. Even if the user configures all his devices manually with static IPs, this will fail eventually and has to be reconfigured manually across multiple devices with different user interfaces and logins, at latest when the wifi router is replaced. That’s a user experience we don’t consider good enough for nymea.
If on the other hand we’d allow to enter MAC addresses, which would allow to uniquely identify a device, then nymea will have to resolve the MAC to the IP at which point the discovery really should work anyways. If it doesn’t it’s considered a bug in the plugin.
I understand that it may be convenient at times during development or in test setups to quickly enter an IP to connect, but it’s not something we consider suitable for the end user. Some plugins additionally allow being set up manually but it’s somewhat hacky, again, because the IP will eventually change, so those plugins will actually resolve the IP back to a mac address and work with that again. If the discovery doesn’t work, all of that would likely not work either. This makes the manual ip parameter somewhat pointless, so we haven’t spent the effort to add that to every plugin.
Again, filtering by mac address manufacturer as the mennekes plugin currently does, is indeed not the best way, but there are ways to implement a reliable discovery which doesn’t require continuous maintenance. Dropping that line in the mennekes plugin seems good enough as the proper thing is done right below already.
A backup strategy could be that if no device is discovered, all devices found on the network are returned as a list.
Perhaps we could consider adding special filtering, e.g. DNS servers, routers are excluded or only devices with a specific port open are considered.
Thank you for your response! I agree with you that if proper discovery and reachable check is implemented your strategy should be robust in theory. Field tests will show if this holds true for all weird environments out there
When going this route, I think it would be really important to enforce a plugin to support the discovery properly. Right now the discovery process is quite different in many of the plugins. Lots of work to do but I hope we can support you by improving the plugins!
