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.
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?
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).
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.
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).
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.
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
One more link for you from the FAQ which might be useful:
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
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.
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.
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.