Madoka Emulation

[javimurcia]

I'm working on capturing the communication between the indoor unit and the madoka room thermostat (human comfort interface, BRC1HHDx)

But, whenever i reboot the interior unit, the P1P2 bus is also power cycled, so i'm losing the startup sequence, since the ESP8266 is busy connecting to WiFi and the MQTT broker (i'm not seeing any 80 addressed packet)

I'm using the P1P2-ESP-interface v1.1. Is there any way to supply power over the programming pins, so the device doesn't shutdown when the indoor unit restarts? i was thinking of using a power bank to rule out weird coupling issues.

any idea @Arnold-n?

[Arnold-n]

Hi @javimurcia,

Well, you can power the ATmega and the ESP via the GND and 3V3 wires of the ESP01-program connector, but I do not recommend it. The reason is that the DC/DC converter will feed the 3V3 to the Vraw of the MAX22088 which is then powered with approximately 2.7V when the bus is unpowered, and this may give unexpected results - although I do not expect any strange things if this is for just a few seconds (the same happens during USB-programming but in that case there is no connection to the bus). If you want to take the risk, you can do it: GND in corner of PCB marked GND, and 3V3 diagonally across near ESP and capacitor and marked 3V3. The ESP01-programmer can be used to provide 3V3. It is indeed important to use a stand-alone power-bank to avoid any coupling issues. To maintain the ATmega-ESP serial connection via the jumper, two female-female Dupont wires (or less safe: two female-male wires) between interface and the programmer can be used for GND and 3V3. Power consumption for the WiFi version is 110mA if the bus is unpowered.

This only provides power to the ATmega and ESP, and not to the MAX22088, so this only works to bridge the power-cycle, and does not provide a solution for systems without bus power. The next interface version v1.2 will have an option for an external power supply for that reason.

Another solution would be to change the ATmega and/or ESP code (increase buffer size etc) such that an attempt is made to store all raw data until WiFi becomes available.

[javimurcia]

OK, I'll thinker around a bit, but before making any substancial changes to the firmware I'm thinking of a few "quick and easy" fixes that can improve the connection speed of the p1p2 interface.

The most straightforward one would be using ethernet. Do you know if ethernet is faster to initialize than WiFi?

Another one should be using a static IP, instead of dhcp.

But, there is hope that none of that is necessary, since when you rest the system, the main controller screen shows "syncing with interior unit" wich takes around 10-15", and after that, "syncing with ambient thermostat".

If during the first phase, the main controller only communicates with the hydro pcb, I don't care losing those messages as long I can observe the first message between the main controller and the madoka.

Do you have any logs of the startup sequence between the main unit and an auxiliary controller, so I can see if madoka's initialization has some resemblances?

Also, could you please briefly describe the system architecture?

From what I can infer (10 minutes of browsing through the repo), the atmega fw is in P1P2Monitor.ino and this firmware is the one emulating an auxiliary controller (so here is where the madoka emulation code should be). The ATmega cannot be directly programmed, but instead it has to be OTA updated, via the ESP controller.

And the ESP P1P2-bridge-esp8266.ino this only handles the relaying of messages between the ATmega, and the MQTT broker (and some conversion). This FW can also be ota updated, but in the case the firmware on the ESP is dead, the programming header can be used (withouht a connection to the P1P2 bus)

And lastly, the BRC1HHDAW is not fully compatible with my indoor unit (EBBX16DF9W/ERLA16DAW1). The interior unit recognizes the thermostat, and its capable of reading its temperature. The madoka also seems to be "happy" with my interior unit, and it can start and stop the heating, report the room temperature and change the setpoint.

The only problem is when using the madoka assitant app, it says "not working" "this combination of remote controller with Altherma can only be done with a firmware upgrade" but no firmware upgrade is available.

For now, this doesn't appears to be a problem, since at least the basic functions works. I'll investigate what the app offers, to see if it's worth emulating those functions or not.

[Arnold-n]

Perhaps ethernet is a bit quicker, but not much. I measure 4s for WiFi and 3s for ethernet from power-on to MQTT connection. My Daikin system is just polling (absent) devices during that time.

Your system architecture is right. The ATmega translates the HBS Din/Dout from the MAX22088 and does the auxiliary control operation, and communicates over serial to the ESP, which generates the MQTT output.

[javimurcia]

Btw, it appears that madoka is acting as the second auxiliary controller, as it respond to 0x00F1 messages. Few snippets below (i'll try to capture a proper trace including the initialization)

R T  0.025: 00F03001010000060300000600010000133F
R T  0.279: 00F130010000000001000000000000000019
R T  0.026: 40F1300101000000000000000000000000DD
R T  0.025: 00F13100000001A000170314150A31F4
R T  0.026: 40F131000000010000170314150A311E
R T  0.025: 00F1320000090600000000000000000000000096
R T  0.026: 40F1320000000000000000000000000000000045
R T  0.025: 00F1361600EA00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9B
R T  0.026: 40F136FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF14

R T  0.025: 00F1300100000000000000000000000000B1
R T  0.026: 40F1300101000000000000000000000000DD
R T  0.025: 00F13100000001A000170314150A33E7
R T  0.026: 40F131000000010000170314150A330D
R T  0.025: 00F1320000090600000000000000000000000096
R T  0.026: 40F1320000000000000000000000000000000045

R T  0.025: 00FF30010100000704000106000100001308
R T  0.179: 00F03001010000060300000600010000133F
R T  0.279: 00F130010000000001000000000000000019
R T  0.026: 40F1300101000000000000000000000000DD
R T  0.025: 00F13100000001A000170314150A35D2
R T  0.026: 40F131000000010000170314150A3538
R T  0.025: 00F1320000090600000000000000000000000096
R T  0.026: 40F1320000000000000000000000000000000045
R T  0.025: 00F1361600EA00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9B
R T  0.026: 40F136FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF14

R T  0.025: 00F03001010000060300000600010000133F
R T  0.279: 00F1300100000000000000000000000000B1
R T  0.027: 40F1300101000000000000000000000000DD
R T  0.025: 00F13100000001A000170314150A37C1
R T  0.026: 40F131000000010000170314150A372B
R T  0.025: 00F1320000090600000000000000000000000096
R T  0.026: 40F1320000000000000000000000000000000045

R T  0.025: 00F03001010000060300000600010000133F
R T  0.279: 00F1300100000000000000000000000000B1
R T  0.027: 40F1300101000000000000000000000000DD
R T  0.025: 00F13100000001A000170314150A39B8
R T  0.026: 40F131000000010000170314150A3952
R T  0.025: 00F1320000090600000000000000000000000096
R T  0.026: 40F1320000000000000000000000000000000045
R T  0.025: 00FF30010100000704000106000100001308

There are no other 40Fx (appart from 40F1) messages on the bus

[Arnold-n]

If the Madoka takes F1 as default address, I hope my interface will just work in parallel with just as on other Madoka-less systems where F0 is available.

The messages above look really similar, except for the 00F132/40F132 messages which are not present on all systems and perhaps Madoka-related.

If everything works well, you should be able to see P1P2/P/xxx/?/2/# and P1P2/P/xxx/?/3/# messages for the Madoka traffic above; but these topics /2/ and /3/ are also used for the first auxiliary controller on address F0, if you want to split MQTT topics for different auxiliary controllers the code needs to be modified a bit (the comment here anticipated this but wasn't implemented).