I have an emonPi which runs a local version of emonCMS, and several emonTx/ESP8266’s. I’d like to do a bit more with the data generated, ie using Node-RED automate a smart plug to charge a 12v battery whenever an inverter is producing power.
Is the best way to do this to start using MQTT? I have put some details in the MQTT section of one emonTx (see below), but what else do I need to do to get it so say “Connected: Yes”? I can’t find anything within my emonPi to start an MQTT server (if such a thing is needed), and ssh’ing in to the emonPi and typing sudo service mosquitto restart didn’t do anything
Or can Node-RED (on a Raspberry Pi Zero W) query my local emonCMS data directly?
This is explained in other threads re MQTT and how it works.
The emonPi has the Mosquitto MQTT Broker (rather than server) installed by default and some of the data will pass through that.
The MQTT details on the ESP are for sending (strictly speaking publishing) data to the Broker. emonCMS then subscribes to those topics (i.e. wants and data published to that topic) and uses that an an input. You can subscribe to multiple topics at once in a tree structure and by default, emonCMS subscribes to any data published on the emon/ base topic.
There are 2 ways to get data;
you subscribe to the relevant emon topic in Node-RED - effectively look at the input to emonCMS
as part of the input processing publish data to a new topic (NOTemon) for Node-RED (NR) to pick up. This is useful where the data has arrived via the HTTP API.
You can simply point NR to the broker (by IP) on the emonPi and subscribe to topics and publish data back (for other systems).
The suggestion is to not run Node-RED on your emonPi (recent thread about a dead emonPi).
Suggest you have a good dig around with Google and understand how MQTT works.
I have set up a flow within Node-RED (on 192.168.2.57:1880), but the “answer” is coming back blank - whereas I half hoped it would come back with something like “ct1:200 (watts)” or similar.
By slightly changing things within the espwifi3012 that is attached to the emonTx in the barn (thanks for clarifying this, @borpin ), and being more explicit within NR (ie cutting out things like ‘pulse’, ‘spent’, & ‘Vrms’ etc, the 10 second feed value of the specific CT that I am interested in (“real time” pv generation in watts) flows through.
All I now need to do is work out what to do with this data
I might be misunderstanding something here, and I did check, but the data (from the only CT I have on this emonTx/ESP8266 combo) is actually arriving in both NR and my local version of emonCMS on the emonPi.
Every 10 seconds, the same digit (PV generation) appears in both the NR debug window AND the emonCMS Feed page.
I certainly don’t want to cut out the data going to emonCMS - I just wanted to effectively create a duplicated branch so that I could then work with it in a different way (c/f control a smart plug if, say, PV generation is >=50w).
99% sure my system doesn’t use the RFM due to extended distances between the Tx’s and the emonPi. (Back when I initially set things up I even put RF signal blockers on the aerial screw threads).
For a temporary “proof of concept”, I have now been able to cobble together a NR flow that turns on a Hue lamp on when the barns PV are producing >100w, and turn it off when not. Next stage will be to replace the lamp with a smart plug, & replace the generation Input to an export Input, so that I can use otherwise exported generation to charge a 12v battery which will in turn keep a classic car storage “bubble” inflated FOC for much of the year.
I am tempted to think that the espwifi3012 widget is able to transmit via MQTT to NR and to my emonPi via wifi / emonCMS, as data is arriving in both places. Perhaps @TrystanLea could confirm this?
I have now included a routine whereby if the panels produce <2 watts NR generates an email saying so. This will be handy to monitor the inverter switching off due unexpectedly which is great. It’ll also send me an email each evening as the sun goes down, but I can cope with that for now.
Is there a way to get an emonPi to send MQTT messages? There isn’t the same type of “Control Panel” that the esp8266 wifi devices have. Not sure where else to look …
What do you want to send? Look at the input process - you can include a publish to MQTT, but it is to the Broker on the emonPi (as specified in settings - same one in and out - can’t change that - hence only having one on your network) and use a different base topic notemon.
Thanks. Whilst I measure my barns pv generation on an emonTx, I measure net in/out on an emonPi; I’d have preferred to have used this net out data to control my smart switch.
I understand that one can / should only have one MQTT broker on a network, and because I am using one on a RaspberryPi I would have liked to get my emonPi to send an MQTT message out to the RPi broker. But it seems like this might be a complication too many, so rather than using a net out figure, I will just use a figure of ~50 at the inverter, which will allow for the constant ~35 draw that the barns & office use 24/7.
One other quick MQTT question … Whilst I understand that it is a very lightweight protocol, where do all of the messages end up? Does one need to clear out a cache every now and again to prevent the SD card from filling up? Or is it all de minimis?
EDITED TO ADD: I’d also like to have an automated email alert for if my panels go offline due to a circuit trip; I just thought that MQTT & NR would be a good solution for this.
yes it is that one. The partitions etc of the emonSD have been modified to try and reduce wear levels, log files are in ram and a few other tweaks mean that running anything else on an emonSD based system risks the underlying function (running emonCMS).
If that machine is a Pi and has emonCMS on it, then I suggest that is a bad idea. Run everything on a VM or on an NUC with an HDD/SSD - different beast but YMMV. Good luck.
Not for the first time I have tied myself up in knots
A few days ago …
I installed a Mosquito broker on a headless RPi that is also running Homebridge.
I told an emonTX/ESP8266 to publish data from a CT to that broker
I created a Node-RED flow that uses this MQTT info
All good so far.
I understood - rightly or wrongly - that one should only have one MQTT broker on a LAN. But because I would like to send a Feed data from my emonPi via MQTT so that it can be included in the NR Flow I needed to make some changes to the Broker.
I took it that I ought to delete the MQTT broker on the RPi first. Trouble is, I don’t know how to. I ssh’d in and typed sudo apt-get purge --remove mosquitto* but whilst it seemed to accept the command the MQTT feed within NR is still working, despite a RPi re-boot.
Moving on, I ssh’d in to my emonPi, created a new MQTT password & restarted the Pi following the instructions at Service Credentials - Guide | OpenEnergyMonitor but whilst I can log back in to emonpi.local and see the Tx Inputs and Feeds etc, all of the Inputs on the emonPi are showing “n/a” & “NULL”
OK, I have managed to back out of most of the errors, but I am left with two questions … but one can wait for now.
Getting MQTT data out of a local emonCMS on an emonPi
I have set the emonPi to act as MQTT broker, and it is working well for data arriving from two emonTx/ESP8266’s. But I can’t work out how to publish MQTT out of a CT Input on the emonPi. Does anyone know how to do this?
Within the MQTT section in the espwifi page of an emonTx/ESP8266 I have this.
Both work well and do what I want. But the lack of the MQTT “page” when logging in to my emonPi on 192.168.2.50 means that I can’t work out how to tell the emonPi what Topic to use etc. I have added a Process (see below) to one of the CT’s on the emonPi, but I can’t retrieve the data that I want within Node-RED. I’ve tried lots of combinations of Topic forms, but none work. It may well be that the emonPi isn’t even generating any MQTT data of its own, but I don’t know how to even check this.
@haffle, great to see your progress! I’m rather behind you, but on MQTT I used “MQTT Explorer” (free download for most platforms) to understand the structure of all the topics coming out of the broker - it saved a great deal of frustration trying to figure that out from Node-Red & other MQTT clients.
Also helpful in understanding the format of data items I was publishing…
