LocalDeck: This feature is not available for the IDF framework version 5 .

GraemeD

I just ran the ESPhome update in HA and got the following when trying to do the localdeck update:

`WARNING GPIO8 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
Failed config

light.esp32_rmt_led_strip: [source /config/esphome/esphome-web-f98e24.yaml:435]
platform: esp32_rmt_led_strip
name: Ledstrip
id: ledstrip
rgb_order: GRB
pin: GPIO8

This feature is not available for the IDF framework version 5.
rmt_channel: 0
num_leds: 24
chipset: SK6812
restore_mode: RESTORE_AND_OFF
effects:
- addressable_rainbow:
name: Addressable Rainbow`

BertQuodge

GraemeD /me too, I just ran into this issue after I updated ESPHome. I’ll keep an eye on the testing/updates mentioned in the thread.

zorg

INFO ESPHome 2025.2.0
INFO Reading configuration /config/esphome/localdeck-f810f8.yaml...
WARNING GPIO8 is a strapping PIN and should only be used for I/O with care.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins

following that URL reveals it should be possible to squelch that warning with this configuration:

light:
  - platform: esp32_rmt_led_strip
    name: Ledstrip
    id: ledstrip
    rgb_order: GRB
    pin: 
      number: GPIO8
      ignore_strapping_warning: true 
    rmt_channel: 0
    num_leds: 24
    chipset: SK6812
    restore_mode: RESTORE_AND_OFF
    effects:
      - addressable_rainbow:
          name: Addressable Rainbow

However it then fails with:

light.esp32_rmt_led_strip: [source /config/esphome/localdeck-f810f8.yaml:155]
  platform: esp32_rmt_led_strip
  name: Ledstrip
  id: ledstrip
  rgb_order: GRB
  pin: 
    number: GPIO8
    ignore_strapping_warning: True
  
  This feature is not available for the IDF framework version 5.

Further googling leads to this change:

esp32:
  board: esp32-c3-devkitm-1
  framework:
    type: esp-idf
    sdkconfig_options: {}
    version: 4.4.8
    platform_version: 5.4.0

Turns out the ignore_strapping_warning is not needed at all.

GraemeD

zorg

thanks has a few warnings but seems to work again thanks

WARNING The selected ESP-IDF framework version is not the recommended one. If there are connectivity or build issues please remove the manual version. WARNING The selected ESP-IDF framework version is not the recommended one. If there are connectivity or build issues please remove the manual version. WARNING GPIO8 is a strapping PIN and should only be used for I/O with care. Attaching external pullup/down resistors to strapping pins can cause unexpected failures. See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins WARNING RMT_LED_STRIP support for IDF version < 5 is deprecated and will be removed soon.

AAllport

Hi Both,
Just checking in to say we’re aware of this and taking a look internally.

From next week, we should have our test environment back up and running correctly, and we’ll be issuing updates across all of the managed ESPHome configs we provide!

derobert

I think all you need to do to get it working with current IDF 5 is to remove the “rmt_channel: 0” line entirely (or comment it out). That seems to work here.

That change is noted at https://github.com/esphome/esphome/pull/7770

m3lvm

After spending hours messing around with the configurator flashing the factory config on to the deck to get it to work again after multiple failed atttempts to get it working. I went to add more button functions, and went to compile but rmt_channel: 0 issue came up again. I even went into the yaml file in the esphome folder, and hashed the rmt_channel: 0 line. went back to the configurator it put the line back in un hashed. where is the file the configurator stored?

AAllport

m3lvm went back to the configurator it put the line back in un hashed. where is the file the configurator stored?

The configurator doesn’t use a separate file.
Inside the YAML for your device, you’ll see a line that says, “Anything below this line will be removed when saving”, and then “Edit” with a long URL.
That URL has a config parameter representing your changes to the stock config.
Everything from the entity names to the labels and emoji

When you open the file in the configurator, we read this line and load the changes from the URL—no additional files are needed!
One bonus is that you can use the web version of the configuration here: LocalBytes Blog / Tools / LocalDeck Configurator.
The link to edit will be in the file it generates!

AAllport

Morning All,

We’ve merged LocalBytes/localdeck-config#54, which should fix the issue.
The issue was caused by incorrect validation, saying the RMT channel was a required parameter, so we added it.
However, esphome/esphome#7770 essentially removes the param, causing the error to occur.

Before we fully release the update, we want to properly test it, which can only happen later this week when the new office has internet and we can get our test environment rebuilt.

In the meantime, you have two options to build new firmware:

Install the Development Version of the addon where the fix has been deployed
Once you’ve made changes to your LocalDeck via the configurator, hop into the yaml and remove/comment out the rmt_channel line

We’re also thinking of adding the squelch for strapping pin usage, just to make the install look a little cleaner 🙂

RGS

AAllport

What if you are not using the addon?

My automation just looks at the esphome values directly. Still good to comment out that line?

AAllport

RGS Absolutely! The fix is the same.

I’m curious what your config looks like…
Did you originally use configurator, and then hand craft various other bits, or, are you importing the yaml from GitHub via packages?

RGS

AAllport

import from yaml from github, thats it. (Not packages, I copy it straight from GH and pull out a few bits) but it prevents any unknown breaking changes on my side if you were to update.

but its just this file for the most part
https://github.com/LocalBytes/localdeck-config/blob/main/packages/localdeck-codegen/esphome-localdeck.yaml

And then on the HA side, its all done on automations based on values from ESPhome

hunterdrayman

I also don’t use the configurator as I have built automations in node-RED that map the buttons and lights directly. I did find when onboarding that things went better if I had the configurator stuff from ‘above the line’ rather than attempting to craft that myself. I’m still not confident enough with ESPHome to do without the configurator - might need it one day. LOL

Something I learned early on was to always put the wi-fi IP address in manually. It made restarting the localdeck much more efficient. i.e.

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: Dressing Room Keypad Fallback
    password: blahblahblah
  manual_ip:
    static_ip: 192.168.4.103
    gateway: 192.168.4.1
    subnet: 255.255.255.0
    dns1: 192.168.4.1