I’m running EMONCMS V9.8.30 on 64Bit Debian and using MQTT exclusively for inputs. Its been pretty reliable but I think I should bring it up to date.
Are there any breaking changes or general bits of linux mischief I need to look out for? Should I update to an interim version along the way or just move to the latest? Do I simply need to change to the EMONCMS folder and issue a GiT Pull or is there more to do? My setup is based on the Pi low write version with the feeds stored on a separate /home/pi/data partition
What is the base Debian version? Jessie can cause some issues.
What feed engines are you using? IIRC I needed to convert my data to a different engine at some point in time but I’m not sure what version that was.
There have been quite a lot of changes since then. Do you have much in the way of dashboards? Whilst the update script tries to accommodate the changes, I’d be inclined to try for a fresh install.
I’m guessing this is not RPi based. I’m wondering, if you have a spare RPi, you could use it as a stepping stone; set it up, copy the data across and see if it will run. As you are using MQTT, running 2 along side each other should not be an issue. Once that is running, you can blat the original and do a fresh install there and then simply use the export/import functionality to move the data back.
Make sure you have a good backup!!!
No there is quite a bit more involved than that. Additional modules need updating as does the way the services work & get started.
I’m running Debian GNU/Linux 9 (stretch) which will get updated as part of this on a Mini PC. I have one Dashboard plus the MySolar App.
I’m using phpfina, phptimeseries and sql for my ram feeds plus MQTT Publish to feed some things to OpenHAB. The admin page says I have the following modules
Administration | app | Backup v1.1.2 | Dashboard v1.1.1 | EventProcesses | Feed | Input | CoreProcess | Schedule | Time | User | Visualisation
As I have a very extensive OpenHAB system on the same box doing a simple format and reload is likely to be very time consuming although I will image the hard disk first in case it screws up. I do have a spare Pi2 that I could play with if needs be, although I’d need to go through my inputs to get rid of those that publish to MQTT before it would run in parallel
Is there any documentation I can look at before I start? I slipped on quite a few banana skins before I got a stable workable system and I am keen not to do it again.
That should be OK
No real issues there.
OK.
No!
My immediate thoughts for potential banana skins are;
- A simple git pull will not work.
- You will need the Device, config, and Graph modules installed (not part of the core).
- The way the services are run has changed from init.d to systemd
- There have been issues reported on the Mosquitto version. In the past Emoncms used a beta version, the ‘newer’ beta version might be a problem. Depending on how you set this up, your installation may still be inclined to pull that one down.
- The MQTT input and publish mechanism has changed.
Other thoughts on how you are setup -
- Do you use REDIS & Feedwriter (used to be referred to as ‘low-write’)?
- Is service-runner service running?
- Are the logs on tempfs?
@pb66 and @TrystanLea - do you have any further thoughts?
Have a look at the update scripts that are normally used emonpi/update at master · openenergymonitor/emonpi · GitHub plus the newer install scripts GitHub - openenergymonitor/EmonScripts: Emoncms Stack Installation and Update scripts. There is also an sql backup script here.
TBH there are lots of potential pitfalls but as long as the data is backedup and you can live with a bit of a gap in your data, you should be fine.
I did something similar a number of years back, let myself get behind the releases, and it is a bit of a PITA to then update.
I do use REDIS & Feedwriter, service-runner is running and the logs are on tempfs.
Do you know if the backup scripts will remember everything including all the input setup details? It seems like I’d be better off deleting it all and starting again after changing the box over to buster. I had to do a lot of messing with SQL before it’d work last time around when I built it on stretch, and as I’m running from a SSD I’d like to keep the low write stuff.
So far my SSD seems to be wearing out at around 1% per year which is good considering what I have running on it
OK, we’ve been looking at using a different approach to managing the logs on tempfs as there have been a few issues.
It should do 
I have moved data a number of times on my Pi-Hole but that was largely between the same version number. Coming from your version might cause some issues.
I do think that starting from scratch may well be easier in the long run. I would though, be inclined to use the backup and try and import it onto a new SD card on a separate system to prove the concept (of the export/import) and to have a running system while you rebuild the main system.
I’ve moved away from running everything on one machine for just this sort of reason. Now, most of my stuff (Emoncms, Node-red, MQTT, Pi-Hole, and HomeAssistant) all run on separate VMs under EXSI on an HP Microserver. It means I can snapshot and rapidly restore any of them and the only interruption is any data coming from them. Has made my life so much simpler than worrying about interdependencies on a single machine.
Thanks for the info, I’ll take a full image backup when I have a spare few hours and start experimenting. Experience tells me to not go near this when I’m short of time!
One final question, will my current version likely survive an OS update to Buster?
Short answer - probably, but that is the best I can do. Take the backup first!
Thanks very much!
I’ll do this in stages when I have spare time and update this thread so it helps anyone else following on
1 Like
It’s time to work on this, and I’m thinking of removing EMONCMS after taking backups, and manually deleting anything that’s left behind before updating Debian to Buster. I’ll then restore the backup. After a fight I’ve got the backup working and it saves the Maria DB, an empty emonhub.conf, an empty Emoncms.conf, and settings.php together with the feed data in a tar file which I can open on my windows pc. Everything I have is MQTT based and I’ve removed any dependencies my OpenHAB installation has on Emoncms.
Now the questions:
- is this a good way of doing things
- what’s the best way to totally remove Emoncms
- what’s the best way to install Emoncms 10
- can Emoncms 10 work in low write mode as I run from an SSD.
I’ve had to reboot my system several times recently whilst I’ve been updating OpenHAB and I’ve had to repair the SQL inputs table and manually flush REDIS before Emoncms would work again so I think it’s time to give the new version a go
Personally I find, as you have, that running multiple systems on one device can cause issues especially when it comes to updating the underlying OS.
If you do want to 'completely remove emoncms on an existing machine, look at
- the services running
- the www folder
- the data folders
- the folder in
/home/pi/ rc.localcrontasks
[I may have missed some]
Start from scratch
Normally I’d say use the EmonScripts. The fly here is that you are using an SSD so a hybrid between a Pi and non-Pi system. Is the rootfs on the SSD or just mounted as a folder?
Either way, the Scripts do not account for an SSD (@TrystanLea - needs thinking about) so will want to do things you probably do not want wrt partitions etc. but will want to do things specific to the Pi.
Low write mode, is a buffering process, using REDIS, designed to reduce the number of writes to SD Cards. While you can switch off the buffering, there is not a great deal of advantage but you can reduce the buffered time (I run on 60s). Any reduction in writes preserves the life of any disk. You do still need REDIS as it does a few other things as well.
I’d be inclined to take the plunge and start from scratch. The update to Buster, while possible in theory, seems to introduce it’s own daemons (as in bad things!).
No real need to run in low-write mode if you’re using a true SSD, i.e. not a SD or µSD card.
SSD longevity is measured in TBW - TeraBytes Written. With that kind of llifespan, there’s
no worry about wearing one out with an OEM system.
Ref: The SSD Endurance Experiment: They're all dead - The Tech Report
Two of the drives in this test exceeded 2 PB (Petabytes!) before permanent failure.
Thanks Brian and Bill.
A little background to my system in case it’s relevant.
Essentially it’s an intel based laptop board in a passive case with an old 80Gb SSD which has 96% life remaining. It runs normal 64bit Debian. Software wise it has Java, OpenHAB, and Emoncms on it. Emoncms is configured using the low write SD build instructions. It’s been running happily for over a year, until recently when the repeated rebooting I’ve been doing has annoyed Mariadb. I tried to segment things with Docker when I installed it, but that proved too hard to get running so I opted for this setup. My background is windows and DOS, whilst my knowledge of Linux and Git is better than it was when I started this journey it involves a lot of web searching.
I’ll read the scripts to see what happens in the background before starting Emoncms from scratch after uninstalling the old version. Experience tells me to tread carefully due to many things being dependant on many other things
Great article - thanks.
I’m not so keen on the sudden lack of access at the end though. I thought these things remained accessible as read only
Ah Ok, different again.
I suggest you start with a clean Debian install then run the EmonScripts from there using the Debian instructions.
[edit]
Is there an OpenHAB docker? If so I’d go for that alongside EmonCMS. There are plans for a Docker install for EmonCMS but that is a way off.
Is there an OpenHAB docker? If so I’d go for that alongside EmonCMS
I’m not sure I can see the point of that given OpenHAB runs in Java. It has very few dependencies that I’ve found so far, and its been very well behaved.
That was using a data write rate of 1 MB/Sec for 10 hours per day, 24/7/365.
If that’s extraoplated out to 1 MB/Sec continuously, that comes to ~36 TB per year.
All of the drives went well past the 300 TB mark which would be just shy of 10 years of
operation at that write rate.
The larger the drive is, the longer it will last because wear leveling spreads out the
storage cell use over a greater number of cells. It would seem that before one failed, you
may likely have replaced it with something larger/cheaper.
The test was started on 2013 but wasn’t complete till 2015. In the past five years, SSDs
have gotten cheaper and capacitiy has increased considerably. A 500 GB drive can be had
for ~60 USD. That much storage would take nearly 20 years to “wear out” at 1 MB/Sec 24/7/365.
I’ve just done the upgrade to Buster and the good news it it worked and OpenHAB continues to work. The bad news is my emoncms inputs are all not working. Fixing the inputs on the DB and flushing redis from the Administration tab no longer fixes it.
The first error in emoncms.log is
|ERROR|phpmqtt_input.php|ErrorException: Redis::exists(): connect() failed: Connection refused in /var/www/emoncms/Modules/input/input_model.php:191
its time to remove all of emoncms V9 before installing V10
That was an epic fight, php didn’t recognise the extensions mosquitto.so and mysql.so, the backup script both filled up the disk and also complained that the sql backup was missing when it was in the archive, together with many other things including the data drive disappearing from /opt/emoncms. I’ve now mounted it back at /home/pi/data and symlinked the feed folders back.
I’ve lost my dashboards and graphs but kept my feeds and input setup.
Experience told me it wouldn’t be easy so I’m happy to get away with it working again after 7 hours so far…
Looking at the log I see a couple of issues.
Issue 1
|ERROR|user_model.php|Please update database
How? The update database button has gone
EDIT: Found the answer on https://github.com/emoncms/emoncms/blob/master/docs/Upgrading.md
In your internet browser open directly the admin/db page to launch the database update script.
http://localhost/emoncms/admin/db
Plus its given me back my graphs and dashboard albeit the dashboard keeps throwing errors
Issue 2
2020-01-25 07:08:14.320|ERROR|emoncms_mqtt.php|ErrorException: A non well formed numeric value encountered in /var/www/emoncms/Modules/process/process_processlist.php:846
Stack trace:
#0 /var/www/emoncms/Modules/process/process_processlist.php(846): exceptions_error_handler(8, 'A non well form...', '/var/www/emoncm...', 846, Array)
#1 /var/www/emoncms/Modules/process/process_model.php(71): Process_ProcessList->scale('0.01', 1579936094, '24127Publish,em...', NULL, Object(Process))
#2 /var/www/emoncms/Modules/process/process_model.php(122): Process->__call('scale', Array)
#3 /var/www/emoncms/scripts/services/emoncms_mqtt/emoncms_mqtt.php(379): Process->input(1579936094, '24127Publish,em...', '2:0.01,1:13')
#4 [internal function]: message(Object(Mosquitto\Message))
#5 /var/www/emoncms/scripts/services/emoncms_mqtt/emoncms_mqtt.php(137): Mosquitto\Client->loop()
#6 {main}
Is there an easy way of finding out which input is causing this?
Should I start new threads for these?