Continuous monitoring sketch with MQTT publishing (over ethernet)

If anyone is interested here is the Arduino sketch I have running on my Uno clone (which has ethernet built in) and the EmonTX Arduino shield. It is based on the continuous monitoring sketch, originally written by Robin (calypso_rae). It will make real power measurements on all 4 CT sensors and publish results to various MQTT topics every 5 seconds.

I am running mqttwarn on my home server which subscribes to these topics and transforms the payloads into something suitable for EmonCMS (https://github.com/jpmens/mqttwarn#emoncms). EmonCMS is running on the same home server.

This has been running for a couple of months and the daily/monthly cumulative totals are within 0.5% of the totals being reported and billed by my electricity provider so I am very happy with it all.

Note: if you decide to use this you will need to work out your own calibration values and update the sketch. I calibrated it by comparing the daily totals recorded by EmonCMS with the values reported by my provider (who have a portal showing daily totals since we have smart meters down here in NZ). But adjusting the calibration values I have been able to get it pretty accurate.

You will also need to update the MQTT broker IP address, username and password of course.

Not sure if anyone is interested but wanted to share what I had done since I received so much help and advice on this forum, as well as all the fabulous sketches already written and made available by the likes of Robin and Trystan etc. So many thanks to everyone on here!

Cheers,

Ben

 

pbertra's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

I am really interested!

I have an arduino mega, I ordered an ethernet shield and I will order the emontx shield soon to send data to a mosquitto server server on a raspberry pi. There, I use node-red to publish to emoncms. So I will test this soon...

 

Thank you!

sumnerboy's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

No worries - glad someone might find this useful!

TrystanLea's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

Thanks for sharing this Ben, I've added a link from the emonTxShield example list in the readme to this forum post so people can still find this in time as it sounds like a nice configuration. https://github.com/openenergymonitor/emonTxFirmware/blob/master/emonTxShield/readme.md

sumnerboy's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

Thanks Trystan - it seems to be working very well so far, 2 months without an issue. I am in the process of merging in some of Robins PV diversion code to control a remote load using MQTT as well - not sure if the MQTT protocol will handle the rapid switching required but I will report back here once I have something to share.

ianw's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

I have done something similar but instead of using MQTTwarn, I use node-red which has a Emoncms output node. I have one EmonTX and 2 EmonTH's. (I have also tried MQTTwarn, which works well, but it is one more program to keep running. Node-red is also one more server to keep running, but it is such an elegant solution).

The combination of node-red, MQTT and EmonCMS is very powerful. Once you get data into MQTT then it is easy to send the data to many other systems.

As an example it is quite simple to send events from Emoncms to XBMC I have running on a separate Raspberry Pi, and these events appear as a notification or a popup on XBMC.

See https://github.com/matbor/mqtt2xbmc-notifications

for the software to install on XBMC.

These events are manipulated by a custom function I wrote to put the message into a form use by this software.

The node-red flow (including the custom functions) is

[{"id":"39eb56aa.c614aa","type":"emoncms-server","server":"http://192.168.0.58/emoncms","name":"Locally Hosted Emoncms"},{"id":"cb79af10.34865","type":"serial-port","serialport":"/dev/ttyAMA0","serialbaud":"9600","databits":"8","parity":"none","stopbits":"1","newline":"\\n","bin":"false","out":"char","addchar":"false"},{"id":"ba386057.845d3","type":"mqtt-broker","broker":"192.168.0.58","port":"1883","clientid":""},{"id":"228442dc.dd7bbe","type":"mqtt in","name":"From Emoncms Home/Curl ","topic":"Home/curl","broker":"ba386057.845d3","x":129.75,"y":565.2000198364258,"z":"766e32e7.8991cc","wires":[["d35ba7db.2ca458","9d04509f.62fbb"]]},{"id":"6ffa34d0.9005cc","type":"comment","name":"EmonTX input ","info":"ie RFM12IN input","x":133,"y":77,"z":"766e32e7.8991cc","wires":[]},{"id":"e4bfc607.1b4038","type":"serial in","name":"RFM12 Radio on serial port","serial":"cb79af10.34865","x":121.75000762939453,"y":197.75000286102295,"z":"766e32e7.8991cc","wires":[["c49746a9.3b68b8","8e712794.718ed8"]]},{"id":"c49746a9.3b68b8","type":"function","name":"Parse EmonTX input","func":"//we are expecting data in form \"nodeid data1 data2 etc\"\n// Note much of this is redundant - there is a splitter node available that can do this. \n// And you could also just copy msg payload without any processing. \n// I have left this like this in case I want to validate the data that comes in.\nmsg.payload = msg.payload.trim();\n\n var tokens = msg.payload.split(\" \",66);  //FM2Pi will have a max of 66 bytes payload\n var outString = null;\n var outTopic = null;\n var msg2 = null;\n var nodeid = tokens.shift();\n \n if(!isNaN(nodeid)) {\n     nodeid = nodeid & 0x1F; // strip out the additional flags\n     var raw = tokens;\n     buf = new Buffer(raw);\n     outString = [];\n\n         for (var i=0; i<(tokens.length); i+=2) {\n         outString.push( buf.readInt16LE(i) );\n         }\n//Create topic from node number  \n      outTopic = 'Home' + nodeid;\n      msg2 = { payload:outString, topic:outTopic};\n      }\n// EmonTX data\n  if (nodeid == \"10\") {\n    return [msg2, null,null];\n  }\n// EmonTH No 1  \n  if (nodeid == \"19\")  {\n    return [ null,msg2,null];\n  }  \n  EmonTH No 2\n  if (nodeid == \"20\")  {\n    return [ null,null,msg2];\n  }","outputs":"3","x":431.99998474121094,"y":196.99999618530273,"z":"766e32e7.8991cc","wires":[["9dfe7b06.620188","860efd52.79f1"],["642d2457.9bd2dc","89ffe4c7.760018"],["b87e983d.478168","7ba25e5.f845da"]]},{"id":"9dfe7b06.620188","type":"mqtt out","name":"Publish node 10 RFM12  data ","topic":"Home/10","qos":"0","retain":"true","broker":"ba386057.845d3","x":720.9999694824219,"y":145.99999618530273,"z":"766e32e7.8991cc","wires":[]},{"id":"860efd52.79f1","type":"debug","name":"Node 10 Radio debug","active":false,"console":"false","complete":"true","x":699.9999694824219,"y":177.99999618530273,"z":"766e32e7.8991cc","wires":[]},{"id":"8e712794.718ed8","type":"debug","name":"From input A","active":false,"console":"true","complete":"false","x":405.50000762939453,"y":233.50000762939453,"z":"766e32e7.8991cc","wires":[]},{"id":"89a97de1.76568","type":"mqtt in","name":"MQTT Broker rfm12b Node 10","topic":"Home/10","broker":"ba386057.845d3","x":130.1999969482422,"y":381.20001220703125,"z":"766e32e7.8991cc","wires":[["2fc0479c.d03fb8","7e2265fe.81dd9c"]]},{"id":"2fc0479c.d03fb8","type":"emoncms","name":"Emoncms node 10 input","emonServer":"39eb56aa.c614aa","nodegroup":"10","x":438.2000274658203,"y":350.20002365112305,"z":"766e32e7.8991cc","wires":[]},{"id":"7e2265fe.81dd9c","type":"debug","name":"From MQTT node 10","active":false,"console":"false","complete":"false","x":426.2000274658203,"y":380.4500198364258,"z":"766e32e7.8991cc","wires":[]},{"id":"d35ba7db.2ca458","type":"debug","name":"From MQTT ","active":false,"console":"true","complete":"true","x":388.45002365112305,"y":596.200023651123,"z":"766e32e7.8991cc","wires":[]},{"id":"9d04509f.62fbb","type":"function","name":"fnSendtoXBMC","func":"var paylmqtt =  msg.payload;\nvar topicstr = msg.topic;\n// This is a lvl 2 topic\noutmsg = msg;\npayloadmqtto = '{\"lvl\":\"2\",\"sub\":'\npayloadmqtto = payloadmqtto + '\"' + topicstr + '\",';\npayloadmqtto = payloadmqtto + '\"txt\":\"'+paylmqtt+'\",\"img\":\"/home/pi/.xbmc/userdata/Thumbnails/background.png\",\"delay\": \"20000\"}';\noutmsg.payload = payloadmqtto;\nreturn  outmsg;","outputs":1,"x":387.14290618896484,"y":564.888879776001,"z":"766e32e7.8991cc","wires":[["ac384fd9.53c7b","f223ef04.0ddc1"]]},{"id":"a311c387.5cee4","type":"mqtt out","name":"Send to TVs running XBMC","topic":"/Home/xbmc1","qos":"0","retain":"true","broker":"ba386057.845d3","x":841.805534362793,"y":566.0833377838135,"z":"766e32e7.8991cc","wires":[]},{"id":"ac384fd9.53c7b","type":"debug","name":"After massaging for XBMC","active":false,"console":"false","complete":"true","x":618.2658920288086,"y":593.8928813934326,"z":"766e32e7.8991cc","wires":[]},{"id":"f223ef04.0ddc1","type":"delay","name":"12 sec delay","pauseType":"delay","timeout":"12","timeoutUnits":"seconds","rate":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":571.0571594238281,"y":565.2000370025635,"z":"766e32e7.8991cc","wires":[["a6d361ea.592ca","a311c387.5cee4"]]},{"id":"a6d361ea.592ca","type":"debug","name":"After delay","active":false,"console":"false","complete":"true","x":790.1641502380371,"y":534.4500198364258,"z":"766e32e7.8991cc","wires":[]},{"id":"642d2457.9bd2dc","type":"mqtt out","name":"Publish Node19 RFM12 data","topic":"Home/19","qos":"0","retain":"true","broker":"ba386057.845d3","x":722.1999816894531,"y":209.2000093460083,"z":"766e32e7.8991cc","wires":[]},{"id":"89ffe4c7.760018","type":"debug","name":"Node19 Radio debug","active":false,"console":"false","complete":"true","x":699.1999816894531,"y":241.20002365112305,"z":"766e32e7.8991cc","wires":[]},{"id":"1e8dda1e.e17226","type":"mqtt in","name":"MQTT Broker rfm12b Node19","topic":"Home/19","broker":"ba386057.845d3","x":127.70000457763672,"y":413.20001792907715,"z":"766e32e7.8991cc","wires":[["d4e7d75b.2b1828","c50bff5d.3af4"]]},{"id":"d4e7d75b.2b1828","type":"debug","name":"From MQTT node 19","active":false,"console":"false","complete":"false","x":426.4500217437744,"y":443.95001792907715,"z":"766e32e7.8991cc","wires":[]},{"id":"c50bff5d.3af4","type":"emoncms","name":"Emoncms node 19 input","emonServer":"39eb56aa.c614aa","nodegroup":"19","x":435.2000274658203,"y":412.9500198364258,"z":"766e32e7.8991cc","wires":[]},{"id":"b87e983d.478168","type":"mqtt out","name":"Publish node 20 RFM12 data","topic":"Home/20","qos":"0","retain":"true","broker":"ba386057.845d3","x":725.2500076293945,"y":271.50000381469727,"z":"766e32e7.8991cc","wires":[]},{"id":"7ba25e5.f845da","type":"debug","name":"Node20 Radio debug","active":false,"console":"false","complete":"false","x":701.5000076293945,"y":301.50000381469727,"z":"766e32e7.8991cc","wires":[]},{"id":"b6ebb0ce.49145","type":"mqtt in","name":"MQTT Broker rfm12b Node20","topic":"Home/20","broker":"ba386057.845d3","x":127.75,"y":442.7500057220459,"z":"766e32e7.8991cc","wires":[["7e3279de.81cd88","e1f23fca.1e0dc"]]},{"id":"7e3279de.81cd88","type":"emoncms","name":"Emoncms node 20 input","emonServer":"39eb56aa.c614aa","nodegroup":"20","x":435.25000762939453,"y":474.00000762939453,"z":"766e32e7.8991cc","wires":[]},{"id":"e1f23fca.1e0dc","type":"debug","name":"From MQTT node 20","active":true,"console":"false","complete":"false","x":424.00000762939453,"y":506.5000047683716,"z":"766e32e7.8991cc","wires":[]}]

 

 

 

sumnerboy's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

Nice one Ian - MQTT really does seem to be picking up steam - I am continuously trying to move anything I can to it!

FYI there is also an XBMC service in mqttwarn - I am using this for all sorts of home automation notifications, along with emonCMS events.

I haven't played with nodered but it sounds similar in concept to mqttwarn, but with a much fancier UI on top and a lot more options in terms of routing events around. I have seen some pretty clever things done on nodered that most definitely would not be possible with mqttwarn!

mqttwarn is more of a simple, low-overhead script for generating notifications from MQTT messages. 

ianw's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

Thanks Ben. I have tried the XBMC option in MQTTwarn, and it works well.

There is an error in the node-red function I posted - a simple typo. There is a comment line in the Parse Emon TX input function that is not commented. Easy to spot, and trivial to fix so I won't post a correction. Anyone who has problems contact me.  But the error will stop the flow and you won't get anything.

pbertra's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

Just a small question about the shields... I have a Mega, an ethernet shield and the emontx shield (no RF). Can I just stack them in this order with no other change? Does someone use this configuration?

pbertra's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

I answer my own post because it can be useful to others. You can stack a mega, an ethernet shield an the emontx shield in this order. You even have to... Because the emontx shield does fit on an arduino mage when soldered in the recommended way: the jacks are at the place of the additional mega IOs.

You also have to set the jumper to let pin 10 free.

And finally, for any sketch you upload, do not forget to initialize the ethernet board when it is connected because if you don't do so, the USB becomes unavailable after a few seconds... No idea why.

With these precautions, the sketch is working, more or less:

  • I get the IP address
  • I have the confirmation of the connection to the MQTT server
  • I see the first message ("/clients/emontx" topic)
  • I see the measures

but I don't receive any  "emontx/+" message... I still have to debug to find out why.

pb's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

A question mainly for Ben (sumnerboy), but feel free to chip in if you can help.  

I have finally set up my system and decided on a very similar setup to yours.  I have:

EtherTen [ EmonTx Shield -> MQTT reporting ] -> Raspberry Pi 2 [ MqttWarn -> EmonCMS ]

The EtherTen is running a modified version of the code you posted in this thread, I am using the onboard id chip to set the MAC address by changing TXShield Ch4 to IO6.  

Everything seems to be generally working, except the 'Use Today' in My Electric is always blank.  Looking through the setup guides for EmonCMS this is generally driven by a separate input stream (something like 'Ch1 Wh').  The code you posted does not generate this feed, just power.  I presume this can be generated within EmonCMS by setting up a separate feed, do you mind sharing your config for this or point me in the right direction please?

On a side note, the MQTT/MQTTWarn path for data seems like a good one, it forms a nice common interface between systems which can be easily debugged.  Thanks for sharing and writing up your work on here, it certainly has helped me.  Once I get brave enough I might even dive into OpenHAB on the Pi2.

sumnerboy's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

Hey PB, there is a bug on the My Electric page currently which means USE TODAY is always blank/NaN - I am seeing the same thing unfortunately. However you are right in that you need a separate feed for kWh/day. There are pretty good instructions here (https://github.com/openenergymonitor/documentation/blob/master/Applicati...).

Basically you take your raw W input (from your EmonTx) and generate an accumulating kWh/d feed - this is all internal to EmonCMS so nothing for the EmonTx to worry about. Takes a bit of fiddling to get your head around the inputs/feeds stuff but once you have it sorted it is pretty straightforward.

Glad you are finding MQTT/mqttwarn useful - thanks for the kind words.

aheyworth's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

Hi all

Firstly, good work!  I'm using MQTT across my network of Arduinos and interfacing them with OpenHAB.  I've planned to use Arduino Uno, Ethernet Shield and EmonTX shield, and for data to publish via MQTT which both EmonCMS (local server) and OpenHAB to independently collect.

With all of the hardware assembled I took to trying out Ben's code.  I've entered my broker IP, topics etc.  I dont use a username and password locally to removed this from the code.

The serial output shows an IP has been obtained and its connected to successfully to the broker.  Using MQTTlens I cannot see any data being published to topics.

I noticed that Ben's code - as good as it is - also wants manual calculations.  Is there any chance that someone could produce/modify code that:

a) applies automatic calculations based on AC voltage readings fed directly into the emontx shield.
b) allows static IP address assignment.
c) includes temperature data from the onboard shield temperature sensor, publishing via MQTT.

Many thanks

aheyworth's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

Updating my last message.

I now can see MQTT data being posted; although only a '1' and then 30 seconds later or so, a '0'.

I am not seeing any actual data being published, this is with the original unmodified code (except IP and topics).

Assistance please, would be great.

Thank you.

sumnerboy's picture

Re: Continuous monitoring sketch with MQTT publishing (over ethernet)

What code are you running exactly?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.