ESPHome Component for EmonTX (ESPx & PiPicoW)

Hardware emonESP
1

Continuing the discussion from EmonESP - ESPHome Component:

3 years since I first suggested this!

The idea is still to simplify the interface between the EmonTXx and other systems via Wi-Fi rather than RFM69. This is done by using the ESPHome Core and adding on a component specifically for the EmonTX. This approach has a number of advantages:

  • The C++ code base required to be maintained by OEM is reduced resulting in bug fixes and security updates to the base libraries being easily passed onto the ESP device.
  • Updates & configuration changes can be done OTA
  • The interface to HomeAssistant would be simplified and the device work independently from EmonCMS.

ESPHome has changed significantly since I first suggested this, with the core developer now part of the HA family and the integration to HA tighter and the support on a more professional footing.

I have a basic component up and running on a WEMOS D1 Mini and when ESPHome support for the PiPico chip (RP2040) arrives on Wednesday, I intend to try that out. It should ā€˜just workā€™. The Component in itā€™s current form can be found here GitHub - openenergymonitor/esphome_components: ESPHome Components with my working fork here GitHub - borpin/esphome_components: ESPHome Components.

However, for this component to work more widely, the EmonTX firmware needs to be modified to output a JSON string (again discussed elsewhere).

If anyone with some C++ skills wants to chip in, they would be very welcome as Iā€™m reaching the limit of my C++ knowledge.

Things to do:

  • Add HTTP interface (possibly including compression)
  • Add a configuration item for scale to the Pulse output (currently assumes 1 pulse = 1 watt)
  • Investigate the SPI interface to the RFM69 chip
  • Investigate being able to modify the EmonTX settings from ESPHome
  • Investigate moving the I2C and OneWire sensors to be read directly by this device. This would widen the sensors supported by the EmonTX.
3 Likes
2

@awjlogan - if you are looking at this, Iā€™d suggest two components

  1. A component to read the data from the TX Serial
  2. A component to send the data to emoncms. Using a Lambda to send the data by MQTT is horribly clunky. Could provide an option for MQTT or HTTP API then it could go to emoncms.org.
1 Like
3

@borpin - apologies, Iā€™ve only just had a chance to have a look properly at this. Looks great - Iā€™ll start having a play with it!

On the todo items, the emonPi3/Tx++ can easily do the OneWire interface and thereā€™s an expander on board for I2C and Iā€™ve left the temperature API agnostic to the actual sensor being used. We can skip the SPI interface and directly interface with the UART (using the existing header) - I put JSON support in to match the Tx4/Pi2 firmware, and this is clearly where it came from!

As it interfaces with the UART on the Pi3, if ESPHome supports commands being sent to a destination, it could configure it directly.

Currently, I have a USB-C header on the ESP board for programming - this seems a bit clunky (as thereā€™s already a USB-C connector on the Pi3), so Iā€™ll also look at programming the board through the Pi3 as well (Iā€™m not too familiar with Espressifā€™s stuff yet).

In the meantime, I can make you an ESP board up (probably, have to check my part stash) and after Iā€™m happy it works, could send you one to use as well?

1 Like
4

Great - Iā€™m a real fan of this approach. I think my fork may be more up-to-date with what I am using - I really canā€™t remember!

Yes, I got @TrystanLea to add the JSON option :slight_smile:

One of the advantages of an ESPHome component is that it then integrates with HA easily.

Secondly, you can configure ESPHome on the device to be ready for a ā€˜first useā€™ scenario by a user.

Iā€™m pretty sure ESPHome will communicate over any interface you like :slight_smile:

1 Like
5

Quick skim of the ESPHome documentation suggests that the UART Component would be a reasonable place to start. It does support transmit from the ESPHome as well, so could be used to configure the Tx/Pi in situ.

Looking at Brianā€™s Tx4 module, one question I have would be how to generalise it so the JSON decoding is not static. That is, the Pi3 can support 3 digital (OneWire or pulse) or 1 extra analog and 2 digital (OneWire or pulse) inputs. The number of temperature sensors is not defined but is detected at start up. There is a defined maximum for static allocation, but unlikely to be used in practice so youā€™d end up with a lot of empty entries (ā€œT5ā€: 30000, ā€œT6ā€: 30000 ā€¦). See what I can come up with - I also need to set up HA so I can test things :slight_smile:

6

I think the JSON Decoding needs to move into the component itself to make it faster (I tried but could not work out how).

You can then create a configuration within the yaml to tell it what interfaces to use, and what sensors to create.

You donā€™t really. The HA integration is automatic once the sensors are created by ESPHome :slight_smile:.

There is the Web Tools that you can use (I think) plus the Web Component.

ESP Web Tools (esphome.github.io)

The Discord Channel is pretty good if you can get them to engage.

7

Thanks Brian, thatā€™s very useful :slight_smile:

1 Like