-
|
I'm learning about this project, and I'd like to understand why the hardware device needs both an ATMega 328 and an ESP8122. Do you think an ESP32 could do both the P1P2 serial decoding (that the ATMega currently does) and the WiFi interfacing? I assume that it would be simpler to maintain one code base, and also for firmware updates. Background: I'm considering getting a Daikin Altherma Geo 3 heatpump. I'd like to implement my own wireless room temperature sensor solution instead of Daikin's wired Madoka or ugly EKRTR wireless room sensor. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 10 replies
-
|
The reason for a 2-CPU solution is both history and preference. History as the bus decoding was developed on an Arduino Uno, and an ESP was added later to do the high-level decoding. And preference as a 2-CPU solution is architecturally preferred to have low-level hard-real-time code on a hard real-time ATmega, and to have high-level code on a soft-realtime ESP. As the hardwareserial library on the ESP also indicates that it is inherent not error-free, it may be difficult to achieve the same timing reliability on an ESP as on the ATmega. The current solution does not replace the Madoka, but supplements it, just like a (W)LAN adapter. |
Beta Was this translation helpful? Give feedback.
-
|
Mine is a BRC1HHDAW, perhaps I was just lucky. In your situation I agree that the Madoka will likely be an aux controller. Even then I am not yet sure whether the Madoka acts exactly in the same way as other (LAN type) aux controllers, as newer systems seem to have different addresses for different controllers (30, 31, and 3F), whereas older systems only supported 30 (or sometimes 30 and 31). If you want to monitor the Madoka traffic with my interface to find how to emulate it I can lend you my Madoka. |
Beta Was this translation helpful? Give feedback.
-
|
It has to have some mechanism to address multiple devices, since at least, you can connect a madoka and a cascade controller adapter to the p1/p2 bus. The traditional wireless wired gateway appears to be incompatible (at least it is not in the accessory list), and the cloud functionality is archived via an SD-like wifi adapter, or a wireless gateway that appears to communicate over uart. I'm still building the p1p2 interface, but I'll let you know when I have it up and running, if I still haven't sourced a reasonably priced madoka, so I can sniff its traffic and try to emulate it. |
Beta Was this translation helpful? Give feedback.
-
The plot thickens: according to the compatibility table of my unit, the reference for the madoka remote controll should be BRC1HHDx (note the missing A, the x is the color: W white, K black, and S silver). And of course, daikin offers no explanation on what are the differences... |
Beta Was this translation helpful? Give feedback.
-
|
My guess is "A" might be "North America" since the hits on search for that model are in English, and the other model results are all different languages. |
Beta Was this translation helpful? Give feedback.
-
|
ESP32 more than enough to handle the serial data from P1P2 bus, but since your old code still working, it is fine, but for the hobbyist, it is still complex. |
Beta Was this translation helpful? Give feedback.
The reason for a 2-CPU solution is both history and preference. History as the bus decoding was developed on an Arduino Uno, and an ESP was added later to do the high-level decoding. And preference as a 2-CPU solution is architecturally preferred to have low-level hard-real-time code on a hard real-time ATmega, and to have high-level code on a soft-realtime ESP. As the hardwareserial library on the ESP also indicates that it is inherent not error-free, it may be difficult to achieve the same timing reliability on an ESP as on the ATmega.
The current solution does not replace the Madoka, but supplements it, just like a (W)LAN adapter.