Assuming the files in the feed folders are not updated when this happens, MONIT could be used to monitor the folders and send out an alert - basically what is was designed to do.
I did this for my weatherstation many years ago as at the time, the python script just stopped writing the data for no good reason. Worked like a charm.
I’m sure this works well and I know many users have set up node-red to do some checks too. @cagabi is taking yet another approach in his tasks module (which I do really like the sound of, but not for this specific task).
My thoughts on this are that it should be integral to emoncms. Feeds not updating really shouldn’t go un-reported. I think if there are so many repetitive tacks like listening for MQTT and buffered-write and updates/notifications etc a emoncmsd service could also provide the hook for many tasks including checking for dormant feeds.
I think having an additional field for each feed that is 0 (for disabled) by default and can be set to any value in seconds by the user would work well if on each update of a feed an “alert_due” (current update timestamp + the “alert_period”) was recorded in redis for each feed and every Xsecs (eg 1min?) emoncms simply checks to see if any of the “alert_period” values are less than the current time, those that are get added to a single alert per user, where the maximum alert rate (aka “snooze” setting) can be set by the user (or turned off) in the user account settings.
A single email every hour/day that lists the stalled feed names and their current values might give some insight into where the fault is without needing to resort to searching the logs or even logging into emoncms to check what the feeds are based on a feedid based filename type alert from an external source eg monit.
I’m not knocking the use of Monit (or any other method) and it may still be a good call to use it as an over all watchdog, I’m just expanding on my comments in that other thread as to what I meant and why.