Hi Guys,… just wondering if it was getting the point where the world stops…
Well for some reason,… my emonPi stopped logging ‘its own gathered data’,… last Thursday 21st at 4:41am,… it just stopped.
Data from the emontx v4 continued to be logged,… as this communicates via the usb port,… however the emonTh temperature probes also lost the comms and logging ability.
Initially, when trying to fix my lack of house supply power graphs in HA,… I just did a simple reboot of the emonPi,… when this did not fix things I recalled previous chats where only a physical power down will get the board to ‘reinitialise’,… this I duly did,… and thankfully normal service has now been resumed.
I summary, emonCMS logging continued to work fine,… ( as data from Emontx4 was been logged ), its just data received via the emonPi addon board that suffered loss, CTs and RF received data.
I ask the collective ‘OpenEnergy community’,… anyone else has any similiar events/trouble with Pi addon board… as loosing data,… is the pits. 
I am running 11.3.22 CMS core,… Looking at past threads,… there are Pi issues but none directly associated with the addon board,… Any thoughts comments welcome,…
Many tx to the team
I have a similar problem as well - see:
My emonPi receives data over USB from a Jeelink USB module, from an emonTx3 and some emonTxShields (all using the Jeelink format radio data).
The emonPi also receives receives measurement data from the atmega328 add-on board - e.g. Vrms and temperature measurements, and LPL format radio data from an emonTx4 via the on-board RFM69.
The emonPi regularly stops recording emonTx4 data from the RFM69, although the measurement data from the atmega328 often continues, so the atmega328 is still working.
I also have an emonBase unit which shows that the transmitted emonTx4 data is not dropping out. The emonBase is next to the emonPi so I don’t think it’s a signal strength issue.
When the emonTx4 data is lost, it disappears from the emonHub log.
At first I thought the the RFM69 was failing, but the problem can be fixed by restarting the emonHub, or halting the emonPi, and turning the power off and back on.
Any thoughts?
Is it possible that the USB data is colliding with the serial data from the atmega328 and upsetting things, perhaps in emonHub?
The issue continues,…
Just realised my emonpi logging stopped nearly 3 days ago @22:29…
I have copied the dmesg and syslog data from around that time window,… if anyone is able to share any inspiration as to why the Addon board is dropping out…
Following a full power down, and back up,… logging resumes as expected…
curious as well,… why do all the undervoltage, voltage normalised , power save enabled, logs appear,… dmesg is full of them
[Fri Oct 6 23:00:19 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:05:20 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:05:54 2023] hwmon hwmon1: Undervoltage detected!
[Fri Oct 6 23:05:58 2023] hwmon hwmon1: Voltage normalised
[Fri Oct 6 23:06:52 2023] hwmon hwmon1: Undervoltage detected!
[Fri Oct 6 23:06:57 2023] hwmon hwmon1: Voltage normalised
[Fri Oct 6 23:10:20 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:15:20 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:15:37 2023] hwmon hwmon1: Undervoltage detected!
[Fri Oct 6 23:15:43 2023] hwmon hwmon1: Voltage normalised
[Fri Oct 6 23:15:59 2023] hwmon hwmon1: Undervoltage detected!
[Fri Oct 6 23:16:06 2023] hwmon hwmon1: Voltage normalised
[Fri Oct 6 23:17:16 2023] hwmon hwmon1: Undervoltage detected!
[Fri Oct 6 23:17:21 2023] hwmon hwmon1: Voltage normalised
[Fri Oct 6 23:20:19 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:25:20 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:30:20 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:35:19 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:40:20 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:45:20 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[Fri Oct 6 23:50:19 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
whilst the syslog data looks as follows
Oct 7 22:20:27 emonpi rngd[520]: stats: Entropy starvations: 0
Oct 7 22:20:27 emonpi rngd[520]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Oct 7 22:25:01 emonpi CRON[11564]: (root) CMD (/usr/local/bin/wifi-check > /var/log/emoncms/wificheck.log 2>&1)
Oct 7 22:25:06 emonpi kernel: [1231502.879424] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Oct 7 22:30:01 emonpi CRON[11584]: (root) CMD (/usr/local/bin/wifi-check > /var/log/emoncms/wificheck.log 2>&1)
Oct 7 22:30:07 emonpi kernel: [1231803.567160] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Oct 7 22:35:01 emonpi CRON[11606]: (root) CMD (/usr/local/bin/wifi-check > /var/log/emoncms/wificheck.log 2>&1)
Oct 7 22:35:07 emonpi kernel: [1232103.248006] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
Oct 7 22:39:01 emonpi CRON[11626]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Oct 7 22:39:01 emonpi systemd[1]: Starting Clean php session files...
Oct 7 22:39:01 emonpi systemd[1]: phpsessionclean.service: Succeeded.
Hello @diyhouse
My guess here is that something may be causing the radio module on the emonPi to lock out. The full power down fully resets the RFM69 registers which does not happen if you just try restarting emonhub. I assume the full power cycle, power pulled out for a few seconds? is required?
What is the power supply that you are using with the emonPi? I wonder if that’s causing it to get into this corrupted state?
This is the type of module I use to supply the 5v,… they’re good for 5v at 3amp ( with heat sink etc, albeit not continuous, ),… but for the Pi in run mode is around 500mA to an 1Amp, so well within range,… the input is 12v,… so plenty of slack for the smps to regulate in…
I could add some more decoupling,… I’ve got a range of electrolytic caps lying around…
power pulled out for a few seconds? is required?
Controlled Shutdown,… followed by pull power plug out,… count to 10,… and power back on is the procedure I use…
Tx Tryston,… just some more for the ‘pot’,… just checked power supply and it seems to be delivering approx 5.1v,… and with my DC current clamp,… ( so not the world most accurate, but certainly a good indicator ),. current is in the order of 300mA,. and that’s with the Tx4 plugged in the USB as well.
On inspection on the power source it seems I took the precaution of adding extra decoupling I think around 1000uf, ( not sure on exact value as not visible as it is mounted. )
My only concern about my ‘supply’ is the actual lead itself,… which only seems to have small ‘lower power’ connecting wires,… and at probably 1m long may make to pi susceptible to power spikes.
If I shorten this power cable,… is this worth a punt,… as a next steps…
Many tx
mark
If there are current spikes (i.e. short, milliseconds or the low tens of), some reservoir capacitance at the load end of the cable should help. But it won’t be much use for prolonged periods of high current.
The minimum operating voltage of your Pi is 4.8 V, so you have 0.3 V to play with. At 300 mA, this is 1 Ω loop resistance, or 0.5 Ω per core.
Not wishing to side track anything here … but
My logging problems may have a different cause to @diyhouse , but going to
Setup / Emonhub /
and clicking the orange ‘Restart’ button at the top right of the page seems a reliable (!) way of getting all my logging going again after a stoppage. No full power cycle is necessary.
I am assuming that this means I have an EmonHub problem … perhaps …
Ok,… So modified my power supply lead,… (The old one was over a Metre in length)
I now have a much short Power lead,…
And I can confirm the Electrolytic capacitor is 2200uf…
we’ll see how this pans out over the coming weeks
Just a quick update,…
…have powered down my EmonPi today,… (re-jig of power source supply), and as the system was shutdown,… ‘uptime’ should just over 24.5 days on the clock,… and the add on board was still performing/working fine.
So looking hopeful…
Hi guys,… my unit appears to be logging correctly now,. however two weeks ago I inspected the emonPi to see how it was ‘getting along’,… to see that although it was working ( logging etc. ), the push button was not been responded to,… ie the display backlight did not come on, and the display info, did not change, so I infer the button press is not being registered or recognised by the system,…
I duly powered down the system,… ( pulled power plug ),. and restarted,… and normal service was resumed on powerup,… button presses were being actioned and display updated accordingly.
today;-
Just checked emonPi this morning,… and same fault has occurred,… button presses not being recognised…
Any Thoughts?? from the authoritative knowledge gurus,…
Many Tx
just an update here,… after another 20days ( or so ) of uptime,… my display fails to activate when the button is pressed,… and the display contents do not change… ( when you look closely at the display with an external light source ). Logging still continues though.
A full power down ( plug out ) and power on, normal service is resumed,…
regards
After further troubles with this board I contacted ‘the boys’, directly… and spoke with Glyn,. who said he had heard of this issue before…
He suggested I ‘reseat’ the daughter control monitoring board’, as it was probably due to a bad connection on the 40pin Pi connector.
This I duly did,… disassembling the boards,… lubricating pins with a little WD40,…
An since this action,… Unit appears to be operating without further issue…
Tx Glyn for the suggestion and help.