ESPHome Component for EmonTX (ESPx & PiPicoW)

borpin · 10 June 2025 09:43

You can see the JSON construction here

github.com/openenergymonitor/avrdb_firmware

emon_DB_6CT/emon_DB_6CT.ino

5eb44367d


      
              Serial.println("ack");
              emontx.T1 += rf.retry_count();
            } else {
              emontx.T1 += rf.retry_count()+1;
            }
            */
          
            delay(50);
          }
          
          if (EEProm.json_enabled)
          {
            // ---------------------------------------------------------------------
            // JSON Format
            // ---------------------------------------------------------------------
            Serial.print(F("{\"MSG\":"));
            Serial.print(emon.Msg);
          
            for (byte ch = 0; ch < NUM_V_CHANNELS; ch++)
            {
              Serial.print(F(",\"V"));

borpin · 10 June 2025 09:46

Interesting that the non-JSON format can include Current values. Is this an oversight not including it in the JSON format?

borpin · 10 June 2025 09:50

Is there a reason not to concatenate the values and then do a single print statement? Is this more efficient?

github.com/openenergymonitor/avrdb_firmware

emon_DB_6CT/emon_DB_6CT.ino

5eb44367d


      
          Serial.print(F(",\"V"));
          Serial.print(ch + 1);
          Serial.print("\":");
          Serial.print(emon.V[ch] * 0.01);

awjlogan · 10 June 2025 10:04

It’s just the Arduino implementation - it may or may not be better to build the string in advance, depending on the situation. In this case, it’s all blocking calls so there’s no point in allocating a chunk of memory just to do this - the cost is some extra function calls. If there’s non-blocking available (i.e. you transmit using DMA), then you’d build the string in advance at the cost of requiring to allocate the full message size in memory. This is what I do in the Pi3 as there’s a DMA unit available - the full string is built, then the DMA gets the message size and sends it off in the background and the processor is free rather than polling the UART or responding to interrupts (UART is slow compared to the processor!).

I don’t think it’s been requested, is all - it’s not a particularly interesting piece of information (as far as I’m aware!). Easy to add

Robert.Wall · 10 June 2025 10:33

It used to be when it was necessary to calibrate each c.t., probably not so much now as we’re using rather more precise c.t’s and components generally. It’s still nice to have either current or power factor in addition to power/energy, if you’re trying to identify the type of load you’re measuring.

borpin · 10 June 2025 10:44

It is one of those really annoying things that OEM tend to do. Logically, if you enable it for one output form, why wouldn’t you mirror that in the other output form especially when it is optional!

Robert.Wall · 10 June 2025 12:45

I wonder whether the consideration was disc space on the emoncms.org server from the days of NanodeRF before the emonPi appeared, and the thinking simply hasn’t changed?

FredM67 · 10 June 2025 13:00

Hi guys,
Well, after a LOT of fighting with the whole ESPHome framework (that’s unbelievable how restrictive is everything ! No way to let an unused variable, no way to pass a my_string.c_str() of if the function takes a const std::string&, …), I finally got my PR green !

Well, now it’s compiling with all checks/test/s…

Here’s the very simple yaml file I use (boilerplate stuff not shown):

And here what I get:

“Inconnu” means “unknown”. These are sensors my old emontx4 does not deliver.

I’ve defined default parameters for each sensor depending on the prefix/pattern. This can be overwritten by the user.

If someone wants to play with this component, here’s what needs to be defined in the yaml:

external_components:
  - source: github://pr#9027
    components: [ emontx ]
    refresh: 0s # ensure a fresh pull from GitHub - only required if you think things will have changed.

uart:
  id: emontx_uart # using UART2
  rx_pin: GPIO16
  tx_pin: GPIO17
  baud_rate: 115200

emontx:

sensor:
# your sensors

and then, all the sensors.

Here the pull request, still marked as draft.

FredM67 · 10 June 2025 19:50

Well guys,

Slowly but surely, I’ll need some “infinite” access to an emoncms server, so I can test the forwarding of the data through http

Fred

awjlogan · 10 June 2025 21:17

Nice @FredM67

Re. the server, do you have emonCMS setup locally? If you have a spare Raspberry Pi, or similar, you can either use the docker image or flash a pre-configured SD card.

FredM67 · 10 June 2025 21:52

Well, I could grab some old hw (Raspberry Pi 3 !), but well, I takes too much time + my desk is already full of HW and other stuff.
Maybe, that’d be better and faster to test on the real emoncms.org.
I’ve an account on it, but well, if possible, I’d prefer not waste my credits for testing !

We could also define a “test account” on emoncms.org.

awjlogan · 11 June 2025 04:49

@TrystanLea or @glyn.hudson might be able to help? In the meantime, you could just run a local server to look at the HTTP requests? I assume it’s just a POST request, so you could use something like this gist and point the ESPHome to your local IP address.

borpin · 11 June 2025 06:03

There is an HA add-on available.

Emoncms self contained docker container and HomeAssistant Addon - Emoncms - OpenEnergyMonitor Community

Open-Building-Management/emoncms: emoncms home-assistant addon

FredM67 · 11 June 2025 08:57

That’s not the same use-case I think. That’s an add-on to “import” completely an emoncms instance, right ?
From my personal point of view, what I want is to have all my EmontxV4 sensor data in my HomeAssistant to track consumptions, define automations, …

And the mentioned solution is realized with docker. Not sure it’s usefull when using HaOS.

FredM67 · 11 June 2025 14:05

So… http forwarding from inside the component finally works fine.

Btw, I’ve found that the pre-def device for EmonTx4 is wrong on Emoncms.

I don’t know how it looks like on a single phase firmware, but at least for 3 phases, it’s Vx and not Vrms. (already mentioned the discrepancy in the source code).

FredM67 · 11 June 2025 14:48

Should I now go for MQTT ?

awjlogan · 11 June 2025 16:16

You’re on a roll, it seems, so go for it

FredM67 · 11 June 2025 16:53

Lol…
That’s now easier for me to just continue. If I make a break, and the break is too long, I’ll forget a lot and then I’ll have to dive again in it!.

That’d be cool and useful, if someone or better a couple of people test what’s already available.
If everything is ok and stable, I’ll also start the doc…

The only point about this http forwarding where I didn’t do anything yet is the parameter “Fingerprint”. If someone can explain me in details what it is for, perhaps I’ll be able to add it.

Btw, there’s also a webserver on it, to show the data similar to emonESP.
If you want to give a try, here the address: http://82.64.56.179:8080/
Login: admin
Pwd: .emoncms.

alexandrecuer · 11 June 2025 20:13

That’s not the same use-case I think. That’s an add-on to “import” completely an emoncms instance, right ?
From my personal point of view, what I want is to have all my EmontxV4 sensor data in my HomeAssistant to track consumptions, define automations, …
And the mentioned solution is realized with docker. Not sure it’s usefull when using HaOS.

the emoncms addon works on HaOS, it is designed for that. It is not an add-on to “import” completely an emoncms instance. It creates an emoncms server in homeassistant. If you have a backup, you can restore it with the backup module of emoncms… after it works like a classic emoncms server, with all the workers, redis, etc etc

to track an emontx in home assistant with a usb adapter, you can use this add on : GitHub - Open-Building-Management/emontx_sniffer: home-assistant addon sniffer for devices like openergymonitor emontx
cf also
RFM69 id and group resets to i0 and g210 · Issue #1 · Open-Building-Management/emontx_sniffer · GitHub

FredM67 · 11 June 2025 21:38

Well, @Robert.Wall @TrystanLea @awjlogan, should I continue, or just give up?
I think, @alexandrecuer solution is one solution, that sounds for me somewhat “overkill” for a lot of people.
Both solutions can coexist, each with its own user.