Hey,
I was able to activate snmp on the meter.
And now, i can nicely monitor the up time, bandwidth usuage of the interfaces, the device usuage...
Do you've got an idea how i can read the values for the power reading?
Do you guys know what OID i can use to have a reading?
...
ps i'm also writing a kind of manual to do this. So once i've managed to sort out the 'power use' statistics, i'll complete it for sharing...
What you have been able to read out are standard oid's. In order to read out power reading they would need to define oid's for those and implement some code to make it work. I'm assuming the latter part is not done.
I was afraid that it was something like this...
Does anybody knows where to find the proper data? Maybe we can create the OID ourself? I don't know how much work this is (or what skills you need to have)...
I think we need to know what value we need to read?
I personally think this would be a very big positive step forward.
I can image that firms that run their own monitoring tools (HP OV, nagios, cacti...) would be more interesting to insert this into their tools, then to use a third-party tool...
i'm not sure which snmpd is running on the openwrt
but normally these linux snmpd deamons can just execute any cli command and export it ...
the commands that can be expected on a v1 flukso should be these:
https://gist.github.com/icarus75/flukso/tree/develop/mote/v1/openwrt/pac...
so executing restful.lua should give you some data???
http://glr81.free.fr/pages/openwrt-snmp-oid.htm might also be interesting to have a look at.
hmmm,
Seems very intresting that site. If i've got it wright, i only need to add a kind of command in their that checks the (electricity) value...
Anybody an idea where i can get that?
Can i check that with restful.lua you think?
I'll try to check some things this evening, i don't have access for the moment to the meter... :$
The Fluksometer v1 contains 'experimental' support for real-time monitoring of the current clamp ports. This feature was only gradually introduced in the sensor board, so your mileage may vary.
You could install the latest Flukso v1 package, which will write the last minute of measurements in second resolution into the /tmp/sensor directory. The format of the file is an array containing [timestamp, value] pairs in JSON format. Very similar to the format described in this blog post.
An even more direct way of trying this out is to:
1/ Rename the /usr/share/lua/flukso/flukso.lua file (just in case...).
2/ Download the flukso.lua and flukso.uci files from the Github repo to your computer.
3/ Copy the files to the Fluksometer v1:
4/ Edit the flukso uci file and set the localEnable parameter to 1:
5/ Restart the flukso daemon
There is no need to use the restful.lua script, which basically reads out this file and pumps it into an HTTP response.
HTH,
Bart.
Hey,
just tried the 'direct way'...
When i start the flukso daemon with the new flukso.lua, it won't start. When i copy the old one back (thank god for the copy ;) ), it runs fine again.
Possible that i need something else?
In the config, you put /tmp/sensor. Isn't this folder erased once you reboot? :$
Hmmmm... Can you try to run flukso.lua directly by:
and report back on the error generated by the Lua VM?
Hey,
No prob, this is:
./flukso.lua: line 6: syntax error: newline unexpectedThe new flukso.lua starts with
<!DOCTYPE html>Where the old one starts with
#!/usr/bin/env luaIs this correct? :$
Isn't there a linux command that can be used to read the value of the power realtime?
Could be enough for that what i'm trying to do...
I have updated the instructions to show how to get the files in raw format, not the HTML encoded ones. Download both flukso.lua and flukso.uci like this (or just browse to the URLs and save the page). This should fix the error.
Cheers,
Bart.
Yep,
Now it's runs without an error.
But the folder /tmp/sensor stays empty. :$
ps the option localEnable was already 1... Any thoughts?
This would mean your sensor board firmware doesn't support reporting power measurements. Can you stop the flukso daemon once again, then
and dump a short output in this forum thread.
Hey,
De output (ziet er goed uit).
Is dit de echte stroomwaarde? Anders heb ik er waarschijnlijk genoeg met.. :$
Wat is het verschil tussen pls en pwr?
Cool,
If you want to read the value of your sensor (in my example with the 'id' 285afa070a3fd4a5f2a69f55e0b8007c), you can give following command on the console:
cat /dev/ttyS0 | sed -n 's/^pwr 285afa070a3fd4a5f2a69f55e0b8007c:\(0*\)\(.*\)/\2/p'Okay,
Finally had the time to dig into this a bit deeper. Today, I'm able to read the values with my own snmp monitoring system. Jieppieeee....
For an example: http://cacti.oniria.be. You can login with flukso / flks.
You can see the standards views of the flukso meter (like load, network...) and of course the graph 'powerconsumption'. I'm not sure if i'll keep it open like this, but in the time being... Send me a pm if you want to have more view rights in cacti...
What i've done? http://www.oniria.be/pri/index.php/linux/724-flukso-monitoring-met-cacti....
Sorry, in dutch, if you ask nicely, i'll have a look to put it in english... ;)
The only problem i've got is that the flukso meter is rebooting from time to time. I'm not sure if this is normal behaviour, or if it's with the changes. I'm not a developer, so i'm sure that it can be done better. But at least, i've got the values now also locally. And with my standard method (snmp read) of getting information of my devices. I love standards, they make your life so much easier... ;)
Hi Ben,
Nice work! The rebooting could be triggered by the 15min cron job monitoring the presence of the flukso process.
Speaking of standards, there's now an IETF working group drafting an energy management MIB, see [1] and [2].
[1]: http://133.40.3.100/wg/eman
[2]: http://www.ietf.org/proceedings/80/slides/eman-10.pdf
Cheers,
-Bart.
Yep, i was also thinking about this...
But it's something weird.
Sometimes he reboots, sometime only a few snmp services aren't available...
So it seems that he can carry the complete load? Maybe i need to play around a bit with some timeouts...