My first concern is that, since I do not want to use the 433mhz connection/emonTX to emonPi bridge, when I connect this device via HTTP or MQTT does it try to connect as its node ID to the emonPi?
What identifier does it use, or how do I configure this?
My second concern is which protocol is more reliable/better? Should I use HTTP or MQTT?
My last and final concern is:
I am having a hard time understanding how accurate any of these devices are, I thought that the stats were cumulative with the EmonPI, but when I was talking to @Robert.Wall on the other side of the forum, it seems that we are just recording datapoints, and then the device is adding them up/stats for the EmonTX…
How does this make sense, and how does this not affect the accuracy of the devices?
If a data point is plotted every 5-15 seconds, if there is a power spike in between that time, but normalizes before a data point record, will I not get bad results?
I thought that was the case, but I wasn’t absolutely sure.
The sketch in the emonTx (and in the emonPi) takes a discrete (not discreet) sample of the current and voltage for a duration of 200 ms and from that calculates the average voltage, current and power over that period, and transmits those values. The emonTx repeats that every 10 s by default, the emonPi every 5 s. This is called “discrete sampling”.
Given that, obviously any change in the quantity won’t be known until the next sample is done, and if there’s a short transient change during that period of sleep, it is never seen.
As I mentioned elsewhere, those power values are transmitted immediately by the emonTx and are not stored. If the transmit path fails, the data is lost.
So yes, if the data doesn’t arrive, and if there’s something that’s missed, then you have an error. EMonLibCM was developed to address these issues.
If you want to change the - I call it “reporting” - rate from the default I mentioned above, then yes. However, emoncms.org will not accept data more frequently than every 10 s. Your own emoncms (running on your own server) does not have that limitation.
I would say hands down HTTP as far as the broader OEM project goes. HTTP has been around a lot longer and proved a very stable, robust and accurate way to get data into emoncms. MQTT is used between emonhub and emoncms on the emonSD and has had a pretty bumpy road to date, but most of the reliability troubles have been dealt with now, However, where the HTTP is a direct connection the MQTT is still dependent on at least one extra moving part, the broker, and there’s the emoncms MQTT input service too.
Having said that, I’m not overly experienced with using emonSEP this way so cannot comment too much on that specific use, but sending data from an emonESP using MQTT, you are not sending it direct to emoncms, you are just publishing that data to the broker and emoncms is listening in, using the same MQTT input script as used on the emonSD.
In practice you may not detect any differences or issues with either, but I bet if there is a problem, the HTTP route will be more resilient and less likely to falter.
There can be some very valid reasons to use MQTT rather than HTTP, but a flip of a coin isn’t one of them. If you do not need to specifically use MQTT, stick with HTTP. I’m sure someone is likely to point out they have had no issues with MQTT and quite possibly you might not either, but HTTP is undoubtedly the more solid of the 2 when posting to emoncms.
Just one more question. When I pointed the EmonESP to the EmonPi, it created a new node based on the name I gave the EmonESP.
Is the same behavior observed with MQTT?
Since I do not have a solid understanding of all the relationships between all the different services, I did not know if when I connected it, if it would report or overwrite other node data that was being transmitted wirelessly.
Both the HTTP and MQTT input methods of emoncms have the ability to use named inputs, it really depends on the method used. Take for example the HTTP input api’s, you can use named inputs (eg 'input1':123.45,'input2':67.89) or just using CSV (eg 123.45,67.89) , the former will result in inputs called “input1” and “input2” whilst the latter inputs will be “1” and “2” as emoncms uses the index+1 for the input name. These 2 methods are not currently interchangeable (See Development: Indexed Inputs) but either can be used with HTTP or with MQTT, so if you create inputs via MQTT and then switch to HTTP or vice versa, providing they use the same method and the names are the same, it will continue to update the same inputs, incoming data is processed to the same inputs depending on id’s and names etc not by delivery method. The named method can of course be made to be compatible with the csv method by using index numbers as names (eg '1':123.45,'2':67.89) although I can’t imagine why anyone would want to do that unless it was purely for compatibility, with the bulk upload api for example.
AFAIK the emonESP uses named inputs for both MQTT and HTTP.
If it has the same node name/id and input name/id then yes it would end up in the same place regardless of where it comes from or how it is delivered, whether it overwrites or not depends on other things such as input processing, feed type, interval and whether feedwriter is enabled etc.