Features for non ESP-Home Firmware

[Lonestar78]

Hi All,

@nliaudat - really nice work :-)

i currently started working on a non-ESPHome Firmware (no complaint on the existing, just personal preferences), Arduino for ESP32 based.
Features planned:

• Wifi Manager for initial Configuration over WebUI to avoid hard coded configs & MQTT config over the same way
• Web Interface for configuration and manual usage of floor heating system (number used channels plus naming, manual initialization of valve motors, manual open/partial/close)..., including multiple thermo elements (i will do only ds20b18, maybe subsribe to MQTT available sensors as well, for room temperatures)
• end then the core....automated dynamic hydraulic equalizing by ensuring constant deltaT in each water circuit combined with room targets...on this i need to think a little bit how to do that from algorithm perspective.
• openhab integration example (via MQTT and rules)

So, what else do we need in this?

Kind regards
Christian

[nliaudat]

Hi,

Esphome Way

Wifi setup can be done without hard config be enabling AP mode and MQTT Client the same way.

For webserver, it's disabled by default but you could enable it in config.yaml

web_server:
  port: 80  

It enable the REST API too, so the automation can be controlled by openhab or others.

dynamic equalizing

I've tested PID climate from esphome, but without good results.

If you use hassio, you could try multizone_thermostat or better_thermostat or HASmartThermostat

I mean controlling the board from a more powerful system (hassio, openhab, etc) would be better. If you want a fine grain, you must store and compare many data like weather forecast, history and the onboard memory is not enough. Look at viboo.io cloud solution

Complete rewrite

I suggest you the following projects as starting point :

• https://github.com/kvoit/FloorHeatingController_SW
• https://github.com/bakeromso/thermostat_actuator
• https://github.com/f-reiling/vdMotCtrl

[Lonestar78]

Thanks a lot for the code references. some stuff in there to safe time :-)

[nliaudat]

For the dallas DS20b18 temperature sensor, look at esphome integrated dallas sensors or NTC sensors

[nliaudat]

You can controll the board without home assistant by disabling [api] section in board.yaml and enabling web interface with rest api

[nliaudat]

please check the new wiki

[nstadigs]

Another route might be to implement a custom component for esphome. Then you only have to worry about the loop logic required to drive this motor controller. People can pick and choose between web, mqtt and home assistant components and combine them with your custom component via yaml.

[nstadigs]

Great initiative btw! I also looked into this a while ago but I never got time to work on it. My main objective was to see if it was possible to have more precise positioning by counting motor revelations. This is what https://github.com/Lenti84/VdMot_Controller is doing. But he's using two socs on his board. One STM32 for motor control and one esp32 for communication. I wanted to see if that's possible using only what's provided by this board and the esp32.

[nstadigs]

This would be my first embedded project, so it was a bit too overwhelming for me at the time 😅

[nstadigs]

Update: this can apparently be done by using the MCPWM peripheral of the esp32 according to this reddit answer.

[nliaudat]

Be carefull, controlling a motor directly from an ESP board is the best way to burn the board. The output power is limited and that's why I use a l9110s chip.

Getting the relative position after a movement is not so complicated. Stepper motors are the best way to achieve that. But getting the absolute position (after a reboot) is more difficult and need a linear resistor or a precise position detector. I am testing IR opto sensors cause the movement of the valve is under 5mm, but it's still under dev.

Regards

[nstadigs]

Thanks for the heads up. To be clear tho I'm not suggesting that we drive the motor through that peripheral. I'm talking about using the "MCPWM Capture" feature in standalone just to count the motor revelations via the adc (that we already use for end stops) so that we can know how far the pin has moved regardless of the motor speed.

[nstadigs]

And regarding the reboot I'm thinking that we just recalibrate on boot?

The people using the repo mentioned above seem to be very happy about the results of this revelations counting approach.

The reason I want to achieve all of this with the current hardware is that I have bought 13 HmIP-VDMOT actuators and they are working really well for me, without any breakage, and I don't want to throw them away. Meanwhile, the force required to push the pins on my valves is not linear, so they can get out of sync pretty quickly if I'm just using timers to calculate the positions.