ESPhome based HVAC system control with waveshare esp32 industrial

ESPHome
, ,
1

Hi everyone, I need to gradually replace my old Eagle BACnet controller, which currently manages my AHU, pumps, valves, fan coils, and so on. The expansion modules connected to it are starting to fail after more than 14 years in service, and I can’t repair them because the controller requires a licensed reseller. Replacing it with a new one would cost around 10k €, which I’d really like to avoid.

I recently discovered the Waveshare 8‑Channel ESP32‑S3 WiFi/ETH board (https://www.waveshare.com/esp32-s3-eth-8di-8ro.htm?sku=30838), which can be expanded over Modbus using both Waveshare and third‑party modules (AI, AO, DI, DO, relays, etc.). It’s obviously license‑free, ESPHome is easy to work with, it has Ethernet, and it can communicate with my Home Assistant instance via MQTT + TLS.

From your experience, do you think this setup would be robust and powerful enough to handle a system like mine? My Eagle BACnet controller currently manages about 100 points (including the ones that no longer work).

If you have suggestions or alternatives, I’d be happy to hear them :slightly_smiling_face:

Thanks!

2

Give the Protocol Wizard a try to confirm everything is contactable.

1 Like
3

Thanks, but is this just for home assistant and not esphome? The esphome device should communicate via mqtt with home assistant.

Also since i/o in the waveshare is limited I think most of the job will be communicating with modbus slave via the rs485 interface.

4

MQTT data transfer protocol is only one option of those available for ESPHome. It can, not necessarily should.

ESPHome supports serial communications too, which is what the RS485 interface uses to talk to the physical devices connected to the bus.

Try the protocol wizard, if only to troubleshoot failing devices. You may find it supports RS485 connections and WaveShare hardware, both of which you have mentioned. BACnet protocol too.

The WaveShare device you mentioned is low cost, flexible, and incorporates the RS485 interface and an ESP32-S2 so may fit the bill quite well. Only eight ports however, so the cost to add thirteen of them to cover switching 100 devices may be huge. You may wish to consider the 32port version at https://www.waveshare.com/product/modbus-rtu-relay-32ch.htm - only three required.

BACnet and ModBus are protocols that work over the physical RS485 layer. Ethernet is another physical layer for making connections.

Ready made HomeAssistant BMS integrations to tie everything together similar to the BACNet may involve a fair bit of fiddling, and you may get spare change out of 10k € of time spent. They may already exist, or you may have to reverse engineer the commands required to achieve your goals.

You haven’t mentioned what devices you are attempting to control - make and model. Any inputs requiring monitoring too? What interface do they have to your existing controller? Do you wish to replace those interfaces too?

You may be able to cherry pick, replacing failing devices gradually, rather than the entire system, watching the RS485 bus and sharing the control load between the old and new systems.

The older relay interfaces that do the switching that are still working and controlled via RS485 commands from the BACNet controller should be able to be retained and also controlled from HomeAssistant via the WaveShare interface, simultaneously.

Like a chocolate elephant, eat it a bite at a time.

5

Yep this is what I will do to gradually replace non working parts. I should start with some pumps and some of the logic associated to them that right now are manually controlled (always on).

This is fine, i’m considering also this in pair with the esp32 device that will “act as main”.
So the ESP32 waveshare will have all the sensors and will be communicating with other modbus devices via the integrated rs485 port.
I think i need mainly relay to control contactors (mainly pumps) but i also need some analog input/output (valves) and PT100/PT1000/NTC10/NTC20 boards for thermistors.

I need mqtt because my home assistant instance is right now running in a separate cloud VPS that is not connectable to my local network via VPN at the moment.
I’m using right now nodered as a modbus “poxy” to my home assistant cloud instance.

For this i have to check if maybe something i have is already modbus… But for bacnet i’m worried that the reverse engineering process is more expensive than buy another modbus device to replace it :sweat_smile:

Anyway many thanks for all the insights!!

6

Hint: Maybe RS485 bus is promiscuous and you can listen in and record the different devices chattering to each other to help with reverse engineering. If the wizard doesn’t do it, ask the author if they will add it.

1 Like
7

Hi,

I made the protocol_wizard.
Current making the revpi integration (ha_revpi). It is also in github/partach as is the protocol_wizard.
The revpi is a great industrial solution with modules for DI/DO/AO/AI. I am using the connect 5 with a MIO module.
As luck would have it, am trying to set it up to control things like AHU!
Via templates (same as protocol_wizard) you can define the AHU.

Have a look at the templates.md in the docs directory to see if this is something to go for. It is a more industrial solution and probably much better than all kinds of lose boards with much tinkering you are planning…
revpi is not cheap but think you could be done for less then $1K

Just started development recently but think the latest pre-release should be able to do what you want with it…

Have a look at the readme if it could help you out: GitHub - partach/ha_revpi: Revpi and RevPI module support for Home Assistant · GitHub

9

Thank you!!
I have already encountered the revolution pi and it is really promising.
I have a couple of doubts.
As I said my Home Assistant instance cannot talk directly with my local network where the controllers will be, so they need a “”“proxy”“” like the mqtt or nodered home assistant library.
If i read correctly your amazing integration works if the two components can talk directly via their IP.
The second is that the devices are much more expensive (and also much more powerful and more stable of course) As the main device comes at 500€ and the single expansions slots are 100/200€ each. I’m worried that for some small application it wold be a little bit overkill.
46 risultati per ‘revolution pi’ | RS

Also how do you connect the expansions slot to the main one?

On the other side i’m worried about the esp32+esphome reliability…

10
  • I am willing to add MQTT for you, was already thinking of doing that. Let me give that some thought
  • It is more expensive, but industrial …
  • connecting the modules is easy (their website explains and my readme a bit). Basically you can connect via a connector on top of the modules. Then you configure it via an integrated web tool on the RevPi: PiCtory. It is basically drag and drop and some checkmarks. This creates a config.rsc which is basically the memory pool where also HA integration will read and write to and from.
  • The esp solution would comprise different quality PCBs thrown together. It can work but the maintenance would be a hassle and also probably the uptime.
1 Like
11

By the way: is there a possibility to create routing/NAT between your two networks via a router(s)?

Goal: Devices on LAN A (e.g. 192.168.1.0/24) can ping/talk to devices on LAN B (e.g. 192.168.2.0/24) and vice versa, using real IPs.

Simplest & cleanest setup (works on almost any decent router):

  1. Use one router as the “core” router (the one with Internet uplink)
  • LAN IP: 192.168.1.1/24 (LAN A)
  • Connect your main devices here (or via a switch)
  1. Connect the second router (LAN B)
  • WAN port of router B → LAN port of router A
  • Give router B a static WAN IP in LAN A (e.g. 192.168.1.2)
  • Router B LAN: 192.168.2.1/24 (different subnet)
  1. Add static routes (the critical part)
  • On router A (main router):
    • Add route: 192.168.2.0/24 → gateway 192.168.1.2 (IP of router B)
  • On router B:
    • Add route: 192.168.1.0/24 → gateway 192.168.1.1 (IP of router A)
    • Disable NAT/masquerade on router B (or set WAN → LAN mode / DMZ mode if available)
  1. Optional but recommended:
  • On router A: enable firewall rules to control what LAN A can reach on LAN B (and vice versa)
  • Disable DHCP on router B if you want a single DHCP server (or keep it for isolation)

Result:

  • Full bidirectional communication
  • Devices see real IPs (e.g. 192.168.2.50 can ping 192.168.1.100 directly)
  • Gaming/UPnP/port-forwarding works normally
12

Nope,
Home assistant is on a cloud VPS and the network infrastructure of my company is not allowing VPN connection between the networks. It’s not a house and i’m not in direct control of network infrastructure.

I’m planning in the future on moving the home assistant into my company private VMs and then i’ll be able to talk between subnets. But at the moment as homeassistant is talking with some blocked cloud services (tuya) i need some more time to eliminate them before.

Yeah the uptime is my main concern about the waveshare solution but thinking about another a very simple setup - 6 pumps and some themistors - where i don’t have any bacnet controller (not the one i was thinking for the opening post) should be fine or at least better with my actual solution involving different shellies connected to a laggy wifi :sweat_smile:

For the mqtt to work there should be a component running on the pi module and the remote home assistant should discover the “devices”. Right?
I think another easy option would be use the integrated nodered for logic programming and entity creation on home assistant via node-red-contrib-home-assistant-websocket (node) - Node-RED.

For external modules: i see that the only “official way” to read temperatures is via the RevPi AIO that has 2 slots for temperatures. Since temperatures are a main compoent to monitor in HVAC system i think i will need some of them to just read temperatures and leave the AI/O pins unused. This could be very expensive… Either way i can buy a modbus module that reads temperatures and connect it to the rs485 port of a pi revolution connect version.

13

For external modules: i see that the only “official way” to read temperatures is via the RevPi AIO that has 2 slots for temperatures. Since temperatures are a main compoent to monitor in HVAC system i think i will need some of them to just read temperatures and leave the AI/O pins unused. This could be very expensive… Either way i can buy a modbus module that reads temperatures and connect it to the rs485 port of a pi revolution connect version.

Did not dive into the details but would there not be an official way via a 1-10V temperature sensor? This can be directly read via an anlogue input?
Also the revpi (some connect cpu modules) you can order with RS485 modbus ready connectors…

1 Like
14

Which kind of thermometer?
I think those will have to be powered from DC and then (for example on nodered) i need to wire a logic to convert the voltage value to a temperature.
Correct?

15

this one?
Not that i am an expert or used it but it states it supports different protocols. Like 1-10V

1 Like
16

I also found this one for NTC sensors
Z-8NTC | Moduli I/O Analogici | SENECA

17

I released revpi 0.5.0 for you, it includes MQTT reporting

18

Does this still need a local home assistant instance?

19

Strictly no. HA runs on the revpi which is at the ahu facility. Only thing you would need is an app to read the mqtt messages.
Currently it is a unidirectional street in that the revpi sends device states to the mqtt server. (well strictly speaking the HA sends the MQTT messages)

20

So i’m missing something. As of my case:

  • Home assistant and MQTT runs in the cloud and can’t talk with local network
  • Revolution PI is in my local network
  • Your external component runs on home assistant and sends updates to mqtt

But if Home Assistant cant talk with Revolution PI how are they working toghether?
BTW I think that Node red and the node-red-contrib “palette” is a good way to easy program some logic and still have a websocket connection to home assistant.

21

The way i saw it: HA runs on revpi. Revpi is physically at the ahu site as it needs to be connected to the pumps, sensors, etc. There you connect to a mqtt server in the cloud (in the integration on HA which runs on revpi). The mqtt server is then accessible to your other site where you read the information

1 Like