[MES-WiFi] Bringing a Windhager pellet heater online

Since we own our house with a pellet heating system, it does its job day for day and delivers the warmth you’d expect from it. It rarely fails. Well, rarely. Except when I forget to refill the pellet container which has to be done every 3 to 14 days.

Unfortunately the system is closed and does not offer a simple solution of getting it online to notify me about any interruption, be it a failing component or just a failing human pellet refill bot. I could just upgrade the system to some automatic feeding system, but it would neither be the cheapest solution nor easily installed.

That was the reason for me to look a bit deeper into its guts and what is happening in it and how I could get this thing tell me whats happening. The schematics that come with the system quickly revealed some kind of local bus called LON which later confirmed speaking LONTalk from the 90’s on a RS485 physical layer.

And the best about this, the system has three slots where you can place so called MES-modules, like the UML C1 or others. And only two of those three slots were used in my installation.

5.4.8 
Fig. 88 
Kontaktbelegung 
Y 14 
Y13 
Y12 
YIO 
XI 
MESPLUS Heizkreismodul 
Kontakt: 
Y14 
Y13 
Y12 
Yil 
YIO 
Y7 
Y5 
Y4 
Y3 
YI 
XI /X2 
Belegung: 
Spannungsversorgung +12 VDC 
S annun sversor un -Masse GND 
nicht belegt 
LON Masse GND 
LON Data + 
LON Data - 
eBus + Signal (20 - 24 VDC) 
eBus - Masse GND 
Außen-Temperaturfühler 
Warmwasser-Temperaturfühler 
nicht belegt 
Vorlauf-Temperaturfühler 
Fühler -Masse GND 
Motormischer - Zu 
Motormischer - Auf 
Warmwasserladepumpe/Warmwasserladeventil 
Heizungspumpe
Snapshot from the MES plugin card system of Windhager heater systems.
Not exactly my revision, but the important signals are the same. [Source, Pg. 48]

Measuring the physical signal confirms the guesswork and gives a signal with 78 kHz, which is biphase manchester coded and results in 38 kbit/s. There are usually 8 or 9 start bits (ones) and then the payload as specified in the LONTalk protocol specification.

A scope trace of the LON bus lines

While the specification defines all packet formats (APDU, TPDU, SPDU, NPDU, PPDU, …) addressing formats etc. this is not enough to get data out of the system. You have to know about the NV (Network Variable) IDs and their meaning, as well as the NM request codes to fetch certain values.

Thus I started with a ESP32 board, directly interfacing the LON bus and dumping all traffic via UDP to my LAN. Better than buying an off-the-shelf solution if you don’t know how far this project will get.

The first revision of MES-Wifi in action. Forgive me the vertical video syndrome, but better a vertical video than a dropped phone.

The MES-WiFi v1.0, equipped with a ESP32-WROVER module with PSRAM, was my first iteration along with a MP1584 for 5V and a AMS1117 for 3.3V. This was the first step to get things started, but not exactly the most efficient setup component-wise. USB and thus the CP2104 shall not be missed. For snooping the LON bus, a MAX1487 was chosen. The first revision had two of them, as I wanted to set up a test bench for stress testing the software by simultaneously forging and parsing packets.

Speaking of packets, the LON packets received from the bus using the first PCB revision were sent to a broadcast address on my LAN and captured using Wireshark. Step by step I built a LUA dissector that decoded the packets into readable form as shown below. A helpful person from mikrocontroller.net gave me a lot of information about similar modules that was neccessary to find out the IDs on the system I had.

After the decoding was done far enough, the Arduino based ESP32 firmware was extended to not just “sniff” the broadcast messages seen above, but also actively ask some other Network Variables within the PMX main control unit and the other UML modules. You can see this REQUEST/RESPONSE pair in the screenshot above. All this information is not only sent as “raw” packets to my LAN, but also interpreted and fed to a really small MQTT broker on my server. Warnings, like low temperatures or an empty pellet reservoir, get pushed to my phone using pushingbox.

You can find my firmware on github.

MQTT is boring. Feed data to grafana to make it visually a bit more attractive.

When cleaning up the PCB – which is now at revision v1.3 – I changed quite a few things. Instead of a large WROVER module, I used the smaller WROOM without the PSRAM that I never used. Also the inefficient MP1584/AMS1117 pair was replaced with TPS62163/TPS62291. WSON soldering with mm-scale components, yeah! I also added some smaller relays to drive some circulation valves. Somewhen :)

Finally I routed some IOs to the APP+ and APP- lines where I will attach the already installed 1-Wire temperature sensors measuring pipe temperatures.

You can get the schematics and the layout on EasyEDA.

The third and last revision of the MES-WiFi board with an antenna attached
Shot with a more artistic touch using a proper DSLR

There is also a 3D printable housing on OnShape for the module, which reveals that I also planned to add an ePaper display, but did not find enough time to continue working on that.

The revision v1.2 was running half a year without any interruption, so I am optimistic that the v1.3 will also do a great job.

Btw – I really love how the JLCPCB blue looks like. I can absolutely recommend it.
The red is also nice, but it misses a bit of this professional touch. If you are one of the brave ones, choose the black. You will never be able to trace your … uh … traces beneath this matte black finish.

The very first revision which was just for mechanical tests and component testing.

So this was the journey of building a 25 € cheap WiFi extension module for a windhager pellet heating system.

Leave a Reply