Archived Forum

David,

you probably have the old firmware, the one before the locking was implemented. Are you comfortable with re-programming an Attiny84? Nathan Chantrell has pretty good instructions on doing that with an Arduino (in case you don't own an ISP programmer) http://nathan.chantrell.net/20120225/an-attiny-based-wireless-temperature-sensor/

There is a pre-compiled .hex file on github with the firmware 

https://github.com/mharizanov/RFM2Pi/tree/master/firmware/Pre_compiled_A...

If you feel that is too hard to do, you can return the Attiny84 to whoever you purchased the board from (I believe Trystan/Glyn won't mind if you got the board from the openenergy shop) for a replacement.

The v2 of the board allows pretty easy firmware upload without the need of programmer, just fyi

Just in case it wouldn't be clear, Martin is advising you to update to latest firmware version but I'm pretty sure it should work with yours, anyway, shouldn't it, Martin ?

I don't know what's wrong, perhaps can you try to debug that adding print statements in the php script.

When logged in to emoncms, enter this in your URL bar :

http://your_path/emoncms/raspberrypi/get.json

to check correct settings are entered in database.

Thank you Martin for your response.

I shall look into either trying to use an emontx with Nathan Chantrell's instructions, or buy an ISP programmer, to update the firmware. The problem that I am having seems directly related to EmonCMS v5, as the RFM12Pi board worked fine in the Raspberry Pi with EmonCMS v4 (prior to the SDCard dying). Whilst locking in the data on the RFM12Pi board is a work-around; it will be nice if EmonCMS were to actually tell it that information on boot-up; unless I am missing something here.

David

Thank you Jérôme and mharizanov for your responses.

I embarrassingly have to report that it was due to finger trouble on my part. I had entered 211 instead of 221 as the network group and, despite checking it several times, it took a few more observations for me to notice.

I finally spotted it whilst working through my initial response to Jérôme's posting, and after replying to mharizanov. suggestions (which I may still take up, though later as I can now concentrate on restoring the rest of the EmonCMS v5 to that in my previous v4 system; then make an image of the SDCard and put in place a better data back-up regime.

Please accept my apologies for the posting of a false error report.

David

Whilst locking in the data on the RFM12Pi board is a work-around; it will be nice if EmonCMS were to actually tell it that information on boot-up; unless I am missing something here.

If you're suggesting that the locking order (123) should be sent on startup after radio setup, there is an objection : the emoncms GUI allows for radio setup anytime. I admit that I can't think of real life use cases where you would need to reconfigure on a regular basis, but since this is offered by the GUI, it needs to be addressed, so we don't want the settings locked.

We could think of workarounds :

- Send 123 before and after changing a config item ? But what if on of the 123 commands is garbled ? We're in a stuck state where we lock when we want to unlock, etc. Unless we parse the help message to see in which state we're in.

- Add a workaroud button to send the 123 command manually ? Why not, a bit ugly but why not ? Then we may want to add a status led widget telling whether the config is locked. This means parsing the answer to the help message.

If think the unsaid position here may be "since the bug is gone in new HW rev, why bother ? Owners of older HW could use minicom as a workaround. Besides, as far as we know, this only affects people using the send time for send time emonGLCD feature."