ESP Home - Power meter reading with PoE - Homeassistant
Introduction
I have been living in my current apartment for two years. From the first day, I had been using Home Assistant, and my installation has grown continuously since then (I don't see an end to this development until now ^^^). To track my energy consumption, I used an intermediate meter with Modbus so far.
Last week, I had a little wish and I had an e-car. The problem was that the consumption of the Wallbox could no longer be detected, as my Modbus intermediate counter is installed in the UVT (subdivision) within the apartment. The Wallbox is connected directly to the HVT (main distributor) in the basement. Accordingly, I could no longer fully record my total consumption. This problem – along with the fact that I had no way to track negative consumption (my balcony power plant feeds into the public network) – has finally moved me to read my main counter. So my journey started...
Main part
Requirements for everything to work - energy and network...
Unfortunately, I do not have the luxury of a home, so I have to adapt more or less to the conditions of the counter space. In my case, this means that, unlike in my apartment, I cannot open walls to transfer cables. This led me to face the following challenges at the beginning:
No network connection of any kind.
No electricity (ironically directly at HVT^).
I had to solve both first, which is why I quickly went to search for a suitable solution. In my case, the Other Use of an existing empty tube which was actually intended to lead optical waveguides (LWL) into the apartment. However, there is no LWL until today, and I do not assume that this will change in the near future.
This enabled me to start my first PoE project (Power over Ethernet) – an opportunity that I naturally took directly.
So I put a network cable from my utility room (HWR) in the apartment to the cellar. So I finally had both energy and network available. The next step was to select the appropriate hardware.
Hardware selection Microcontroller
As so often, when selecting the hardware, you have the skill of choice. My requirements for the hardware are incredibly modest. I need a microcontroller that somehow makes PoE after 802.3af or similar, is compatible with ESPHome and is pleasant to store. So for the first time nothing special and accordingly is the selection.
My favourites were:
- Selfbuilt (creating a board with exactly my wishes)
- ESP32-POE-ISO
- LilyGo T-Internet POE
In the end, it became LilyGo T-Internet POE. Small tip on the edge: If you also want to buy a PoE module, use the linked manufacturer pages (no commission). These are significantly cheaper than Amazon.
A little over electricity meters aka. Modern measuring devices...
I live a quite new building from 2021, and therefore I am lucky that my counter is already a so-called "modern measuring device". In my case, it is a counter of the EMH brand, more precisely the EMH eHZB. This counter has two interfaces that are accessible to me (usually there is another, more powerful interface on the back side, which can transfer significantly more data).
- IR pulse LED – This charming little hole on the front of my counter indicates a number of n pulses per kWh (in my case 10,000). I can potentially track my consumption on the basis of the impulses and thus determine the count and performance. The problem: inaccurate measurements – There are many solutions, but most have difficulties and occasionally skip one or two impulses, which leads to drift errors over a medium to longer period of time. This interface is therefore rather unusable for a smart home.
- The "optical interface" – This interface always consists (almost) of two components. The first is a light sensor or a “optical operating element” with which the current meter can be controlled. This means, for example, you can view consumption values of the last days, months or the year, enter a PIN or (most importantly for me) adjust the data communication modes. For more information, see the instructions of your counter. The second component is the "optical data interface" or also "customer interface". This allows the customer (so you as a customer) to read the data of the counter. The optical data interface uses a protocol called SML (Smart Meter Language). SML is the protocol we will ultimately read out to receive our data. The advantage of SML is that it is a foreseeable protocol that sends data – even with the possibility of checking the numbers. But this is not the focus for the first time and is not to be deepened further here.
Next we should be the term OBIS key figures to introduce. OBIS metrics categorize the transmitted data and enable a simple, standardized assignment. Codes 1.8.0 and 2.8.0 are examples of such OBIS numbers. It is important that OBIS metrics are standardised, but not every manufacturer or measuring device supports all OBIS codes (which is not possible by default as these codes are used in several industries). There are several identifiers that are always present, but 1. are not all available on the customer interface, and 2. the counter may have to be configured first to get all relevant values. But later more...
With the second approach, we have a pretty cool way to read out our data without having many problems. But how do we do that now?
Hardware selection - Power meter reading...
We already have a matching microcontroller, but somehow the data from the counter to the microcontroller have to build something to the optical data interface... the question is how is it? The solution to this is surprisingly quite simple. As it seems, have All Measuring devices installed around the interface a fairly strong magnet. This has the advantage for us that the fastening is absolutely simple. The hardware selection is also quite simple, because there is more or less an “industrial standard” in the maker scene and this is the Hichi TTL. Here again it is significantly cheaper to buy the Hichi via the “manufacturer”. In this case, you save about 50% if you here Buy (No commission... It is simply cheaper.
Implement
Now to the fun part: the implementation of the entire solution. To do this, we add all parts together, which ultimately means that we connect four cables to the ESP board: voltage (3.3 V and GND) as well as data (TX and RX).
Once everything is assembled, you should first find out what your own counter can do. With me it was (and probably with you) necessary to enter the PIN of the measuring device. You receive the PIN from your network operator or Measuring point operator (Important: This can be someone else than your power provider!). Once the PIN has been entered, you should deactivate it in the best case in the main menu of the counter. In my case this was so: I held the optical interface for about a second to the lamp, then repeated briefly until “PIN” appeared on the display, and confirmed this.
It may also be necessary to activate the “complete record”. By default, counters send a “reduced data set” that does not contain instantaneous active power, but only the manufacturer identifier, the model and the consumption (1.8.0 and 2.8.0). In order to get the “complete record” you must go on in the menu until “Inf” is displayed (in other models the setting can also be named differently) and set this option to “On”.
Now we can start configuring the ESP software. My wish was, ESPHome use as comprehensive as possible to build a homogeneous software landscape with simplified maintenance. Therefore, the use of Tasmota, as described in many other blog posts, not meaningful...
Configuring ESPHome...
The configuration of ESP Home can differ depending on the environment. In the following, I simply show my configuration and this can be adjusted accordingly.
For the first attempt and to find out what the counter can do, only the part should be copied until before "sensor".
esphome:
name: stromzaehler-main
friendly_name: Stromzaehler_Main
esp32:
board: esp32dev
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "<<key>>"
ota:
- platform: esphome
password: "<<password>>"
ethernet:
type: LAN8720
mdc_pin: GPIO23
mdio_pin: GPIO18
clk_mode: GPIO17_OUT
phy_addr: 0
manual_ip:
static_ip: <<ip>>
gateway: <<gateway>>
dns1: <<dns>> (optional)
subnet: <<subnet -> meistens: 255.255.255.0)
uart:
#Hier müssen die PINs (GPIO) eingetragen werden, die zum Lesekopf gehen...
id: uart_bus
tx_pin: 14
rx_pin: 12
#Die Baudrate bestimmt der Zähler. In meinem Fall 9600 baud
baud_rate: 9600
# Der Debug Mode zeigt später was der Zähler alles kann.
debug:
sml:
id: mysml
uart_id: uart_bus
sensor:
- platform: sml
name: "Total energy In"
sml_id: mysml
obis_code: "1-0:1.8.0"
unit_of_measurement: kWh
accuracy_decimals: 3
device_class: energy
state_class: total_increasing
filters:
- multiply: 0.0001
- throttle_average: 300s
- platform: sml
name: "Total energy Out"
sml_id: mysml
obis_code: "1-0:2.8.0"
unit_of_measurement: kWh
accuracy_decimals: 3
device_class: energy
state_class: total_increasing
filters:
- multiply: 0.0001
- throttle_average: 300s
- platform: sml
name: "Current Power"
sml_id: mysml
obis_code: "1-0:16.7.0"
unit_of_measurement: W
accuracy_decimals: 0
device_class: power
state_class: measurement
- platform: sml
name: "Current "
sml_id: mysml
obis_code: "1-0:31.7.0"
unit_of_measurement: A
accuracy_decimals: 2
device_class: current
state_class: measurement
filters:
- multiply: 0.01
- platform: sml
name: "Current Frequency"
sml_id: mysml
obis_code: "1-0:14.7.0"
unit_of_measurement: Hz
accuracy_decimals: 3
device_class: frequency
state_class: measurement
filters:
- multiply: 0.1The first part (until "sensor:") can now be flashed to the ESP, so we can now find out what the counter can send, as this can differ from manufacturer to manufacturer.
If the reading head is already correct, the output should include the following:
[...]
[18:34:31][D][sml:078]: OBIS info:
[18:34:31][D][sml:084]: (0a01454d480000aae351) 1-0:96.50.1 [0x------]
[18:34:31][D][sml:084]: (0a01454d480000aae351) 1-0:96.1.0 [0x----------------]
[18:34:31][D][sml:084]: (0a01454d480000aae351) 1-0:1.8.0 [0x-----------------]
[18:34:31][D][sml:084]: (0a01454d480000aae351) 1-0:2.8.0 [0x-----------------]
[18:34:31][D][sml:084]: (0a01454d480000aae351) 1-0:16.7.0 [0x-------]
[...]What can be seen here are the data that the current meter sends. The codes can be checked. Here is what sends mine (and if you see the same numbers behind the ":" also your...
- 96.50.1 -> Manufacturer ID
- 96.1.0 -> Burial Identification
- 1.8.0 -> Counter level Import (network cover) -> Unbound (If you have a tariff counter, there may also be 1.8.1 and 1.8.2
- 2.8.0 -> export counter reading (net import, e.g. from a PV system with surplus feed)
- 16.7.0 -> Current active power
Here you will find a document from the network operator "Avavcon", which are by far not all codes, but the document is really very well built and understandable.
From here on, the remaining configuration is quite simple. The second part of the configuration can now be copied or adapted. As an example:
- platform: sml
name: "Current "
sml_id: mysml
obis_code: "1-0:31.7.0"
unit_of_measurement: A
accuracy_decimals: 2
device_class: current
state_class: measurement
filters:
- multiply: 0.01First, ESPHome must be told that we would like to use the Smart Language protocol (platform: sml).
The Obis code is removed from the dump.
Accuracy is defined on the basis of the counter instructions and may vary if necessary.
Lastly, the filter can be found either by try and error or from the instructions.
Finally, the updated configuration has to be flashed and then it can start...
Final
Within approx. 30 minutes it is possible to read a power meter quite reliably with ESPHome. It is important to check whether the pin is entered and whether there is an advanced mode if you want to have the instantaneous power. Surprisingly, the latter has not mentioned a blog post so far and only with the instructions I could find this information ^^^.
Finally, there is a 3D pressure housing and now the ESP works with me in the connection room. With PoE, I have no more maintenance.
If you have any questions, you can send me an e-mail mail@pure-smart.de send.
Back…