@GeorgeB: if you look at the code of the “webserver” you can see the different keywords it uses:
ex: inputs are displayed with ip_of_iota/status?inputs=yes
outputs, frequencies, uptime,raw data, it can all be displayed 
I am also experimenting with this (due to bad wifi reception at the electricity case). I just use the main serial (the mini usb cable) to output the data. Ok, there are some status messages passing by, but EmonPi just ignores these. However it’s only running 34h like this, so no longtime experience yet.
I see it’s just the regular emonCMS API. I could work with that but it’s far from ideal.
I’m taking a wild guess here but I suspect many users will not be hooking up the full 14 channels.
Is there any way of freeing up a GPIO so I can “touch” the data?
I’m a little confused.
In any event, the API is not documented yet. It is a modification of the GET/FEED/DATA that Emoncms uses to feed the various reporting apps. The protocol is basically the same but modified to work more efficiently with the data organization on the Iota’s log file.
Probably the most complex part is determining the "feed-id"s to use in the request. That’s one of the things that is different from Emoncms. I have it on the short list to see if graph can use, or be adapted to use, the actual names assigned in the Iota config file with some pre/post notation to designate power or energy. Without getting into the exact syntax of the request, you specify:
The begin time in unixtime
The end time in unixtime
The interval desired in seconds
The feed id desired (or a json array of feed id’s)
The response is a json array (the time index) of json arrays (the feed id’s).
So if you requested:
http://iotahome.local/feed/data?start=1507840330&end=1507840340&interval=5&id=[01,12,13]
You might get:
[[120.0,204.7,3561.85],[119.9,161.7,3561.85],[120.0,175.2,3561.85]]
which is an array of three arrays at times (1507840330, …35, …40)
Each containing the voltage on channel 0, the power on channel 1, and the cummulative KWh on channel 1.
That was an actual transaction on my home IotaWatt.
The handler uses HTTP “chunking” so you can rip a lot of data without worries about buffering, but it is a little slow due to the SPI SD.
2 Likes
Looks to be suitable @overeasy do you have an ETA for the API?
Any thoughts on freeing up a GPIO or is that a none starter?
The API is there now. Id like to try to change the feedID part in the near future but might not be able to get to that. There is another API that also returns json and can be used to match input names to id’s:
http://iotahome.local/feed/list
If you have an iotawatt, try it, then try the feed/data/.
Don’t see it in this device’s future. The relief comes with a port to the ESP32, which I envision fitting in the same enclosure. Opens up a lot of opportunities. Timeframe? no idea.
2 Likes
Appologies, I thought you were after the Emoncms API docs rather than IotaWatt directly. @overeasy should be able to help. IotaWatt docs are work in progress.
I notice this is for local feeds, does IotaWatt also update emoncms.org with the same format or is it not available on emoncms.org?
Edit:
I see from the Wiki at Home · boblemaire/IoTaWatt Wiki · GitHub that IotaWatt can upload to EmonCMS.org. Does that mean data can be retrieved using the regular (ms start / stop) API?
This is an adaptation of a similar facility available on Emoncms. It has been modified to better adapt to the way IoTaWatt maintains it’s time series data. So the answer is that you can get the same data from Emoncms (assuming feeds are defined at the interval you need). Without getting into the specific syntax, the main difference is that the Emoncms API is for a single feed, and the IoTaWatt request can return multiple feeds. That means if you are interested in multiple feeds, you would need to make multiple requests of Emoncms. While that may sound burdensome, Emoncms is much faster and can service several requests in the time it takes IoTaWatt to service those requests in a single call - about 4 seconds.
We crossed in the mail on this. Yes, you can upload to Emoncms and it’s exactly the same as data uploaded using any of the OEM products. One signoificant difference though is that IoTaWatt will recover from most WiFi or internet outages and upload the data accumulated during the outage.
1 Like
@overeasy the problem we have is that the servers we use for our Smartphone app are set with a minimum of 15s between each API call. We can switch servers and drop the 15s to 1s but we would prefer to stay with the standard servers.
So this means:
- Only “whole house” monitoring on a single channel would be used.
- To obtain say voltage, realPower, apparentPower and current would take 1 minute and they would be out of “phase” with each other by 15s to 45s.
We wouldn’t want to go through port forwarding to access the local feeds and the extended API.
@glyn.hudson is it likely that the standard API for EmonCMS.org will be upgraded to cover IotaWatt in the near future?
I think we’re talking about two different things here. I understood you to be asking about the ability to query the IotaWatt for data, and then about the existence of a similar capability on Emoncms.
This appears to pertain to the communication between IotaWatt and Emoncms when uploading data.
IotaWatt uploads everything in a single transaction. In fact, it can be set to aggregate several measurement intervals and send them in a single transaction. So for instance, you can monitor all 14 channels and upload three 10 second observations of those 14 channels in a single transaction every 30 seconds.
The data can be sent securely with encryption and it is a synchronous posting so that if an acknowledgement is not received, thedata will be retried until successful.
All of the data that is uploaded to Emoncms is timestamped, so there is never an issue of data being out of phase on sending or retrieving. IotaWatt uploads an exact representation of it’s own internal log with a timestamp.
@overeasy for other OEM hardware we pull the data directly from the hardware to use in our Smartphone app. As the IotaWatt has no external interface i.e. no spare pins, then we are left with pulling the data from EmonCMS.org.
Your upload and aggregation of data to EmonCMS is fine it’s just our ability to pull down the data at 15s intervals from the server that’s the problem.
If EmonCMS used the same API as you use locally then we could pull down simultaneous data feeds, rather than “phase” shifted feeds. Phase has nothing to do with electricity in this context.
I get the context of phase here. The data is time stamped, so whether you get it in one transaction or several, it is the same data from the same time interval. Don’t know if that works for you.
Seems to me that if you could be close enough to the iotawatt to read a serial stream, you should be able to get the data through local WiFi, but you seem to have a specific idea.
Ah yes it would. Bit of extra coding as I was expecting to use “now” but providing I hold the same now value for 3 or 4 API calls it would be OK.
An ESP attached to the OEM hardware interfaces with an online server. The Smartphone app interfaces with the same online server. It appears the app is connected to the ESP but it’s not directly connected, works without all that port forwarding nonsense.
Hi Bob,
I was wondering what plans you have with regards to refactoring the code for IoTaWatt?
You mentioned that you wanted to refactor the output services and I also saw you working on the log format before.
I got a pvoutput output service working for my purposes, though one thing that was missing from the IoTaLog was a “count” of the number of samples in a given log record. There is a logHours member, which is good for obtaining power from the accumulated energy for a power channel, but I also want to report mean Voltage over the period from the voltage channel (reported up to pvoutput).
If my reading of the code is correct, to do this I want to basically divide the accum1 for the voltage channel by the count of samples accumulated in it. Is this a reasonable thing to add to the IoTaWatt log?
For now I am just reporting the current voltage from the input channel directly so it doesn’t work with historic information from the IoTaLog.
Also, in implementing the output service, I couldn’t help but see how similar all the output services are. I wonder if you have plans to make a single more generic HTTP output service that can just be configured for each use case?