No need, you already have. unless they have changed and have something new to tell us. No worries, you’ve posted them whilst I was mid post (the phone rang)
That doesn’t sound right, if/when you use the script can you also view the led? Can you confirm it gives a 1 second flash at reset? The flashes on receipt of data should be noticeably shorter.
Do you have another RFM69Pi handy if needed?
From what I recall, the issue as it was previously didn’t put the led on permanently (I would need to read the other threads to confirm) can you please try swapping the rfm69pi if you have another one handy?
It now sounds like the rfm69pi might be failing during startup, why it is restarting and subsequently failing to do so, I have no idea at this time. Tell us about your power supply, do you have an alternative (beefier) 5v dc supply you can try?
I just ran the script again whilst looking at the LED’s, it gave a one second flash, then resumed the shorter flashes.
I do have another new emonHUB setup, including the power supplies purchased with it, ill switch out the RFM69pi now for you, shall I also change power supply?
I do not have any alternative power supplies other than the ones you can buy from the shop with the emonHUB.
IMO and this is mainly unproven, the power supply to the rfm69cw (or rfm12b) may be the cause of the previously known issue (this issue may well be different though). I believe the 5vdc going into the pi which is then passed out to the rfm2pi and dropped to 3.3v, then distributed to the cpu and the rfm69cw may not be stable enough at the rfm69pi connection, I have not experienced the issue more than a handful of times in the years I have been pursuing the issue on behalf of others, so I cannot test for it myself. this maybe because I have only ever used quality 3amp psu’s with any RF based installs.
You may need to consider another psu if for no other reason than to eliminate it from suspicion IF nothing else turns up.
I do think you should try a different rfm69pi board as this issue appears to have different symptoms and is more in keeping with a handful of instances of bad rfm modules (or connections to that module) seen on emonTx’s. We haven’t seen this issue before on RFM2Pi so swapping out is a good test, it’s unlikely you will have 2 faulty boards as it is that rare.
If the fault continues, it is most likely a PSU issue (PSU itself, conn to PI, Pi itself or conn to RFM2Pi), although I cannot rule it out completely, it’s less likely to be an RF traffic/collision based issue unless the RFM module’s duty cycle is causing it to crash out (possibly still
We can eliminate a faulty PSU (but not an under powered one), faulty Pi or faulty RFM2Pi board by substitution as you have multiple units (do not swap everything out at once as that tells you nothing if it works ok).
Another thing you might want to consider is purchasing a JeeLink, it might not help much with this specific issue, but getting this far would have been easier and you could plug the JeeLink into the emonBase (Pi can supply up to 1.2a via USB so it may be more stable or a better physical connection than gpio) and temporarily point the [[RFM2Pi]] interfacer to /dev/ttyUSB0 to test.
I wouldn’t want to be without mine now, basically it is a 16MHz (faster and more stable) USB “RFM2Pi” type receiver. You can plug it into your PC and get an instant picture of whats happening “in the air” by using a serial console (eg the Arduino IDE). The power supply to it via the PC’s usb port will be more stable and it will run the same RFM2Pi sketches. It would prove invaluable to you whilst trying to set this project up and for debugging now and possibly later.
By plugging the JeeLink into a laptop you can walk around the building and see all the nodes by switching between the floors/groups (typing just 210g or 209g etc into the console) you can test for RF dead spots etc.
I’m not suggesting you need one, but IMO managing, debugging or developing for RFM networks is soooo much easier with one, if you might end up getting one down the line, might as well get it now and make use of it here.
Hi,
That JeeLink sounds great! I will get one ordered. Can you recommend a power supply?
I need to deploy asap, and in one of the forum posts you linked to earlier, someone mentioned making a watchdog. I know it’s not a fix but wondered if you happened to have something that perhaps looks for no activity, then calls your reset script you posted earlier.
Till then, ill switch out bits one by one so we can work out maybe what the cause is
The power supplies I use are “Genuine LA-530 5V 3000mA”
is where I have got them before (£10.98) but I have just spotted this significantly cheaper listing (£8.75) I might buy a couple more for the stock cupboard:-)
but as always, on fleabay “genuine” doesn’t always mean genuine but returns are really easy when the seller says “genuine” and they turn out not to be.
I got hooked on these power supplies through using an HD-PVR years ago, every conceivable issue with an an HD-PVR always boiled down to the same thing on their forums, using a different PSU than these ones supplied as standard (different plug but same manufacturer and spec).
[edit] @Paul might be able to give you some pointers on the watchdog, I have never had cause to set one up. But please do not enable it whilst we are debugging as that will hide the issue and delay finding a solution, enabling the watchdog should only occur once you’ve given up or run out of time.
I use node-red to act as a watchdog for emoncms, using a simple flow as attached below.
The flow monitors emoncms by MQTT subscribing to one of the feeds, and if it is not updated at least every 90 seconds (can be any time period), then it sends the message “Emoncms has stopped updating!” out via the delay node msg.payload.
You can attach anything that you want to the delay node, a push node, email node, twitter, Twilio etc.
I use a ‘Pushover’ node to push the message to my mobile.
[{"id":"55067d65.aaf984","type":"mqtt in","z":"7fc7e6a6.803818","name":"Watchdog","topic":"trigger","qos":"0","broker":"ed3cf937.12c308","x":90,"y":431,"wires":[["882ad1c7.0555d"]]},{"id":"882ad1c7.0555d","type":"trigger","z":"7fc7e6a6.803818","op1":"","op2":"Emoncms has stopped updating!","op1type":"nul","op2type":"str","duration":"90","extend":true,"units":"s","reset":"","name":"","x":269.8957824707031,"y":430.7777404785156,"wires":[["9cab2767.b157d8","8080a96.0362358"]]},{"id":"9cab2767.b157d8","type":"delay","z":"7fc7e6a6.803818","name":"","pauseType":"delay","timeout":"5","timeoutUnits":"seconds","rate":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":265.89581298828125,"y":473.7777404785156,"wires":[["882ad1c7.0555d"]]},{"id":"8080a96.0362358","type":"delay","z":"7fc7e6a6.803818","name":"Limit Messages","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","rateUnits":"hour","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"x":473.8957824707031,"y":429.7777404785156,"wires":[[]]},{"id":"ed3cf937.12c308","type":"mqtt-broker","z":"","broker":"192.168.1.8","port":"1883","clientid":"","usetls":false,"verifyservercert":true,"compatmode":true,"keepalive":"15","cleansession":true,"willTopic":"","willQos":"0","willRetain":null,"willPayload":"","birthTopic":"","birthQos":"0","birthRetain":null,"birthPayload":""}]
Paul
Funny you should ask…
It’s only triggered when I’ve had a low signal strength blip, and since I’ve used a ground plane, it doesn’t triggered at all.
The big change came when I updated to Raspbian Stretch, the old problem stopped completely, and I haven’t had to restart the RFM2Pi once. It’s been rock-solid since.
Paul
that’s not a bad idea on the node red watcher but at this rate, ill be getting quite a few emails as it has gone down once more with the new module on, I have the red solid light again on the RF module.
Ill swap power supplies over now, come to think of it, I have one of these kits so I will try that.
In the Raspberry PI in the above kit, I have it doing some processing of temp sensors from another setup of sensors we already had which involves connected a hub to the PI via USB, it also has a mouse and keyboard attached, anyways, when I plugged in the OOM power supply into the above PI, it went ‘mental’ as in, the keyboard didn’t work, the mouse didn’t work, and all the lights on the device I have attached to it via USB started flashing in a very unusual way… maybe the power supply is the cause, I suppose time will tell!
Yes some pointers on a watchdog that calls your script Paul would be a great help, I won’t enable till I deploy.
While I was writing this post, it restarted. The PI seemed to actually restart as when I tried to SSH to the PI right after the RF LED started to flash, it would not connect for a few moments (like when you first power on).
I think that might be worth trying but it doesn’t prove it’s not a power related issue if it doesn’t improve, if you do not have a beefier PSU to try, is there any way to reduce the load on the PSU? Are you using WiFi ? try disabling WiFi and using an Ethernet cable, try disabling some other services.
Yes I think that would be a beefier supply.
We can look at that later if all else fails, to be honest if this is a power issue, restarting is only adding to the drain and it wmay become a lucky dip if there is enough juice available when the reset is called, resulting in a rapid resetting frenzy unless you only reset once and wait the full X mins again, which might mean several laps before actually starting, this is all a bit hit or miss right now.
That also suggests power issues.
[edit] the shop sold unit is only 1.2a and the recommended minimum for a Pi3 is 2.5a although “bareboard” consumption is given as only 400ma, I do not know what the RFM2Pi draws but you are working it pretty hard and the emonSD is loaded with services so it would be understandable if the 1.2a supply was struggling a little.
sorry, I was doing the annoying thing for you of editing my post, you might be interested in what happened when I connected the OOM supply to another raspberry PI i have.
Doh! And I have just seen your last message after finishing editing my previous post.
So far so good, ill give it another day though just to be sure. It seems I need to return some power supplies…
Good too hear!
Have you tried another OEM power supply to see if it the first power supply was faulty or just under powered?
The Official Raspberry Pi 2.5 A supplies are not that expensive (compared to the OEM supply or the example I linked) maybe get a couple more of those? Might be better to stick with what you know works, I haven’t tried the 3 A PSU’s on a system with ~20 RFM nodes, I have with 32 I²C connected nodes and a spinning HDD so I would be surprised if it didn’t work ok.
Keep in mind the Official Raspberry Pi 2.5 A supply has a different USB connector then the emonPi. The Official Raspberry Pi supply has a micro USB and the emonPi has a mini USB.
I bought this converter cable to make the two work together:
Motorola micro USB Female to mini USB Male Adapter Converter (SKN6257A)
PS - there are many other choices of converter cables or adapters.
Correct. but Tom has a emonBase which uses the Pi’s micro USB direct. not via an emonPi add-on board.
My bad! I saw the pi@emonpi(ro):~$ prompt at the top of the thread and assumed wrong! 
Indeed!! One can be forgiven for thinking it is an emonpi when it actually introduces itself as an emonpi. An emonBase running an emonSD image should not really have an emonpi prompt, technically both the emonBase and emonPi are both emonbases (as was the nanodeRF predecessor) and both run emonSD so emonPi is in fact the only name that cannot be applied to both implementations…