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:-
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.
[edit]
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):
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.
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.
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.