Trouble reading (volt) if LED is ON on a devices panel -Making dumb device smart

[Jim_Bag]

I have a dehumidifier that I’m trying to make ‘smart’ with an ESP32 board.
Using ESP Home as this is for Home Assistant

• I can control the control buttons by bridging them with a relay controlled by the ESP.

• I’m trying to read the ‘state’ of the dehumidifier by taking the power signal from multiple LEDs on the dehumidifier panel and feed that into the ESP via the ADC GPIOs.

Issue: The power coming from the (+) of the LEDs seems to fluctuate very erratically (from 0.3v to 2.20v) regardless if the LED is lit/on or not.
(voltages jump around when measuring with ESP or multimeter).

I currently have the ESP monitoring x3 LED’s on the dehumidifier and it is impossible to tell what one of the three is on and what ones are off due to the voltage bouncing around so much.
The (-) side of the LED’s share a common trace in the PCB so can not measure off that side.


I’m at a loss of how to achieve this and hopeful that you lot are much smarter than me here, thanks!


Additional info:

ESP is powered via a 5v circuit inside the dehumidifier.

ESP Config I’m using for testing:

Code: [Select]

captive_portal:

binary_sensor:
  - platform: template
    name: "TEST Probe32 Triggered"
    id: mb_b
    lambda: |-
      if (id(test_pin32_probe).state > id(test_probe32_trigger_level).state) {
        return true;
      } else {
        return false;
      }
  - platform: template
    name: "TEST Probe33 Triggered"
    id: mb_c
    lambda: |-
      if (id(test_pin33_probe).state > id(test_probe33_trigger_level).state) {
        return true;
      } else {
        return false;
      }
  - platform: template
    name: "TEST Probe34 Triggered"
    id: mb_a
    lambda: |-
      if (id(test_pin34_probe).state > id(test_probe34_trigger_level).state) {
        return true;
      } else {
        return false;
      }

sensor:
  - platform: adc
    pin: GPIO32
    attenuation: auto
    name: "TEST Pin32 Probe"
    id: "test_pin32_probe"
    icon: mdi:lightning-bolt
    update_interval: 0.1s
    filters:
      - sliding_window_moving_average:
          window_size: 30
          send_every: 5

  - platform: homeassistant
    name: "TEST Probe32 Trigger Level"
    id: "test_probe32_trigger_level"
    entity_id: input_number.test_probe32_trigger_level

  - platform: adc
    pin: GPIO33
    attenuation: auto
    name: "TEST Pin33 Probe"
    id: "test_pin33_probe"
    icon: mdi:lightning-bolt
    update_interval: 0.1s
    filters:
      - sliding_window_moving_average:
          window_size: 30
          send_every: 5

  - platform: homeassistant
    name: "TEST Probe33 Trigger Level"
    id: "test_probe33_trigger_level"
    entity_id: input_number.test_probe33_trigger_level

  - platform: adc
    pin: GPIO34
    attenuation: auto
    name: "TEST Pin34 Probe"
    id: "test_pin34_probe"
    icon: mdi:lightning-bolt
    update_interval: 0.1s
    filters:
      - sliding_window_moving_average:
          window_size: 30
          send_every: 5

  - platform: homeassistant
    name: "TEST Probe34 Trigger Level"
    id: "test_probe34_trigger_level"
    entity_id: input_number.test_probe34_trigger_level
Photos of control board PCB attached.

[Kim Christensen]

Issue: The power coming from the (+) of the LEDs seems to fluctuate very erratically (from 0.3v to 2.20v) regardless if the LED is lit/on or not.
(voltages jump around when measuring with ESP or multimeter).
I currently have the ESP monitoring x3 LED’s on the dehumidifier and it is impossible to tell what one of the three is on and what ones are off due to the voltage bouncing around so much.
The (-) side of the LED’s share a common trace in the PCB so can not measure off that side.

Sounds like the LEDs are multiplexed. You have to monitor the "common trace" as well as the + side of the 3 LEDs. Then only consider the + side of a LED to be valid when the "common trace" is low (0V) and ignore when the "common trace" is high. An oscilloscope would show you what's going on better than a DMM.

Another option is to figure out what chip U1 is, and snoop the serial data line feeding it. Then you'd need less interface wires.

[DavidAlfa]

VK16K33 datasheet

[Jim_Bag]

Sounds like the LEDs are multiplexed. You have to monitor the "common trace" as well as the + side of the 3 LEDs. Then only consider the + side of a LED to be valid when the "common trace" is low (0V) and ignore when the "common trace" is high. An oscilloscope would show you what's going on better than a DMM.

Another option is to figure out what chip U1 is, and snoop the serial data line feeding it. Then you'd need less interface wires.

Thanks for the reply! I had a feeling that they might have been multiplexed.

I'm sorry for sounding very dumb here but, do you know if there is a 'simple' way I can monitor monitor and compare using something like an ESP32 or Arduino?

I did notice there were what looked to be i2c or some sort of wires to the board and assumed if I were a smarter man that I could tap into that and do everything i want but, not realy sure how to so trying to do it more analogue so I could do this without help but, the LED IC on here has me beat still haha.

[Jim_Bag]

Not sure if a silly question or not: could I place a PNP/NPN transistor using the same (+) and (-) of the LED and have that output HIGH to the ESP when that particular LED is on?

[DavidAlfa]

Put a 10K resistor in parallel with the led to avoid random voltages, you'll get steady 3.3/5V when that led is off.

[Kim Christensen]

DavidAlfa linked the datasheet to U1 above.

Page 10/34 shows how the LED ROW/COM scanning works. You could use that info to mod your interface wiring (Add the "common trace" wire) and write the code to read each LED state. Note that the lines get tri-stated making it a bit more complicated.

Or dive deeper into the datasheet, and snoop the i2c line to the VK16K33 to figure out the LED status. (More elegant solution)

You could also ground reference the LED pulses by using some transistors. Then you wouldn't have to worry about the Hi-Z state of the lines:

[Jim_Bag]

Thanks, I think going 'old school' is a bit more up my ally and skill set here.

I had a google at i2c snooping and couldn't make much sens of how to go about it, unfortunately. Would definitely be the more correct approach here.

Currently I have an a92 NPN in a breadboard that I'm about to rig up, I initially wasn't going to use as many resistors as you have in the drawing.. It might be best if I ask what R values I should use or how to work them out?

(Is it clear that I don't know much about what I'm doing? haha I knew a lot more about this stuff some years back but, frustratingly I have forgotten most of it now)

I was going to do a very quick setup like this:

[Kim Christensen]

The transistors in both my and your diagram are PNP. Not NPN.

You could try my diagram without R2... It may not be required. If Q1 tends to turn on when it shouldn't, then add R2 and make it the same value as R1.
Assuming 3V LED voltage drop: Try something around 47K for R1 & 10K for R3.

[Jim_Bag]

I really appreciate your help here.

You are correct, sorry I was meaning PNP.

I'm not having much luck at the moment.
I'll have another crack at this during the week when I can have a reset and get things tidy to make sure it's all connected in the correct way.

As a side note, is an optocoupler ran in parallel with the LED's likely to be a plausible solution to this?
(this whole circuit is going to a bit large and cumbersome by the time I have it all done but, as long as i get my desired end result, I'll be happy haha)

[Kim Christensen]

As a side note, is an optocoupler ran in parallel with the LED's likely to be a plausible solution to this?

The isolation isn't really needed, but you could do that. You'd need a resistor in series with the Opto's LED since it's voltage drop will be lower than the green LED's and it would hog all the current. You'll get pulses on it's output just like the transistor circuit above.

Perhaps that's your issue? Difficulty detecting low duty cycle, short pulses, in software? I don't think that using the ADC on the ESP32/Arduino is a good method for detecting short pulses directly. A logic level input would be more suited for that.

If you wanted to go more old school, you could feed the pulses into a 555 timer (Or a peak detector) set up to give a steady output when pulses are detected. But you shouldn't need to, since you can do this all in code.