RGB LED Control from Temperature

[meatalhead]

I'm currently running Node Red through Home Assistant on a Raspi 4, with a Mosquitto MQTT broker.

I've connected a couple of APA102s (RGB LEDs) and a BME280 (Pressure + Temp + Humidity sensor) to a NodeMCU ESP8266. I've flashed the ESP8266 with ESPHome and all are interacting with Home Assistant.

Is it possible to use Node Red to vary the colours of the APA102s with change in temperature? Ideally set a specific RGB value for certain temperature ranges?

[Nodi.Rubrum]

Short answer is yes. But... does the ESPHome firmware support any type of REST API or MQTT messaging? Can ESPHome accept in-bound messages or commands? Basically there are two options:

1. Have NR do the evaluation of temperature, and take action, i.e. send command to control LEDs. You may have to write or find an ESP firmware image you can change to allow some type of communication back to the ESP module from NR.

2. You have ESP firmware image do the evaluation of temperature, and change the LEDs state as needed. Again, you have to find or write a firmware image that does this as needed.

Either way, NR needs input and depending on the option the ability to output to the ESP module, i.e. via REST API, MQTT, etc.

I have not done much with ESPHome, or canned/configurable firmware images. Since I know C, I tend to just write my own firmware images for ESP modules.

[craigcurtin]

Yes you can do this

Install the Webhooks Node red module (there is an active thread on the 3rd party add-ins forum on HA about this)

Once this is installed and you have generated a long access token in HA then you have all the entities and states exposed to NR - you can then control them however you wish and they will go through the HA process and be sent out to the ESPHome nodes

Craig

[meatalhead]

Thanks both, I've added an input select. This all works well and can turn the light on and off through a call service. Is it possible either in NR or HA to specify the colour of the light when it's turned on?

I'd ideally like to create the following:
Input select: On - Light on full brightness white
Off - Light off (this already works)
Auto - Links to another select that changes the colour based on temp
Night light - Dim blue light

(The blue boxes with # are links to scenes, however I'm getting an error with those at the moment)

Thanks

[Nodi.Rubrum]

What is the LED setup? SM or tri-head color diode? Mine, have separate RGB pins (https://howtomechatronics.com/tutorials/arduino/how-to-use-a-rgb-led-with-arduino/), so if I vary the power level per pin I can get pretty much almost any color. But most micro controllers require PWM use to control specific GPIO voltage levels. If it is the SM* type multi-color LED (https://ledlightsworld.com/blogs/led-lighting-knowledge-base/difference-among-smd2835-smd3528-smd5050-smd5630-smd5730), for these there is actually a small control chip that can be programmed to set the color levels. There are many examples of how implement both.

[meatalhead]

@Nodi.Rubrum, I've got a couple of Blinkt! modules which are APA102s (5v, ground, clock and data.) These are linked to my ESP8266 and flashed from ESPHome. They work really well from HASS and I can use the colour wheel to change their colour.

Where I'm stuck is I only seem to be able to turn them on/off from node red, I don't know how to change the colour. So for example, if I want them "on" I'd like them at full brightness but "nightlight" to be blue and 50%.

Thanks

[Nodi.Rubrum]

Not familiar with the specific SM node, but the datasheet should give us a clue. The key will be the integrated driver chip that drives the LED. I think this might be the data sheet for the APA102s https://cdn-shop.adafruit.com/product-files/2351/SK9822_datasheet_SHIJI.pdf.

Which pins did you use on the ESP8266? Per the datasheet, VCC, GND, SDI, and CKI right? Are you using 1 or a strip of them? Did you get these from Adafruit or where? If they have the SK9822 control chip, the Adafruit library should work with them.

We need to find out how ESPHome is driving the LEDs. It might be using this https://nodemcu.readthedocs.io/en/master/modules/apa102/ or similar code based on C versus Lua.

Can you tell me which ESPHome ESP8266 firmware image you are using? Document a like to it here?

[Nodi.Rubrum]

Ok, I got chance to look at the bones of ESPHome. The issue is going to be which communication protocol can be used, be it a REST API, MQTT or whatever. If we can figure out what ESPHome receives and sends, then we should be able to craft something from NR to send to ESPHome, and drive the LEDs accordingly.

For example, it appears you can 'script' or configure a custom action to be taken when the ESPHome node receives a defined MQTT topic. From the documentation:

on_message Trigger

With this configuration option you can write complex automations whenever an MQTT message on a specific topic is received. To use the message content, use a lambda template, the message payload is available under the name x inside that lambda.

[meatalhead]

@Nodi.Rubrum Thank you,

I've been trying to find away of viewing what mosquitto sends to the LEDs, in hope I could just reverse engineer it.

[Nodi.Rubrum]

The problem is the MQTT communication is 1 to 1. You could network sniff the traffic. But that is pretty significant task, if you are not familiar with the technology and tools to do such. At any point do you have access to the actual firmware image source code? If you could get the MQTT topic that is used, that would be a step in the right direction to trying to establish a 1 to many connection via MQTT. But if the firmware is written correctly, it should not let you setup an other publisher, to spoof the communication. That would be an obvious and directive hacking or attack vector. Can't see the ESPHome firmware being wide open to such abuse if get my meaning.

[Colin]

If you subscribe to "#" on the mqtt broker then you will see all the communications going through the broker.

[dceejay]

(Though some brokers deliberately block subscriptions to # at the root for just this reason)

[Steve-Mcl]

@dceejay

some brokers deliberately block subscriptions to #

Emqx blocks # by default.

[Nodi.Rubrum]

Yup... when I was digging to the ESPHome details, it became clear that using the 'message trigger' option was the likely way to cross link the functionality, i.e.. the custom message activates a bit of template (code) to invoke the LED control routines already present.

[Colin]

I am a bit confused, where is the MQTT broker running?

[meatalhead]

I'm running mosquitto in a docker container

[Colin]

In that case if you subscribe to # then you will see all the communications. I was confused by the reference to Emqx.

[Nodi.Rubrum]

Once you have 'target' topics, you can basically have NR spoof the message, so to speak. But I thought you said ESPHome image was not using MQTT to communicate? It was some other protocol?

[meatalhead]

@Nodi.Rubrum. I'm using mosquitto as my mqtt broker. I've got home assistant running in a docker container, with ESPHome and mosquitto in separate containers.

esphome:
  name: nursrey_light_temp
  platform: ESP8266
  board: nodemcuv2
  
wifi:
  ssid: [SSID]
  password: [PASSWORD]
  manual_ip:
    static_ip: [IP]
    gateway: [IP]
    subnet: [IP]
  power_save_mode: none
  reboot_timeout: 0.5min
  
# Enable logging
logger:

# Enable Home Assistant API
api:
  password: [password]
  
ota:
  password: [password]
  
captive_portal:

i2c:
  id: bus_a
  sda: 4
  scl: 5
  scan: False

mqtt:
  broker: [IP]
  username: [UN]
  password: [Password]
  port: 1883
  discovery: True
  discovery_retain: True

sensor:
  - platform: bme280
    i2c_id: bus_a
    temperature:
      name: "Nursery Temperature"
      oversampling: 1x
    pressure:
      name: "Nursery Pressure"
    humidity:
      name: "Nursery Humidity"
    address: 0x77
    update_interval: 5s  

light:
  - platform: fastled_spi
    chipset: APA102
    data_pin: GPIO14
    clock_pin: GPIO12
    num_leds: 8
    rgb_order: BGR
    name: "FastLED SPI Light"