Closed nhurman closed 2 years ago
I see this happening across all the other drivers as well, for the Kasa integration. Same change helps.
Will update on next release version.
As far as libraries, I develop my code using the Hubitat editor and then update exported drivers. Hubitat has the ability to create libraries to import. I use the libraries for functions that are common to the 9 device drivers in the series. When exported, the libraries are included in the export code with a comment to the LINE of the library code (so the developer can find an error/issue source location.
Cool! Thanks for explaining.
Context: I have a Hubitat hub, and I've been using this package (thanks!) to control a few Kasa devices. Recently, I clicked in the package manager to update the version to the latest one (probably installed this last year) and did a re-scan to add a few devices.
After those steps, I noticed the multi-plug strip stopped answering commands (on/off).
Doing some debugging, it turned out that the string "null" (the STRING, not the null value) got saved under the deviceData. This is likely a bug in the discovery app that I haven't looked at further. Probably converts null to "null" somewhere.
However, once this null string has been added, it breaks the code as the HubAction tries to send a udp packet to "\<ip address of plug>:null". The Hub's API sucks here and provides no error code/exception, but obviously the udp packet goes nowhere.
This just adds a check to the driver code to wipe & ignore the value if it's this "null" string
I have no idea what's going in this repository with all "// library marker" comments (or the Hubitat things in general, this is the first time I look at any Driver's code), the files look like the output of some preprocessing you run before committing them? Feel free to fix this yourself in the original files, and please consider committing the source files + the build system. :)