Excellent work guys. Should it work with emoncms modular version.
When I use nanodeRF_multimode_bulksend instead of nanodeRF_multimode it stops posting to my emoncms.
I followed instructions:
ENTER YOUR APIKEY ON LINE 178, AND SET WIRELESS NODE ID, GROUP AND FREQUENCY in sketch.
I was getting Notice: Undefined index: HTT on com port after CSV sent see attached so I added emoncms folder and placed modules inside it stopped above but still not working. When I go back to nanodeRF_multimode it posts again.
Attached doc shows com printout
Found blog link http://openenergymonitor.blogspot.ie/2012/11/queuing-packets-on-basestat...
Sorry didn't realise it was Beta and so new, happy to wait. Please ignore above.
Bulksend works great, I did nothing new compared to above just followed instructions, loaded latest emoncms modular and modified NanodeRF_multinode_bulksend as outlined in sketch.
I have two emonbase's (one nanodRF_multimode and one NanodeRF_multinode_bulksend) collecting from two emontx's and one emonglcd - I will leave on test for a few days and measure bandwith for direct comparison.
Thanks a mil
Great thanks Peter, very useful to hear your results, my test is going well here 3 days in. Maybe scope for improving timing code a bit as some reading seem off time.
In the context of trying to reduce 'collisions' and upload/server size, has anyone tried reducing the transmit rate of the emontx to say 15minutes ; In reality no-one needs sampling faster than that, apart from commissioning the system.
I've tried but can't seem to get it working so I'll try again.
Just think that this would help with the aim of having 'low power' nodes and also help reduce upload and server loads.
So, when I get the emontx code to tx every 15mins I'll post it .
Eamonn, Very true in the case of temperature measurement.
I've just update the bulksend example, I found I was getting some quite large gaps caused in part because it was waiting upto 20s for a reply from the server before allowing new queue formation and probably the larger cause the string format was getting messed up causing quite a lot of format errors. Im not sure why, increasing the buffer size didnt seem to help but speeding up the post rate to 15s so that the queue would not grow to more than about 5 packets and 250 or so characters did help.
I wonder if the ethercard stash feature could be used rather than the string buffer code so that we can extend the queue to a larger size, anyone familiar with the ethercard stash?
SO, I've now got 4 emontx's and two jeenodes (programmed as emontx's) sending data to an OKG programmed with the NanodeRF Multimode Bulksend, I've modified it also to dump the data to the serial port so I can monitor what's it's collecting and sending. - one of the nodes is sending light and color data, so the received string can be quite long.
I also have another 3 or 4 Jeenodes to add in.
- On all the devices I'm using the latest Jeelib library.
Two things appear to be occurring,
1) I had trouble adding a data array to collect the number of instances that a packet had been received from a node - to get this working I had to reduce the buffer to 256 else during start up it went into a continuous reboot cycle.
2) The Length of the transmit string appears to be truncated to 256 characters irrrespective of the buffer value, which means of course that the data doesn't get logged at emoncms.
It also seems to be either suffering collisions or missing data received from some of the nodes.
I've reduced the interval down to 10 seconds (from 15) and it appears at the moment to be sending more reliably.
DId anyone find a way to increase the string length?
Tweets by @Openenergymon
Open-source tools for energy monitoring and analysis. This project uses the GNU General Public Licence