Device rebooting every 15min when using PZEM component

ESPHome
1

I’m trying to build an EspHome based power diverter device for my water heater. I already have a working device I built without using any platform and has been running for more than a year. Now I want to migrate it to ESPHome.

I was trying to build it using the same esp8266 nodemcu board that uses the old device, but I could not go any further than adding a dallas temperature sensor because it was constantly rebooting.
So I changed it for an ESP32 I had laying around and now the behavior is more constant.

When the PZEM component is added, the device reboots itself exactly every 15min.

image
image781×232 23.5 KB

(The first third of the graph was using the esp8266)

To me it seems a memory leak or something alike. Isn’t it?
What should be the best way of debugging this?
Should I file a github issue?

...
dallas:
  - pin: GPIO12

uart:
  rx_pin: GPIO14
  tx_pin: GPIO15
  baud_rate: 9600

modbus:

sensor:
  - platform: dallas
    id: sensor_temperature
    name: "${friendly_name} Temperature"
    address: 0xDD0517C47C63FF28
    filters:
      - or:
        - delta: 0.1
        - heartbeat: 300s

  - platform: pzemac
    address: 1
    energy:
      name: ${friendly_name} Energy
    power:
      name: ${friendly_name} Power
    update_interval: 1s

The final board should have:

A temperature sensor
An energy meter
An AC dimmer component (RobotDyn)
Thermostat component
mqtt subcriber sensor for getting the excess production.
Something that acts like a PID controller for driving the dimmer with the excess.
Perhaps a small LCD and a pair of buttons to turn on/off and changing modes.

I still can’t check if it will be possible to integrate all those things on an EspHome device.
What do you guys think?

2

15min is the default reboot_timeout for the Wifi, Mqtt, and the api (check relevant pages). So your problem could relate to connectivity there. You could change each one to help debug? You can also set them to 0s to disable.

You can also try decreasing the update interval of your pzem (try 10sec for initial debugging)

Not sure what esp32 you have, but I think you’d want a good quality one for your application (there’s a thread on them).

ESPHOME should be up to your task though (I think).

3

That’s so interesting as I’m using a wt32-eth01 that is an Ethernet board and i didn’t activate/configure wifi. Is it possible to deactivate the wifi reboot timeout without activating wifi?

Unfortunately i can’t reduce the pzem sampling. This device has to get the power consumption as fast as possible so it can detect changes and prevent inverter overloads.

4

I’m not sure but I assume the wifi reboot timeout is therefore not applicable if you’re not using it? Could be the mqtt or api timeout then?

What you can do it just reduce the pzem update interval temporarily just to check if that’s the cause (I don’t think it is, but it’s worth ruling out).

Edit: I also just noticed this warning.

IMG_20221106_181501
IMG_20221106_1815011080×1555 221 KB

5

Seems that you hit the nail there! The board has 23min uptime and counting.

I use both mqtt (to get the excess production) and the API for home assistant. I had the previous version of the device setup in home assistant so I assumed that this one (wifi → ethernet) was already linked. But as expected the Ip changed, so no API usage.

Anyways it seems odd to me that if HA drops, all the devices would stop working normally and restart every 15min.

Do you know if by not configuring wifi, the adapter is shutdown?

Now I have to start thinking in how to integrate the PID functions I had that works with power and a setpoint instead of temperature.
Given a power setpoint (reserve for charging the battery) it tries to match the excess with the diverter power consumption by driving a 0-255 pwm dimmer.
It could be made by directly scaling the power to pwm, but then there could be 2 problems:
Consumption would raise so abruptely that the inverter would change it’s priorities.
As I’m isolated from the grid, the production has to be forced to raise slowly.

:thinking: :thinking: :thinking: :thinking:

6

Your yaml is missing but are you even sure you need mqtt at all? Can’t you get the “excess production” from HA via the native api? Also if you only want to subscribe you probably don’t even need the full MQTT Client Component — ESPHome but the MQTT Subscribe Sensor — ESPHome would be enough which (I think) doesn’t cause any restarts when not available :bulb:

One more link for you from the FAQ which might be useful:

1 Like
7

Thanks for you suggestion Orange. I will take a look at the subscriber.

I need to decouple the diverter from HA so it works independent from the HA server status. I want all my AC system devices to be like this. Even I previously had an isolated network for the all the PV devices, EV charging and diverter, but had to reintegrate it when a problem arose.

So at the end I’ll be trying to disable the API rebooting, if that’s possible.

EDIT:
MMMMmmmmm… I thought you were talking about something else than:

  # Incoming excess production
  - platform: mqtt_subscribe
    name: "${friendly_name} Available power"
    id: excess
    topic: diverter/available
    disabled_by_default: true
    internal: true

The only additional thing I have configured is the mqtt component, that I guess it’s needed for this to work :wink:

8

BTW It’s normal to always show as offline when it’s connected to ethernet and even has the use_address and domain informed?

9

And that is probably your problem like just expressed in my last post:

No

11

That’s what I was suggesting to the OP here?

12

Oops. Yeah, I saw your suggestion but missed seeing ‘api’ in it, which prompted me to redundantly point out both of them. Sorry. I’ll see if it’ll let me delete mine.

1 Like
13

This project has evolved a bit, and it’s trying to overflow me. Now I’m building a new PID component that it’s decoupled from a climate entity.
There’s not enough documentation from ESPHome and I’ve never built one.
So I’m taking the let’s be calm and stay cool approach. We’ll see what this ends. :sweat_smile:

1 Like
14

I don’t know much about PID controllers but I found this

I also searched for “PID controller” on the Discord forum (the new and old “show off channels”) and there were lots of results.

I think you’ll find something very similar to what you’re doing if you dig on Discord.

Screenshot_2022-11-13-07-34-58-792_com.discord
Screenshot_2022-11-13-07-34-58-792_com.discord1080×2400 261 KB

1 Like
15

Thanks @Mahko_Mahko
The problem with all those PID controllers is that they are focused to temperature control. They drive heating or cooling devices with temperatures as references.

What I want to do is drive power consumptions based on excess production. That has some mmore factors to account. For example it’s useful to have different constant parameters for raising and lowering input, so you can cut loads faster when excess production stops and an overload is possible.

Those PIDs also include their own climate/thermostat entity, but as you’re working with values in 1000 ranges, you end with two thermostats in HA (one more for the heating temperature). And one of them shows absurd values.

1 Like