I’ve been running EmonCMS on a Raspberry Pi 3 for quite a while with few problems. This afternoon I ran a backup and full update (as I’ve done many times before) and now some of the graphs are showing what can only be described as ‘wriggles’ along the axis (looks like a massive scaling error ?) and others complete nonsense. Most of the data in the CSV fields are showing ‘null’.
The feeds are working as expected and the MQTT system is working Ok as I can see the data being captured into InfluxDB and Grafana from the MQTT broker by my programs. Not quite sure what’s going on, any suggestions please ??
What concerns me more than the graphs is that the feeds are not being logged properly and I’m losing data in the EmonCMS system !!
In order to sort this out I resorted to rebuilding the EmonPi, downloaded ‘emonSD-21Jul21.zip’, which appears to be the latest SD card image. Flashed it, ran EmonPi, updated it and imported the latest un-corrupted backup from yesterday. No difference, I still had the corrupted graphs.
I then resorted to flashing the July21 image again and imported yesterdays backup without first updating the firmware, this works fine with no corrupted graphs. Updated the firmware and I get the corrupted graphs again !! For info. I last updated the firmware on the 4th of February with no problems, so sometime in the past couple of months some sort of bug seems to have crept into the graph routines.
For now I’m now stuck with the July 21 image and cannot update it if I want the EmonPi to carry on working correctly. Not ideal, but at least I now have my data stream back up and running. Is there any way I can update the firmware to the end of February and not include the latest updates ?
Update - tried clearing the cache, and with two different browsers (Firefox and Opera), no joy I’m afraid, I still get graph errors whatever route I take to get to an up to date install.
I found an SD card image of a clean install I did on January 2nd this year. It runs just fine with todays backup so long as I don’t run a ‘Full Update’, if I do I’m back to the errors.
Just as an aside, the RPi ‘pishrink.sh’ utility works just fine with EmonPi SD card images, shrinks my 15Gb image down to 5.1Gb
** Another update ** - I rebooted and now have the corrupted graphs once more !!! Does EmonPi do any sort of automatic update when I reboot ???
I’m not sure how I can help I’m no emonCMS expert.
That would be symptomatic of a single “wild” data point somewhere on the graph. The graphs - unless you tell it differently using “min” and “max” below the graph area - are automatically scaled so that (a) one graticule suits both axes and (b) the visible points take up as much vertical scale as possible. If one point is huge (a wrong value), it will effectively compress the rest. Find the point (there might be many) and edit it and the problem should be resolved. [ Visualisation → choose Edit realtime ]
No I haven’t run out of space. Pishrink creates an SD card image that is automatically expanded when first run, just like the RaspiOS does when you install it.
A couple of examples posted. The left graphs are the corrupted ones, the right graphs are what they should look like, with a small time shift. It’s not a ‘wild’ data point as suggested by Robert.Wall as all the graphs are corrupted and most have fixed axes. The accumulated power graph is the pulse count output from our smart meter, the two graphs bear no resemblance. The shape of the corrupted one bears more resemblance to our total power consumption than the pulse count.
All of these graphs were created from the clean install of the July '21 SD card image, not from a restored image using pishrink, so there is no subtle corruption from that route.
This is our power consumption graph, which looks remarkably similar to the corrupted accumulated power graph. Maybe this is some form of indexing problem in the code that retrieves the data to create the graphs, is it written in ‘C’ ???
I’ve used this before to ‘correct’ rogue points, especially if I forget to stop EmonPi when changing the batteries in the EmonTH units as they send a series of zero values when restarted. However I have great difficulty in selecting ‘zero’ data points for editing, which is extremely frustrating !!!
If they are sending the “factory test” transmission on startup, there’s an update (emonTH V2 - sketch V3.2.6 If they aren’t emonTH V2s, it’s a simple software change) that sends this on a different group, so it shouldn’t be picked up by the emonPi. But unless you change the batteries inside a minute (and not crossing the minute boundary by Internet time), you’ll get “NULL” values in the data, which are plotted as zeros.
The CSV data shows an awful lot of ‘nulls’ compared with what is usually shown, I export the CSVs every month so am familiar with what is ‘normal’.
The zoom factor is 1 on all the graphs, that wouldn’t explain the corrupted accumulated power graph anyway as in the real world that can only increment.
I’m going to have to build a second EmonPi to further investigate this problem rather than keep killing my live feeds. Is there any problem in having two EmonPis receiving the same data from the Tx3 and TH units ? I assume the wireless data feed is unidirectional.
Only if @PaulM47 is using the RFM69 Native format - as far as I know.
The emonTx and the emonTH can clash, but as the emonTH should only be reporting every 55 s or so, and the emonTx should be reporting just under every 10 s, clashes should be quite rare.
The timebase for the feeds has not changed? The reporting interval of the sensor nodes should be slightly less than the feed timebase, so the emonTH expects a 60 s timebase and so reports about every 55 s, the emonTx expects a 10 s timebase so reports about every 9.9 s.
Is the emonhub log showing any unusual activity - has another transmitted operating on the same frequency suddenly appeared, that’s blocking reception? (Not necessarily in your house even, it could be tens of yards away.)
Ok, I’ve done a definitive test using a second Raspberry Pi 3 on a different sub-net but receiving the same wireless data, fortunately I bought a second wireless receiver a while ago. Both have the 21st July 21 SD card image programmed, the first was updated from a good backup yesterday and has been running ok since, not re-booted or updated. I exported the data from this one and imported it into the second so now both essentially were running with the same data, no corrupted graphs.
I re-booted the second with no problems. I exported the CSV data for the power used during the past day and imported it into a spreadsheet, which shows the same graph as the EmonPi. I then ran a full update, logged out and logged back in, result corrupted graphs. I then exported the CSV data again for the power used during the past day and again exported it into a spreadsheet and again it shows the same (corrupted) graph as the EmonPi.
Not sure about the corruptions I saw yesterday on re-boot, but the update certainly caused the problem. I cannot upload the CSV files as I’m restricted as a new user.
PPD1 is the first Raspberry Pi 3 that’s been running since yesterday. PPD2 & 3 are the second with the same data after import and update, PPD3 has the fixed axes set to +/- 1000 as it now has negative data
I shall export the data from the second Pi, showing the corrupted data, then re-flash the SD card and re-import the data to see if the raw data is corrupted by the update or if it’s only the graphs…
The re-imported data is not showing as corrupted and displays Ok until the latest full update is run, which is good news. It’s looking to me like extracting the data from the feeds to create the graphs is the problem.
It’s not a browser cache problem either as I’ve been very careful to clear the cache when necessary.
It sounds to me that the issue will be related to post interval vs feed interval.
If you put a tick in the box for ‘Average’ for each feed in the ‘Feeds in view’ and then click ‘Reload’ it may show the data that is present. If that works then it is an interval related issue. Perhaps some packets of data are being missed…
I do wonder if we should enable averaging by default on data shown in the graph page view as this is likely to be an issue that will trip a lot of people up, it’s got me a few times… The downside is that it does present a slight performance hit as you zoom out to very long time ranges
Taking a sideways off-topic look… What would be the price of a separate but related database of (say) hourly or daily (or both) averages, automatically created, and automatically used for the graphs as appropriate?
For the 10 s feed, an hourly database represents a 360× speed-up, so you’d use that when the graph spanned more than a month or so.
