Desky Standing Desk (ESPHome) [Works with Desky, Uplift, Jiecang, Assmann & others]

@edenhaus, mostly because those gave me some data. I counted the pins from right to left initially though, so I meant pins 1 & 5. I might have swapped them around, because I also measure 3.3V between 1- and 5+.

Looks like a decent guess to me.

I think that’s a decent start for some further uart debug inspections.

These are quite handy for this kind of thing too.

Just found this amazing item on AliExpress. Check it out!

AU$11.39 | USB Logic Analyzer 24MHz 8 Channel 24M/seconds Logic Analyzer Debugger For ARM FPGA Logic Analyzer Logic 24M 8CH
https://a.aliexpress.com/_mNQQEyU

I’ve been using this tool with a couple of standing desks, one from Uplift and one from Deskhaus and it works pretty well, the only problem is that the Uplift occasionally seems to lose the tilt value, and it floods my logs (and eventually kills HA) with entries like this:

[09:02:42][D][cover:170]: 'Detached Desk' - Publishing:
[09:02:42][D][cover:178]:   State: CLOSED
[09:02:42][D][cover:184]:   Tilt: nan%
[09:02:42][D][cover:186]:   Current Operation: IDLE

Is there any way to set the tilt to some default integrer, or rate limit the state reporting when it doesn’t get an initial value from the desk controller? If I manually adjust the height the desk correctly reports, and the log flood stops, but the desk is in another building, and routinely loses the tilt value so not sustainable to manually move the height all the time.

What config are you using?

Is the esp perhaps rebooting? You can add an uptime sensor to check.

Here’s my config file. Oddly it’s exactly the same (aside from obvious things like name and measurements) as the Deskhaus, which doesn’t exhibit this behavior. Whenever I update via OTA I get the above condition where the logs are flooded.

I’m using the same ESP boards and same wiring in each as well.

esphome:
  name: detached-desk
  friendly_name: Detached Desk

esp8266:
  board: d1_mini

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "secret"

ota:
  - platform: esphome
    password: "secret"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Detached-Desk Fallback Hotspot"
    password: "secret"

captive_portal:

external_components:
#Fetch ssieb's custom component# https://github.com/ssieb/custom_components/tree/master/components/desky
  - source:
      type: git
      url: https://github.com/ssieb/custom_components
    components: [ desky ]

uart:
  - id: desk_uart
    baud_rate: 9600
    rx_pin: GPIO1 #Labelled TX on my D1mini clone (mislabelled?)
    ##You can uncomment the debug section below to see UART messages.
    # debug:
      # direction: RX
      # dummy_receiver: true
      # after:
        # bytes: 4
      # sequence:     
        # - lambda: UARTDebug::log_int(direction, bytes, ',');

substitutions:
  # Required (replace these with your own values!)
  desky_request_height_pin: GPIO14 #Request desk height | white wire  
  desky_purple_pin: GPIO12 #purple wire  
  desky_down_pin: GPIO5 #Move desk down | yellow wire  
  desky_up_pin: GPIO4  #Move desk up | green wire  
  descriptor: 'Detached Desk'
  unit_of_measurement: 'in'
  min_height: '25.3'
  max_height: '50.9'
  default_standing_height: '29.2'
  stopping_distance: '1'

desky:
  id: desk_controller
  up:    
    number: ${desky_up_pin} #D2
    inverted: true 
  down:  
    number: ${desky_down_pin} #D1
    inverted: true
  request:
    number: ${desky_request_height_pin} #D6
    inverted: true
  stopping_distance: ${stopping_distance}
  timeout: 15s
  height:
    id: desk_height
    name: ${descriptor} Height
    accuracy_decimals: 1
    unit_of_measurement: ${unit_of_measurement}
    filters:
    - delta: 0.05
    - throttle: 200ms
    - multiply: 0.1

cover:
  - platform: template
    name: ${descriptor}
    device_class: blind
    icon: mdi:desk
    lambda: |-
      if (id(desk_height).state >= id(desk_standing_height).state) {
        return COVER_OPEN;
      } else {
        return COVER_CLOSED;
      }
    open_action:
      - lambda: id(desk_controller).move_to(id(desk_standing_height).state * 10);  
    close_action:
      - lambda: id(desk_controller).move_to(id(desk_sitting_height).state * 10);  
    stop_action:
      - lambda: id(desk_controller).stop();
    tilt_lambda: |-
        return (id(desk_height).state - ${min_height}) / (${max_height} - ${min_height});
    tilt_action:
      - lambda: id(desk_controller).move_to(((tilt * (${max_height} - ${min_height})) + ${min_height}) * 10);



number:
  - platform: template
    id: desk_sitting_height
    name: ${descriptor} Sitting Height
    optimistic: true
    unit_of_measurement: ${unit_of_measurement}
    min_value: ${min_height}
    max_value: ${default_standing_height}
    step: 0.1
    restore_value: true
    initial_value: ${min_height}
    mode: box
    icon: mdi:arrow-down
    
  - platform: template
    id: desk_standing_height
    name: ${descriptor} Standing Height
    optimistic: true
    unit_of_measurement: ${unit_of_measurement}
    min_value: ${default_standing_height}
    max_value: ${max_height}
    step: 0.1
    restore_value: true
    initial_value: ${default_standing_height}
    mode: box
    icon: mdi:arrow-up

Does the desk not report it’s height after boot or OTA by chance… Until you move it?

You can probably test if the request height command is working properly with the below using your gpio14. May need to allow_other_uses to use the pin twice.

switch:
#wake up ther desk and request it sends its height 
  - platform: gpio
    id: wake_desk_and_get_height
    name: "Request Desk Height"
    pin:
      number: D5
      inverted: true
    on_turn_on:
    - delay: 100ms
    - switch.turn_off: wake_desk_and_get_height

It’s probably better to try to address the underlying problem, but you can probably check for and workaround nans using something like this in your tilt lamda.

Does the desk not report it’s height after boot or OTA by chance… Until you move it?

Yes, that’s exactly what happens!

I added the height request switch and also added the lambda (THANK YOU as that solved the log flooding). However, activating the switch results in no height returned, and basically the desk acts as if it were “dead” until it is moved at the physical controller, and then all works as expected. This state seems to occur after an OTA. I haven’t tried after a power failure or similar, but I recall this happening outside of just OTA so any reboot of the ESP may trigger this state although I can confirm next time I’m out there.

You should double check your wiring / connections on GPIO14. And then try moving it to another GPIO if that doesn’t resolve it.

I had a cheap D1 mini kind of die slowly. Possibly just due to it being a crappy board. Or possibly because we are using 5V logic on the 3V pins (they are 5v tolerant but may not last in the long run).

Give the above a go…

Do you know if the configuration from @ssieb has been used or tested on ESP32 boards? I’ve only seen examples of the D1 mini’s here for that config.

I’m currently trying the same cover config that Slappy a few posts above is using. I’m running an esp32s (esp32-wroom-32), trying to control an Uplift V2 desk. Pins have been changed per open pins from here.
I’ve tested all used GPIO pins to ground w/ a multimeter, and they are at a constant 3.3V when inactive, showing that the invert is working, however when I try to give any commands, I don’t get a low level signal at all. I wrote some test code with a few switches to fire the same exact GPIO pins, and it works without issues.

All other aspects, such as height fetching work as intended

Any thoughts?
Current config with issues:

substitutions:
  name: "office-desk"
  friendly_name: Office Desk
  # Required (replace these with your own values!)
  desky_request_height_pin: GPIO18 #Request desk height | white wire  
  desky_purple_pin: GPIO19 #purple wire  
  desky_down_pin: GPIO21 #Move desk down | yellow wire  
  desky_up_pin: GPIO22  #Move desk up | green wire 
  descriptor: "Office Desk"
  unit_of_measurement: 'in'
  min_height: '25.3'
  max_height: '50.9'
  default_standing_height: '42.0'
  stopping_distance: '1'

esphome:
  name: ${name}
  friendly_name: ${friendly_name}
  min_version: 2024.6.0
  name_add_mac_suffix: false
  project:
    name: esphome.web
    version: dev

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
- platform: esphome

# Allow provisioning Wi-Fi via serial
improv_serial:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: 192.168.12.102
    gateway: 192.168.12.1
    subnet: 255.255.255.0

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Office Desk Fallback"
    password: "redacted"


# In combination with the `ap` this allows the user
# to provision wifi credentials to the device via WiFi AP.
captive_portal:

dashboard_import:
  package_import_url: github://esphome/example-configs/esphome-web/esp32.yaml@main
  import_full_config: true

# Sets up Bluetooth LE (Only on ESP32) to allow the user
# to provision wifi credentials to the device.
esp32_improv:
  authorizer: none

# To have a "next url" for improv serial
web_server:

external_components:
#Fetch ssieb's custom component# https://github.com/ssieb/custom_components/tree/master/components/desky
  - source:
      type: git
      url: https://github.com/ssieb/custom_components
    components: [ desky ]

uart:
  - id: desk_uart
    baud_rate: 9600
    rx_pin: GPIO1 #To TX0.
    ##You can uncomment the debug section below to see UART messages.
#    debug:
#      direction: RX
#      dummy_receiver: true
#      after:
#        bytes: 4
#      sequence:     
#        - lambda: UARTDebug::log_int(direction, bytes, ',');

desky:
  id: desk_controller
  up:    
    number: ${desky_up_pin} #D22
    inverted: true
  down:  
    number: ${desky_down_pin} #D21
    inverted: true
  request:
    number: ${desky_request_height_pin} #D18
    allow_other_uses: true
    inverted: true
  stopping_distance: ${stopping_distance}
  timeout: 15s
  height:
    id: desk_height
    name: ${descriptor} Height
    accuracy_decimals: 1
    unit_of_measurement: ${unit_of_measurement}
    filters:
    - delta: 0.05
    - throttle: 200ms
    - multiply: 0.1

cover:
  - platform: template
    name: ${descriptor}
    device_class: blind
    icon: mdi:desk
    lambda: |-
      if (id(desk_height).state >= id(desk_standing_height).state) {
        return COVER_OPEN;
      } else {
        return COVER_CLOSED;
      }
    open_action:
      - lambda: id(desk_controller).move_to(id(desk_standing_height).state * 10);  
    close_action:
      - lambda: id(desk_controller).move_to(id(desk_sitting_height).state * 10);  
    stop_action:
      - lambda: id(desk_controller).stop();
    tilt_lambda: |-
        return (id(desk_height).state - ${min_height}) / (${max_height} - ${min_height});
    tilt_action:
      - lambda: id(desk_controller).move_to(((tilt * (${max_height} - ${min_height})) + ${min_height}) * 10);



number:
  - platform: template
    id: desk_sitting_height
    name: ${descriptor} Sitting Height
    optimistic: true
    unit_of_measurement: ${unit_of_measurement}
    min_value: ${min_height}
    max_value: ${default_standing_height}
    step: 0.1
    restore_value: true
    initial_value: ${min_height}
    mode: box
    icon: mdi:arrow-down
    
  - platform: template
    id: desk_standing_height
    name: ${descriptor} Standing Height
    optimistic: true
    unit_of_measurement: ${unit_of_measurement}
    min_value: ${default_standing_height}
    max_value: ${max_height}
    step: 0.1
    restore_value: true
    initial_value: ${default_standing_height}
    mode: box
    icon: mdi:arrow-up

switch:
#wake up ther desk and request it sends its height 
  - platform: gpio
    id: wake_desk_and_get_height
    name: "Request Desk Height"
    pin:
      number: GPIO18
      inverted: true
      allow_other_uses: true
    on_turn_on:
    - delay: 100ms
    - switch.turn_off: wake_desk_and_get_height

Yes I’ve tested it personally. No issues. Just use different pins. However that was an earlier version.

There were some changes to it a while back that possibly caused issues. I’m not sure if they were ever worked through. So could be that.

Does a basic “move_to” command work?

Say with a hardcoded value using a virtual button (making sure you’re in the right units)?

on_...: 
  then:
    - lambda: id(my_desky).move_to(150); # https://github.com/ssieb/esphome_components/tree/master/components/desky

We’re on the same train of thought. After giving it a break last night, I wanted to come back and try to drive it through the desky configuration. Basic “move_to” and “stop” commands are working fine (units set to ‘in’, sending hardcoded ints of inches*10). Only anomaly with the code I tacked onto the end is that the switch “turn_off_action” doesn’t actually send a stop command. I need to hit the button for that, but that’s easy to build a workaround.

Looks like it’s now narrowed down to the cover entity setup from my original config, which I can certainly dig into. That’s what I get for copy-pasting I guess.

Test code additions:

switch:
  - platform: template
    name: Move Up
    id: desky_move_up
    turn_on_action:
      then:
        - lambda: id(desk_controller).move_to(509);
    turn_off_action: 
      then:
        - lambda: id(desk_controller).stop();

  - platform: template
    name: Move Down
    id: desky_move_down
    turn_on_action:
      then:
        - lambda: id(desk_controller).move_to(253);
    turn_off_action: 
      then:
        - lambda: id(desk_controller).stop();

button: 
#Move to test function
  - platform: template
    name: Go To Desky Height x
    id: go_to_desky_preset_height_x
    on_press:
      then:
        - lambda: id(desk_controller).move_to(420); # Check your desk for a suitable value to use.
#Stop movement 
  - platform: template
    name: Stop Desk
    id: desky_stop_desk
    on_press:
      then:
        - lambda: id(desk_controller).stop();
        
binary_sensor:
  - platform: template
    name: Desky moving
    lambda: return id(desk_controller).current_operation != desky::DESKY_OPERATION_IDLE;
1 Like

I was mistaken. It’s not narrowed down to the cover, but rather it looks like something in the firmware flashing causes issues. Tried to re-build bits and pieces of the cover entity and flash again. Nothing worked as before, so I reverted back to the original working code. Still there was no output, so I think I’m moving on from the external components from github.

Has anyone gotten this working with older, non-V2 Uplift desks?

I don’t have much info about the model and am not seeing any identifying info on the control box, but I did buy it ten years ago so its pretty old and definitely not the V2.

Where I’m at now is I’ve flashed an ESP32 with a few different configs, with @Mahko_Mahko’s more complex config I get the following:

With the rx pin disconnected:

  • basic up/down/stop functionality does work
  • getting the desk height does not work, HA shows “unknown” value
  • telling the desk to go to a specific height will set the desk in motion but it does not stop at the correct height or even move in the correct direction (obviously HA/ESPhome won’t know which direction to go in or where to stop if it doesn’t know the height)

With the rx pin connected:

  • the desk will go up and down at seemingly random intervals/durations regardless of whether or not any action has been requested from HA

With @ssieb’s simpler config the result is similar but when the rx pin is connected there is no random movement, rather the controls on the desk’s control panel stop working, but work again if you disconnect the rx pin.

Next step would be going through and debugging but as I do that I was hoping to get confirmation of whether or not I should even expect this to work off the shelf given the age of my control box.

I would continue trying. There is some hope I think.

You need to focus on :

  1. Confirming you can see some uart messages when you move the desk with the desks buttons. Enable/ uncomment uart debug and set logger level to verbose.
  2. If/when you see consistent uart messages, post them so we can take a look.

It would also help debugging if you post some pictures of your control box, wiring, and post your best config. Could be your wiring or you may need to switch rx/tx etc.

Does your control box just have a rj45 port or does it have an rj12 too?

Thanks for the advice and also whoops I lied lol, there is a model identifier on it, pics attached.

When I attempted to get the uart debugging setup I noticed this message in the logs:

[W][uart.arduino_esp32:206]:   You're using the same serial port for logging and the UART component. Please disable logging over the serial port by setting logger->baud_rate to 0

A little research led me here and following that guide I started testing with GPIOs 9 and 10 instead of 1 and 3 (because I had noticed you said you had to switch rx/tx on your D1 so I’ve made a point to try with both on this board).

That did bring with it a positive change, which is that the desk no longer randomly moves around when the rx or tx pins are connected. I can also use the buttons on the control panel with either of the pins connected, and sending up/down/stop commands all work fine.

Unfortunately getting the desk height and sending it to a specific one still don’t work, and I am not seeing any uart messages in the logs at all, and definitely not when I press the desk buttons.

Does your control box just have a rj45 port or does it have an rj12 too?

My control box does have both rj45 and rj12.

It would also help debugging if you post some pictures of your control box, wiring, and post your best config. Could be your wiring or you may need to switch rx/tx etc.

Attached pics of control box with model info, wiring pics, and pinout from seller for ESP32 board. Wiring all seems to be solid and as mentioned I’ve been trying switching rx/tx to no avail (both changing the pins specific in config, but also switching between the pins physically without changing the config). Let me know if anything stands out and thanks again for the help.

Simple config used to test for uart debugs (I’ve also tried your more complex config with the same pins/etc and the behavior is the same now that I’ve switched to trying GPIO’s 9 and 10 as rx_pin):

esphome:
  name: desk
  platform: ESP32
  board: node32s

logger:
  level: VERY_VERBOSE ##Uncomment to see UART debug messages 

external_components:
#Fetch ssieb's custom component# https://github.com/ssieb/custom_components/tree/master/components/desky
  - source:
      type: git
      url: https://github.com/ssieb/custom_components
    components: [ desky ]

uart:
  - id: desk_uart
    baud_rate: 9600
    rx_pin: GPIO9
    debug:
      direction: RX
      dummy_receiver: true
      after:
        bytes: 4
      sequence:     
        - lambda: UARTDebug::log_int(direction, bytes, ',');

desky:
  #uart_id: desk_uart  (optional, unless multiple uarts are defined)
  id: my_desky
  height:  # optional sensor publishing the current height
    name: Desk Height
    id: desk_height
    # any other sensor options
  up:    # optional <pin> config
    number: GPIO26
    inverted: true  # probably needed
  down:  # optional <pin> config
    number: GPIO25
    inverted: true  # probably needed
  request:  # optional <pin> config to request height updates at boot
    number: GPIO27
    inverted: true  # probably needed
  stopping_distance: 15  # optional distance from target to turn off moving, default 15
  timeout: 15s  # optional time limit for moving, default is none

binary_sensor:
  - platform: template
    name: Desky moving
    lambda: return id(my_desky).current_operation != desky::DESKY_OPERATION_IDLE;





We want to focus just on the wire that the desk sends messages on.

So try this.

Remove all config relating to the desky component (comment out). Similar to below. We want to focus on just using the uart debug to try to find uart messages.

I don’t think gpio09 is any good for this. See table with green/red etc. Although I’m not sure about that. Try say 21 in both config and wiring or one of the other ones that are all green in that rough number range.

Once you have done your initial flash with usb, you remove the usb cable and should try powering and grounding the esp via the desk. OTA connecting for looking at logs. Then try having just three wires connected to the esp. Gnd, power and the tx (which goes to your nominated rx on esp). See image.

Set that all up and see if you get some uart debug messages.


esphome:
  name: desk
  platform: ESP32
  board: node32s

logger:
  level: VERY_VERBOSE ##Uncomment to see UART debug messages 


uart:
  - id: desk_uart
    baud_rate: 9600
    rx_pin: GPIO21
    debug:
      direction: RX
      dummy_receiver: true
      after:
        bytes: 4
      sequence:     
        - lambda: UARTDebug::log_int(direction, bytes, ',');

Thanks a million, will run through this soon. I had left the power and ground cables disconnected from the ESP32 as the control box wasn’t powering them when I had them connected.

I played around with getting that to work at first without luck, then saw someone with the same issue say that powering from control box worked as long as they used USB power to boot the ESP32. Tried that and I started getting some smoke out of the ESP32 so immediately disconnected and have not tried powering it from the control box since lol. ESP32 seems to run fine despite that incident and the issues I’m having existed before that but who knows, could have fried something in the chip that will stop this from working.

1 Like

The other thing worth checking and confirming is that your pass through wiring is all correct.

It’s easy to make a mistake or for something to be amiss.

To do that check, follow this post.

Basically disconnect all wires from the esp and confirm the desk works as per normal with just the pass through wires in place.

Pass through wiring seems fine, desk controls all work fine when the control panel is run through the breakout and the ESP32 is fully disconnected.

Had some success using the config you suggested with GPIO21 set for uart, after rigging that up I see uart debug messages in the log. I’ve included those below, it doesn’t appear to be very consistent but then I don’t really know what I’m looking at.

Holding the down button:

[17:38:17][D][uart_debug:176]: <<< 255
[17:38:17][D][uart_debug:176]: <<< 255
[17:38:18][D][uart_debug:176]: <<< 255
[17:38:18][D][uart_debug:176]: <<< 255
[17:38:18][D][uart_debug:176]: <<< 255
[17:38:19][D][uart_debug:176]: <<< 255
[17:38:19][D][uart_debug:176]: <<< 255
[17:38:19][D][uart_debug:176]: <<< 255
[17:38:19][D][uart_debug:176]: <<< 255
[17:38:19][D][uart_debug:176]: <<< 255
[17:38:20][D][uart_debug:176]: <<< 255
[17:38:20][D][uart_debug:176]: <<< 255
[17:38:20][D][uart_debug:176]: <<< 255
[17:42:02][D][uart_debug:176]: <<< 255,255,255,255
[17:42:02][D][uart_debug:176]: <<< 127,255,255,255
[17:42:02][D][uart_debug:176]: <<< 255,255,255,255
[17:42:03][D][uart_debug:176]: <<< 255,255
[17:42:03][D][uart_debug:176]: <<< 253,255
[17:42:04][D][uart_debug:176]: <<< 255
[17:42:04][D][uart_debug:176]: <<< 253
[17:42:04][D][uart_debug:176]: <<< 109
[17:42:04][D][uart_debug:176]: <<< 255
[17:42:05][D][uart_debug:176]: <<< 255
[17:42:05][D][uart_debug:176]: <<< 255
[17:42:06][D][uart_debug:176]: <<< 255

Holding up button:

[17:39:10][D][uart_debug:176]: <<< 255
[17:39:11][D][uart_debug:176]: <<< 219,255,251,251
[17:39:11][D][uart_debug:176]: <<< 255,255,255,255
[17:39:11][D][uart_debug:176]: <<< 255,255,255,255
[17:39:11][D][uart_debug:176]: <<< 251
[17:39:11][D][uart_debug:176]: <<< 255,255,255,255
[17:39:11][D][uart_debug:176]: <<< 255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:12][D][uart_debug:176]: <<< 255,255,255,255
[17:39:13][D][uart_debug:176]: <<< 255,255,255,223
[17:39:13][D][uart_debug:176]: <<< 219,223,255,255
[17:39:13][D][uart_debug:176]: <<< 223,251,251,251
[17:39:13][D][uart_debug:176]: <<< 251,219,255,251
[17:39:13][D][uart_debug:176]: <<< 251,251,251,219
[17:39:13][D][uart_debug:176]: <<< 255,251,255,255
[17:39:13][D][uart_debug:176]: <<< 255,255,251,255
[17:39:13][D][uart_debug:176]: <<< 219,255,255,255
[17:39:13][D][uart_debug:176]: <<< 255,219,251,255
[17:39:13][D][uart_debug:176]: <<< 255,251,251,255
[17:39:13][D][uart_debug:176]: <<< 251,251,223,255
[17:39:13][D][uart_debug:176]: <<< 255,255,223,223
[17:39:14][D][uart_debug:176]: <<< 255,255,223,255
[17:39:14][D][uart_debug:176]: <<< 255,255,255,255
[17:39:14][D][uart_debug:176]: <<< 251,255,255,255
[17:39:14][D][uart_debug:176]: <<< 251,251,251,255
[17:39:14][D][uart_debug:176]: <<< 219,251,251,219
[17:39:14][D][uart_debug:176]: <<< 219,251,219,251
[17:39:14][D][uart_debug:176]: <<< 251,251,219,251
[17:39:14][D][uart_debug:176]: <<< 251,251,251,255
[17:39:14][D][uart_debug:176]: <<< 255,251,251,251
[17:39:14][D][uart_debug:176]: <<< 255,251,251,251
[17:39:14][D][uart_debug:176]: <<< 251,251,251,219
[17:39:14][D][uart_debug:176]: <<< 251,219,219,251
[17:39:14][D][uart_debug:176]: <<< 255,251,251,251
[17:39:14][D][uart_debug:176]: <<< 219,251,251,251
[17:39:15][D][uart_debug:176]: <<< 251,255,255,251
[17:39:15][D][uart_debug:176]: <<< 251,251,251,251
[17:39:15][D][uart_debug:176]: <<< 255,251,219,255
[17:39:15][D][uart_debug:176]: <<< 255,251,251,251
[17:39:15][D][uart_debug:176]: <<< 251,255

I then tried using GPIO21 for the rx_pin in your more complex config and found an interesting result:

  • if the up or down pins are connected the ESP32 stops sending logs to the console and stops responding to network traffic
  • if the request desk height pin is connected the ESP32 maintains network connectivity and the logs show a constant stream of the following:
[17:47:36][D][uart_debug:176]: <<< 0,192,0,224
[17:47:36][D][uart_debug:176]: <<< 224,254,224,192
[17:47:36][D][uart_debug:176]: <<< 224,192,224,224
[17:47:36][D][uart_debug:176]: <<< 192,224,224,224
[17:47:36][D][uart_debug:176]: <<< 62,254,248,248
[17:47:36][D][uart_debug:176]: <<< 248,224,192,192
[17:47:36][D][uart_debug:176]: <<< 192,192,254,248
[17:47:36][D][uart_debug:176]: <<< 192,240,240,192
[17:47:36][D][uart_debug:176]: <<< 192,192,240,254
[17:47:36][D][uart_debug:176]: <<< 254,248,240,240
[17:47:36][D][uart_debug:176]: <<< 192,248,192,240
[17:47:36][D][uart_debug:176]: <<< 240,192,240,254
[17:47:36][D][uart_debug:176]: <<< 248,248,192,240
[17:47:36][W][component:237]: Component uart took a long time for an operation (193 ms).
[17:47:36][W][component:238]: Components should block for at most 30 ms.
[17:47:36][D][uart_debug:176]: <<< 240,0,0,224
[17:47:36][D][uart_debug:176]: <<< 0,192,0,192
[17:47:36][D][uart_debug:176]: <<< 0,192,0,192
[17:47:36][D][uart_debug:176]: <<< 0,224,0,192
[17:47:36][D][uart_debug:176]: <<< 0,192,0,192
[17:47:36][D][uart_debug:176]: <<< 0,240,0,240
[17:47:36][D][uart_debug:176]: <<< 0,192,0,192
[17:47:36][D][uart_debug:176]: <<< 0,192,0,192
[17:47:36][D][uart_debug:176]: <<< 0,192,0,192
[17:47:36][D][uart_debug:176]: <<< 0,192,0,224
[17:47:37][D][uart_debug:176]: <<< 224,62,254,248
[17:47:37][D][uart_debug:176]: <<< 224,192,224,224
[17:47:37][W][component:237]: Component uart took a long time for an operation (177 ms).
[17:47:37][W][component:238]: Components should block for at most 30 ms.
[17:47:37][D][uart_debug:176]: <<< 224,192,192,224
[17:47:37][D][uart_debug:176]: <<< 254,248,224,248
[17:47:37][D][uart_debug:176]: <<< 224,248,192,224
[17:47:37][D][uart_debug:176]: <<< 224,192,0,192
[17:47:37][D][uart_debug:176]: <<< 0,224,0,192
[17:47:37][D][uart_debug:176]: <<< 0,224,0,192
[17:47:37][D][uart_debug:176]: <<< 0,224,0,192
[17:47:37][D][uart_debug:176]: <<< 0,192,0,224
[17:47:37][D][uart_debug:176]: <<< 0,192,0,240
[17:47:37][D][uart_debug:176]: <<< 0,192,254,254
[17:47:37][D][uart_debug:176]: <<< 248,224,192,224
[17:47:37][D][uart_debug:176]: <<< 192,192,224,192
[17:47:37][D][uart_debug:176]: <<< 192,192,0,224
[17:47:37][W][component:237]: Component uart took a long time for an operation (181 ms).
[17:47:37][W][component:238]: Components should block for at most 30 ms.
[17:47:37][D][uart_debug:176]: <<< 0,192,0,192
[17:47:37][D][uart_debug:176]: <<< 0,224,0,224
[17:47:37][D][uart_debug:176]: <<< 0,192,254,248
[17:47:37][D][uart_debug:176]: <<< 224,192,240,192
[17:47:37][D][uart_debug:176]: <<< 240,240,192,192
[17:47:37][D][uart_debug:176]: <<< 62,254,254,248
[17:47:37][D][uart_debug:176]: <<< 240,240,192,240
[17:47:37][D][uart_debug:176]: <<< 192,192,192,192
[17:47:37][D][uart_debug:176]: <<< 240,192,192,62
[17:47:37][D][uart_debug:176]: <<< 254,248,240,240
[17:47:37][D][uart_debug:176]: <<< 0,224,0,192
[17:47:37][D][uart_debug:176]: <<< 0,192,0,224
[17:47:37][W][component:237]: Component uart took a long time for an operation (169 ms).
[17:47:37][W][component:238]: Components should block for at most 30 ms.
[17:47:37][D][uart_debug:176]: <<< 0,192,0,240
[17:47:37][D][uart_debug:176]: <<< 0,192,0,192
[17:47:37][D][uart_debug:176]: <<< 0,192,0,224
[17:47:37][D][uart_debug:176]: <<< 0,224,0,192
[17:47:37][D][uart_debug:176]: <<< 248,224,224,224
[17:47:37][D][uart_debug:176]: <<< 224,192,224,192
[17:47:37][D][uart_debug:176]: <<< 224,224,254,248
[17:47:37][D][uart_debug:176]: <<< 248,248,224,192
[17:47:37][D][uart_debug:176]: <<< 224,224,192,192
[17:47:37][D][uart_debug:176]: <<< 192,192,192,0
[17:47:37][D][uart_debug:176]: <<< 224,0,192,0
[17:47:37][D][uart_debug:176]: <<< 192,0,192,0
[17:47:37][D][uart_debug:176]: <<< 224,0,192,0
[17:47:37][W][component:237]: Component uart took a long time for an operation (183 ms).
[17:47:37][W][component:238]: Components should block for at most 30 ms.
[17:47:37][D][uart_debug:176]: <<< 254,248,248,248
[17:47:37][D][uart_debug:176]: <<< 192,240,192,192
[17:47:37][D][uart_debug:176]: <<< 192,254,0,240
[17:47:37][D][uart_debug:176]: <<< 0,192,0,192
[17:47:37][D][uart_debug:176]: <<< 0,192,0,240
[17:47:37][D][uart_debug:176]: <<< 0,192,0,192
[17:47:37][D][uart_debug:176]: <<< 0,240,0,240
[17:47:37][D][uart_debug:176]: <<< 0,240,0,192
[17:47:37][D][uart_debug:176]: <<< 0,192,0,192
[17:47:37][D][uart_debug:176]: <<< 0,224,0,192
[17:47:37][D][uart_debug:176]: <<< 0,192,0,224
[17:47:37][D][uart_debug:176]: <<< 0,192,248,248
[17:47:37][W][component:237]: Component uart took a long time for an operation (169 ms).
[17:47:37][W][component:238]: Components should block for at most 30 ms.
[17:47:37][D][uart_debug:176]: <<< 224,248,192,224
[17:47:37][D][uart_debug:176]: <<< 224,224,192,192
[17:47:37][D][uart_debug:176]: <<< 0,192,0,192
[17:47:37][D][uart_debug:176]: <<< 0,224,0,224
[17:47:37][D][uart_debug:176]: <<< 0,192,0,192
[17:47:37][D][uart_debug:176]: <<< 0,192,0,240
[17:47:37][D][uart_debug:176]: <<< 192,62,254,254
[17:47:37][D][uart_debug:176]: <<< 224,192,224,192
[17:47:37][D][uart_debug:176]: <<< 224,192,192,0
[17:47:37][D][uart_debug:176]: <<< 192,0,192,0
[17:47:37][D][uart_debug:176]: <<< 0,240,0,240
[17:47:37][D][uart_debug:176]: <<< 240,62,254,240
[17:47:38][D][uart_debug:176]: <<< 248,240,240,192
[17:47:38][W][component:237]: Component uart took a long time for an operation (181 ms).
[17:47:38][W][component:238]: Components should block for at most 30 ms.
[17:47:38][D][uart_debug:176]: <<< 240,240,240,240
[17:47:38][D][uart_debug:176]: <<< 192,240,254,192
[17:47:38][D][uart_debug:176]: <<< 224,224,224,192
[17:47:38][D][uart_debug:176]: <<< 192,0,192,0
[17:47:38][D][uart_debug:176]: <<< 192,0,192,0
[17:47:38][D][uart_debug:176]: <<< 192,0,192,0
[17:47:38][D][uart_debug:176]: <<< 224,0,224,248
[17:47:38][D][uart_debug:176]: <<< 248,248,192,224
[17:47:38][D][uart_debug:176]: <<< 224,240,192,192
[17:47:38][D][uart_debug:176]: <<< 62,254,254,248
[17:47:38][D][uart_debug:176]: <<< 240,240,192,240
[17:47:38][D][uart_debug:176]: <<< 192,240,192,192
[17:47:38][W][component:237]: Component uart took a long time for an operation (175 ms).
[17:47:38][W][component:238]: Components should block for at most 30 ms.
[17:47:38][D][uart_debug:176]: <<< 240,254,248,254
[17:47:38][D][uart_debug:176]: <<< 248,240,248,192
[17:47:38][D][uart_debug:176]: <<< 240,240,192,0
[17:47:38][D][uart_debug:176]: <<< 192,62,254,248
[17:47:38][D][uart_debug:176]: <<< 224,192,224,192
[17:47:38][D][uart_debug:176]: <<< 224,192,192,192
[17:47:38][D][uart_debug:176]: <<< 62,248,248,224
[17:47:38][D][uart_debug:176]: <<< 248,224,230,192
[17:47:38][W][component:237]: Component uart took a long time for an operation (110 ms).
[17:47:38][W][component:238]: Components should block for at most 30 ms.

Ok I think that’s progress.

I think the messages can be noisy if you’re not grounded properly. Try adding the ground wire like this. Remove it if anything smokes etc;) I think it is ok.
I assume you are still powering via usb?

After looking at logs for that, also, try changing this to 9.

bytes: 9

Move the desk up or down and post logs again please.

If we do hit a dead end with the rj45 port, you can also try your luck with the rj12 port. It’s even potentially preferable.

Also, if you have a multimeter, it’s worth checking you get 5v on the power/gnd desk wires that go to the esp.