EmonHub changes: any interest?

Hi,

I’ve published a few changes to emonhub on my GitHub account. If there is interest in including these changes in the appropriate upstream repository I would be happy to make pull requests but wanted to determine interest first. As the emon-pi variant seems quite different than the emonhub upstream I’m not sure where the best destination is for this stuff, although probably emon-pi in the first instance since that’s the branch it’s based off.

Repository is here: GitHub - adpeace/emonhub: emonHub is the link between your inputs and emonCMS

Here is a summary of the changes

MQTT subscriber/publish to EmonCMS: 741f03a

For whatever reasons, I found the PHP MQTT listener in the emoncms repository to be unreliable. I wanted to use MQTT because I’m taking the data pushed by emonhub (at least for temperature) and using it in other applications too. Since I’m not too familiar with PHP and the available PHP MQTT libraries I decided to write a simple Python script that subscribes to the topics and posts to EmonCMS.

This is installed by not enabled by default in the package (see below) because it requires a config file with the MQTT username and password, and the EmonCMS API key. A sample config file is provided.

Debian packaging: 322b469

I created basic Debian packaging for the repository. This probably wouldn’t be good enough to get the package upstream, but I think it would help user deployments of emonhub and building of the emon-pi image.

There is a todo file with a few changes still to be made here - the only one preventing deployment is probably ensuring the emonhub user gets added to the dialout group, which should be a trivial change.

JSON-format MQTT payload: 0b84022 (emonhub) and 4e42060 (emon_mqtt_subscriber)

For another internal application I’ve written it was convenient for me to know which readings were grouped together (i.e. to get a temperature and humidity reading into the same ‘reading group’). I didn’t want that application to have to know about the payload layout as in the old emoncms ‘rx’ format, so I added support to emonhub and the MQTT subscriber above to product a JSON-formatted message that combines all readings received together. I’ve separated commits for the emonhub and subscriber parts of this so if the community is only interested in the former then it can be taken on its own.

An example of a message published might be:

topic emon_sensors/10: {"power1": 120, "power2": 0, "vrms": 240.0 ...etc}

No config re-reading and other cleanup: 151a74c..d18f0c9

This is probably the most controversial and may not be suitable for general use as-is (in particular I’ve not tested it with the config module of EmonCMS so it probably breaks that). I stripped out parts of the code that periodically check for updated config files. I don’t need that functionality and found it to cause a drain on my Pi’s CPU (I’m still using an old Model B with 256MB of RAM).

There are a couple of other minor bugfixes in that range that are probably worth having.

Thanks,
Andy.