I'm using the emonCMS system now for quite a while and I'm really fascinated about it. And I would like to express a big, big "thank you" to all the contributors.
Although I'm using a RaspberryPPi with the latest RFM12Pi expander board (with ATMega328) I have another one of the old version with ATTiny84 (RFM12B to Raspberry Pi expansion board v.1"), which I would like to use for some measurement and debugging purposes. As a starting point in software I wanted to use the original one, but I cannot find the source code anymore. Could you please post a link to a (hopefully still existing) old GitHub repository? I played a while around with JCW's RadioBlip and some serial examples but was not yet full ysuccessful and hope somebody still has the old sources ...
Thanks a lot in advance ...
I am trying to answer that, but the spam checker kills my replies, if they contain a link
trying to cheat the spam checker by masking the hyperlinks:
[Is this what you wanted - RW] :
Ah, yes, thanks a lot. The demo was what I wanted. The hex file I already had.
I'm shamelessly hijacking this thread to bring your attention to this issue reported with the standalone python gateway:
I think I have an easy workaround but I'd like to rootcause, and get a better understanding.
It looks like here
if(acked) showString(PSTR(" -> ack\n"));
println() adds a new line character that is not understood by python's serial.readline().
I don't know much about new line character conventions, and serial.readline() function seems limited as regards to this. Apparently, showString changes the \n into \r but readline() understands this as a new line. println must be using another character, then.
Do you have an opinion ? Do you think this is limited to RFM2Pi v1 (software serial) ?
More info in the bug report comments.
Any help/comment appreciated.
I posted on this thread yesterday, but my message must have been lost in the anti-spam filtering.
My message was totally off-topic. I wanted to bring Martin's attention to this issue I have with the standalone gateway :
It seems the println() function here uses an end-of-line character that python's serial.readline() does not interpret as such
if(acked) showString(PSTR(" -> ack\n"));
All details are in the bug report.
I have a workaround but I'd like to understand better, and rootcause the issue.
Any hint appreciated.
github -> Jerome-github/oem_gateway/issues/15
[Edit: anti-spam must have detected my hidden link. Retrying.]
'Newline' is an ongoing problem. There are only two characters involved, but many combinations. Some use <cr><lf>, some <cr>, some <lf>, some <lf><cr>, and sometimes <lf> or <cr> is converted into the other and then it acts on both. I think over the years I've seen all the possibilities. Usually however, it's either the "Windows" <cr><lf> or the "Linux" <lf> that's used, and often both are recognised correctly. http://en.wikipedia.org/wiki/Newline has the details.
I think elyobelyob's boards are running very early firmware, the node IDs that are being reported are > 31, while the latest firmware strips any extra info from the header, so it is impossible to get a nodeID reported as 47 or 52 as seen in the pastebin dump.
mySerial.print((int) rf12_hdr & 0x1F);
Anyway, it is normal to see several 'acks', after all these are not guaranteed to have reached the node that requests them, and it may end up sending a bunch before giving up.
I'm not sure this helped much :)
Thanks for answering.
I don't mind several acks: the following acks are on a new line and are already discarded. My issue is with the ack that is on the same line than the data because the data gets then judged misformed. I have an easy workaround: just add a new test for ack at the end of line, but it is a bit ugly, and I'd rather fix the newline issue correctly.
Maybe new versions don't have this problem and only elyobelyob and other users of this old version should either update their firmware, or patch the gateway with the workaround.
Not sure this is clear if you don't have all the elements in mind...
Open-source tools for energy monitoring and analysis. Forum has moved to: https://community.openenergymonitor.org