Standalone installation failing after install over old version

First this is installed on a standlone Raspberry. I updated the RPI to Buster. I had a previous version installed and that failed after the upgrade. To fix that I installed a version using the Debian build script on the page.

I can log into the page but think it’s the wrong one - the one from my previous installation. The version says 9.8.7 | 2017.06.16.

I’m also getting this on every page:
Warning : scandir(): (errno 2): No such file or directory in /opt/emoncms/modules/demandshaper/demandshaper-module/demandshaper_model.php on line 58

And I can’t get emonhub to talk to emoncms. For some reason emoncms_mqtt.service is not running and when I try to start it it says there is no such service.

No I don’t have a back up - emoncms wasn’t running due to the buster upgrade and didn’t know how or what to back up. Plus I’m sure things are different since I last updated 4 years ago.

Right now I’m leaning toward uninstalling all and reinstalling but I have no idea what to keep or how to uninstall it or if I can just uninstall parts and reinstall.

What is the best approach to fix this mess? Thanks

For the mqtt service issue i turned off all except for mqtt in the EmonScripts/install/config.ini and ran again. I saw this:

WARNING: Module mosquitto ini file doesn’t exist under /etc/php/7.0/mods-available

Ah, do you mean that or did you follow the link to the EmonScripts?GitHub - openenergymonitor/EmonScripts: Emoncms Stack Installation and Update scripts

Top of the page…

That is definitely wrong.

Why not use the EmonSD image?

More info on mosquitto install failure: I was getting an issue with php 7.0. I think I fixed that. But now when I try to install I get the following:

Mosquitto Server installation and configuration

Reading package lists... Done
Building dependency tree
Reading state information... Done
mosquitto is already the newest version (1.5.7-1+deb10u1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree
Reading state information... Done
libmosquitto-dev is already the newest version (1.5.7-1+deb10u1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Mosquitto Client installation and configuration

Reading package lists... Done
Building dependency tree
Reading state information... Done
libmosquitto-dev is already the newest version (1.5.7-1+deb10u1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
pecl/Mosquitto is already installed and is the same as the released version 0.4.0
install failed

Install Emoncms EMONPi / EmonBase specific Modules

Note the install failed with no other reason.
I’m stuck now.

Edit - fixed formatting. BT, Moderator.

following and the link for New Debian build script takes me to EmonScripts/ at master · openenergymonitor/EmonScripts · GitHub. Then down the page under " Install the EmonCMS Installation Scripts" I followed the instructions for wget and ./

This Raspberry does more than just emoncms - email server, ntp server, pihole servers and others… I prefer not to use special OS’s but open systems. I don’t want to have to reinstall all those other apps and utiltites.

So that could easily be your problem. Pretty difficult to work out the issue. I’d look to the fact that Pihole listens on port 80 with lighttpd as does emoncms on Apache. 2 different webservers on one machine is bound to have issues.

PHP 7.0 is EOL PHP: Supported Versions.

Pihole is not the problem. It was at first but I shut down the lighttpd web server and forced to not restart. Pihole still works without it.

If I wanted to do a clean uninstall what would I need to remove? I’m thinking that a clean reinstall would work but it appears that emoncms thinks things are already installed and doesn’t update them.


You’d need to go through the scripts and even then I’m not sure how to undo some of the PHP stuff.

That’s why I run each different system in it’s own environment - you do not get this cross contamination then!

As I said PHP7.0 is EOL and that might be the issue. All 3 of my systems are running 7.3.

It would seem it may be falling over at this point

I removed everything on the system that referred to emoncms and emonhub. I did not remove mysql, mosquitto, redis or other packages not related to emoncms. I removed php 7.0 though I do see some php packages that refer to 7.1 and 7.2 though ./usr/lib/php only shows 7.3.

After some hiccups getting things started again I have all services started except emonPlLcd which I don’t think is needed for standalone. I ran into an issue with mysql using root but managed to get by that.

The web page is showing version 10.2.6. Emonhub log is showing it’s receiving data and sending it.

I had an issue with the feeds. The data in /var/opt/emoncms/* had no metadata. I copied the data from the original location and the old data showed up in the feeds. To see this data I had to set the prefix in redis to ‘emoncms’.

However I’m not getting data from emonhub. I am seeing it transfer info through MQTT but it never makes it to emoncms. I’ve tried ‘emoncms/’ and ‘/’ for basetopic but neither worked.

I’m suspecting it’s a database issue. In the original install I used ‘root’ as the user for mysql. I only see the feed data if I use that userid. If I use the emoncms I don’t get anything. The only error I’m seeing in the emoncms.log is something about demandshaper. I’ve checked the other logs of redis, emonhub or other logs. The only thing in the apache2 log in emoncms is
PHP Warning: Constants may only evaluate to scalar values in /var/www/emoncms/Lib/units.php on line 30, referer:

I wonder if I should blow away the database and then rebuild it with the emoncms userid. If so how to blow it away? and if so will it kill the existing data? Or is there a way I can rename the ownership, and userid/password. Note I know little about sql.

What should I look for now? Thanks,

No you can mask that service

Latest version

Did you do a complete restore of your previous data - this will likely cause things to not work properly.

And that will prevent feedwriter working I suspect.

The usual process is to install emoncms, check everything works and then import a backup either from file or from USB. Did you do that?

All the fiddling suggests the install is not correct in the first place. The fact you part uninstalled is probably not helping and probably very difficult to resolve. This really is why we advise to use a dedicated machine or VM. Sorry, emoncms is not designed or tested to work alongside other things and you do so at your own risk. Doesn’t mean to say it won’t, just that we cannot easily help if you try.

Ok so I’m about to trash 5 years of data to get this working again.

If I set prefix=’’ for redis. then go into mysql and delete the emoncms database (after a back up), set the userid/password to the suggested in settings.ini and then reinstall, would this get it working again? Anything else I should do?

One question - is the actual data from the feeds stored in sql or is that separate? I didn’t anything for the data entries but then I’m a novice in sql.

I got into this mess for several reasons. 1) I think I installed the earlier version 5 years ago as root and found out later it should have been by pi. There are still no warnings to that effect. 2) When I reinstalled, it installed as if it were a new install so it didn’t copy new files over the old (ie, it saw the /var/www/emoncms folder and skipping doing anything) 3) documentation on the various parameters is woefully lacking and incomplete. There is no theory of operation about how it works and how the parts fit together which makes debugging nearly impossible.

Thanks for you help and understanding.

No the database just holds some meta information for the system, config etc. The data are in the feed folders/files.

Did you take a backup from the UI (or from anywhere) before you started?

Well if you are on a Pi, it is a reasonable assumption you are using the user pi!

Yes it would. You are way out of date, the script didn’t exist then and you are probably one of less than 1% of the user base. Asking first before making such a radical move might have been prudent. We could have helped make a backup that could be restored at a minimum.

Always happy to accept PRs for improvements.

The biggest lesson is to keep up to date in future. Incremental changes are easier to absorb.