Another emonPi stopped logging thread

sorry, I’ve just noticed this post:

emonhub.log (364.1 KB) doesn’t cover the period when the error first occurred looks like it has a lot of noise? I’ve attached the most recent version, but I think I need to adjust the logrotate.conf file so I keep logs over a longer period?

looking at /etc/systemd/system/mqtt_input.service I think it’s not logging by default? and I need to uncomment for it to log to syslog?

Description=Emoncms MQTT Input Script
After=mosquitto.service mysql.service redis.service

ExecStart=/usr/bin/php /var/www/emoncms/scripts/phpmqtt_input.php

# Uncomment instead of above to use standard log file, else use systemd log
# Type=forking
# ExecStart=/bin/sh -c '/usr/bin/php /var/www/emoncms/scripts/phpmqtt_input.php 2>&1 > /var/log/mqtt_input.log &'

# Restart script if stopped
# Wait 60s before restart

# Tag things in the log
# View with: sudo journalctl -f -u mqtt_input -o cat

# Un-comment to pipe log to syslog


I can’t figure out where I need to enable logs for feedwriter? should I edit /etc/init.d/feedwriter? or the thing that calls the init script?

sorry for the shotgun approach to asking questions, would welcome any help :slight_smile:

@mozster is your system fully up to date? I notice a divide by zero error in your emoncms.log for kwh_to_power processor. Im not sure if that’s related, you mentioned restarting emonhub fixes the issue which would suggests it isnt related. Perhaps try removing the kwh_to_power process for a period of time?

thanks @TrystanLea

I updated last week or so. so I think I’m up to date, I’ll run an update again from the admin interface and also do a full power cycle ( update.log.txt (6.8 KB) )

EDIT: I think from looking at the log above, I needed to do a manual upgrade on account of disabling RF in src.ino? I’ve done that now (git pull/re-apply changes/compile/update) emonpiupdate.log.txt (6.3 KB)

:flushed: I’ve done that now, restarted emonhub and it’s kicked back into life again, I’ve tried enabling some more logging in mqtt_input and keeping more emonhub logs, will report back if it falls over again

From the server information (really useful);

So Feedwriter Daemon is not running but this is a Low-write install (not actually sure what the impact of this is).

Next time it stops can you please run the following commands from SSH and post the output

sudo systemctl status emonhub
sudo systemctl status feedwriter
sudo systemctl status mqtt_input
sudo systemctl status mosquitto

My suspicion is the mosquitto service has stopped as the phpmqtt_input.php script cannot establish a connection.

If it has try sudo systemctl restart mosquitto then check the status. If you can get the mosquitto log it may help diagnose why it stopped.

Do you really mean just restarting emonhub or do you mean rebooting the EmonPi?

1 Like

thanks Brian, will share the requested logs next time it falls over

Yup restarting the service: sudo systemctl restart emonhub

@mozster check out Collecting Local EmonCMS debug information
maybe it helps :slight_smile:

1 Like

I think it is related, the time it occurred aligns with the feeds “last updated” time in the screendump.

This is not the first time we have seen this, checkout the “Emonhub crashed with OOM error in /var/log/messages” thread for a similar event. On that occasion I added a fix PR to emoncms to avoid divide by zero errors when using the wh_accumulator process, but this has occured with the kwh_to_power process this time round.

There are several places that need a similar fix to make the emoncms code more robust against divide by zero errors whenever an input is duplicated or even just end up getting an identical timestamp due to the use of integer timestamps.

In that thread I question how that could happen with a QoS 2 level connection, since QoS 2 messages require 4 messages to complete (2 in each direction), until all the messages are completed, it is assumed that the payload wasn’t successfully received and will be resent until all 4 parts are successful.

All the MQTT disconnections and re-connections play havoc with the chances of all 4 messages completing and because a new random client id is issued by the broker each reconnection, the 4 part interaction cannot resume after a disconnection, all 4 parts must occur in one session because emoncms doesn’t supply a reuseable client id (see the “A question over whether emonCMS is compatible with MQTT” thread for more on this).

There must be multiple elements at play here, possibly but not definitely inter-connected.

The fact the feed-writer isn’t running will mean that no feed data will be written to disk, it will all remain in the buffer, but that is not the reason the feeds page is not updating, we have seen issue when the feedwriter has stopped previously and the feeds page continues to update as normal.

Is this an emonpi or an emonBase? I suspect it is an emonPi due to the emonhub.log and screen dumps showing node 5 and the fact you are editing src.ino, but the start of the update log shows there is no emonLCD found and if you are changing the emonPi FW, you should avoid using the “update emonpi” button in emoncms as it will over-write your FW changes, you must use the “wrong” button ie emonbase for an emonpi. (see the Update EmonPi Button or Update EmonBase Button? thread for more on that).

The emonhub.log seems to show that the rfm is still working as there are many “discarding RX frame ‘unreliable content’” log messages.

In the emonhub.logs it also shows that every 5secs the MQTT connection has to be re-done and appears to be successful but then gets disconnected, perhaps restarting emonhub is giving the broker a chance to get back on it’s feet after being knocked over by emoncms? (bit of a stab in the dark there as I do not (yet?) understand how restarting emonhub can effect the broker or make the feedwriter spring back to life)

1 Like

I have checked the other processes and I think this is the only one that is currently vulnerable to this so I have submitted a PR for consideration, but I do not think it is an ideal fix. It simply tries to avoid a crash/exception.

It is not ideal to be passing a value of zero to the next process, for example if that is a log to feed, the previous good “current” value could be over-written with 0 watts just because the input was duplicated (if buffered write is not in use, see Data Viewer questions - #14 by pb66).

Thankyou @pb66. I have merged your pull request. Its not yet in the stable branch that runs on the emonpi, Il look into merging later.

@pb66 thanks - really appreciate you looking into it

I bought an emonPi PCB only and plugged it into an old RPi 1 I had spare, so don’t have the enclosure & LCD connected. I wasn’t sure at first if the update button was using a downloaded FW or recompiling after applying changes, but I’ll have a look at the thread - thanks for the link.

It shouldn’t be a problem if the kwh_power process has been removed for testing in this instance.

No problem! The emonSD update routine (AKA the emonpi updater) always re-uploads the latest.hex each time it’s run. Your best bet is to compile your own hex file and call it something else and put it somewhere safe, then upload the hex to your emonpi board using the same avrdude command but with a different path and file name. Then always use the “update emonbase” (not update emonpi) button so that the upload command fails because it’s the wrong upload baud, leaving your FW intact but updates everything else. By not using the src.ino or latest.hex files, the updates to the repo will not get blocked by local changes.

@TrystanLea can the PR I put in to stop the MQTT input throwing an exception be merged please. the exception occurs on a retry connection which is followed by a subscribe whether the connection was successful or not.

I’m not too sure how the logs above are able to be generated. It looks to me that the code hits the ‘retrying session’ log entry before the callback onConnect records the ‘connection successful’.

Just checking, do you actually have any MQTT inputs to emoncms? Just wonder if we are barking up the wrong tree here!

Also, it seems from the log emonhub cannot get a reliable MQTT connection either. What is your emonhub configuration?

Thanks @borpin I will have a look at your pull request. All @mozster’s inputs should be being posted via MQTT if they are coming from a standard configuration emonhub.

I think they are, the inputs page uses a named input and the mqtt reconnection attempts in the emonhub.log seem to be triggered by the attempts to publish the emonpi data.

Ah, OK. Had not realised MQTT was the standard way for an EmonPi. I use the HTTP API personally.

As a matter of interest, why use the MQTT interface?

@mozster - are you still having problems?

That’s a very good question.

As it stands users are trading reliability and accuracy to use MQTT “exclusively” and thus make the same data available to other SW like openHab etc.

I would recommend using http to post data to emoncms, at least until the emoncms mqtt inputs are sorted and emonhub can post mqtt timestamped data to emoncms reliably. It is possible to just set up another interfacer like the emoncmsorg one and point it at the emonPi/emonbase but to avoid double posting (timestamped via http and untimestamped via mqtt) one of 2 things needs to happen, either stop the mqtt interfacer in emonhub, but that means other SW cannot subscribe to the energy data OR disable the emoncms mqtt_input so that emonhub can continue to publish without emoncms getting that data via mqtt, but that means other SW cannot publish mqtt to emoncms.

So you can only successfully have any 2 of these 3 things emonhub publish MQTT, emoncms subscribe to MQTT or reliable and accurate data, you cannot have all 3.

Unless of course you can somehow change the topics so that data emonhub publishes is not subscribed to by emoncms mqtt input.

It is now understood that different topics are required for “local status info” and “time-sensitive data”, future emonHub versions should have the ability to double publish mqtt as single value per topic and timestamped batched data to serve both needs (discussed in depth in the EmonHub Development thread)

That “2 streams” method is basically what I’ve suggested above, just using http and the one existing mqtt interfacer for now, until there is a timestamped mqtt interfacer to replace the more reliable and accurate http method.

But you can simply republish the data from Emoncms via MQTT so that is easily solved. I suspect the group of folks who need this is fairly small.

Third option, post from emonhub by HTTP API to emoncms and publish from emonhub by MQTT on a different topic from so emoncms will not pick it up.

Fourth option, post from emonhub by HTTP API to emoncms and publish from emoncms by MQTT on a different topic.

Which implies the only route to reliable and accurate data from emonhub to emoncms is via the HTTP API.

But why is MQTT better as a transport medium than the HTTP API? That is the bit I am not seeing. Is it the potential to buffer the data?