Re: Large monitoring rollout: how to differentiate output from several emonpi units

A continuation of the “Large monitoring rollout: how to differentiate output from several emonpi units.” thread started on the old forum.

“Before I start though, is there a reasonable way to monitor via ssh the inputs that emonhub is receiving and posting if I haven’t installed emoncms?”

Yes, the emonhub’s “DEBUG” loglevel is intended for this purpose, each packet is numbered as it arrives so you can track it’s progress through the decoding etc.You can easily keep another terminal window open ssh’d into the same emonpi and use tail -f /var/log/emonhub/emonhub.log to see the log entries as they happen, or if you install the emonhub utilities it’s just emonhub -dl or emonhub --display-log.

emoncms v8.5 was a bit of an interim version that brought in many changes before the massive overhaul of v9 so it is advised to move onto v9> if you can, the latest emonSD images intended for the emonPi have all used v9 since it was available so you must have an early and un-updated image. Your “intranet” version should definately be > v9 as the v8.5 “low-write” was aimed at SD card installs and the standard v8.5 was quite buggy. v8.5 “extended” was the pre-runner to v9.

The latest emonpi image works well, with offset nodes- and their labels- showing up nicely.

As a quick way of making it completely read only, to be safe in power cuts, would it help to stop apache and mysql and possibly a few other services from starting at boot time? This can easily be done by installing sysv-rc-conf, which will work through an ssh connection. Stopping them does not seem to stop emonhub from sending data. I could then write a little script to start these services only when I actually want to use them- mostly at setup time, where the web GUI would be nice. Mostly, the emompis will just be shifting data to an upstream server.

You could try some of these things out, it may help, it may also have effects that do not come to light immediately and/or hinder debugging etc.

Since IMO the biggest shortfall of the emonPi image for what you are doing is that is is overly complicated and modified in so many ways that are not needed for your application, it doesn’t sit well with me to add yet something else to take away something that needn’t be there in the first place.