Accumulator Random Spikes

Hi,

I’m uploading energy data from Octopus but keep getting these random spikes in the accumulator feed:

I’ve got the historic files and have tried re-uploading a couple of time. Sometimes there are random increases sometimes random drops.

Any idea what might be causing this?

Thanks,

Chris

Select
image
Does that change things?

No difference.

@borpin Surely an accumulator should never dip like that?

Where is the accumulator? Is it accumulated data that is being downloaded, or is it hourly (or something) block totals that you are accumulating in emonCMS?

If the data is coming from historic files, what does the source data show at and either side of the time of the spike?

No, and don’t call me Shirley :rofl:

Ok so what is you system setup? select copy markdown in the admin/system page and paste here (no further formatting).

What is the source for the input and what processing are you then doing to create the Feed?

:laughing: I’ve not heard that one in a while!

Server Information

Server Information

Services

  • emonhub :- Active Running

  • emoncms_mqtt :- Active Running

  • feedwriter :- Active Running - sleep 300s 180 feed points pending write

  • service-runner :- Active Running

  • redis-server :- Active Running

  • mosquitto :- Active Running

  • emonPiLCD :- Failed loaded failed failed

  • demandshaper :- Not found or not installed

Emoncms

Server

  • CPU :- 1 Threads(s) | 4 Core(s) | 1 Sockets(s) | Cortex-A72 | 216.00MIPS |
  • OS :- Linux 5.15.76-v7l+
  • Host :- emonpi | emonpi | (192.168.2.21)
  • Date :- 2023-02-24 22:38:36 UTC
  • Uptime :- 22:38:36 up 15 days, 11:45, 0 users, load average: 0.27, 0.28, 0.27

Memory

  • RAM :- Used: 14.92%
    • Total :- 1.83 GB
    • Used :- 279.36 MB
    • Free :- 1.56 GB
  • Swap :- Used: 0.00%
    • Total :- 100 MB
    • Used :- 0 B
    • Free :- 100 MB

Disk

  • **** :- - / :- Used: 40.72%
    • Total :- 5.78 GB
    • Used :- 2.35 GB
    • Free :- 3.11 GB
    • Read Load :- 44.24 B/s
    • Write Load :- 616.26 B/s
    • Load Time :- 15 days 7 hours 28 mins
  • /boot :- Used: 19.52%
    • Total :- 254.99 MB
    • Used :- 49.79 MB
    • Free :- 205.2 MB
    • Read Load :- 0 B/s
    • Write Load :- 0 B/s
    • Load Time :- 15 days 7 hours 28 mins
  • /var/opt/emoncms :- Used: 0.59%
    • Total :- 9.61 GB
    • Used :- 57.96 MB
    • Free :- 9.06 GB
    • Read Load :- 5.98 B/s
    • Write Load :- 233.16 B/s
    • Load Time :- 15 days 7 hours 28 mins
  • /var/log :- Used: 30.83%
    • Total :- 50 MB
    • Used :- 15.41 MB
    • Free :- 34.59 MB
    • Read Load :- n/a
    • Write Load :- n/a
    • Load Time :- n/a

HTTP

  • Server :- Apache/2.4.54 (Raspbian) HTTP/1.1 CGI/1.1 80

MySQL

  • Version :- 10.5.15-MariaDB-0+deb11u1
  • Host :- 127.0.0.1 (127.0.0.1)
  • Date :- 2023-02-24 22:38:36 (UTC 00:00‌​)
  • Stats :- Uptime: 1347671 Threads: 4 Questions: 1293541 Slow queries: 0 Opens: 58 Open tables: 40 Queries per second avg: 0.959

Redis

  • Version :-
    • Redis Server :- 6.0.16
    • PHP Redis :- 6.0.0-dev
  • Host :- localhost:6379
  • Size :- 554 keys (797.67K)
  • Uptime :- 15 days

MQTT Server

  • Version :- Mosquitto 2.0.11
  • Host :- localhost:1883 (127.0.0.1)

PHP

  • Version :- 8.1.12 (Zend Version 4.1.12)
  • Run user :- User: www-data Group: www-data video Script Owner: pi
  • Modules :- apache2handler calendar Core ctype curl date dom v20031129exif FFI fileinfo filter ftp gd gettext hash iconv json libxml mbstring mosquitto v0.4.0mysqli mysqlnd vmysqlnd 8.1.12openssl pcre PDO pdo_mysql Phar posix readline redis v6.0.0-devReflection session shmop SimpleXML sockets sodium SPL standard sysvmsg sysvsem sysvshm tokenizer xml xmlreader xmlwriter xsl Zend OPcache zlib

Pi

  • Model :- Raspberry Pi 4 Model B Rev 1.5 - 2GB (Sony UK)

  • Serial num. :- 1000000070F92BBC

  • CPU Temperature :- 40.41°C

  • GPU Temperature :- N/A (to show GPU temp execute this command from the console “sudo usermod -G video www-data” )

  • emonpiRelease :- emonSD-10Nov22

  • File-system :- read-write

Client Information

Client Information

HTTP

  • Browser :- Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/110.0.5481.83 Mobile/15E148 Safari/604.1
  • Language :- en-GB,en;q=0.9

Window

  • Size :- 414 x 720

Screen

  • Resolution :- 414 x 896

Here’s the CSV data around the time.


It’s not a single wrong value, the wrong values cover at least 90 seconds each (15 s × 8). Is this the historic data? If it is, no amount of reloading will correct it, and the fault either existed in the data at the time it was recorded, or it is a failure of the recording medium.

To get any further, you need to work out the significance of the number 30340.2

I think we might have actually had a power outage that day. What I can’t understand is why the accumulator dropped and then shot back up again. It’s like the nulls are throwing it out.

Since the 3040.2 isn’t raw data, I’m hoping that I can work out how to correct it.

There is a PR, but this is a reset to zero not a ‘spike’

It’s really strange. I’ll have a play about and see if I can work round it.