This is the foundation post for the rest of my Home Assistant energy series (if I ever get to it). Before I could automate around electricity, I obviously needed a (real-time) view of what’s actually flowing in and out.

Some context first

• I have solar panels (with a Huawei inverter installed by the previous owner)
• Smappee EV charger (bad purchase, it’s quite dumb and has a terrible UI and Home Assistant can’t control it),
• and I recently got 2x Marstek batteries (great hardware, cheap, and the worst software ever, truly terrible software. Oh and support started ghosting me after I lost my patience around Lunar New Year — they just will not reply to any of my help messages anymore).
• I drive a Polestar 4 (first edition, 2025)

note: the original Huawei inverter was dead when I moved in and likely never worked, don’t think the previous owners ever noticed & it got replaced under warranty after a lot of chasing and nagging Huawei directly. Rensol couldn’t move it forward and I basically asked to be cc’ed in the ticket and got my PA to chase Huawei with all het wrath. Great service from both Huawei and Rensol…

So that’s that… ;)

SlimmeLezer

… And more context.

I use a SlimmeLezer+ with my P1 port (Fluvius smart meter). As ESPHome has significantly changed since I got mine and it wouldn’t compile on a recent release, here’s my working config. ¯\(ツ)/¯

The SlimmeLezer used to be entirely powered by the P1 port but brownouts did happen; my initial config tried to limit memory and WiFi usage in an attempt to prevent these brownouts)… As this is no longer much of an issue (see below), I’ve stopped optimising that. But YMMV depending on your setup.

As the Marstek CT also uses the P1 port and I needed a splitter: I started off with a passive splitter but it was quite clear from the get-go that there were tons of issues (both meters were powered over P1). It’s been a while but I think roughly half the messages didn’t go through to SlimmeLezer (IIRC the message would just be forwarded across the two ports but would be too weak to be consistently read or something). I then got an active P1 splitter. As I only had one power plug available, I’d power either the splitter or the SlimmeLezer over a USB-C PSU… But what really fixed it and brought stability was doubling the power sockets: the splitter is powered over P1 power, both the SlimmeLezer and the Marstek CT have their dedicated power in via USB-C.

Honestly, I had a lot of issues with the Marstek CT, to the point they actually shipped me a replacement unit. In hindsight I don’t think it was broken, more a mix of crap software + P1 power issues + delayed/laggy Marstek dashboards + …

The setup, end to end

                ┌─────────────┐
                │ Solar panels│
                └──────┬──────┘
                       │ DC
                ┌──────┴──────┐
                │   Huawei    │── fusion_solar (cloud)
                │   inverter  │
                └──────┬──────┘
                       │ AC
        ───────────────┴───────────────  ← house AC bus
        │              │                │
  ┌─────┴──────┐ ┌─────┴──────┐  ┌──────┴────────┐
  │ Marstek    │ │ Fluvius P1 │  │ Smappee EV    │
  │ Venus E ×2 │ │ smart meter│  │ Wall + CTs    │
  │ (1× CT003) │ └─────┬──────┘  └──────┬────────┘
  └─────┬──────┘       │ RJ12, DSMR     │ (cloud; read-only)
        │ Modbus       │                │ 
        │ TCP   ┌──────┴──────┐         │
        │       │SlimmeLezer+ │         │
        │       └──────┬──────┘         │
        ▼              ▼                ▼
        ┌────────────────────────────────┐
        │       Home Assistant           │
        └────────────────────────────────┘

SlimmeLezer is fire-and-forget (at least as long as you don’t update ESPHome). Huawei is a cloud-poll. Marstek is local Modbus (but Modbus/battery BMS or firmware does crash and gets stuck. Restarting the integration sometimes fixes it). Smappee, cloud-only, can only read data (as opposed to telling it when to, for example, start/stop charging my EV).

Sensors

What you get out of it, sensor-wise:

sensor.slimmelezer_power_consumed — instantaneous import (kW)
sensor.slimmelezer_power_produced — instantaneous export (kW)
Per-phase power in / out
Per-phase voltage and current
Cumulative energy import + export per tariff
Gas consumption (if you have a gas meter on the same connector)

That’s all I need to know whether I’m paying or selling at any given moment.

The SlimmeLezer YAML

Stock Zuidwijk firmware with three small tweaks and a few changes to get it to compile on the latest ESPHome at the time of writing):

1. output_power: 14dB on the WiFi to fit inside the P1 250mA budget without rebooting (before getting an active splitter and dedicated power).
2. rx_buffer_size: 1200 on UART (down from default 1700). Belgian P1 telegrams are well under 1200 bytes; saves ~500 bytes of heap which the ESP8266 will thank you for.
3. A “Last Restart” and “Last Time Sync” template sensor so I can spot if the device has flatlined.

---
substitutions:
  device_name: slimmelezer
  timezone: "Europe/Brussels"
  domain: ".iot.internal"
  wifi_fast_connect: "false"

esphome:
  name: ${device_name}
  name_add_mac_suffix: false
  project:
    name: zuidwijk.slimmelezer
    version: "2.0"
  on_boot:
    then:
      - if:
          condition:
            lambda: return id(has_key);
          then:
            - lambda: |-
                std::string key(id(stored_decryption_key), 32);
                id(dsmr_instance).set_decryption_key(key.c_str());
          else:
            - logger.log:
                level: INFO
                format: "Not using decryption key. If you need to set a key use Home Assistant service 'ESPHome: ${device_name}_set_dsmr_key'"

esp8266:
  restore_from_flash: true
  board: d1_mini

mdns:
  disabled: false

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: "${wifi_fast_connect}"
  domain: "${domain}"
  # Powersaving for brownout due to 250mA restriction P1
  output_power: 14dB

logger:
  level: INFO
  baud_rate: 0

api:
  reboot_timeout: 15min
  encryption:
    key: !secret encryption_key_slimmelezer
  services:
    service: set_dsmr_key
    variables:
      private_key: string
    then:
      - logger.log:
          format: Setting private key %s. Set to empty string to disable
          args: [std::string(private_key).c_str()]
      - globals.set:
          id: has_key
          value: !lambda "return private_key.length() == 32;"
      - lambda: |-
          std::string pk_str(private_key);
          if (pk_str.length() == 32)
            pk_str.copy(id(stored_decryption_key), 32);
          id(dsmr_instance).set_decryption_key(pk_str.c_str());

ota:
  platform: esphome
  password: !secret ota_password
  on_error:
    then:
      - logger.log:
          format: "OTA update error %s"
          args: ["x"]

dashboard_import:
  package_import_url: github://zuidwijk/dsmr/slimmelezer.yaml@main
  import_full_config: true

time:
  - platform: homeassistant
    id: homeassistant_time
    timezone: "${timezone}"
    on_time_sync:
      then:
        - text_sensor.template.publish:
            id: last_time_sync
            state: !lambda 'return id(homeassistant_time).now().strftime("%Y-%m-%d %H:%M:%S");'
        - if:
            condition:
              lambda: 'return id(device_last_restart).state == "";'
            then:
              - text_sensor.template.publish:
                  id: device_last_restart
                  state: !lambda 'return id(homeassistant_time).now().strftime("%Y-%m-%d %H:%M:%S");'

globals:
  - id: has_key
    type: bool
    restore_value: yes
    initial_value: "false"
  - id: stored_decryption_key
    type: char[32]
    restore_value: yes

uart:
  baud_rate: 115200
  rx_pin: D7
  # Drop DSMR/UART buffers from 1700 → 1200 (Belgian P1 is fine at 1200; saves ~500–600 bytes).
  rx_buffer_size: 1200

dsmr:
  id: dsmr_instance
  max_telegram_length: 1200

sensor:
  - platform: dsmr
    energy_delivered_lux:
      name: "Energy Consumed Luxembourg"
    energy_delivered_tariff1:
      name: "Energy Consumed Tariff 1"
    energy_delivered_tariff2:
      name: "Energy Consumed Tariff 2"
    energy_returned_lux:
      name: "Energy Produced Luxembourg"
    energy_returned_tariff1:
      name: "Energy Produced Tariff 1"
    energy_returned_tariff2:
      name: "Energy Produced Tariff 2"
    power_delivered:
      name: "Power Consumed"
      accuracy_decimals: 3
    power_returned:
      name: "Power Produced"
      accuracy_decimals: 3
    electricity_failures:
      name: "Electricity Failures"
      icon: mdi:alert
    electricity_long_failures:
      name: "Long Electricity Failures"
      icon: mdi:alert
    voltage_l1:
      name: "Voltage Phase 1"
    voltage_l2:
      name: "Voltage Phase 2"
    voltage_l3:
      name: "Voltage Phase 3"
    current_l1:
      name: "Current Phase 1"
    current_l2:
      name: "Current Phase 2"
    current_l3:
      name: "Current Phase 3"
    power_delivered_l1:
      name: "Power Consumed Phase 1"
      accuracy_decimals: 3
    power_delivered_l2:
      name: "Power Consumed Phase 2"
      accuracy_decimals: 3
    power_delivered_l3:
      name: "Power Consumed Phase 3"
      accuracy_decimals: 3
    power_returned_l1:
      name: "Power Produced Phase 1"
      accuracy_decimals: 3
    power_returned_l2:
      name: "Power Produced Phase 2"
      accuracy_decimals: 3
    power_returned_l3:
      name: "Power Produced Phase 3"
      accuracy_decimals: 3
    gas_delivered:
      name: "Gas Consumed"
    gas_delivered_be:
      name: "Gas Consumed Belgium"
  - platform: uptime
    name: "SlimmeLezer Uptime"
  - platform: wifi_signal
    name: "SlimmeLezer Wi-Fi Signal"
    update_interval: 60s
  - platform: template
    name: "Free Heap"
    lambda: |-
      return (float)system_get_free_heap_size();
    unit_of_measurement: "bytes"
    accuracy_decimals: 0
    entity_category: diagnostic
    icon: "mdi:memory"

text_sensor:
  - platform: dsmr
    identification:
      name: "DSMR Identification"
    p1_version:
      name: "DSMR Version"
    p1_version_be:
      name: "DSMR Version Belgium"
  - platform: wifi_info
    ip_address:
      name: "SlimmeLezer IP Address"
    ssid:
      name: "SlimmeLezer Wi-Fi SSID"
    bssid:
      name: "SlimmeLezer Wi-Fi BSSID"
  - platform: version
    name: "ESPHome Version"
    hide_timestamp: true
  - platform: template
    name: 'Last Restart'
    id: device_last_restart
    icon: mdi:timeline-clock
    entity_category: diagnostic
  - platform: template
    name: "Last Time Sync"
    id: last_time_sync
    icon: mdi:clock
    entity_category: diagnostic

Drop that into ESPHome, set your WiFi/encryption secrets, flash, and the device will appear in HA’s ESPHome integration with all the sensors above.

I’m very happy with the SlimmeLezer+ and got my parents one too.

I recently got a WP6003 Air Box (Aliexpress). The official product page seems to be offline but can be accessed through Archive.org.

It's quite straightforward to integrate in a Bluetooth Proxy and Home Assistant thanks to Omar's work.

The major problem I have with it, is that the Bluetooth (4.0) range is terrible. Neither my Mac Mini nor my Bluetooth Proxy could connect with it if I moved it from the office to the kitchen (had it on top of the fridge, so some metal there) that's roughly 10ish meters away.

Sensor wise, I've only had it working for a few days, and so far, it doesn't seem to be very accurate. The temperature is 1-2° below my other sensors... But hey, it's quite cheap and the previous tool I linked has a way to calibrate it (but I haven't tried that yet).

In the screenshot, Airquality level converts bytes into meaningful sensor readings:

• Temperature: Extracted from bytes 6 and 7, then divided by 10 to get the temperature in degrees
• TVOC (Total Volatile Organic Compounds): Extracted from bytes 10 and 11, then divided by 1000 to get the concentration in parts per
• HCHO (Formaldehyde): Extracted from bytes 12 and 13, similarly processed to TVOC.
• CO2 (Carbon Dioxide): Calculated from bytes 16 and 17, adjusted by subtracting 150 to correct the baseline.

Each of these values is then published to different sensor IDs within ESPHome, allowing Home Assistant to display and use this data.

The function returns the size of the data packet as a float, which can be used for debugging or validation. In my case (and assume yours as well) it's 18. I've marked it as internal: true in my config, as it's not useful to show once it's working.

My config for ESPhome can be found here.

You can use this tool to read out the sensor (and find the MAC address) from Chrome.

Guess it's a bit hard to show (and for some reason Firefox refused to take a screenshot of the entire page) but this is my current view in Home Assistant.

Note that I have since added 3 more ATC Xiaomi thermometers and hidden Airquality levels.

In my Home Assistant quest and simplifying (not sure if that's actually happening) and getting more control (aka less reliant on the cloud and 3rd parties) I've been playing with Zigbee.

Zigbee is quite cool because it's a mesh network. As I used it before with my Philips Hue bulbs, I was eager to expand and play with Zigbee.

First thing first. Not all routers are equal. I've got these two smart power plugs as an example (Grey and Blue colour, v2 with HomeKit support) and they act weirdly. They don't seem to route sensors properly, and randomly turn off whatever is plugged in.

The one that seems to work reliably well is this orange Zigbee plug.

Compared to my bulbs (more on that here) the sensors do detect them the two aforementioned power plugs, and do connect, but generally little to no data flows. I'm not entirely sure what the issue is (bad antenna, bad routing software) but the consensus on the internet seems to be: add more routers, don't trust some routers (Ikea and Hue seem decent), and not all endpoints are very smart and pick the best router (so may need to repair or force it to join a specific router). Unlike WiFi, in this case it seems that more is better.

When setting up the network, it's also recommended to first set up and pair the routers and then the endpoints (battery-powered sensors).

And the network takes a while to stabilise (and all routes to be learned). Some people even suggest waiting one or two days for the dust to settle.

Moving routers screws up a lot, too. I've had sensors stop working (and refusing to pair again) after moving some routers and turning some off -- routers that weren't used by said sensors. So really odd stuff.

As always, with Aliexpress, it's very much unclear what the brand/model is, but according to Z2M, all three are TS011F, but two of the three are definitely different (has Apple Homekit support and the plugs are bigger).

The energy (kWh) and Power (W) reporting works well, though, on all three models.

Can see when a charger is plugged in, and charging a MacBook Air.

I'm buying EU plugs because I'll be relocating back to Europe in the next 6 months. So I'm slowly getting rid of my UK smart plugs and replacing them with EU plugs.

Note that these plugs are not approved for (official) sale in Belgium though: child safety is not up to spec and the grounding is not approved (i.e. needs to be a pin). 

In my Home Assistant quest and simplifying (not sure if that's actually happening) and getting more control (aka less reliant on the cloud and 3rd parties) I've been playing with Zigbee.

Zigbee is quite cool because it's a mesh network. As I used it before with my Philips Hue bulbs, I was eager to expand and play with Zigbee.

I have several bulbs, including: Hue Iris, Hue Go, some random bulb, a reading spot, and Hue Play (3x).

My Home Assistant setup uses the Skyconnect. I've updated the firmware (on a Mac) to use Ember firmware as ezsp will be deprecated soon(™).

At the time of writing you can't update the firmware directly from HA just yet, you need another device.

As I had two Zigbee networks (one for Hue, and one for my sensors and Ikea bulb) it made sense to merge them (and have one less connected bridge): it would reduce interference, and the bulbs all act as a router, so that would greatly improve my network coverage and stability.

Generally speaking, it went quite smoothly: delete the devices in the Hue app (it factory resets them and puts them in pairing mode) and then pair them in Zigbee2Mqtt (I use that over ZHA).

However, my main issue was that my Zigbee bulbs were unreliable: it sometimes worked, but often it lagged or timed out. Especially when controlling multiple bulbs at once (such as a big room such as the living room) or sending multiple commands in sequence (on/off/on/off).

In hindsight, my sensors were unreliable as well: there was data missing, and it didn't properly broadcast/update every 5 minutes. I first thought it was just because they were cheap Chinese (TuYa) sensors using battery-power. If the temp or humidity didn't change enough, it wouldn't broadcast.

I often saw errors such as these in Z2M:

2024-05-26 22:29:02Publish 'set' 'state' to 'Hue Play Right' failed: 'Error: ZCL command 0x0017880104d89bc4/11 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed ({"target":29608,"apsFrame":{"profileId":260,"clusterId":6,"sourceEndpoint":1,"destinationEndpoint":11,"options":4416,"groupId":0,"sequence":110},"zclSequence":244,"commandIdentifier":11} timed out after 10000ms)'

But the annoying thing (in debugging, and thinking the network "needs to settle") was that it often worked just fine, and then randomly started breaking down/time outing when I thought it was finally solved.

I almost gave up and went back to a Hue bridge, when I asked for some advice on Discord. The reason was the channel...

First off: check the Zigbee channel of your Hue. It's likely 25. Z2M uses channel 11 by default.

There are 4 channels that are getting the least WiFi interference. These are called ZLL channels (whatever that stands for): 11, 15, 20, 25. However, it seems that 11 is quite terrible, and I would not recommend using it.

My Z2M sat on Channel 11 (which is Channel 1 for WiFi). I live in Singapore, in an apartment building, with a shit-ton of WiFi, hence the massive interference and lag on Zigbee.

Also, 2.4Ghz WiFi is generally 20Mhz channel width, whereas Zigbee is 2Mhz, so one WiFi channel overlaps many Zigbee channels. 

You can modify the channel (via the config file in /homeassistant/zigbee2mqtt/configuration.yaml) by adding the following and restarting the Z2M container:

advanced:
  [...] # there should already be a ton of things
  channel: 25

The problem with changing the channel, is that it requires repairing (some of) the Zigbee devices. And it's a total mess to repair Hue bulbs once they are no longer on a Hue bridge.

There's no need to remove the devices from Z2M as that will wipe their configs (I believe). It's possible that removing the devices from Z2M will put them in pairing mode again (for Hue bulbs, see below) but I couldn't get a confirmation.

Ikea has the 6x power off/on sequence that resets them, but Hue dropped support for something similar in some firmware upgrade (why?!?!).

TouchLink is another option, but that didn't work for me at all.

Some Hue bulbs can be reset by long pressing (30-60seconds) the power button (for example the Hue Go), but what worked best for me is pairing them again on the Hue bridge using the serial (force pair), deleting them again, and pairing on Z2M.

However, I didn't have the serial of two bulbs: one Hue Play has the label missing, and the Hue Iris didn't have any label at all. I thought I would be forced to go and purchase a Hue dimmer/remote control (that comes with TouchLink and allows resetting the bulbs)...

However, suddenly, after an hour or two of messing around, the Hue bulbs that weren't repaired just started working again.

So it seems that if they are disconnected from their bridge for a while, they start changing channels until they find the bridge again. I guess there's a chance, with enough patience, that I didn't have to repair my Hue bulbs (not sure about Ikea, and I would definitely not trust my Chinese Power plugs and sensors to come back online).

The sensors are quite easily repaired (long press the pairing button or pinhole and done -- don't forget to set Z2M in Permit join)

Other stuff you can try if the range or network sucks can be found here.

However, if it kinda works, you better not mess with it... :)

I've finally started working with Home Assistant and while the learning curve has been steep, it's been fun.

I'm going to post some random notes (mostly for myself) on things I discovered, and I need to keep in mind.

For example, I have set up an ESP32-c3 Bluetooth Proxy for a Mi ble thermometer.

I've assigned the ESP device to an area: IT cabinet. However, the BLE sensors are scattered across the house (in different areas). Took me a while to figure it out, but you can assign entities to specific areas.

Head to Entities and select the entity config, and at the bottom, unselect use device area, and select the correct area.

Tadaaa, you can now assign the sensors to the correct area, and they'll show up in the right dashboards/cards.

The proxy config can be found here.

I have set up an ESP32-c3 Bluetooth Proxy for a Mi ble thermometer (and I have a few other BLE sensors that I haven't managed to set up yet).

The proxy config can be found here.

Be sure to modify the variables to match whatever you want to do. I'm using static IPs because auto discovery is unreliable (hostname.iot.internal).

You'll also need to add the !secret variables into the secrets.yaml file.

Note that there's an issue with Bluetooth and WiFi on single cores (i.e.: the ESP locks up as it can't do both at boot). The workaround is in that config file.

Use on single-core chips

On dual-core devices the WiFi component runs on core 1, while this component runs on core 0. When using this component on single core chips such as the ESP32-C3 both WiFi and ble_tracker must run on the same core, and this has been known to cause issues when connecting to WiFi. A work-around for this is to enable the tracker only while the native API is connected. The following config will achieve this:

esp32_ble_tracker:
  scan_parameters:
    continuous: false

api:
  encryption:
    key: !secret encryption_key
  on_client_connected:
    - esp32_ble_tracker.start_scan:
       continuous: true
  on_client_disconnected:
    - esp32_ble_tracker.stop_scan:

Esphome

To flash the Mi thermometer, use this flasher and the firmware from here.

Example output of the log (from Esphome in Home Assistant directly, but can be seen from the web interface as well):

You can then add the proxy (and the entities) in Home Assistant. It should update every couple of minutes (the Mi device updates every 5 or so minutes, the Proxy scans every channel every 3-ish minutes).

In the example above, I (at the time of writing) only have one Bluetooth sensor, but it should be quite trivial to add more. The hardest part is finding the right MAC address of the sensors... :)

Recently visited Ikea and had to get a Christmas star-light like I used to have during my childhood.

Most of my (non-track) light at home is smart using either a TP-Link Kasa smartplug or Philips Hue (and I want to avoid adding more brands, more apps, and more shit). However, Philips Hue is quite $$$ and not always all that easy to get in Singapore (shady retailers, limited stock, not many options).

I knew that Tradfri was technically compatible with the Hue Bridge, but never made the jump as I just wanted things to work (don't want to mess around with lights). Until today. Figured I may as well give it a go.

Surprisingly, everything worked out of the box. I had to do a factory reset (not sure if that's because I kept the light on for ~10 minutes before trying to set it up, or if this was a returned product as clearly the box had been opened before)...

• Turn on light
• Reset light by turning it off and on 6 times
• Open Philips Hue app and search/add light
• Tada... Should work

Side note: it requires a modern firmware (and I assume all lights being sold today have said firmware, but if for some reason you end up with old stock, you may need to update). To update you need the Ikea Bridge though (or... apparently the dimmers/buttons may work as well -- did not test).

All the controls are working as well (dimming, changing colours, etc).