I downloaded the ISO from git and installed using etcher "emonSD-30Oct18.img
dont know what low-write version means.
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
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”
Services | ||
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 : (192.168.1.78) | |
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 | 127.0.0.1 (127.0.0.1) | |
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 (127.0.0.1) | |
Size | ||
Uptime | 0 days | |
MQTT Server | Version | Mosquitto 1.4.10 |
Host | localhost:1883 (127.0.0.1) | |
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 |
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 time.google.com
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.
-g
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.
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!
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.
[edit]
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
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/ntp_update.sh not found.
I’m keeping a note of all the anomalies that I find.
I’ve found this to be helpful on other aspects …
https://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/readme.md
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.
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 …
https://github.com/openenergymonitor/emonpi/blob/master/docs/SD-card-build.md
and …
[emoncms/readme.md at master · emoncms/emoncms · GitHub](emoncms/readme.md 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
Thx again