[No Longer Maintained] IoTaWatt+ [BETA]

What is this?

A parent and child driver combo to integrate the IoTaWatt electrical monitoring system.

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 .

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.

Optionally: Use in tandem with [RELEASE] Energy Cost Calculator [BETA] to calculate spending costs.


The following will be populated for all devices, if available:

  • Current power
  • Energy use for today
  • Voltage (based on the 9V reference input)
  • Current amp reading
My Other Things

[RELEASE] Energy Cost Calculator [BETA]
[RELEASE] Sensor Groups+
[RELEASE] Window Tracker

A huge thank you to @ogiewon for pioneering the IoTaWatt integration and being a huge help with supporting information.


Known Issues

  • 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.

To-do List

  • Figure out a to-do list.

Feature Requests (Not Guaranteed)

  • None.


Thank you. I'll install tomorrow and give you some feedback.

1 Like

Is this different than the existing integration in some way?

1 Like

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.


Outside of power used today, what advantages over @ogiewon's driver is there? Or what do you plan?


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.

1 Like

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.

1 Like

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.

1 Like

Thanks. I suppose I could add this to my other hub and compare as well.

1 Like

Yeah, it's in HPM.

haha I ninja edited my post. Soon as I hit reply, I went back to teh top and saw you had in in HPM :slight_smile:

I'm installing it now...

1 Like

It also brings it into the energy cost calculator which is huge for me.


1 Like

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.


Could you stagger the polling so it's not hitting at the same time?

1 Like

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).

I actually set the original one to poll every 60, and yours every 70 seconds. I'm not getting that error, but I do have some of these in my logs.

1 Like

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 :slight_smile:

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.

Ah gotcha. I'll give it a reboot and see.

I mostly just installed yours side by side to play with.

I don't really need the extra values, but I do like the input names getting synced from the Iotawatt

1 Like

Download the Hubitat app