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)