A parent and child driver combo to integrate the IoTaWatt electrical monitoring system.
INSTALLATION
Can be installed using HPM; just search for "IoTaWatt+".
Manual installation requires the parent and child drivers. All code can be found in my GitHub repo .
SETUP
Pretty straightforward.
Install the drivers.
On the device page, enter your IP address for the IoTaWatt hub, and hit Save.
The driver will poll the IoTaWatt hub and create child devices for each input/output automatically. The device list and attributes are updated based on the set polling frequency. The names of the child devices will match whatever the input/output is named in IoTaWatt. If a device is renamed or removed, the old child device will be deleted and, if necessary, a new one will be created for the new name.
Logging is mostly handled at the child device level. They will follow the logging preferences of the parent.
There seems to be an issue with DNS resolution if you use a DNS name instead of IP address. Issue is more apparent on a C-8 over a C-7. Possibly due to differences in the network stack.
It looks like there's an API limiter on the IoTaWatt. If there are multiple instances of drivers polling it simultaneously, then it will start throwing 408 errors.
It gives all attributes for each device instead of just the primary attribute type. For example, the other will give you power for a device. This will give you power, energy use today, and current.
I'm also syncing the child device names to what is set in IoTaWatt vice setting the name to the input number.
I'm curious to check this out. How does it compare to the other one in processor and memory usage? The other integration is always at the top of my app stats.
Just more data points most likely like historical energy use, min/max power, that kind of thing. At least for now. Given that I've only had it for a few days, I'm still digging to figure out what can be done.
I'm not sure yet. I'm going to presume that this one will sip a little more since I'm pulling more data. To get the extra bits, I'm having to call three API points and parse each one. The other integration does a single call. I'll run this one in tandem with the other to compare for a bit though.
I setup my driver and the other to be able to compare usage stats. Both instances started throwing response errors. Oddly, I just rebooted the IoTaWatt and everything recovered. Since then, I have seen a few errors getting thrown intermittently. My suspicion is that if the IoTaWatt is currently responding to one API request and then gets another, it leads to the errors.
I'm not sure there's much I can do about that from the driver perspective. My advice, if you want to run multiple instances or this driver with the OG one, is to bump up the polling interval and try to stagger the installations so they aren't running updates concurrently.
I do inside the driver. This is only a problem if you setup more than one instance. Like using ogiewon's alongside this one or two instances of this one (what I do since I have both my dev and production hubs connected). The two instances aren't aware of each others scheduling, so there's no way to deconflict. Currently. There might be a way to check that I'm unaware of, but even then, it would only be between like instances (e.g., deconflict two instances of this driver only).
That is the error. I need to add some better error handling to the API calls apparently, but, essentially, the API call is getting back a blank response so the hub throws that JSON error since a NULL response is not JSON formatted
Try just rebooting your IoTaWatt and see if it clears up.
The polling frequency doesn't necessarily matter in this case. The interval is just a countdown until the next refresh runs. So, if you set the driver up at 12:00:01, the next run would be 12:01:01 (for 60 seconds) and 12:01:11 (for 70 seconds). That's all well and good, but if the updates happen to occur at the same time (every 420 seconds in this case), then you may end up with the drivers throwing a response error.
