Hi Glyn
Can the emonpi be updated just with using the update button or do you have to download a new image?
Kind Regards
Dave
Downloading at the moment, I’ll see if I can do anything with the 1.5GB download size…
1 Like
You will get all the important security updates and Emoncms updates by running:
Admin > emonpiupdate in local Emoncms and upgrading Debian packages
rpi-rw
sudo apt-get update && sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo reboot
When given the option choose to keep the version of php.ini currently installed
the 2nd command line is the same command twice… should be this?
rpi-rw
sudo apt-get update
sudo apt-get dist-upgrade
sudo reboot
changes to the corrected lines…
Crushed it down to an 825MB download…
825MB download version
MD5: 3961e96cf2e1ab46d750d0a0cae72a2e emonSD-07Nov16.zip
MD5: cf8537e90ffd98ffb5838fbe3c878d4d emonSD-07Nov16.img
Did you try and boot the image? Does your version boot ok?
Yes, correct. Update then Upgrade. I’ve fixed my post above
Yes and yes, I’m planning to write some full instructions on how I manage to compress the image so far, its not that complex, but there are a few steps to it.
I’ll re-download your version and make up a full how to with all the steps in it, plus the commands etc, that should help you (or anyone else) understand how to really pull the size down prior to putting images up for download.
Glyn - I started my testing last night but quickly found this was a 4GB image instead of the 8GB image discussed here: Increase emonSD pre-built SD card to 8GB min
I had been writing (trying to write?) a migration script that captures the items not grabbed by the backup/export script. And I quickly ran out of space on the /data directory:
/dev/mmcblk0p3 194M 37M 147M 21% /home/pi/data
Is it possible to create the 8GB image instead?
I booted the emonPi with the beta 4GB image, let it do the first boot emonPi update, and then did the expand for an 8GB card (thank you Paul!):
sudo emonSDexpand
Â
After the emonPi reboot I saw this on the display:
ERROR: MQTT
Not connected
Â
It is easily corrected with:
sudo service emonPiLCD restart
I tried a sudo reboot and a paperclip shutdown. Sometimes it boots fine and other times I get the above mqtt display error.
Can the update-nodejs-and-nodered command be run as part of the build?
Updates:
- Node-RED version: v0.15.2 (I think the Nov build already had v0.15.2)
- node.js version: v4.6.2 (from version 0.10.x)
- npm version: v2.15.11 (from version 1.4.x)
PS - my apologies for the rapid fire posts! 
Hi @Andy_Taylor, just tested your packed down version. It seems to work great for me. It would be interesting to hear what you did to it to shrink it down!
Hi @Jon , thanks a lot for your testing. Sorry for the delay in getting back I’ve been away.
As mentioned in the change log for the emonSD 07Nov16, I decided to keep the image 4GB. This was party due to @Andy_Taylor 's space optimisations. The image can be expanded to fill 8GB with sudo emonSDexpand.
Interesting, did the message say forever or if you left it for 5min or so would MQTT connect?
What benefit would this have?
Nodejs and nodered should be updated via apt for the stable versions. IMO I would prefer to stick to the stable builds released via apt and the Debian packages. Keen users can always update manually if desired.
Thanks for letting me know, however this is not a big issue since there have been no changes to the huawei repo, however I have fixed the permission error during the update script:
Download file has been updated to @Andy_Taylor compressed 825MB image:
https://github.com/openenergymonitor/emonpi/wiki/emonSD-pre-built-SD-card-Download-&-Change-Log#emonsd-07nov16
small forever - the ERROR: MQTT message was there for a few hours.
I am assuming this is a locales configuration related to the US:
I believe this is something like the format of mm/dd/yyyy versus dd/mm/yyyy.
Is this a bad?!? Should I not be picking the US locales?
Per the Node-RED website: “We recommend the use of node.js LTS.”
NodeJS v0.10 does not work with some nodes (like the Nest node: node-red-contrib-nest v0.1.9)
I’m a rank newbie with emon. By way of feedback though; I managed to download and build the emonSD-07Nov16 BETA SD card. It ran flawlessly through the install, partition expansion and initial registration of Emoncms 9.7.7 | 2016.10.29.
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model name: ARMv7 Processor rev 5 (v7l)
1 Like
Mmm ok, I’ll have to do some more testing. I have been unable to re-create this.
We don’t all life in the US. Personally, I much prefer the European dates dd/mm/yyy. I vote to stick with the default local and let users change if they prefer. Do you know if the Pi does any autodetection of IP location to infer NTP time timezone? I don’t think it does. When we power up a new Pi with the pre built SD card here in the UK it gets the correct time from NTP. Do you know what happens in the US? Is it essential for you to set the timezone to make Emoncms work? What happens if you don’t set the timezone? / locale?
Ok, good point. However, node-RED does work fine (and is proven stable) with the flows that we use with the version of node currently installed. I have just installed the LTS version of node so I can test. However, it was a hefty 50Mb install. I’m not sure it here is much beneft to force this on all users.
Update: installing nodejs V6.9.1 has broken my nodered :-(. I get error
nodered : Depends: nodejs-legacy (>= 0.10)
No it doesn’t change the timezone by IP, the default Raspbian OS image will be using “UTC” ie timezone not set. This will appear correct for UK users now until spring when BST kicks in as GMT is the same as UTC. if you use the date command it will tell you the timezone. Below is a stock Raspbian image before and after setting the timezone to “Europe/London” via raspi-config.
pi@raspberrypi:~ $ date
Tue 15 Nov 16:10:29 UTC 2016
pi@raspberrypi:~ $ sudo raspi-config
Current default time zone: 'Europe/London'
Local time is now: Tue Nov 15 16:10:42 GMT 2016.
Universal Time is now: Tue Nov 15 16:10:42 UTC 2016.
pi@raspberrypi:~ $ date
Tue 15 Nov 16:10:49 GMT 2016
Both emonhub and emoncms use UTC for timestamping data so setting the timezone should make no difference to collecting and persisting energy data (providing the UTC time is correct(ed) by NTP), the emoncms user timezone set in emoncms for the correct midnight and DST will allow data be displayed correctly etc. However the Pi’s logs including emonhub.log (not so sure about emoncms) will all be in local time according to the timezone, so they can be misleading unless the timezone is set or it is understood all logs are in UTC times.
Setting the locale would probably change the logfiles date/time formating too so there maybe some benefit for those used to the US date format, but the majority of the benefit of setting “locale” will be for “Desktop apps” which are absent from the emonSD.
EDIT - Although I can see the image creation guide mentions “setting internationalization”, I couldn’t find any reference to setting the Pi’s timezone in the “users guide” but that could well be that I was looking in the wrong place. It would be worth while users setting the timezone at least to avoid confusion with logs down the line (especially in the summer “DST” months)