Direct USB Ardiuno not showing in graphs or database

I downloaded the ISO from git and installed using etcher "emonSD-30Oct18.img

dont know what low-write version means.

First things first, why does your Pi thing it’s Oct 2018?

This is most likely why your data is not showing. You are collecting data for April 2019 but when the data is saved it will have a Oct 2018 timestamp.Try scrolling back in the graph window or zooming out to 1year to try and see if there is any data being shown for a different time.

If the time has always been wrong, you might find the current data being saved back in Oct, but if the clock has recently gone back for some reason, your data will now be getting discarded as you cannot write data older than the laterset datapoint eg if you posted data correctly with the right timestamp last month, then posting data now with an oct 2018 timestamp will not stick.

Do you have an external network connection? Can the Pi reach the internet to update the clock?

Can you try manually updating the clock? (I think there is a how-to in the guide section of the site [edit -there is at Troubleshooting - Guide | OpenEnergyMonitor]).

Next, I’m confused by the version saying 9.9.8 at the top but v9.5.1 in the “describe”

Can you please post the full server info? Not a picture of part of it, use the download server information button and just paste it to your forum post.

So i found my little squiggly line of joy sitting in October :slight_smile:
Ill have to check up on how to change the system time, i am currently on the same network as the device is and i personally dont have an issue. so i will read up on how to ammend the time

Attached is the “copy server information to clipboard”

Server Information
emonhub Active Running
emoncms_mqtt Active Running
feedwriter Active Running - sleep 60s
service-runner Active Running
emonPiLCD Active Exited
redis-server Active Running
mosquitto Active Running
Emoncms Version low-write 9.9.8
Modules Administration : App v1.2.1 : Backup v1.1.6 : EmonHub Config v1.1.0 : Dashboard v1.3.3 : Device v1.2.1 : EventProcesses : Feed : Graph v1.2.3 : Input : Postprocess v1.0.0 : CoreProcess : Schedule : Network Setup v1.0.0 : sync : Time : User : Visualisation : WiFi v1.3.1
Git URL: GitHub - emoncms/emoncms: Web-app for processing, logging and visualising energy, temperature and other environmental data : Branch: * stable : Describe: v9.5.1-1775-gd0db7a57
Server OS Linux 4.14.71-v7+
Host emonpi : emonpi : (
Date 2018-10-30 20:34:53 UTC
Uptime 20:34:53 up 3:25, 0 users, load average: 0.09, 0.11, 0.07
HTTP Server Apache/2.4.25 (Raspbian) HTTP/1.1 CGI/1.1 80
MySQL Version 5.5.5-10.1.23-MariaDB-9+deb9u1
Host (
Date 2018-10-30 20:34:52 (UTC 00:00‌​)
Stats Uptime: 12296 Threads: 3 Questions: 11324 Slow queries: 0 Opens: 27 Flush tables: 1 Open tables: 21 Queries per second avg: 0.920
Redis Version 3.2.6
Host localhost:6379 (
Uptime 0 days
MQTT Server Version Mosquitto 1.4.10
Host localhost:1883 (
Pi Model Raspberry Pi 3 Model B Rev 1.2 - 1 GB (Sony UK)
SoC Broadcom BCM2835
Serial num. B9EB44FB
Temperature CPU: 44.01°C - GPU: 44.0’C
Release emonSD-30Oct18
Memory RAM Used: 15.35% Total: 976.74 MB Used: 149.9 MB Free: 826.84 MB
Swap Used: 0.00% Total: 100 MB Used: 0 B Free: 100 MB
Disk Mount Stats
/ Used: 39.95% Total: 3.81 GB Used: 1.52 GB Free: 2.11 GB
/home/pi/data Used: 3.44% Total: 3.21 GB Used: 112.81 MB Free: 2.93 GB
/boot Used: 51.69% Total: 42.52 MB Used: 21.98 MB Free: 20.54 MB
PHP Version 7.0.30-0+deb9u1 (Zend Version 3.0.0)
Modules apache2handler : calendar v7.0.30-0+deb9u1 : Core v7.0.30-0+deb9u1 : ctype v7.0.30-0+deb9u1 : curl v7.0.30-0+deb9u1 : date v7.0.30-0+deb9u1 : dom v20031129 : exif v7.0.30-0+deb9u1 : fileinfo v1.0.5 : filter v7.0.30-0+deb9u1 : ftp v7.0.30-0+deb9u1 : gd v7.0.30-0+deb9u1 : gettext v7.0.30-0+deb9u1 : hash v1.0 : iconv v7.0.30-0+deb9u1 : igbinary v2.0.1 : json v1.4.0 : libxml v7.0.30-0+deb9u1 : mbstring v7.0.30-0+deb9u1 : mcrypt v7.0.30-0+deb9u1 : mosquitto v0.4.0 : mysqli v7.0.30-0+deb9u1 : mysqlnd vmysqlnd 5.0.12-dev - 20150407 - $Id: b5c5906d452ec590732a93b051f3827e02749b83 $ : openssl v7.0.30-0+deb9u1 : pcre v7.0.30-0+deb9u1 : PDO v7.0.30-0+deb9u1 : pdo_mysql v7.0.30-0+deb9u1 : Phar v2.0.2 : posix v7.0.30-0+deb9u1 : readline v7.0.30-0+deb9u1 : redis v4.1.1 : Reflection v7.0.30-0+deb9u1 : session v7.0.30-0+deb9u1 : shmop v7.0.30-0+deb9u1 : SimpleXML v7.0.30-0+deb9u1 : sockets v7.0.30-0+deb9u1 : SPL v7.0.30-0+deb9u1 : standard v7.0.30-0+deb9u1 : sysvmsg v7.0.30-0+deb9u1 : sysvsem v7.0.30-0+deb9u1 : sysvshm v7.0.30-0+deb9u1 : tokenizer v7.0.30-0+deb9u1 : wddx v7.0.30-0+deb9u1 : xml v7.0.30-0+deb9u1 : xmlreader v7.0.30-0+deb9u1 : xmlwriter v7.0.30-0+deb9u1 : xsl v7.0.30-0+deb9u1 : Zend OPcache v7.0.30-0+deb9u1 : zlib v7.0.30-0+deb9u1
Client Information
HTTP Browser Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
Screen Resolution 1366 x 768
Window Size 1349 x 576

It’s bizarre that it thinks it is 30 Oct 2018 as that is the date the image was built. So the question is has it ever had the correct time? Has it suddenly dropped back to that date? or is it like groundhog day and always 30th Oct 2018?

Does the Pi have access to the Internet at all? If not, then it wont ever update its time. There is a fake hardware clock used by default, which saves the current time to the filesystem on shutdown and then reads that time on boot up (instead of booting up with the time set to epoch), but if you never get to the Internet the time service cannot update the time with the correct time.

You can manually set the date/time using (modify to the current UTC date/time):
sudo date --utc --set "2 April 2019 01:22:00"

I have seen this before. Because the time is so far out the NNTP services will not correct it. I did a blog (so I remembered it as usual) - but that may be a little dated.

To force a sync;

sudo sntp -s

I also got DietPi to put in a fix as again, I’d seen an issue with first boot for an old image.

You will also find any apt update will have failed.

If the -g switch is used, the NTP daemon will set the time correctly no matter how far off the system time is.


Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options.

Ref: ntpd(8): Network Time Protocol daemon - Linux man page

1 Like

Just be wary everyone. We do not know what is or isn’t included in the Oct2018 image as there is no build guide despite significant changes.

This is the first Stretch image and it is no longer RO.

The older images used ntpd and had a custom ntp-backup utility installed to deal with the fact the OS was RO so the time was saved to disk each hour. There was also another “fix” added along the way to force a NTP time correction via a cronjob after bootup too. Since Stretch uses systemd-timesync by default and we have no idea how much of the older build guide was used in the new image it’s not easy to know what exactly is required. Is ntp even installed? Should it even be installed if systemd-timesync is used?

This has also come up in passing on another thread a few hours ago too.

[edit] Actually that cronjob to force an update apparently ran every hour!

So that begs the question why isn’t the clock updated? Is it a network issue or is it a mismatched correction procedure? (rhetorical Q, just highlighting it may not be a simple network issue). Perhaps the ntp_update and/or ntp_backup utilities are failing because the rpi-rw command doesn’t exist? Just an example!

@Wesley_Phillip if you can ssh in is there any info at /var/log/ntp_update.log? (I’m not even sure it’s still used, sorry)

Maybe I read too much into that, but “I am currently on the same network as the device” implies to me at least that its on its own network, possibly with no Internet connection.
Thus my suggestion to set the time manually using date.

Is it even connected to the Internet?

Ha, different eyes see different things, I took that as a vague reassurance that the Pi had internet as he was talking to us and the Pi at the same time.

That might well work, but will it save? ie will it be available for the next reboot or will it still be 30 oct 2018? hence the groundhogday ref. I doubt we will ever see a build guide for this image now with a new incarnation on the horizon!

1 Like

Never comfortable with the relationship between ntpd and timedatectl - there was a suggestion that the 2 should not both be installed on a system together.

From the man page

The systemd-timesyncd service specifically implements only SNTP.

Which I think is why I ended up with the original command I posted - only sntp is installed where timedatectl is managing time (I think).

BTW perhaps we should split this time discussion out :smile:

Yep. NOT a good idea.

Looked at my EmonPi and it is using timedatectl / systemd-timesyncd.

I did discover from a timedatectl status that the system timezone was not set (obviously not actually needed).

I’ll fire up a fresh image and see what happens. I wonder if, if there is no network on first boot, it then gets in a tizzy.

Just for info …

I’m in the process of trying to build emon on a Raspian Lite Stretch OS.

I included the NTP Update cron job as described in the Oct 2017 Build Guide.

It has resulted in a /var/log/ntp_update.log entirely filled with … /home/pi/emonpi/ not found.

I’m keeping a note of all the anomalies that I find.

I’ve found this to be helpful on other aspects …

Thanks for all the input guys.
This morning i got round to updating the time and left it to run. All looking wonderful now.

will try and setup the ntp correctly but ntpd is not installed by default.

1 Like

Hi John, we are working on a new build script. I’d take a look as it may save you time. We know that Jessie build guide is out of date and elements are not relevant to Stretch.

Deliberately so as Stretch uses timedatectl. Installing ntpd will cause more problems than it solves.

Brian …

Many thx

I’ve noticed all the activity and recognise the OEM ‘powers that be’ have quite a task to cover the waterfront …

emonPi or emonTx

Radio transceiver or ESP or Serial direct connect using RPi’s wireless

Updating an existing installation or a fresh install

Catering for the tinkerer or for those that need a one shot SD image

And, perhaps, even being agnostic between Raspbian and DietPi – both are underlying Debian with just different ‘labels on the tin’?

On a point of detail and re the WIP new build script – line 52: is that emoncms service or emonhub service? – but perhaps my inadequate understanding

Many thx again for yr pro-active help


Brian …
Thx to you & the other key guys on the Forum plus adding a trailing ‘,’ …
I now have a working ‘dumb’ emonHUB which only sends sensor data to another emon instance (local server) on the local network that does the emoncms ‘fancy stuff’
It’s Raspian Lite Stretch + emonTx + serially direct connected RPi3 with NO radio transceiver
My key resources were …

and …

[emoncms/ at master · emoncms/emoncms · GitHub](emoncms/ at master · emoncms/emoncms · GitHub

Plus Forum help + personal persistence/time

Perhaps it’s now time for me to try it out on a base of Diet Pi :slight_smile:

Thx again

1 Like