Create system to control the heater
Conceived features:
- room controller:
- display to represent status
- requested room temperature
- room temperature
- heater flow temp (ebusd message ‘FlowTemp’, also rounded in `status01`)
- heater return temp (ebusd message ‘ReturnTemp’, also rounded in `status01`)
- outside temperature
- heater mode: heating/hot water (ebusd message ‘HwcDemand’ or ‘HwcWaterflow’)
- tap water temperature (ebusd message ‘FlowTemp’ when tap is running)
- flame on/off (ebusd message ‘Flame’)
- pump on/off (ebusd message ‘WP’)
- heater modulation
- power usage (?) to be tested (ebusd message ‘PowerValue’)
- sensor for actual room temperature
- controls to set required temperature
- display to represent status
communicate date and outside temperature to heater unitimpossible and irrelevant, see * +Broadcast datetime+- control remotely using a telegram bot, that way we do not need to open any ports to the outside
- (LOW PRIO, MAYBE LATER) display graphs over time of relevant values
- room controller (ESP32 + display + temp-sensor)
- retrieve outside temp from free API service like OpenWeatherMap
outdoor unit, communicates temperature to “master” ESP32 on heater unit over ESP-NOW - (LOW PRIO, MAYBE LATER) master forwards to MQTT for monitoring/graphing
- ✓ eBUS communication protocol (pretty much got this down)
- Valliant’s eBUS commands are proprietary
- ESP32 ULP programming is in assembler
Tasks should re-ordered so the first items should be the first things to pick up, items that are DONE need to move to * project log
consider ESP-NOW so “sensor” modules can profit from reduced “ON” time.
This needs a “master” though to forward to MQTT if required.
Good read and entry point is here: https://hackaday.io/project/174898-esp-now-weather-station
New idea on topology is to use a single ESP32 as thermostat which harvests energy from eBUS for power.
The advantage is that there is no wireless communication needed for basic thermostat functionality.
This does however require a more sophisticated power design as we need a LiPo battery (or similar) with circuitry and most likely use of ESP32 ULP to stay within the power budget.
Wireless connectivity is still possible for things like getting NTP, outside temperature from a free API service and communicating as a telegram bot, but display and wireless need to repect the available energy budget.
When operating in power-harvest mode we do not want the display on when maintenance chores are done.
The display does not have a pin to regulate the backlight, so it needs to be switched off completely when in sleep mode.
Starting point are project that use solar energy like here https://randomnerdtutorials.com/power-esp32-esp8266-solar-panels-battery-level-monitoring/
This will include staring to use ESP32 ULP programming in assembler to measure the voltage/battery level in low power mode
All basic functionality needs to be prototyped and tested before doing this.
Consider using JLCPCB assembly, this way we can use SMD without the hassle of sourcing SMD components, let alone soldering them
2021-10-26 07:24:00.949 [update notice] sent read bai PartloadHcKW QQ=31: 20
2021-10-26 07:24:00.951 [bus notice] >3108b509030d0704ee<0001148f>00
2021-10-26 07:27:48.647 [update notice] sent read bai ModulationTempDesired QQ=31: 35.0
2021-10-26 07:27:48.650 [bus notice] >3108b509030d2e000c<00025e01a2>00CurrentPower = PartloadHcKW * ModulationTempDesired / 100%
CurrentPower = 20 * 35.0 /100 = 7KWdiscussion on calculating power consumption: john30/ebusd-configuration#89
After running tests, code coverage report can be generated by executing the following commands:
$ lcov --capture --directory .pio/build --output-file coverage.info
$ genhtml coverage.info --output-directory out
driver IC: ST7789VW
size: 240x320 px
library used: TFT_eSPI
bought here: https://www.aliexpress.com/item/4000830895622.html
| pinout | meaning | ESP32 | note |
|---|---|---|---|
| CS | chip select | GND | active low |
| DC | SPI Data Command | GPIO 27 | |
| RST | Reset | GPIO 5 | |
| SDA | SPI MOSI | GPIO 23 | |
| SCL | SPI clock | GPIO 18 | |
| VCC | +3.3 | ||
| GND | GND |
- http://www.pittnerovi.com/jiri/hobby/electronics/ebus/index.html
- https://github.com/slavikb/BaiMon/blob/master/BaiMon.ino
- https://www.14core.com/wiring-and-flashing-programming-esp-32-esp32s-with-usb-ttl-uart/
- https://www.thingforward.io/techblog/2017-08-08-embedded-testing-with-platformio-part-2.html
- set datetime: john30/ebusd#286
- formatting C time struct: https://www.ibm.com/docs/en/i/7.3?topic=functions-strftime-convert-datetime-string
get ESP32 to listen in on eBUS messages and forward them ad-verbum to serial port for monitoring/debugging
implemented a pretty simple queue
later i found out about the provided facilities of FreeRTOS (live and learn…)
the simple mock queue is however still very usefull for unit-testing in native mode
actual implementation will use FreeRTOS queues provided by ESP-IDF/FreeRTOS
suggested for this todo are some of the messages already known:- FlowTemp
- ReturnTemp
- HwcWaterflow
- Flame
As a reward these values can already be put on display, gaining some instant gratification and bragging rights.
Shorting 390 Ohm across the eBUS still held an upper voltage of 20.2V and bus seemed to work fine.This equals a current draw of ~52mA, or 1.06W, this is actually quite substantial, this was measured with a really tiny copper wire (telephone wire) connection to the heater, so losses will be less on thicker wiring.
Using 220 Ohm the bus still managed to do some communication but errors did occur, the maximum voltage dropped to 19.2V. This equals a current draw of ~87mA and a power of 1.68W! The resistor got really toasty and discoloured!
At 336 Ohm (60mA, 1.2W) bus still behaved perfectly.
In conclusion, round about 50mA or a little more seems to be a very safe limit with only a single device on the bus besides the heater.
Send broadcast of datetime and check ebusd messages ‘DCFState’, ‘DCFTimeDate’, ‘DateTime’.
My line of thinking was completely wrong, i assumed the DCF77 device was “Yet Another eBUS device”. It is not. It is a module connected to a separate port on the heater. The broadcasts (presumably) are by the heater when it has detected a DCF signal.
Further more, i have not found any way to set the date/time on the heater through eBUS, and believe me, i’ve tried.
In the end it is not really relevant anyway, the room controller takes on the full role of director anyway when controlling the heater over eBUS, so the date/time on the heater is then completely irrelevant.
Irrelevant for the same reason outlined in * +Broadcast datetime+, in eBUS mode the heater is just a rather dumb slave dancing to the tune of puppet master room controller
read sensor and output value to serial port It makes little sense for the master to loose WiFi connection to send beacons because of channel switching. Instead the slave(s) should do this as they have no active WiFi connection to begin with. Data sent over ESP-NOW is not sensitive so encryption is not very relevant. However, we do not want rogue data being operated on by the controller.