Feeding data into EMONCMS via MQTT or API, or

HI all,

I’m trying to get a better sense of the archtecture of the code on the EmonPI - who talks to who?

I have the commercial EmonPI, with a EmonTX and a couple of EmonTH. I also have a HomeAssistant system and programming skills.

I’m trying to understand how EmonHUB, the MQTT layer and EMONCMS go together.

When I watch the MQTT events I see events from the various sensors. My understanding is that EmonHub makes those events as it reads data from the sensors. Is that right?

Now how does this stuff get into EmonCMS? Does EmonCMS read those events from MQTT, or is EmonHUB pushing them directly to EmonCMS in parallel?

I made a little temperature/humidity probe out of an ESP8266 and DHT22. I published the values from that into MQTT in the same style that I saw coming from EmonHUB and EmonCMS is happy to treat them as an input. So I guess EmonCMS must read from MQTT, right?

Now I’ve got some code that can read stuff off my inverter and my Lithium batteries.

At the moment the monitor on my inverter is making a JSON payload and publishing to MQTT like so:

{
  "InverterTime":"20181224102320",
  "TotalProduction":0,
  "GridVolts":213.4,
  "GridWatts":-67,
  "GridHz":50.0,
  "LoadAmpsMaybe":0.3,
  "LoadVolts":212.9,
  "LoadWatts":0,
  "LoadHz":50.0,
  "LoadAmps":0.0,
  "LoadPercent":2,
  "DCBusVolts1":440.7,
  "DCBusVolts2":440.7,
  "BatteryVolts":53.2,
  "BatteryPercent":100,
  "PVWatts":0.0,
  "PVVolts":49.7,
  "InverterWatts":0,
  "Temp":42.0,
  "BatteryChargeMode":"F",
  "BatteryChargeAmps":0.5,
  "BatteryFloatVolts":53.2,
  "BatteryMaxChargeAmps":25.0,
  "BatteryBulkChargeVolts":53.2
}

For my batteries I’m reading:

>  VoltageUpLimit: 53.25, VoltageDownLimit: 47.0, MaxChargeCurrent: 25.0, MaxDischargeCurrent: -250.0, Status: 0xc0
>  CellsCount: 15, TemperaturesCount: 5
>  TotalCurrent: 0.000A, TotalVoltage: 53.185V, RemainingCapacity: 50.000Ah, P: 0.00
>  Quantity: 2, TotalCapacity: 50.0Ah, Cycles: 0
>  CellVoltages: [3.547, 3.546, 3.538, 3.542, 3.547, 3.525, 3.546, 3.548, 3.549, 3.549, 3.55, 3.549, 3.549, 3.55, 3.55]
>  Temperatures: [28.0, 25.0, 25.0, 25.0, 25.0]

I’ve got this info for each of 2 packs

I’d like to get all this stuff into EmonCMS, and also be able to see it via MQTT in HomeAssistant and manipulate with NodeRED.

But to publish each item on a separate topic is a lot of messages.

But EmonCMS can’t read JSON I don’t think.

I see that the EmonTX publishes all the values in one string, but I’m not sure how the EmonPI knows what they all represent?

What’s the best practice - to have my probes publish into MQTT - then I can see the raw event in HomeAssistant and EmonCMS - but I can’t use the structured JSON format.

Or to use the EMONCMS API?

Or to publish and have NodeRED republish to MQTT and back into EmonCMS.

I’d appreciate any pointers and hints,

Thanks
Steve

So several different means of doing this, but yes EmonCMS will accept a valid JSON object. It also looks for a ‘time’ key value pair and will use that time if it finds it.

Just post the JSON object to a topic starting emon/ and EmonCMS should show that as an input node with each key value pair as an input.

There is also a Node-Red node in NR which uses the HTTP API.

If you check on the inputs page on your local setup, you will see Input API Help. You will see a note about the time element.

[edit]Note that ‘InverterTime’ is not a unix timestamp.
[edit2]Emoncms will not (currently) handle the array. You’d need to process that down to individual key/value pairs beforehand.

Hi,

Thanks for the reply.

I must change the timestamp to Unixtime, or Javascript style milliseconds since epoch?

I’ll check the docs for more insight, and was poking around the code too.

As for the battery packs, I didn’t do the MQTT side yet so can structure it any way that Emoncms likes.

I do have the Emoncms node type in my Nodered.

Thanks,
Steve

No needs to be Unix (i.e. Javascript time / 1000; I think I toyed with a check for this on the input side but took it out) or else a format the PHP understands (like ISO8061). Unix time is best though as it avoids timezone conundrums.