RFM69Pi stops updating/freezes

[adpeace (Andrew Peace)]

@pb66

which RFM2Pi are you using? rfm69pi, rfm2pi(rfm12) or rfm2pi(rfm69)

It’s the RFM69Pi (I believe - not sure what the latter two are?)

@pb66

which version of emonhub are you using? original v1.2 or “emon-pi” v??

I"m using a modified version of the emon-pi branch. My changes are on github here: GitHub - adpeace/emonhub: emonHub is the link between your inputs and emonCMS

My changes are mostly around emonhub config handling (removing a lot of code) - the interfacers are unmodified.

@pb66

When you say you used “screen” I assume you started a serial console like minicom or similar? there can only be 2 parties involved with the serial port at any one time, minicom could block emonhub and/or vice versa. the “q” function only tells the FW whether to print the data or not, it doesn’t do anything significant enough to nudge things back to life as far as we have seen previously. so that was probably coincidental or the result of another action that was previously blocked by multiple parties on the line.

I was surprised to be able to connect to the serial console too but it definitely works - I can also connect to it and see the packets whilst emonhub is running (and still posting to emoncms) using screen as root. Screen is GNU/Screen: Screen - GNU Project - Free Software Foundation - I connected using screen /dev/ttyAMA0 38400. Maybe the two are racing to read input and so some stuff gets through to emoncms and others to screen?

However, I’m pretty sure my actions did cause the module to come back to life - it had been dead for days previously and suddenly started working. It may have been one of the other commands, admittedly - I issued other commands prior to ‘q’ thinking they hadn’t worked.

@pb66

There is specific firmware in use in this thread so that we know we are all using the same, the [RF12demo.12] label covers many releases, updates and edits, so there is no real way of knowing what you have beyond when did you buy it and how long could it have been on the shelf or had the FW installed prior to that. plus we cannot know what version compiler and/or library versions were used etc etc.

Fair enough - my issue may also be different to the others’. It doesn’t seem to happen very often and I can’t reproduce it deterministically either. It was bought last November from the OEM shop but as you say it could have anything on it. When I get more time, if there is a sketch you prefer to test with, I can flash it with that.

@pb66

When the data stops does the led on the RFM2Pi continue to flash ? (assuming it does normally flash on receipt of a packet). The issue on this thread has been narrowed to point where we can nudge the device back to life by setting the node id, group or frequency. There is a utility script for this purpose in the original thread on the old forum (link in the post at the top of this thread) but you can do it via emonhub very easily, but since emonhub will only apply changes you will need to change a setting, save the cof and then change it back to trick emonhub into resending the original setting.

Not sure about the LED. If it happens again I’ll check it.

@pb66

What sketch is the emonTx running? what is a typical packet? can you post a log excerpt?

Whatever it was shipped with, it’s a v3 device. I don’t think it’s the emontx that is problematic since in all cases restarting emonhub has fixed this.

Here’s an example packet:

OK 10 147 1 0 0 0 0 0 0 184 95 184 11 184 11 184 11 184 11 184 11 184 11 1 0 (-31)

My main interest is in helping to find/fix any issues - this isn’t in a critical installation so I’m not too worried about supporting it.