I think the graphing features of the IoTaWatt are wonderful. I even wish there were a way to feed other data, such as temperature, into the graphs, so I could combine energy use with temperature on the same screen. The graphing is awesome!
Since I can’t feed my own temperature data into the IoTaWatt graphs, I have to get the energy data out, and I already have my own graphing infrastructure in place (using data from sensors connected via Hubitat), so don’t want to install any of the three systems that IoTaWatt talks to.
Yes, I will look into the query API. I was hoping to avoid polling.
Since all I want to do is have the data pushed to me where I can save it in a file, installing any of those Data Uploader programs and their multiple dependent packages that I will never use really is “bloat” for my purposes. All I want is the data; I don’t need their databases.
IoTaWatt almost has the functionality I need using its Data Uploader facility. It already keeps a queue of what data hasn’t been uploaded when the other site is down; polling does not (unless I write the recovery logic into my polling program).
My problem is, the three services IoTaWatt knows how to upload to aren’t familiar to me and it will be work to figure out some specific protocol so that I can write a little script to mimic the service and log the records written.
The IoTaWatt could have the exact functionality I need if it had a simple Data Uploader service that wasn’t tied to a specific protocol.
The Hubitat hub Maker API URL made it easy to upload data. Given a URL, it would simply POST the JSON records to that URL and my two-line CGI script at the other end would append them to a file. Easy!
I wish that I could specify just the interval and the inputs to be sent and IoTaWatt would POST the data to the URL I supplied, just as Maker API can do. Absent that, I’ll eventually get around to figuring out and decoding one of the other three protocols.
(And if IoTaWatt had a websocket interface that I could listen on to get the same interval data, it would be much more efficient than incurring the overhead of thousands and thousands of separate HTTP Data Uploader connections, though perhaps the ability of IoTaWatt to queue data when the remote site is down would be harder to do.)