Yes, probably a good opportunity.
Are you not using the IoTaWatt's built-in InfluxDB integration? Doing so means that Hubitat is not involved with any data transfer to InfluxDB.
No, I found it just easier to inject the data through hubitat. If I need to go that route I can.
Thank you for explaining the outputs. Got it.
@ogiewon Thanks for the heads up. I am probably a couple months from pulling the trigger on this. I’ve been moving some things over to RM5 to get a feel for it but my plan is to move the rest using legacy GVs over to hub variables and that’s going to take me some time.
Definitely consider using the IoTaWatt’s built-in InfluxDB integration. It’s works great, and will even transfer data that it collects while your home network, InfluxDB server, or Hubitat hub are down for any reason. The IoTaWatt will buffer the data and transmit it to InfluxDB when it can reestablish the connection.
I'm trying to figure out why I'm losing connection to IoTaWatt. I have -66 for WiFI.
What would cause debug logging to just quit?
I'm also communicating on IoTaWatt's support page to overeasy.
Hubigraph:
Debug Logging automatically disables itself after 30 minutes. This is the same design used by all of the Hubitat built-in device drivers.
Sounds good. Thank you.
Just getting set up on this and wanted to say thanks, so great to pull it all in easily.
I realised this driver isn't on Hubitat Package Manager... Is there a reason for that or just not a priority? I've got used to the convenience of it now and takes virtually zero extra maintenance for the drivers that I maintain, plus could have done the child drivers automatically.
I can do all of the setup on your behalf if useful, but means you'd need to push a small update to my GitHub if you wanted to auto update users (literally just a version number/id change).
I have chosen to not add my code to the HPM as I do not personally use the HPM app. I am a “less is more” and KISS sort of guy. Also, most of my contributions to Hubitat are fairly mature at this point, and thus do not change frequently. I’d rather not have to keep up with maintaining them in HPM. Thank you for your understanding.
3 Likes
Yes that's true/fair, it's only new users that it helps really, but can be a nice simplification (I did the setup on my phone and it didn't like copying the raw DTH so I used the URL in the end).
It's a task that all users currently need to know how to do, but my view is that in the long term (for Hubitat to grow massive) it probably shouldn't be a requirement. I remember in ST when fairly regular updates to my code were needed because ST changed something in the background, hence was keen to use a solution that improves things, but luckily that is not the case on HE!
Thanks again for the integration (and recommendation), I'm loving the new toy and the insight it's already bringing!
1 Like
Just a heads up that I do intend to make a breaking change to the Parent IoTaWatt driver to eliminate the need for the custom child drivers now that Hubitat has built-in versions of these. See the following post for the new Parent driver. I’d love to hear your feedback on it.
Yes I swapped to the updated version when I came here to ask about HPM, seems to be working well for me, and always nice to have a shorter driver list to sort though!
1 Like
Great, thanks for the feedback. I’ll update my main repo when I get back from traveling. Since it is a breaking change, I really only recommend new users use it. It’ll require some rework for existing users.
1 Like
Just changing the type of the children right? Shouldn't take more than a few minutes really... 
All, I have released v0.1.20220103 in my GitHub repo. PLEASE KNOW THAT THIS IS A BREAKING CHANGE for existing users.
My process for upgrading from a previous version to this one was to rename the old driver, add the new driver to the hub, and then create a new Parent Device based upon this new driver. I then modified each app that had a reference to one of the old child devices, to use the newly created child devices. Once all app references were addressed, I simply removed the old Parent Device, and then deleted the old driver code.
Is there any reason for a current user to make this update?
No, there is no additional functionality whatsoever. And, I do not have any current plans to add anything new in the near future. Thus, no urgency to update for existing users.
1 Like
Feature Request: Would it be possible to do polling on a per child device instance instead of overall? Use case: Have polling of main lugs done every 3 mins but have dryer child device polled every 1 min..have water heater child device poll every 10.
The parent driver issues a single call to the IoTaWatt which returns the status of all configured inputs and calculated outputs. So, it would be a little challenging to try to split it up.
I have mine polling every 30 seconds. But I can see how that might generate a lot of events on the hub. I have this running on my “LAN” HE hub, as opposed to my Main hub that handles all Zigbee and Lutron tasks.
2 Likes
