Loss of inputs following upgrade (Solved I think!)

I have just upgraded to 9.9.8 by creating new SD and doing a backup and restore.

When I first logged in a few feeds were missing. One set came from just one emonTX.

I discovered some were missing because duplicates inputs appeared which I deleted. Some were missing that are from my MQTT broker. I rebooted the broker and they all reappeared.

That left me with the one set missing that come from the one emonTX. At this stage I noticed an input that I did not recognise so I deleted it. I was delighted to see the missing inputs from the emont]TX started showing. I then expanded all the inputs and began going through them methodically. I found another input that was coming in as a duplicate to an input with associated feed. So I deleted it and the correct input came in and updated the feed. I then noticed the set from the emonTX stopped updating again.

Then over night the inputs did show occasionally. I can see the effects on some graphs

It seems I have this set of inputs coming into emoncms intermittently. Any suggestions? Sods law of course these are the inputs with the most complex processes so I am very loath to delete them. Is there a way to see inputs below the hood so to speak to confirm they are really there?

This may all be associated with me recently adding demandshaper which has created a number of inputs that I know nothing about. It also doesn’t work for me as it assumes a standard MQTT port number and unless that changes it will not be of any use. Is there an easy way to remove demandshaper to see if it is causing the problem? the install instructions are:-

sudo ln -s /home/pi/demandshaper/demandshaper.service /lib/systemd/system
sudo systemctl enable demandshaper.service
sudo systemctl start demandshaper

How do I reverse that?

You should just be able to stop the service;

sudo systemctl stop demandshaper.service

If you want to prevent it starting on reboot do

sudo systemctl disable demandshaper.service

Hello Ian, You mention your mqtt server is on a different port, is it also a mosquitto server? but on a different machine? do you know which version you are running?

The demandshaper gets its MQTT settings from emoncms/settings.php and so it is compatible with MQTT servers on different ports. Its the smartplugs which are fixed to the port here: https://github.com/openenergymonitor/EmonESP/blob/timer/src/mqtt.cpp#L135 I will make a note to include a configuration item for this.

The two are synonymous in this context. Mosquitto is simply an implementation of the MQTT broker standard.

You can never assume that the MQTT server is local nor which port it is using. I have a machine just to run the Mosquito broker on as I discovered that, if it was on the same machine as something like HA or Emoncms, if those needed systems needed maintenance (or at worst a rebuild) I lost MQTT functions for everything.

As an aside, the service files should not actually include mosquitto as a ‘Wanted’ service as strictly it does not need ‘mosquitto’ as a service, but instead the function requires access to an MQTT Broker and they are not the same thing. I have raised this as an issue. What will happen is that systemd will try and start the ‘wanted’ service that does not exist. It seems to work but more by luck than design I feel.

I am sure you have but I never assume anything (or try not to) - have you disabled/masked the local Mosquitto service on the EmonSD card (I think you will need to mask it to prevent it being started)?

If you use Emonhub, it has MQTT settings in it’s own config as well.


Unfortunately stopping demandshaper has not solved the problem so it must be something else that is different. This was all working without issue before the upgrade.

How do you best do that? Worth a try. I don’t use Emonhub.

Yes my mqtt server is mosquitto on a different Pi as is Node-Red.
I realised it was the plugs that are fixed.
Will there also be a option to change the name from “smartplug1” from the set up page as my only option at the moment is to install using pre-compiled firmware?

You can see if mosquitto is running from the services section of the administration page. It will also tell you what MQTT server EmonCMS is pointing to further down.

To mask the service (mask rather than disable as disable only stops automatic startup on boot but does not stop another service starting the service):

sudo systemctl mask mosquitto.service
sudo systemctl stop mosquitto.service

You might find emonhub is being started as well (again in the services section of the administration screen). Do the same as above.

note an update might restore these services as the update does make certain assumptions.

There is another issue which may be related.
I just noticed a number of feeds not updating.
Checking the inputs reveal a common reason. Inputs are coming up as duplicates of existing inputs. Deleting the new arrivals restores the re awakes the originals and the feeds start updating.

Have you stopped emonhub and Mosquitto?

I have now but I believe this input duplicate issue occurred before I stopped them.

I am also still seeing two inputs that I think are demandshaper related but that no longer appears in the menu so I must assume I have successfully removed it. I have rebooted (several time) since removing demandshaper.

I attach server info in case it gives any clues.
ServerInfo.txt (3.6 KB)

Server Information
emonhub Inactive Dead
emoncms_mqtt Active Running
feedwriter Active Running - sleep 60s
service-runner Active Running
emonPiLCD Active Exited
redis-server Active Running
mosquitto Inactive Dead
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 : demandshaper : 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: 9.9.8-4-gd0db7a57
Server OS Linux 4.14.71-v7+
Host emonpi : emonpi : (
Date 2019-03-03 14:37:11 UTC
Uptime 14:37:11 up 1:33, 1 user, load average: 0.00, 0.02, 0.02
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 2019-03-03 14:37:11 (UTC 00:00‌​)
Stats Uptime: 5585 Threads: 3 Questions: 18942 Slow queries: 0 Opens: 27 Flush tables: 1 Open tables: 21 Queries per second avg: 3.391
Redis Version 3.2.6
Host localhost:6379 (
Uptime 0 days
MQTT Server Version Mosquitto 1.4.10
Host (
Pi Model Raspberry Pi 3 Model B+ Rev 1.3 - 1 GB (Sony UK)
SoC Broadcom BCM2835
Serial num. 4F2878CB
Temperature CPU: 46.16°C - GPU: 45.6’C
Release emonSD-30Oct18
Memory RAM Used: 14.05% Total: 976.74 MB Used: 137.27 MB Free: 839.46 MB
Swap Used: 0.00% Total: 100 MB Used: 0 B Free: 100 MB
Disk Mount Stats
/ Used: 39.93% Total: 3.81 GB Used: 1.52 GB Free: 2.11 GB
/boot Used: 51.69% Total: 42.52 MB Used: 21.98 MB Free: 20.54 MB
/home/pi/data Used: 2.64% Total: 25.4 GB Used: 687.11 MB Free: 23.44 GB
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/72.0.3626.119 Safari/537.36
Screen Resolution 1920 x 1080
Window Size 1660 x 927

You can just paste it here. I have edited the post and done so, so you can see the difference.

This is a longstanding but thankfully infrequent issue. It was seen a lot when there were issues with the emoncms mqtt_input but since that issue has improved this consequential one is less prevalent, but still a pain when it does occur.

I have more recently opened an issue on github but it hasn’t attracted any attention as yet.

If you need to, you can use the emoncms/input/clean api to remove all duplicate inputs in one go, to facilitate that option I always make sure I have at least one process on any valid inputs, even if it’s not used as the api call deletes all inputs without a processlist. Unfortunately this isn’t a cure as you still need to be a aware the duplication has occurred (eg feeds stop updating) to alert you to use the api (or automate it via nodered etc)

Thanks to all the help. I reverted to the older SD card with the original emonCS version and to my surprise that was not receiving inputs from the same emonTX either.
I spent a good part of yesterday learning more than I intended about networks! I used the Fing app which was suggested by our support engineer and with his telephone help we established that something was blocking the IP address of the EmonTX. I am not sure what actually solved the problem but after a number of Router rebooting and restarts of powerline mains network ports I am now running as before.

@pb66 you mentioned

This saved a lot of time as inputs were causing a problem on each emonCMS reboot.

Is there a complete list of API calls anywhere?

Great to hear that you have it working @ian

You can access the input and feeds api list from their respective pages (top-right). Looks like this: