I am in the process of changing my system from having my 3 emonTx/ESP8266’s & an emonPi sending data directly to emonCMS.org to having my 3 emonTx/ESP8266’s sending data via MQTT to my emonPi and me then using emonpi.local instead of emoncms.org for recording the Feeds etc.
During the setup process I seem to have lost the ability to log / record psent & psuccess data; is this data not relevant when using MQTT to send data to a local emonPi? If so, how does one keep a check on communication “up times” etc?
I am having a problem with MIN / MAX values on a couple of MQTT Feeds; I’d like to keep track of a daily max production rate for my PV panels - but the third of these three processes produces a Feed error. Any ideas as to what I am doing wrong?
I am also having similar issues with sending temperature Max/Min daily values - both from the TX’s via MQTT and within the emonPi itself.
I think the psent & psuccess only relate to the HTTP API as that formally acknowledges with an ‘OK’ (What does psent and psuccess indicate? - #3 by pb66). MQTT does have the ability to confirm delivery by using a higher QOS, but I suspect the ESP just uses QOS 0 which is ‘fire and forget’.
However, you do not have to use MQTT from the ESP, if you only want to communicate with the EmonPi. It is perfectly acceptable to use the HTTP API by just inserting the correct IP address and APIKEY on the ESP8266. This then means the ESP8266 is communicating directly with Emoncms on the Pi rather than using the MQTT Broker.
On your Min/Max issue, I do not know the answer.
Many thanks @borpin - very helpful. I’m reading up about MQTT for a separate project (“Home Assistant”, which uses it a lot), and now understand the limitations of QOS 0; it may be that now I have sorted out my initial poor wifi comms that data drop outs will be a thing of the past. But if not, I’ll drop back to using the HTTP API as you suggest.
I think I have realised what causes the Min/Max problems - the Min only updates when a new min is triggered - which might have been much earlier in the day for example. My bad !
Yes it does. It is worth having a single broker on your internal network be it the one on the EmonPi, the Hass.io addon or running on it’s own machine. Multiple brokers are a pain.
In order to not have two MQTT servers on the network I thought that I would get the three EmonTx’s to communicate with my emonpi.local through http instead of via MQTT, as that will free up
hassio to do the MQTT stuff. I made this change a few days ago.
Question: How do I stop an emonTx broadcasting via MQTT?
When I log in to emonpi.local / Inputs I can now see the emonPi, the three “new” emonTx http Inputs and (what I presume are) the three old MQTT Inputs. I have logged in to the 3 Tx’s via their respective LAN IP and tried to delete the MQTT server info, but it won’t let me / insists on having a server entered. If I delete the server (192.168.1.150), ignore the prompt and re-start the Tx, the server info is still there upon reboot.
Ignore the “47 hrs” in red on the attached screen grab - they are misleading.
That would seem to be a problem with the EmonESP software. @glyn.hudson can you help?
Thanks @borpin . Just to be doubly clear, this is the pop up dialogue box that appears after I delete all of the MQTT boxes and click on Save. If I ignore it and restart the Tx the boxes are re-populated with the original data (as if I had never deleted it).
The second screen shot shows the populated data.