My repo is a fork of Brents repo and so it inherited that file.
To help reduce confusion I’ve removed it now (and you are better off just using the external DAC as it seems more reliable/accurate)
The LED decoding is working great (never had any problem with that)
@patrick11 I think I misspoke in my update on how I determined the desired DAC values.
You do need it to be plugged into the keypad when measuring because it relies on the 19v power from the keypad going through the transistor.
To help with this point I wired up two breakout sockets for GND+KEY so I could hookup my multimeter to them
As far as connecting the circuit to the keypad - I just have it connected to the terminals on the back of the keypad only with the ones going to the AC unit.
Your diagram is correct - the circuit is connected in parallel with the wall controller.
To test and determine the DAC values required you need to have the circuit connected to the wall controller as it supplies the voltage which is being adjusted and measured.
If you look further up in this thread you will see I have provided some fairly detailed explanations on exactly how to determine the required values.
My unit keeps ‘sending’ data despite no activity on the unit or the wall panel, is that normal behaviour?
UPD: Had a look at the ESPhome code and it seems to be due to those entities are declared as sensors. Not entirely sure I see the reasoning behind making “Fan Speed” a sensor (but I’m basically a newbie in ESPhome) and I guess making it internal might solve that.
Interestingly, some of the LED data I get is reverted.
To be specific, I have an 8-zone wall panel. As one would expect, the "unk"1-4 values from proto_led2.h actually belong to the bottom row of the zone buttons on the panel. They are still detected, however, the values are reverted, while on the panel it is ON the device reports it is OFF and vice versa.
It seems a bit strange to implement something like that into a product (in the AC, although still possible) so I wonder if that behaviour might be caused by something else?
Also, what would be the best way to rectify it, add conditions to the line below?
pulse_vec[nlow] = dtu < 1000;
(BTW I noticed that in comments it says ‘800ms’ but actually uses 1000ms)
Or just change these lines to “==0” :
unk1->publish_state(ledProto.p[clsLedProto::UNK1] != 0);
The ‘Fan Speed’ is being re-sent every minute because it is from a lambda (so sent even if not changed)
I’ve updated my esphome yaml so it only sends things on change - check it at Actron-Keypad/aircon-keypad.yaml at 56b61e64f9ebdf56ab643084e67fe92c69040b5c · cjd/Actron-Keypad · GitHub
1 Like
Can anyone see an issue with powering the ESP32 from the wall controller power pin with this 19V to 5V converter?
Thanks to all who have contributed to this project. I’ve been wanting to integrate my Actron into my home automation for sometime but did not want to fork out the few thousand dollars to upgrade my indoor unit PCB.
I’ve managed to get this working with my 8 zone LM24-D controller. In the process i’ve discovered the remaining UNK LEDs. Here is the list for anyone who may find it useful. note I’ve removed UNK6=40 as it doesn’t exist. There are only 40 LEDs, 0 to 39.
enum ClassStatLeds {
COOL = 0,
AUTO = 1,
ROOM5 = 2,
RUN = 3,
ROOM8 = 4,
ROOM7 = 5,
ROOM6 = 6,
TIMER = 7,
FAN_CONT = 8,
FAN_HI = 9,
FAN_MID = 10,
FAN_LOW = 11,
ROOM3 = 12,
ROOM4 = 13,
ROOM2 = 14,
HEAT = 15,
_3C = 16,
_3F = 17,
_3G = 18,
_3B = 19,
_3A = 20,
ROOM1 = 21,
_3E = 22,
_3D = 23,
_2B = 24,
_2F = 25,
_2G = 26,
_2E = 27,
DP = 28,
_2C = 29,
_2D = 30,
_2A = 31,
_1D = 32,
INSIDE = 33,
_1C = 34,
_1B = 35,
_1E = 36,
_1G = 37,
_1F = 38,
_1A = 39,
};
It also pays to measure your keypad POWER pin voltage and calculate the required voltage divider resistor values. My voltage is 20V so I was getting 3.9V on G33 pin. I needed to replace the 1.2kOhm resistor with 910Ohm. This brought the G33 pin voltage down to 3.3V.
My UI:
I’ve also tidied up the handleIntr() and mloop() functions:
void handleIntr() {
auto nowu = micros();
unsigned long dtu = nowu - last_intr_us;
last_intr_us = nowu;
if (dtu > 2000) {
nlow = 0;
return;
}
if (nlow >= NPULSE) nlow = NPULSE - 1;
pulse_vec[nlow] = dtu < 1000;
++nlow;
do_work = 1;
}
void mloop() {
unsigned long now = micros();
if (do_work) { // If there's work to do (set by handleIntr())
do_work = 0; // Reset the work flag
last_work = now; // Update the last work time to now
} else {
unsigned long dt = now - last_work;
if (dt > 50000 && nlow == 40) {
if(memcmp(p, pulse_vec, sizeof p) != 0) newdata = true;
memcpy(p, pulse_vec, sizeof p);
}
}
}
2 Likes
I did try to power mine using a dc buck converter from the wall panel but I ended up getting a horrible low pitch wine noise from the converter I assumed it was from the data pulse sent on the main voltage wire. Tried a few different converters with the same result so end up just powering the esp from an external power source. Let me know if you have any luck at all.
I just went with the 5V power supply in the end. I have the ESP32 fitted in a small enclosure and tucked away in my mini network server cabinet so a separate supply wasn’t an issue.
What is an issue though, is temperature. It seems the BC584 transistor is extremely sensitive to temperature change and this in turns affects the voltage levels of the buttons. I set all my levels with the ESP32 on the bench. After fitting to my enclosure, which is around 40deg, my zone 8 button started turn on zone 7, then after a few more minutes zone 6 and finally after a few more minutes zone 5! I took the ESP32 out of the enclosure and the reverse happened.Obviously all other buttons were affected too but these buttons provide the clearest evidence on what is happening given their sequential values.
MV_ZONE5 = 740, // 650mV
MV_ZONE6 = 729, // 840mV
MV_ZONE7 = 719, //1000mV
MV_ZONE8 = 710, // 1160mV
I will recalibrate my buttons with the ESP32 in the enclosure but I can see this being an issue as we go through winter/summer/winter. I wonder if anyone else has experienced this? I did read further up that someone had to calibrate their buttons multiple times. I may have to look at temperature compensation.
Could you share your led_proto2 file?
I finally had time to tune in the voltage values, and everything seems to be working fine from the functional point of view, but then occasionally after some time (from an hour to several with no visible pattern so far) the device becomes unresponsive - doesn’t respond to pings, etc. Seems like might be caused by inputs from a wall panel - need to test this.
UPD: I guess it wasn’t able to correctly handle those occasions when we get 41 bit, I slightly modified handleIntr (made sure that “++nlow” is inside “else”) and it seems to be handling it fine, been running continuously for a day now and seems to be doing alright.
That is AMAZING! How did you do that?
Does anyone know if this is expected?
The device goes into the ‘sending bursts’ when the AC starts running:
I manually lowered the temp to get it going, and notice how it keeps sending “ON” and “OFF” for the ‘Run’ sensor.
It usually keeps at it for about 3 seconds (over a dozen ‘messages’) and then stops on the correct value. But occasionally it’s shorter.
Same happens when the AC stops running but before it actually does, so it would go into the ‘burst’ and then after a few seconds it would stop on “OFF” and the AC would also stop at the same time.
It seems like it genuinely gets this stuff from the AC and simply does its job updating the values, but it looks pretty weird for the AC to be ‘flicking’ GND like crazy, does anyone else has this behaviour?
Also a similar glitch to the above but of different flavour. This time nothing happened anywhere in the system - no buttons presses, AC was off and not changing any states that I could tell.
Seems it has issues with detecting correct bits occasionally, should I be adjusting the timings (and how)?
UPD: I figured it out, there are 2 different cases here.
- Someone presses a “show me current wall sensor temp” button on one of the panels, which of course changes the temperature on display. These sequences always come with INSIDE flag and are easy to be ignored or treated in a special way (publishing the temp update to a different sensor, for example).
- Before and after ‘starting the engine’ the AC runs series of ‘on/off’ sequences. I suspect this is due to me having 2 wall panels. These sequences are easily identified by only “ON/OFF” value changing and nothing else and as they are always followed by a normal complete sequence eventually, they can be safely ignored.
The handleIntr() example I posted above has been rock solid for me. The only time I had issues with reading the LEDs was wiring/connection issues. I’d triple check all the solder joints and look for any stray strands that may be occasionally shorting.
I’m not actually using Home Assistant or the yaml code at all so I won’t be much help there. All my code is contained in the led_proto file. I’m using MQTT for communication, talking to an Ignition Gateway running on Raspberry Pi. The UI is Ignition Perspective. Predominantly used for industrial automation but is extremely flexible and free so makes a great option for home automation.
Interestingly, my first attempt at this was to make a standalone Zigbee device (with a custom converter for Z2M) based on the C6 esp chip, but the available info on how to code custom clusters was virtually non-existent, so after a few attempts I put it aside until that ‘field’ is a little more mature.
Does anyone else have 2 wall panels or it’s just me?
I wonder if those on/off bursts are the panels syncing.
Is it possible to use 2N2222A instead?
I am also experiencing drift over time. Did you end up solving this?
Did you try the alternative transistor? If so, were the results promising?
I added a DHT22 and coded some temperature compensation. Solved the issue.