Is there any way to get raw pulse data out of the Flukso? The curl command in the manual shows me how to get the last 16 measurements, but these are already "cooked" up and provide power consumption. What I'd like to get is simply a list of time stamps, one for each pulse, preferably with millisecond resolution. Is this possible?
Thanks,
Michi.
The API on api.flukso.net allows you to fetch the latest [timestamp, meter value]. See section 3.5 in the Fluksometer Manual. The object data field is called "lastupdate".
Work is also nearly finished on the integration of an MQTT broker (mosquitto) on the FLM. Each registered pulse will be injected into the broker.
Thanks for that! From the manual:
{"access":1310045295,"type":"electricity","function":"main","class":
"pulse","voltage":null,"current":null,"phase":null,"constant":1.0,
"enabled":1,"lastupdate":[1310045295,1006793948]}
So, I take it that the second number is the number of milliseconds since some starting time that the most recent pulse arrived? So, if a another pulse arrives exactly one second later, the second number would be
1006793948 ?
Basically, my plan is to monitor the Flukso by getting a real-time feed of whenever a pulse input triggers, with millisecond resolution. If that second number is a millisecond time stamp of the pulse, I think I'm set.
Is there any way I can do this by talking to the Flukso directly via the LAN? I'd rather not hit the Flukso server with request a 0.5 second intervals... Even better, is there a way to have the Flukso to write pulse timings to a pipe that I can read from? Ideally, I'd just open a socket to the Flukso and permanently read from that, rather than having to poll at twice the maximum pulse rate (Nyquist) to measure consumption.
Cheers,
Michi.
The first number of the array is the unix timestamp, the second one is the counter value. For electricity, this counter is in Wh.
Please don't hit api.flukso.net more frequently than once every 5mins. The FLM reports its readings at 5min intervals.
Sensor pulses will be written to a dedicated mqtt topic. You'll be able to access the broker via port 1883 and subscribe to topics. Have a look at mqtt.org for the protocol spec as well as a list of broker and client implementations.
Ah, thanks for the explanation. So, if I understand you correctly, the second number will either stay the same as the previous value or increase by 1 every time I poll, provided that I poll faster than the pulse rate?
(As an aside, mentioning what the values mean and what their units are would help make the examples in the manual more useful.)
My question came about because of the fluctuating minute readings I get form the web interface. I was thinking of graphing that myself with a bit of curl/python. But, if I can't get the data straight out of the Flukso via the LAN, doing this isn't really feasible.
A perfect way to get pulse readings for the LAN would be the following:
- Add an API call that accepts a sensor token. In the reply, the Flukso returns a port number. It waits for incoming requests on that port (say, for the next 30 seconds). If the timer fires, it stops listening on that port.
- If a connection request arrives within 30 seconds, accept the connection and write to the (TCP) socket whenever the corresponding pulse input triggers. The value written would be the number of milliseconds that have elapsed since the previous pulse (or nan for the first pulse after the connection is opened).
With this, I can write a client that asks the Flukso what port it should connect to, connect to that port, and use select() to monitor the socket. Every time some data arrives, I read the value and go on my merry way. To make things easy for clients, each request should have a byte count at the front, so I know how many bytes to read and don't have to resort to non-blocking I/O. (Or, make each record a line, so I can do non-blocking I/O and scan for the newline character.) That'll make the client a little harder to write, but has the advantage that I can just connect and do blocking reads, displaying whatever arrives and write it, say, to a terminal. (That way, would be no binary data written to the socket.)
This would make it super-easy to add monitoring via the LAN and feed that data into other tools.
Another idea: have the Flukso broadcast consumption data on the LAN via UDP. In that case, I can just write a listener that picks up the packets. Each packet would have to contain more data though, such as the sensor number and, rather than time elapsed since the previous pulse, provide a stand-alone reading because UDP packets can get lost.
For example, you could broadcast tuples that contain sensor ID, previous pulse time, and current pulse time. That would give the reader the whole story, without the need for adjusting for a meter constant.
The same thing would also work for analog inputs, suitably adjusted. For example, you could broadcast sensor ID, current instantaneous reading, and average reading over some preceding time interval (together with the interval value or size). If you want to be fancy, the API could even offer to set a different interval for different analog sensors…
Cheers,
Michi.