I have 4 Aqara smart energy plugs,using the Zigbee Switch driver, which have been running with ST Energy Monitor for nearly 2 years. In parallel, I also use @TapioX 's excellent Virtual Energy Power Switch Device driver with API rules to track energy consumption by groups This lets me check the accuracy of both methods, which generally differ by only about ±3%.
Recently, the Energy Monitor started showing a -50% deviation. After investigating, I found that the Aqara plugs were no longer updating power values in the app, while my Eve and IKEA plugs continued reporting correctly.
While trying to find some logic here, using different drivers, I discovered that a new SmartThings driver called “SCU200 InSite Energy Management System” had been installed. After deleting it and switching back and forth between the standard Zigbee driver and Zigbee Thing all 4 Aqara plugs started functioning correctly again.
However, this only lasted about 24 hours, and I now see that the new driver has been reinstalled. I have no idea what this driver is, why it keeps reinstalling itself, or why my 4 Aqara plugs have now stopped functioning. Possibly this is a coincidence, but has anyone else had any issues with these outlets?
It is apparently a LAN driver for the SCU200 controller of an ABB InSite Energy Management System, whatever that might be. So it’s another of those LAN drivers that get installed on every hub, and reinstalled if they are not there, because they apparently can’t be installed on the fly like other hub drivers.
It would be handy if the search- parameters.yaml files that control whether LAN driver discovery runs could somehow be used to decide whether the LAN drivers are installed in the first place (and perhaps also added to the Add device flow).
It looks like this driver has been around for about three months so it seems unlikely to be causing the problem.
I believe the drivers have to be loaded because of the way discovery is done for LAN devices. The driver defines the search parameters for the SSDP or mDNS service discovery so without them the hub wouldn’t know what to search for. The file search-parameters.yml in the repo for each driver is where the device search is defined:
The actual device search is defined in the discovery routine of each driver. The search-parameters.yaml files are optional. Without any of those files the discovery routine of every LAN driver has to be run every time you scan for new devices.
The search-parameters.yaml files are used to do a pre-scan to see if there is anything out there that might interest the drivers. It just means discovery only needs to be run for the drivers that have device matches or don’t have that file.
It’s more useful on stock drivers as you probably wouldn’t install a community LAN driver if you don’t have the device.
I am merely speculating that if there was a way to do the same pre-scan when determining whether any LAN drivers needed installing or reinstalling there wouldn’t be so many unnecessary drivers anyway.
It may have a low cost-benefit, and there would have to be additional checks whenever you onboard a device, but those redundant drivers do seem to be at best a distraction.
Yes, looks more like due to the ‘Smartthings Drivers’ Zigbee Switch update on 6/05. Installed Mariano’s Zigbee Switch Power driver and initially all 4 outlets are reporting.
