Help figuring out possible support for CB38M2D(PB)-2

[Scoff123]

I'm hoping to work out whether or not this can be used with my Flexispot EQ5 model which uses the CB38M2D(PB)-2 control unit with Sanodesk LCD controller. The control unit doesn't have a spare RJ45 port. The LCD button panel connects to the Control box with one cable which splits into two - an RJ45 and a 2 pin connector which both go into the control box. The units appear to be sealed/glued with no easy access so I can't open them to view the boards inside, and with it still being under warranty I'm a bit hesitant to try and split the cases! Pictures to show the units, but I suppose it's a long shot hoping to get this working unless anyone else with the same model has been brave enough to open the units up to investigate?

[IamMattM]

@iMicknl Credit to you for sharing this great repo.

You are wellcome to use any of the posted information above for the repo. Flexispot EQ5 google drive

The "summary" is that the EQ5 can be supported with the ESP32 acting a the "man-in-the-middle" and presenting two RJ45 sockets (EQ5 controller side and Keypad side)

The 3D printable enclosure and the RJ45 blank place (.stl files) in the google drive above are courtesy of others on printable.com

The EQ5 .yaml/.h filesare working ones while the photos will hopefully show enough resolution for others to make sense of the connections required.

Note: EQ5.keypad position#4 is not functional when operated from physical keypad (needs firmware change to filter on both byte#4+5) - Perhaps a small endeavour for you ?

Thanks again for having shared your work - I now have two FLexispot EQ5 "wired" up and controllable through Google ;-) why not !

[deveritt-uk]

Firstly huge kudo and credit to both of you @IamMattM and @Scoff123, all of your work above has been absolutely amazing! It was a great read.

I came across your above thread the other day, but needed to order some more ESP32's as using all my others around the house already.

I have got keystones already (pretty geeky) and plenty of jumper leads / ethernet, also a 3D printer for the case....

What I dont have though is a clear wiring diagram, you said to iMicknl "while the photos will hopefully show enough resolution for others to make sense of the connections required." Unfortunately I can not make sense of them as I'm partially colour blind... (rofl)...

I was wondering if there was any way of maybe putting a basic sketch together (in your paint of choice) if at all possible please?

[IamMattM]

@deveritt-uk :

Try "FlexiSPot_EQ5_Connections.pdf" in the Google repo above.

Forgot to add that the connection numbers for "J2" + "J3" are marked on the side of an RJ45 keystone connector and the implementation follows the T568-B

[IamMattM]

Also please note that if I was to do it again I would flip the DEVKIT as to being able to see the connection names before soldering the wires ( I already had the module headers soldered and did not want to have to un-solder them for this ...)

If you do so, you will just need to mirror top/bottom connections compared to how they appear in the camera shot above but of course the schematic would just remains the same.

[deveritt-uk]

Huge thanks @IamMattM!

That's really great! I thought a few of them were doubled up, so will have to get the soldering iron out to look in to this, I had my partner sat with me trying to decode the colours last night (ha) but we couldn't quite follow them all the way around haha... (Plus was getting late for us)

Shall give this a try out in the next few days and let you know!

Thanks again!

[deveritt-uk]

Evening, so I have it fully wired up and flashed the controller as shown below:

I have it flipped as you mentioned @IamMattM, but used the schematic so it "should" be fine...

When I have it all hooked up to my EQ5, the screen read out shows 68.1 and I can pull that through to Home Assistant in to my dashboard as 68.1 as shown below:

but... I can't send any commands and HA also can not push commands through.

Just wondering if there is anything I can to try and "trouble shoot" my wiring? I suspect something isn't wired up correctly, possibly my TX2

Thanks in advanced!

[IamMattM]

@deveritt-uk

I don't suppose you might have inadvertently swapped EQ5 vs. Keypad RJ45 connections ?

The EQ5 height information to the ESP32 and Keypad screen would be unaffected by this hence why you might still have that functionality working.

On your top-view pics above, the left hand side port should be attaching to the keypad. If that is not the case then it is almost certainly your problem.

If you have it correctly wired-up externally then consider whether the "VirtualScreen" toggle is ACTIVE as this is necessary to allow the EQ5 box to register the requested commands.

[IamMattM]

When compiling the code for ESP32, did you also make use of my versions of the .yaml and with the two .h files ? All in the G.drive.

Those files would already have been adapted to take the VirtScreen (aka keypad is present) to a default=ACTIVE for it to work straight away.

[IamMattM]

I think I found your issue:

If I look at it correctly goes towards the EQ5 port showing on the right hand side.

However, If I try to follow <RX0/IO3=green_kpd> it is also incorrectly going towards the EQ5 port on the right hand side when it should be going to the keypad port on the left hand side - This is why it is not working and is easily fixed by :

swapping out the two internal green wires connections at the ESP32 end, to make it good.

The rest of the internal wires look ok to me. And of course, externally attach to the intended port EQ5 port (right) towards EQ5 box, while Keypad port (left) attaches to keypad.

[deveritt-uk]

@IamMattM

Thanks for the above pointers and info,

It turned out that I had switched the Green 6 and had them the wrong way around so pins 17 and IO3 where mixed up. Checked all the other wiring on the Keystones and they still matched the schematic, I guess that's what you get for trying to multi task at the same time as wiring things up...

Swopped them over and now it's working a treat!

Virtual Screen is indeed active by default as yes I had compiled from the latest yaml in the google drive and also used the two .h files in the esphome conf section.

Thanks for all the tips and pointers

[deveritt-uk]

I think I found your issue:

If I look at it correctly goes towards the EQ5 port showing on the right hand side.

However, If I try to follow <RX0/IO3=green_kpd> it is also incorrectly going towards the EQ5 port on the right hand side when it should be going to the keypad port on the left hand side - This is why it is not working and is easily fixed by :

swapping out the two internal green wires connections at the ESP32 end, to make it good.

The rest of the internal wires look ok to me. And of course, externally attach to the intended port EQ5 port (right) towards EQ5 box, while Keypad port (left) attaches to keypad.

Just seen your reply above as I was typing out, many thanks!

[IamMattM]

One more thing: the WiFi antenna could be upset by the presence of the metal screw head where you have it in your pics. I would consider relocating towards USB connector if there is no clash.

This is only to maximise your wireless range once fitted underneath the desk.

[IamMattM]

@deveritt-uk : GLad you got this going ! Nice one.

[deveritt-uk]

One more thing: the WiFi antenna could be upset by the presence of the metal screw head where you have it in your pics. I would consider relocating towards USB connector if there is no clash.

This is only to maximise your wireless range once fitted underneath the desk.

As I have pan head screws, it catches the EN / Boot buttons that end aha... It's not actually "touching" the wifi antenna now as I just "loosely" put it back in, but might just hot glue it in instead anyway :)

Many thanks!

Now to add it to some automations!

[Scoff123]

Finally my 3D printed case arrived so i got things wired up today. All seemed to go ok, although soldering the cat5 wires to the board was quite fiddling, especially where 2 were joined together such as the brown wires. There must be an issue with either my solder joints, or the board itself though, as I keep getting continuous Virtual screen on/off toggles, which is oddly affected by holding my finger close - without touching - to the blue wire between the keypad keystone jack and the esp board?! I've looked and can't see anything obvious in terms of soldering failures - not the best joints in the word but neat enough - but perhaps not. Seems like some sort of grounding issue perhaps, given the finger close to wire issue, but this is what I'm seeing in the ESP logs:

I guess it's process of elimination, but the blue wires for pins VrtScr seem like a good place to start - although I've resoldered them both now, and continuity checks out fine from the ethernet side of the jacks to the board pins.....

[Scoff123]

OK so I removed the blue wire that comes from the keypad keystone jack to GPIO22 / VrtScr from the esp board. This eliminates the issue, so the problem appears to be GPIO22 on my board. I've swapped to a different pin on the board, GPIO2 and soldered to that one instead, and changed the binary sensor for 'screen' to GPIO2 within the esp config, and flashed to the board. This seems to have resolved the problem! The Virtual screen is staying 'ON' in my Home Assistant dash, and no more on/off toggles constantly in the esp log output :)

I've connected my board in line between my EQ5 and keypad, and I'm not getting the blue LED on my esp board (not sure if this is meant to be lit up or not) and I can send commands to the desk and they seem to work fine. The only slightly odd thing remaining, is that my keypad stays lit up constantly while I have my device in place? The timeout isn't kicking in for some reason. Is there somewhere else that I need to reflect my GPIO pin swap from 22 to 2?

[IamMattM]

@Scoff123 Great to hear you got the 3D printed case.

And well done for porting GPIO22 to GPIO2 to resolve your issue although very odd indeed...

Are you using the two .h files and the .yaml from the Google repo ? What board are you using - PErhaps you need to edit the "board" type to match yours:

[Scoff123]

@IamMattM Thank you. I may have been a bit quick to choose GPIO2, although it works - after checking online to refresh my memory, GPIO2 is used for the onboard LED (hence why I now have a shiny blue light on the board blinding me!). I am using all of the config files from the repo, and currently have:

ESPHome 2023.5.4
INFO Reading configuration /config/esphome/flexispot_eq5_esp32.yaml...
WARNING GPIO2 is a Strapping PIN and should be avoided.
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
INFO Configuration is valid!
substitutions:
  device_name: Flexispot EQ5
  name: flexispot-eq5
  min_height: '71.0'
  max_height: '125.1'
esphome:
  name: flexispot-eq5
  friendly_name: flexispot-eq5
  includes:
  - desk_height_sensor_eq5.h
  - desk_keypad_eq5.h
  build_path: .esphome/build/flexispot-eq5
  platformio_options: {}
  libraries: []
  name_add_mac_suffix: false
  min_version: 2023.5.4
esp32:
  board: esp32dev
  framework:
    version: 2.0.5
    source: ~3.20005.0
    platform_version: platformio/espressif32@5.3.0
    type: arduino
  variant: ESP32

which during validation, throws the above message, so I might move to GPIO4 instead as that one doesn't have any other purpose on the board. The back of my board says ESP32 DEVKITV1, so I might also try changing the board type to the one in your screenshot above as it's probably closer to my actual board.

I'll try that and reflash and plug in the board and see if the keypad starts behaving correctly. Unless it's an issue with the script and timeout feature not working correctly with my esphome version or something...

[Scoff123]

So having moved over from GPIO2 to GPIO18, the blue board LED is no longer lit up, and I don't get the compile warning message. However, I do still have the constant ON/OFF toggle of the Virtual screen sensor. So I'm going to have to look at changing GPIO23. The same seemingly odd behaviour happens though then I touch my finger onto the underside of the blue wire connecting to GPIO23 - it stops the constant toggle, and leaves the Virtual Screen in the ON position - as soon as I remove my finger, the toggling starts. This isn't a bad or loose solder connection, but I think it relates to this:

Capacitive touch GPIOs The ESP32 has 10 internal capacitive touch sensors.

from the info on the ESP board here: https://randomnerdtutorials.com/esp32-pinout-reference-gpios/

Now GPIO23 isn't listed as a capacitive touch GPIO, however my board seems to be treating both GPIO22 and GPIO23 as capacitive touch pins, given what I've experienced. I don't know if this is a fault with my board, or the code that I am flashing, however the same is still happening after specifying my board type as esp32doit-devkit-v1 and flashing.

I'm going to try swapping the blue wire from GPIO23 to GPIO19 instead and see if that behaves any differently.

My board has been used fairly extensively for testing various bits and pieces over the last couple of years, and has undergone a few solder/desolder sessions, so it's possible the board or internal chip has a problem, but it feels like a board mapping issue, given these 2 pins are behaving like capacitive touch pins. If there is no difference using GPIO19 I'll maybe get hold of a new board - thought this would be the easy part!

[IamMattM]

Don't suppose you have a handy pic of your board+wiring just to have a look for anything obvious ?

Also, can you confirm that the USB lead is not in use and that reflashing occurs using WiFi ?

[Scoff123]

Sure, here are a couple of pics-

[Scoff123]

I've looked at the pinouts for various different ESP32 board manufacturers, and none of them use GPIO22 or 23 for capacitive touch functions. My board doesn't have the 'do-it' logo on so I'm not sure it's made by them - more likely just a generic copy (had it for so long I can't remember where it came from but most likely AliExpress). Either way, putting a finger near the blue wire going to 23, or even touching the underside of the wire which you can see in the second picture, completely stabilises the virtual screen function to 'ON' and as soon as you move the finger away, it reverts to a constant state of toggle. It's definitely acting like a capacitive touch pin, but I cannot figure out why, even if I had the wrong board type in my ESPHome config?! I'll move to GPIO19 instead and see what results are produced and report back.

[IamMattM]

I wonder if perhaps GPIO23 , output to the EQ5 is actually floating (not driven out by anything )and when you approach your finger close to the "blue_eq5" wire leading to the EQ5 you capacitively couple the "floating" line to ground ...thereby cleaning it up of any noise pickup from the adjacent wires/activities in the ethernet cable leading to the EQ5...

Can you have a close-up look at whether the WROOM module has actually enough solder to its PCB pads around IO23/22/21 etc... Would be worth touching it up to be 100% certain that continuity exists between WROOM module and PCB tracking.

Not entirely clear on the pitcure but those WROOM pads might have been depleted of their solder ?

[Scoff123]

Thanks, that certainly sounds plausible regarding the floating GPIO23. I've cleaned up the excess flux around those WROOM pins, snd you are right, the manufacturer has definitely been a bit 'light' on the solder around those pins, however checking with my meter there is solid connectivity at each pad around the WROOM. I will top up those few pads in question though.

[Scoff123]

OK I've topped up the solder on the WROOM pads all down that side, but sadly no difference in the fault. De-soldered the blue wire going to GPIO23, still no difference! With the blue wire removed, the virtual screen sensor still toggles on/off indefinitely. I can stop the toggle by touching any ground plane on the board, including the WROOM cover. Only difference now is because GPIO23 is disconnected, the virtual screen sensor in HA stops on OFF when I touch the boards ground plane, rather than ON when the blue wire is connected to GPIO23. This is starting to look more like a grounding issue / faulty ESP board, so I might just get a new one and hopefully that will resolve. Very odd indeed

[IamMattM]

Yep...odd indeed.

I don't suppose you have attached anything to the keypad USB charging point during those tests ? In case it is pulling more current than the +5V (brown_eq5+brown_kpd) and 0V return (white-brown_eq5+white_brown_kpd) wiring arrangement can support.

Perhaps the keypad is power-cycling because of loading / +5V rail collapse/ and power cycling back up again and so on... Might be worth checking the voltage between +5V and 0V on the ESP32 when it happens to confirm that it looks stable at +5V.

The ESP32 board is fitted with an on-board +5V downto 3v3 so even if the 5V rail dropped as long as it did not drop below +3v6 approx you probably would maintain ESP32 operations but the keypad might have a tighter +5V tolerance for it to work especially since it is presenting a +5V charging port.

If the keypad was to power cycle , it would possibly change state on GPIO22 input and possibly go up and down and this would be reflected in the GPIO23 output...just a thought.

In fact, how long is your chosen Ethernet lead between EQ5 (sourcing the +5V) and the ESP32 box ? My one is 0.5meter only. You might have some voltage drops from EQ5 to Box to keypad...would be worth trying out a different cable perhaps. It could affect how good the 0V/GND is at the ESP32 as well.

Otherwise, I have not got any other ideas at this moment. Hope you can get it up and running soon. Good luck.

[Scoff123]

Great, thanks for those suggestions, that gives me a few things to check. Nothing has been plugged into the 5v USB charging port on the keypad during testing. I am using a long ethernet cable between the EQ5 and the ESP just because it's the only spare cable I have to hand - it's around 5 metres long! I'll check the 5v at the board and ground and make sure it's at least getting 3v6 so that the 3v3 is definitely being delivered from the onboard regulator to the rest of the board.

I'll grab a much shorter ethernet cable tomorrow, and I actually have a known good esp32 board (same devkit v1 as this one) in an old project that doesn't get much use. I can easily remove and flash + solder that board if the shorter cable doesn't fix things. I'll report back tomorrow after those tests.

[Scoff123]

So good news - I flashed my other devkit v1 boar with my exact ESPHome config that I've been using, including the substituted GPIO's (to save having to change the code) and I am getting NORMAL behaviour of the Virtual Screen function now! :) No more toggling, and no capacitive touch / grounding issues at all. I'll probably just stick with this board now and order a new one to keep as a spare for future projects. I'm also now using a shorter (50cm) ethernet cable between EQ5 and keystone jack.

This new stability has however allowed me to finally test all of the functions available from within HA and via the actual keypad, and sad to say, there are some issues which I think highlights the very slight differences between my EQ5 controller being the CB38M2D with different ST Microcontroller :(

I'm not sure how much can be tweaked based on symptoms, or if a scope would be needed (which I don't have) to identify what is happening.

I'll come up with a list of what does and what doesn't work correctly and hopefully with everyone's help on here we can figure it out.

I'll post back once I've got some test results from HA and the keypad functions.

EDIT: Oddly, I no longer have the 'STOP' button showing as a control in HA, even though I did previously when I first flashed the old board before I wired anything up?!

[IamMattM]

@Scoff123 Great. Getting somewhere.

As to the missing STOP button , you will find that I am also still in the same boat since mentionning this some time back. Never got the chance to look into it.

And because of this some of the controls from HA are still glitchy: " Whats is not working:

From HA, pressing the Cover.Open (ArrowUp) followed by pressing the Cover.Close (ArrowDown) while feet are moving seems to trigger a lock up : Toggling VirtualScreen OFF/ON seems to resume operations normally... This issue might be due to the fact that somehow my cover component is not exposing a STOP button in my HA integration. No idea why that is.. "

I wonder if your odd behaviour now relates to what I was and still am experiencing....

@deveritt-uk : Could you by any chance indicate to us whether your HA control for the LockTEk motion ESP controller features the "elusive" STOP button ? And if so what ESPHome firmware is in use in your ESP32 ?

I see other posts mentionning the missing cover STOP feature... https://github.com/esphome/issues/issues/4512

I have to say thatt I could not see the "cover.stop_action" anywhere in the yaml file ... Only the cover.open_action and cover.close_action both of wich gets to show up and do something.

[Scoff123]

@IamMattM Thanks, yes it's a relief to have a working board now at least - and I can hopefully iron out a few issues after some further testing. I was just looking into the missing STOP button also, and have found that it's due to a change in ESPHome a couple of versions ago. There seem to be a few posts about it, like the one you mention, and also https://github.com/esphome/issues/issues/4516 and a PR https://github.com/esphome/esphome/pull/4826

There is talk of a fix, which is to add traits.set_supports_stop(true); to the custom header file, of the ESPHome cover 'object' although I'm still trying to work out where this file is, in order to edit it and see if that does the trick.

One thing immediately apparent when I plug my board into my desk, is that the physical keypad lights up, and stays lit up, regardless of not interacting with it, or Home Assistant. So it seems the timeout is not kicking in and turning the screen off. Still testing the other controls and will post up a list of what works and what doesn't. I've left the debug at 0 for now as I read that this can cause glitches if the rate is set to 9600 in order to log, but I'll need to enable this shortly in order to try to make sense of what is and isn't happening when pressing various controls...

[Scoff123]

I've enabled the debug logging to hopefully see what is and isn't happening. Desk currently set at my Preset 2 height of 79.0cm.

Testing Controls in Home Assistant without touching physical keypad

Desk Height shows correctly on keypad as 79.0cm, and also in Home Assistant under desk height sensor. Keypad lit up. 'Screen' sensor shows status 'on'. Keypad remains lit up. Logging shows just output of WiFi Signal and Uptime.

Test 1) Click Cover Up arrow - desk starts moving repeatedly in minute increments every second or so. I had to toggle the virtual screen to OFF in order to stop the behaviour after the height go to 88.3cm (due to not having a STOP button!). This spammed the log output with:

This seemed to crash my ESPHome webpage, so I closed the log output, and eventually could open it again, however the same spamming is still occurring, but the desk is not moving, and I have not executed any further commands since the virtual screen toggle. Not sure it's worth going any further just yet with other controls. ESPHome addon probably grinds to a halt due to the logging filling up the log so quickly.

I then disabled the logging again and reflashed the ESP, opened up the output screen again and back to normal, no spamming, nothing other than WiFi signal and Uptime. So I tried the Cover Up arrow again now, and the desk raised up constantly as expected, all the way to 126cm at the top. The output looked ok, although a lot of output for each cm of travel seemingly, but worked as expected - keypad numbers increased correctly as did height sensor in HA:

So as mentioned, the debug logging being enabled really interferes with the operations, which is a pain...

[Scoff123]

just to follow on, leaving the debug logging disabled,

Test 2) Click Cover Down arrow - the desk moved continuously down to the minimum height, showing 70.7cm on the keypad and in HA - so working correctly and as expected - regular ESPHome output shows a block message for each cm of travel

I have noticed with tests 1 and 2, that the desk doesn't seem to come to a gradual stop like it does using the desk keypad normally without the ESPHome bridge. It's not a harsh stop, just not a gradual stop if that makes sense. But other than this, the Cover UP and DOWN works as expected, provided the Debug logging is disabled. The keypad does remain lit throughout constantly though, so the 12 second timeout doesn't seem to work for some reason, whether you interact with a control in HA or do nothing.

If I can figure out the keypad timeout issue, then I can move onto the remaining controls like Pre-sets as there is some strange behaviour there, even with the Debug logging disabled...

[IamMattM]

I have just tried out the HA "Up" (= minimum up motion only , not the cover.open arrow one you seem to have tried and failed to turn the keypad off) and for that switch , the keypad lights up and correctly goes down after exactly 12secs.

[Scoff123]

Would you mind capturing the standard ESPHome log output when you activate the HA "UP" up to and including when your keypad lights turn off please? Here is my output - the desk does go up an increment, but the keypad is always permanently lit up and doesn't go out either after the 12 seconds. Oddly my keypad an home assistant height sensor showed 70.2 before i clicked the UP button in HA, and after the desk moved up slightly, the display and HA show 69.8?? The desk definitely moved in an upwards direction.

[IamMattM]

@Scoff123

Sure. Here you go:

... ...

A video showing the keypad lit up and going off https://drive.google.com/file/d/1WDnLPL4D1To_5fZ1KKZOlAPtqH1-ggYe/view?usp=drive_link

[Scoff123]

@IamMattM Thanks very much for capturing and posting that. I can see the same output in my ESPHome log window when i execute the same scenario, so it looks like the execution of the code is working correctly at least.

With the factory setup of just EQ5 and Keypad, the initial press of any keypad button triggers a WAKE of the keypad screen and button illumination. After the factory set timeout period with no button presses, the keypad screen and illumination turns off.

Upon plugging my ESP device between EQ5 and Keypad, the keypad immediately WAKES and illuminates, and will NOT turn off regardless of interaction. The only way to shut it off is to unplug the unit. So to me that indicates either my EQ5 is receiving a PERMANENT CONTINUOUS WAKE command from plugging my ESP device in the middle, and the default Keypad timeout is no longer able to kick in, as the EQ5 thinks there is constant interaction. The ESP board could be receiving a TURN OFF KEYPAD command after the factory timeout, from the EQ5, but is failing to process this correctly and in turn switch off the keypad illumination.

Any ideas how I can identify where the issue lies? I'm going to revert to the original GPIO pin assignments in the repo, just so that my ESP config is identical to the known working one that you are using.

[Scoff123]

According to the README on this repo,

Execute a command

The control box only accepts commands when the 'screen is active'. To activate the screen, PIN 20 needs to be set to HIGH for about 1 second. The screen gets disabled automatically again after some amount of time receiving no commands.

Command list

Command name | Start | Length | Type | Payload | Checksum | End -- | -- | -- | -- | -- | -- | -- Wake Up | 9b | 06 | 02 | 00 00 | 6c a1 | 9d

so how can I determine if GPIO20 is permanently being held high - as this would seem to cause the behaviour I am seeing?

[Scoff123]

I've started over with a brand new ESP32 board (NodeMCU Devkit V1), new cat5 wiring and new solder joins with dupont connectors for ease of disconnecting/testing. I've flashed the new board and using the original GPIO designations. I'm now seeing some different behaviour to before - no more strange toggling but I don't know if it's progress or not :/

First of all, my keypad remains lit up as soon as I plug the ESP board inline. The screen doesn't timeout after 12 seconds. If I wait for 12 seconds, then toggle the Empty Command from Home Assistant, the keypad turns off. If i then press a key on the keypad, it lights up, but then doesn't turn off again. I have to wait 12 seconds, issue the Empty Command from HA and only then does the screen turn off. If I try to issue the Empty Command from HA before waiting 12 seconds after an interaction, nothing happens and the screen remains on.

I note there is some commented code under the Virtual Screen section in the yaml here:

- platform: gpio
    name: "Virtual Screen"
    id: "virtual_screen"
    pin:
      number: GPIO23
      mode: OUTPUT
    restore_mode: ALWAYS_ON # Changed since required for keypad control and would otherwise need HA access to enable the virtual_screen
    internal: false

I'm wondering if this is causing the behaviour I am seeing? Although this should only affect the state at bootup

[Scoff123]

[Scoff123]

Also getting a couple of new error messages on the LCD, which I haven't had before - one is ASr - which some googling reveals means that the controller needs to be reset. The other one I cannot find anything for, which is -OL

[IamMattM]

Just checking the obvious as you seem to have a lot of strange behaviours compared to @deveritt-uk and myself

You are using the short ethernet cable and you are connecting the correct ethernet lead to the expected port ? (keypad on the left hand port when viewed like the capture below:

![Uploading image.png…]()

[Scoff123]

Well, I hope it's nothing obvious, as I've checked it all over several times on this latest build with the brand new esp32 board! I've connected things exactly as per the wiring diagram, and have the keypad and controller the correct way around.

HA is showing the desk height at 10 metres, which would be an impressive feat (!) So something has got messed up.

Plugging the keypad back into the controller for factory setup now also shows rst, so I'm going to reset the controller and key the factory setup back to normal before carrying on. It's starting to feel like there just be something different in my EQ5 controller compared with both your controller and @deveritt-uk - actually @deveritt-uk would you mind confirming the exact model of controller that your EQ5 is using please? If we all have the same keypad, then the controller would surely be expecting the same uart messages from the keypad, and giving the same messages back to the keypad, regardless of differences in the controllers internals?

[Scoff123]

I've reset the desk in factory setup, by holding the DOWN arrow on the keypad until the desk got to the lowest height it can go to (62.0cm), and kept it held for around 5 seconds, until the desk moved up and back down very slightly while showing ASr, and this reset the desk so that at least in factory setup things were working correctly again. With the desk reset, I powered it off, and reconnected my ESPboard inline, before turning power back on. No more error messages on the keypad LCD, and it shows the correct current height of 79.0cm on both the keypad and in HA.

The problem, however, is the same as when I first tested - after powering the ESP board up, and having NO interaction with either HA or the keypad, the keypad remains lit up and does not turn off after the timeout.

This is what my ESP device shows in HA upon plugging it in, and WITHOUT interacting with anything:

Logbook
24 July 2023
flexispot-eq5 Empty command turned off
18:16:46 - 7 minutes ago
flexispot-eq5 Down turned off
18:16:46 - 7 minutes ago
flexispot-eq5 Up turned off
18:16:46 - 7 minutes ago
flexispot-eq5 Virtual Screen turned on
18:16:46 - 7 minutes ago
flexispot-eq5 M turned off
18:16:46 - 7 minutes ago
flexispot-eq5 Preset 4 turned off
18:16:46 - 7 minutes ago
flexispot-eq5 Preset 3 turned off
18:16:46 - 7 minutes ago
flexispot-eq5 Preset 2 turned off
18:16:46 - 7 minutes ago
flexispot-eq5 Preset 1 turned off
18:16:46 - 7 minutes ago
flexispot-eq5 Keypad locked turned off
18:16:46 - 7 minutes ago
flexispot-eq5 Desk was opened
18:16:46 - 7 minutes ago
flexispot-eq5 Screen turned on
18:16:46 - 7 minutes ago
flexispot-eq5 Firmware turned off
18:16:45 - 7 minutes ago

So it seems that the Empty Command, although being sent, is not turning off the screen after initial power up. I don't know if this would be the ESP board not correctly sending the Empty Command to the EQ5, which should in turn turn the keypad lighting off?

I'm running ESPHome 2023.7.0 if it makes any difference to how the header files are being handled - what version are you running @IamMattM @deveritt-uk ?

[IamMattM]

I currently am running with Firmware: 2023.6.5

Intesrestingly there is an update that I am told is available 2023.7.0 but it seems to have some issues somewhere in the yaml file so will need to be looked at if going through update...

[Scoff123]

@IamMattM The switch.template config in the yaml will need to be updated slightly for the latest ESPHome version, in order to prevent that warning. I changed the yaml for the 'Keypad locked' section to the following:

switch:
  - platform: template
    name: "Keypad locked"
    icon: mdi:key
    id: "keypad_switch"
    internal: false
    restore_mode: RESTORE_DEFAULT_OFF
    assumed_state: false
    optimistic: true

This uses restore_mode instead of restore_state and I chose the RESTORE_DEFAULT_OFF option as if this seemed to make sense for the keypad lock function, as if the correct state cant be determined then defaulting to off makes sense.

If you do update I would be keen to know if your desk is still fully functional, so if you could post back that would be helpful.

[Scoff123]

I've edited the desk_keypad_eq5.h and desk_height_sensor_eq5.h files to print the actual UART bytes in Hex format, so I can at least try and see what's going on between the 2 devices with the ESP board plugged in the middle. As soon as I plug the board in-between the keypad and control box, the ESP log spams a constant stream of:

[11:32:48][D][UART:085]: Received data from Desk UART: 9B
[11:32:48][D][UART:085]: Received data from Desk UART: 04
[11:32:48][D][UART:085]: Received data from Desk UART: 11
[11:32:48][D][UART:085]: Received data from Desk UART: 7C
[11:32:48][D][UART:085]: Received data from Desk UART: C3
[11:32:48][D][UART:085]: Received data from Desk UART: 9D
[11:32:48][D][UART:025]: Received data from Keypad UART: 9B
[11:32:48][D][UART:025]: Received data from Keypad UART: 06
[11:32:48][D][UART:025]: Received data from Keypad UART: 02
[11:32:48][D][UART:025]: Received data from Keypad UART: 00
[11:32:48][D][UART:025]: Received data from Keypad UART: 00
[11:32:48][D][UART:025]: Received data from Keypad UART: 6C
[11:32:48][D][UART:025]: Received data from Keypad UART: A1
[11:32:48][D][UART:025]: Received data from Keypad UART: 9D
[11:32:48][D][UART:085]: Received data from Desk UART: 9B
[11:32:48][D][UART:085]: Received data from Desk UART: 04
[11:32:48][D][UART:085]: Received data from Desk UART: 11
[11:32:48][D][UART:085]: Received data from Desk UART: 7C
[11:32:48][D][UART:085]: Received data from Desk UART: C3
[11:32:48][D][UART:085]: Received data from Desk UART: 9D
[11:32:48][D][UART:025]: Received data from Keypad UART: 9B
[11:32:48][D][UART:025]: Received data from Keypad UART: 06
[11:32:48][D][UART:025]: Received data from Keypad UART: 02
[11:32:48][D][UART:025]: Received data from Keypad UART: 00
[11:32:48][D][UART:025]: Received data from Keypad UART: 00
[11:32:48][D][UART:025]: Received data from Keypad UART: 6C
[11:32:48][D][UART:025]: Received data from Keypad UART: A1
[11:32:48][D][UART:025]: Received data from Keypad UART: 9D
[11:32:48][D][UART:085]: Received data from Desk UART: 9B
[11:32:48][D][UART:085]: Received data from Desk UART: 04
[11:32:48][D][UART:085]: Received data from Desk UART: 11
[11:32:48][D][UART:085]: Received data from Desk UART: 7C
[11:32:48][D][UART:085]: Received data from Desk UART: C3
[11:32:48][D][UART:085]: Received data from Desk UART: 9D
[11:32:48][D][UART:025]: Received data from Keypad UART: 9B
[11:32:48][D][UART:025]: Received data from Keypad UART: 06
[11:32:48][D][UART:025]: Received data from Keypad UART: 02
[11:32:48][D][UART:025]: Received data from Keypad UART: 00
[11:32:48][D][UART:025]: Received data from Keypad UART: 00
[11:32:48][D][UART:025]: Received data from Keypad UART: 6C
[11:32:48][D][UART:025]: Received data from Keypad UART: A1
[11:32:48][D][UART:025]: Received data from Keypad UART: 9D
[11:32:48][D][UART:085]: Received data from Desk UART: 9B
[11:32:48][D][UART:085]: Received data from Desk UART: 04
[11:32:48][D][UART:085]: Received data from Desk UART: 11
[11:32:48][D][UART:085]: Received data from Desk UART: 7C
[11:32:48][D][UART:085]: Received data from Desk UART: C3
[11:32:48][D][UART:085]: Received data from Desk UART: 9D

so it appears the keypad is sending the 'Empty Command' string continuously, which I believe is correct, however I don't understand what is being received from the EQ5? And subsequently why the keypad is being kept 'alive' and illuminated

[IamMattM]

The EQ5 box should really be sending the payload 0x000000 when at target height and after receiving the empty command.

I don't see that in your log above.

Your log seems to suggest that your EQ5 box sends the unknown message type 0x11 which is different to what I witnessed on my EQ% box, and could well explain why the keypad never switches off...

[IamMattM]

I did the full motor rST and the preset registration withouth the ESP32 in my setup - I wonder if having those presets registered in the EQ5 box could lead to those unknown message type 0x11 to go away allowing the box to send only 0x12 message types with payload 0x000000 which seems to eventually allow the keypad to turn off.

[Scoff123]

Thanks for the info, it looks like I'm going to have to do some more digging into the signals being sent from the EQ5 controller to the esp32. I've done the motor reset, and also saved a height to each of the 4 presets, before connecting the esp32 board, but after connecting it, im still getting the same uart output bytes from the Control box and the keypad is staying lit up with zero interactions.

I'll see if i can revise the .h files so that the esp log output prints the bytes in a string on each line, rather than each byte on a separate line.

[Scoff123]

Looking at the readme, it shows:

and this ties in with the bytes I'm getting spammed with from the keypad. I thought it was an 'empty command' as per the ESPHome yaml:

 - platform: uart
    name: "Empty command"
    id: switch_empty
    data: [0x9b, 0x06, 0x02, 0x00, 0x00, 0x6c, 0xa1, 0x9d]
    uart_id: desk_uart
    internal: false

I suppose this is just a naming thing, however I have no idea why my keypad would be constantly sending this wake command to the controller? As if a button was stuck down on the keypad. Is this likely this is the keypad actually sending this command, or the ESP just 'thinks' this command is being received, and so forwards it to the control box?

[18:23:29][I][desk_keypad:035]: Received data from Keypad UART: 9b 6 2 0 0 6c a1 9d
[18:23:29][I][desk_keypad:035]: Received data from Keypad UART: 9b 6 2 0 0 6c a1 9d
[18:23:29][I][desk_keypad:035]: Received data from Keypad UART: 9b 6 2 0 0 6c a1 9d

or could it be that the controller isn't sending the expected 0x000000 message which would normally stop the wake command from running continuously - or the controller is sending this but the ESP isn't interpreting it correctly.