Worth taking a backup of the system as well.
To add to @borpin’s reply, could you copy and paste here the result of trying to restart emonhub via SSH?
sudo systemctl restart emonhub
sudo systemctl status emonhub
This is the thread @borpin was referring too that both Glyn and I had suffered a potentially similar issue after a power cut: Backup module usb-import.sh script (beta) - #9 by TrystanLea
1st cousin of was is? 
1 Like
1 Like
The outage was in the entire town area where we live, possibly due to a cable failure, so there may very well have been a power surge. Our fuse cabinet has a surge protection for our entire house grid, but the emonpi is just connected to an ordinary power outlet, together with two iotawatts and thus three reference voltage adaptors.
I’ll see if I can play with this tonight or tomorrow. Thanks for quick responses.
You like those little smilies, dontcha? 
I’m glad to see someone’s gettin’ some milage out of them! 
1 Like
It sounds like you have multiple node [[5]] entries. The reason it is failing to restart is that once running if an error is made to the config emonhub will log the error but continue to run on the previous settings, when starting from afresh it doesn’t have that option. You possibly edited emonhub.conf sometime in the past and not noticed that the new settings were not loaded.
Either commenting out that section (as suggested above) or simply changing one of the [[5]] entries to an unused number should prove if this is the case or not.
1 Like
From day 1 for this emonpi I added two emonTH units, then after a few months I added two IotaWatts. This configuration was running until last week, when I replaced the microSD with a brand new, faster one (and larger). During the card replacement, I first took a backup then flashed the new card with emonSD Oct19, and uploaded the backup. I have never knowingly edited the emonhub.conf file, and the new setup ran just fine for a few days until the outage yesterday.
Anyway, I’ll try commenting the section and see what happens.
EDIT: Ok, so I think you are into something here. There was an incident where I messed up the feed setup in the emonpi gui after using the restore backup process on the new card. And I thought I fixed it then. But looking into emonhub.conf now I see that multiple nodes have two entries, starting with [[5]] on line 243. Nodes 5 to 14 suddenly has appeared twice, and with less info in the first entry, example from 2019-12-21:
[[5]]
nodename = emonpi
[[[rx]]]
names = power1,power2,power1pluspower2,vrms,t1,t2,t3,t4,t5,t6,pulsecount
datacodes = h, h, h, h, h, h, h, h, h, h, L
scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units = W,W,W,V,C,C,C,C,C,C,p
[[5]]
nodename = emonPi
firmware = emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino
hardware = emonpi
[[[rx]]]
names = power1,power2,power1_plus_power2,Vrms,T1,T2,T3,T4,T5,T6,pulseCount
datacodes = h, h, h, h, h, h, h, h, h, h, L
scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units = W,W,W,V,C,C,C,C,C,C,p
Looking at my backup from 2019-12-16 (from the old SD card), this was not the case.
Conclusion now is that I need to tidy up the conf file. Which one of the [[5]] entries above look correct?
By the way, I never noticed that bright red LED inside the emonpi case before. That may be because I have never looked, or because some warning LED was switched on. I think it is on the main RPI board, and I can see it through the small gaps around the USBs. Do you know if this red LED is normal?
I removed all duplicate entries in the emonhub.conf file, and now it is up and running again - sort of.
The nodes defined in the conf file seem ok, but the two iotawatt nodes are not. One of them are still Inactive, the other one has status “n/a” on the 18 inputs channels, but 18 new channels (withouth defined feeds) have appeared. And I don’t see the iotawatts appear in the emonhub.conf file at all, not in the old (where everything worked) nor in the new one.
Any suggestions, please?
[Content deleted - not relevant to the topic.]
Since the iotawatt sends directly to emoncms, emonhub plays no part.
Unless of course you are running something non-standard.
1 Like
Delete the new Inputs without the processes. This happens sometimes. No one has been able to work out why.
As Paul said, IoTaWatt does not use emonhub but uses the HTTP API to send the data. Are their configurations OK after the power outage?
[edit] IIRC there was something else recently about IoTaWatt and data input not being restored correctly - have a search on the forum.
That’s what I thought, too. It has worked very well on my previous emoncms setup on a self-configured RPI. Now I have had another issue with the feeds on this emonpi (see this thread and this), so I ended up with deleting all the iotawatt feeds altogether and have now rebuilt them. Since the iotawatts hold all historic data, that should work just fine. The feeds will take some hours to rebuild, but I see that some data are starting to appear now, so things seem to work out.
2 Likes
This just happened to me. We was a brief outage, I realised when I saw all of my graphing was down, when I logged into my terminal server in my garage the uptime was only a few minutes. I was able to edit the emonhub config to remove the duplicate nodes and restart the service which got everything running again. Very weird. Could anyone recommend some sort of mini UPS to power the emonpi for less than a minute to prevent this some happening again? I expect this is rare as my electricity is usually reliable but it would be useful to have it. I will sort out a surge protection myself.
Can the VMS plug connected to the emonpi run properly behind a surge protection plug?
Raspberry pi are pretty bad when it comes to power failures. They can fail to come back at all, or come back with some services running and others not etc etc. They’re not like ‘proper’ computers in this regard.
My solution has been to buy an Adafruit PowerBoost unit and a battery. I’m still testing and they appear to work but I haven’t installed them live yet. Be warned though that I destroyed one Pi 3B+ just by connecting a wire from the LBO terminal to a GPIO pin. You MUST put a diode in the line. I have a simple python script that watches the LBO line and shuts down the pi safely when the line indicates that the battery is running out of power. That part seems to work OK.
I have to be honest and say I have never had a Pi not come back up on power cycle. Power surge is a different matter. The only exception was when the SD Card was failing anyway. I’ve had RPis since the first pre-order of the A from RS Components opened. The only failures have been caused by excessive writes to the card.
That’s been my experience as well. My first Pi was purchased in August of 2012 and is still going
strong, although not on the same SD card that I put in it when I first got it. But the card that’s in it now has been in place for almost five years, and the power in rural Oklahoma where I live, is anything but reliable.
We live at the southern end of Tornado Alley. Along with the convective/mesocyclonic weather,
we get a healthy dose of electrical activity. It wouldn’t be a stretch to say the power here is flaky.
1 Like
You’ve been very lucky then. Mind that I am talking about power failures specifically, not power cycling by means of a switch or even pulling the plug. Power failures can result in much more complex waveforms.
It sounds like Bill has been extremely lucky.
I have asked Raspberry engineers on their forum and they’ve confirmed the vulnerability.