ESP32 has TWO DAC (Digital to Analog) channels built in – these will generate 0 to 3.3v. Then you can use an op-amp to boost it to 0-10v. The only thing is you also need a voltage source at or above 10v for the opamp to control. You can find cheap buck or boost converter modules to provide that.
BUT READ YOUR DEVICE MANUAL FIRST! Some 0-10v devices can be put into different modes, for example to be controlled by 0 to 3v. So then you can control it directly from the ESP32 without any extra nonsense. I wish I had known this before I bought my actuators as I would have tried to find the models that do this (they are referenced in the manual for the 0-10v only model I did purchase). Check out Siemens GDE163.1P and GDE164.1P which can be adjusted for anything between 0-5v start to 0-30v finish… so you can do 0-2v, 0-3v, 1-5v, 4-30v etc.
Bellimo MFT actuators can supposedly be reprogramed in many ways, but I am not sure if you need proprietary/licensed $ software to do it?
"Belimo damper actuators and control valves with Multi-Function Technology (MFT) are an excellent way to standardize your product line while reducing the number of different actuators needed. MultiFunction Technology offers a wide variety of programmable control inputs and feedback signals. Parameters can be set for voltage control (VDC), time proportional control (PWM), floating point, on-off, feedback signal, or torque output. Parameters can be changed on-site to optimize/enable application. You can also set, modify or read position, running time, mechanical working range, address,
status, and diagnostics. "
And here is my latest version of my ESPHome configuration (in packages > include format).
output:
- platform: ledc
pin: GPIO27
frequency: 1220 Hz
id: heiz_sollwert_pwm_output
inverted: False
min_power: 0.00
max_power: 1.00
esphome:
on_boot:
- priority: 500
# When hardware initialized
# Failsafe temperature, approx. 30°C = 20% PWM
then:
- lambda: |-
id(heiz_sollwert_pwm_output).set_level(0.2);
sensor:
- platform: template
name: "Gastherme Sollwert ESP (Temperatur)"
id: gastherme_sollwert_degc_sensor
icon: "mdi:thermometer-chevron-up"
unit_of_measurement: "°C"
accuracy_decimals: 1
update_interval: never
api:
services:
- service: gastherme_solltemperatur_set
variables:
temperature: float
then:
# The formulas for volt and pwm_pct have to be found by experiment
- lambda: |-
double degc = 1.0 * temperature;
double volt = degc * 0.1253 - 1.2751;
double pwm_pct = (volt - 0.4535) * 10.05;
id(gastherme_sollwert_degc_sensor).publish_state(
min(90.0, max(0.0, degc))
);
id(heiz_sollwert_pwm_output).set_level(
min(1.0, max(0.0, pwm_pct / 100.0))
);
In comparison, most logic is now inside the ESP and HA receives final values and has temperature control via a HA service.
Beware. @darren-ha has raised a good point. The combination of service and sensor could be implemented via a Template Number. Be sure to check out the discussion below.
This thread has been very helpful - my initial experience integrating an ESPHome device with Home Assistant had me feeling things were circular/“inside out” (similar to OP’s early comments on this thread). Thanks to all here for the resources and exposition that helped reorient me!
@ThomDietrich , a follow-up question on your latest config: Is there a reason you don’t use ESPHome’s number component (specifically a template number in optimistic mode) as the input control entity? (I gather you are using an input_number on the HA side?)
Context: My use case is also managing an ESP-based PWM from HA; my rationale for using ESPHome’s template number is that it allows me to push even more of the “business logic” (e.g. min/max allowed input values) onto the ESP, leaving HA to serve only higher-level functions (e.g. UI, scheduling) - but I’m curious if you see reasons to prefer not using the ESPHome component.
Hey Darren, great question about an interesting detail.
I would say the number entity is definitely an option and not a bad one. I thought about the pros and cons for some time just now. After dismissing most of them I think the only real reason lies within what you’ve raised yourself:
I gather you are using an input_number on the HA side?
No and a way to unintentionally provide a set temperature directly by a user is something I want to avoid. In Home Assistant I am using a rather complex set of input fields in a dashboard, summarizing template sensors and finally automations to decide on the heating set temperature. This one is then send as a command via the service.
The service approach has two advantages:
A service can accept multiple parameters besides the set temperature. Something I’ve used with other use cases.
The service call does not create it’s own entry in the Home Assistant logbook. That is something you might not care about but for debugging purposes I prefer that.
So long story short. I think I could have done it either way, but the service approach is cleaner.
allows me to push even more of the “business logic” (e.g. min/max allowed input values) onto the ESP
That is an excellent argument for the number entity.
Edit: Over the course of this message I did remove the intermediary sensors from the code above. These were there for debugging only.