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]

Any news with regard to the above ?

I have recently acquired an EQ5 and it has "CB38M2H(PB)-2" labelling on the box with "CB38M2H(PB)-1" on the actual PCB which can be accessed by removing the x4 screws on the base of the enclosure (facing the tabletop)

The microcontroller is "STM32G030C8T6" (https://www.mouser.co.uk/datasheet/2/389/stm32g030c6-1826662.pdf) in "LQFP48" package and the accessible port to the side of the enclosure are for edge-contact SWD JTAG reprogramming/debugging of the microcontroller.

Not sure whether a second UART port (beyond the one made available to connect to the keypad controller) is being made available out of the STM32 and could be wire-tapped to bring out the RX/TX lines necesarry to "command" the EQ5.

[IamMattM]

[Scoff123]

Thanks for posting up pictures of your board, and for the information you've provided. I've not managed to make any progress myself, however I will try to open my controller up and check the board model to see if it's any different to yours. Hopefully someone with more knowledge than myself in this area can help to ascertain whether support of this controller will indeed be possible.

[IamMattM]

I figured out after looking at datasheet for the STM32 part above that if there was going to be a second UART port that would accept any control commands, it would have to be UART#2 since the other UART#1 is already in use and attaches to the RJ45 port.

UART#2 RX/TX pads are currently untracked so it should be possible to send a few commands to it and see if there are any responses....

[IamMattM]

UART#1 goes to RJ45 (while SWD JTAG debug/progrm goes to edge contacts)

[rsiuda]

I’ve received the same control box (and was hoping for 2 ports).

Did you try to use the port with the ESP32 (and not connect the LCD Panel)? Would that work?

[IamMattM]

I have not got the opportunity to connect an ESP32 to the one-and-only RJ45 port.

Was first trying to figure out the details for the box...

[Scoff123]

Great, I look forward to seeing the results. I've also unplugged the 2 pin connector and all functions on the lcd controller work as normal, so I'm also interested in understanding what that connector is used for.

[rsiuda]

I think it's powering the usb (charging) port

[IamMattM]

I imagine that with only one controller box port available for the EQ5 , we will need to use the "passthrough" mode of an ESP32 in order to request changes from both the ESP32 ESPHome and the actual keypad:

where the ESP32 sits in between the controller box and the keypad and "bridges" the messages across...so there is always only a single UART controller driving into the control box...

Looks like "flexispot_e5b_esp32.yaml" would be the starting point for the ESP32 in pass-through mode.... It features x2 UARTs for the ESP32.

And I think the yaml and the physical suggested connection tie up to it should be do-able: https://github.com/iMicknl/LoctekMotion_IoT/blob/f4d57e02546af97f19ae47d47f873480fe083f6b/packages/esphome/flexispot_e5b_esp32.yaml

Just need to figure out now where the controller line RX (TX from ESP32 point of view) /TX (RX from ESP32 point of view)/PIN20(allow commands)/+5V(provide power to ESP32)/GND are on the RJ45 pinout...and introduce two rj45 socket connectors off the ESP32 to be able to become the "man in the middle" without cutting any cables from the EQ5 box or keyboard.

And maybe introduce a 3D printed case for the ESP32 with two RJ45 socket https://www.printables.com/en/model/64174-raspi-esp32-ethernet-keystone-enclosure

[IamMattM]

I did a bit more investigations on the pinout for the EQ5 RJ45 port and scoped the lines using a back to back RJ45 adapter between the keypad and the EQ5 control box.

WARNING: The UART lines are toggling at the full +5V IO swing ! Note: ESP32 max IO levels are quoted at +3.6Vmax (3.3V+0.3V) => there is the possiblity that the ESP32 IOs (inputs) will eventually die after being exposed to incoming +5V levels without introducing either level shifting and/or limiting series resistors.

PIN20 being an always idling +5V line might be the one most at risk of damaging GPIO22 in the table above.

For now I have worked out the EQ5 to ESP32 and will to the second section which is Kpad to ESP32 later on...

[Scoff123]

Great work and thanks for all of your investigations and contributions so far! I'm going to open up the the case of my CB38M2D(PB)-2 to see what is different to the CB38M2A-1 - hopefully it won't be too dissimilar. I've got an ESP32 DEVKIT V1 board spare, so hopefully with level shifting and RJ-45 connectors, plus a case like the printable one you linked, this is going to be achievable...

[IamMattM]

With regards to the need (or not) to protect the ESP32 from the 5V levels on its IO inputs:

https://www.qworqs.com/2021/05/19/are-the-esp32-and-esp8266-5v-tolerant-yes-they-officially-are/

I am happy to take the very small risk and will wire directly as much more convenient. Besides, there seems to be plenty of people having gone ahead and wired their ESP32 to the Flexispot lines (which I imagine are all 5V levels) and I have not come across someone saying their ESP32 died in the process.

I will go ahead and make the necessary connections for testing but it seems from the esp32-e5b.yaml file that it should just work...

Note1: the yaml in the repo is slightly outdated for newest source code and the following lines need to be tweaked from/to in order to compile successfully.

id(desk).open(); => id(desk).make_call().set_command_open(); id(desk).close(); => id(desk).make_call().set_command_close(); id(desk).stop(); => id(desk).make_call().set_command_stop();

Note 2: it calls for the two .h files and Those two files need to be found locally by your esphome compiler. I downloaded both and placed in my local /config/ folder where the yaml file also resides. Compilation succesfull and loaded.

[IamMattM]

A small update to say that the 3D print pointed in the post above seems great for the task required: just need to wire things out correctly now between the two keystone RJ45 sockets and ESP32. One port dedicated to EQ5 connection (need extra ethernet cable) and second port reciving the lead from the keypad....

Fingers crossed.

[Scoff123]

Wow that looks perfect and could easily pass as part of the factory setup! Great work.

I've taken the rubber feet off my control box and unscrewed the cover to check out the board inside. It looks a bit different to your board, and strangely has a reference of ET201-PB, rather than the CB38M2D(PB)-2 which is on the plastic housing...

I'll have to see what the reference is on the chip with the green paint, and try to find the data sheet for it.....

Here we go, it's a STM8S007C8T6 Microcontroller

[Scoff123]

and the datasheet for it https://www.mouser.co.uk/datasheet/2/389/stm8s007c8-1851529.pdf

[IamMattM]

and the datasheet for it https://www.mouser.co.uk/datasheet/2/389/stm8s007c8-1851529.pdf

Thanks - Very intersting that for the same EQ5 model it seems that the controller board uses various flavours of the STMxx microcontroller.

Saying that, with the "pass-through" ESP32 method/wiring, as long as the UART out of the control bo tals at the same BAud rte of 9600 and accepts the same commands as the other ones, it should very much "just" work.

[IamMattM]

and the datasheet for it https://www.mouser.co.uk/datasheet/2/389/stm8s007c8-1851529.pdf

Thanks - Very intersting to see that for the same EQ5 model, the controller board appears to be different and uses various flavours of the STMxx microcontroller.

Saying that, with the ""man-in-the-middle" pass-through" ESP32 method/wiring, as long as the UART(s) out of the control box and keypad talk at the same Baud rate of 9600 and accepts the same commands as the ones listed in the yaml file, it should very much "just" work.

[IamMattM]

Looks like the commands to the EQ5 controller out of the ESP32 are working and I can control the motors up and down. https://drive.google.com/file/d/1YWYhH0tllCWDYCulrfnZ3VSnLo3jmL4k/view?usp=sharing

The keypad and the ESP32 both receive the motor height information from EQ5 controller box and will display height on both keypad and homeassistant.

I have not had a great deal of opportunities to test further but at first glance it is for now encouraging..

The control from the keypad into ESP32.UART0_RX do not appear to be bridged through on ESP32.UART2_TX towards the EQ5 control box so for the time being I was not able to instruct the motor to change height from the keypad.

I need to see if the ESP32 could bridge those keypad messages and redirect towards EQ5 or if perhaps that connection/wire is not properly made.

Anyhow, some progress...

[Scoff123]

Well done, looks like you are nearly there! Great to see it in action, and hopefully you can iron out the issue with the keypad commands not reaching the EQ5 controller box.

I don't have a scope so probably can't take the testing on my own board much/any further, so I'm just going to go with the same setup that you've implemented and give it a test. I'll grab a couple of keystone jacks online, flash my ESP32 board and add it to HA, and try connecting things up and see what happens. This has also convinced me it's time to finally invest in a 3D printer :)

[IamMattM]

Yes, I also did not have a 3D printer until a couple of months ago when there was an offer for the Ender 3 v2 NEO - Since then I migrated the 3D printer to "klipper+klipper screen android" and have been making full use of it for all those IOT/Smart devices enclosures that I need. Well worth it.

I'll try to figure out where things are not working by comparing the various yaml made available...

I can already see that in my HA integration I do not see the "STOP" button like in the following reference picture so definitely some tweaks required.

I have a scope with UART decode that I can place on KEYPAD side of the cable to check the messages are as expected ...etc...

[IamMattM]

An update with regards to verifying the commands sent out by keypad: https://drive.google.com/drive/folders/17fUi4JQyRUNruGem4oYe32flX-6Btzhs?usp=sharing

When the keypad is not pressed, it is correctly sending out continuously the "Empty" command,

When pressed,on the various buttons (Up / Down / Preset1=stand / Preset2=sit/ Preset3 /_____/ Memory) it is also correctly sending out the correct command sequence. *Note: THere is one button that is not yet implemented in the yaml file and that is the PReset4 with command : [0x9b, 0x06, 0x02, 0x00, 0x01, 0xac, 0x60, 0x9d] as captured below:

With the doubt as to whether the keypad was actually sending anything when pressed on the line going to ESP32.UART0_RX (esp32 devkit v1), I can now say for certain that this is indeed happening.

What is NOT happening however is any software "forward" activity of those commands to the ESP32.UART2_TX towards the EQ5...

Maybe the UART bridging is not supported....

@pepsinio @iMicknl : would you be able to comment on the matter of esp32 passthrough for the Loctek Motion keypads using ESPHOME esp32_e5b.yaml ?

I am not having much success....Should keypad control going through ESP32 between keypad and EQ5 control box work at all ?

THere is a section in the code that indicate that ESP32 KEypad_uart gets used but I am not familiar enough with the coding to make sense of it fully :

[Scoff123]

So the keypad is definitely sending the commands correctly the the ESP board. Are you able to view debug logging (logger.log) or print the debug messages (after changing the baud_rate from zero in the ESPHome config yaml) to determine if the ESP is actually receiving these sent keypad commands?

[IamMattM]

@Scoff123 : THanks for the pointer and enabling Baud= 9600 (from 0) I can see the messages when pressing keypad being decoded correctly (except for Preset4 not yet implemented)

[12:49:39][C][mdns:109]: Hostname: esp32-flexispot-eq5 [12:49:39][C][ota:093]: Over-The-Air Updates: [12:49:39][C][ota:094]: Address: esp32-flexispot-eq5.local:3232 [12:49:39][C][ota:097]: Using Password. [12:49:39][C][api:138]: API Server: [12:49:40][C][api:139]: Address: esp32-flexispot-eq5.local:6053 [12:49:40][C][api:141]: Using noise encryption: YES [12:49:40][C][wifi_signal.sensor:009]: WiFi Signal 'WiFi Signal' [12:49:40][C][wifi_signal.sensor:009]: Device Class: 'signal_strength' [12:49:40][C][wifi_signal.sensor:009]: State Class: 'measurement' [12:49:40][C][wifi_signal.sensor:009]: Unit of Measurement: 'dBm' [12:49:40][C][wifi_signal.sensor:009]: Accuracy Decimals: 0 [12:49:50][D][sensor:094]: 'Desk command': Sending state 3.00000 with 0 decimals of accuracy [12:49:50][D][switch:012]: 'Preset 1' Turning ON. [12:49:50][D][main:243]: Executing Preset 1 command [12:49:50][D][main:746]: Executing Empty command [12:49:50][D][main:322]: Executing screen timer command [12:49:50][D][switch:012]: 'Virtual Screen' Turning ON. [12:49:50][D][sensor:094]: 'Desk command': Sending state 8.00000 with 0 decimals of accuracy [12:49:54][D][sensor:094]: 'Desk command': Sending state 4.00000 with 0 decimals of accuracy [12:49:54][D][switch:012]: 'Preset 2' Turning ON. [12:49:54][D][main:308]: Executing Preset 2 command [12:49:54][D][main:746]: Executing Empty command

[12:49:55][D][main:322]: Executing screen timer command [12:49:55][D][switch:012]: 'Virtual Screen' Turning ON. [12:49:55][D][sensor:094]: 'Desk command': Sending state 8.00000 with 0 decimals of accuracy [12:49:56][D][sensor:094]: 'Uptime': Sending state 32.44800 s with 0 decimals of accuracy [12:50:01][D][sensor:094]: 'Desk command': Sending state 5.00000 with 0 decimals of accuracy [12:50:01][D][switch:012]: 'Preset 3' Turning ON. [12:50:01][D][main:373]: Executing Preset 3 command [12:50:01][D][main:746]: Executing Empty command

[12:50:02][D][main:322]: Executing screen timer command [12:50:02][D][switch:012]: 'Virtual Screen' Turning ON. [12:50:02][D][sensor:094]: 'Desk command': Sending state 8.00000 with 0 decimals of accuracy [12:50:03][D][sensor:094]: 'WiFi Signal': Sending state -46.00000 dBm with 0 decimals of accuracy [12:50:09][D][sensor:094]: 'Desk command': Sending state 6.00000 with 0 decimals of accuracy [12:50:09][D][switch:012]: 'M' Turning ON. [12:50:09][D][main:438]: Executing Preset 3 command [12:50:09][D][main:746]: Executing Empty command

[12:50:10][D][main:322]: Executing screen timer command [12:50:10][D][switch:012]: 'Virtual Screen' Turning ON. [12:50:10][D][sensor:094]: 'Desk command': Sending state 8.00000 with 0 decimals of accuracy

[IamMattM]

And it actually worked once for Preset1 and Preset2 (moving feet from keypad) at some point but is now no longer working although the commands are always being decoded correctly by ESP32.

[IamMattM]

When pressing the "up" toggle on the HA integration page I get the following messages and the feet move up:

[13:00:47][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:52][D][switch:012]: 'Up' Turning ON. [13:00:52][D][switch:055]: 'Up': Sending state ON [13:00:52][D][uart.switch:020]: 'Up': Sending data... [13:00:52][D][switch:055]: 'Up': Sending state OFF [13:00:52][D][sensor:094]: 'Desk Height': Sending state 62.10000 cm with 1 decimals of accuracy

[13:00:53][D][main:322]: Executing screen timer command [13:00:53][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:53][D][sensor:094]: 'Desk Height': Sending state 62.20000 cm with 1 decimals of accuracy

[13:00:53][D][main:322]: Executing screen timer command [13:00:53][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:53][D][sensor:094]: 'Desk Height': Sending state 62.30000 cm with 1 decimals of accuracy

[13:00:53][D][main:322]: Executing screen timer command [13:00:53][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:53][D][sensor:094]: 'Desk Height': Sending state 62.40000 cm with 1 decimals of accuracy

[13:00:53][D][main:322]: Executing screen timer command [13:00:54][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:54][D][sensor:094]: 'Desk Height': Sending state 62.50000 cm with 1 decimals of accuracy

[13:00:54][D][main:322]: Executing screen timer command [13:00:54][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:54][D][sensor:094]: 'Desk Height': Sending state 62.70000 cm with 1 decimals of accuracy

[13:00:54][D][main:322]: Executing screen timer command [13:00:54][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:54][D][sensor:094]: 'Desk Height': Sending state 62.80000 cm with 1 decimals of accuracy

[13:00:54][D][main:322]: Executing screen timer command [13:00:54][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:55][D][sensor:094]: 'Desk Height': Sending state 63.40000 cm with 1 decimals of accuracy

[13:00:55][D][main:322]: Executing screen timer command [13:00:55][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:55][D][sensor:094]: 'Desk Height': Sending state 63.60000 cm with 1 decimals of accuracy

[13:00:55][D][main:322]: Executing screen timer command [13:00:55][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:55][D][sensor:094]: 'Desk Height': Sending state 63.70000 cm with 1 decimals of accuracy

[13:00:55][D][main:322]: Executing screen timer command [13:00:55][D][switch:012]: 'Virtual Screen' Turning ON. [13:00:56][D][sensor:094]: 'Desk Height': Sending state 64.20000 cm with 1 decimals of accuracy

[IamMattM]

When pressing the "up" arrow on the keypad I only get to see the following messages and there is no movement in the feet. SCope says command from keypad is: [ 0x9b, 0x06, 0x02, 0x01, 0x00, 0xfc, 0xa0, 0x9d]

[13:03:02][D][sensor:094]: 'Desk command': Sending state 1.00000 with 0 decimals of accuracy [13:03:02][D][sensor:094]: 'Desk command': Sending state 8.00000 with 0 decimals of accuracy

[IamMattM]

Enabling the logger baud rate to 9600 has definitely helped in revealing what might be going on...

[Scoff123]

Ok great that's really helpful, we are narrowing the issue down at least. So:

1) Keypad commands are being sent to the ESP board, and are successfully received and decoded by ESPHome. 2) PROBLEM ESPHome is not transmitting commands which originate from the keypad, onto the controller.

3) Home Assistant commands are being sent to the ESP board successfully. 4) HA commands are successfully being transmitted onto the controller and processed correctly.

Hopefully someone with a bit more ESPHome knowledge can maybe identify what could be going on here with the onward transmission logic of the 'keypad received' commands?

[IamMattM]

An update:

I memorised Preset 1+2+3 using the standard setup (no ESP32 man-in-the-middle) and once using the ESP32 back in the path between keypad and eq5, all of those Presets 1+2+3 are working from the keypad !!

The UP/DOWN key control do not work but then again it does not look like the code interprets those commands correctly as "Up" and "Down" -

This has been done without first triggering any controls from the HA integration just to be sure....

So DEskCommand1(up) and DeskCommand2(down) don't seem to have ever done anything from the keypad....THe other ones have.

And on many occasions now that I am playing with the keypad preset keys, there are occurences where the keypad shows "rST" and I have to lower the feet all the way down using HA (since the down key does nothing from keypad)....

Getting there but it is a bit flaky at present.

I also need to find out why I do not seem to have the "STOP" button on HA ....

[IamMattM]

Since disabling the "Logger" section is seems to be more robust and has not played up when using the Preset1+2+3

[Scoff123]

Getting closer! So I wonder what is different between the up/down key press logic and the preset button press logic? I'll see if I can find what condition triggers the rST message to display, if that information is contained in a troubleshooting guide for the desk/controller anywhere online, or maybe from FlexiSpot themselves.

I don't have anything connected up yet, I've simply flashed my ESP32 Devkit board with the yaml file in this repo, and edited slightly for the eq5 naming, however I DO have the stop button in my list of controls after adding my ESP32 board as an integration in HA:

so I'm not sure why you don't have that. If you go into Dev Tools in HA and services, do you have the service cover.stop_cover available?

[IamMattM]

Hmmm. That is most pecular... I'll have a look.

I think I now know what might cause the UP (DEsk command=1) and DOWN (DEsk Commad=2) keys on the keypad to not respond : in order to compile the code with ESPHOME 2023.5.4 , I had to edit the (open()/close()/stop()) statements with something different to satisfy the latest ESPHOME requirement as otherwise it would no longer compile...

As it happens, those new lines of edited code are dealing with UP/DOWN/STOP - Can't be a coincidence ! See my post from 3 days ago ref: " id(desk).open(); => id(desk).make_call().set_command_open(); id(desk).close(); => id(desk).make_call().set_command_close(); id(desk).stop(); => id(desk).make_call().set_command_stop(); "

[IamMattM]

Sorted ! Appears to be me tweaking the file for those (open/close/stop) statements.

I reverted back and althouth there is a warning during compilation, it does get through and can be compiled fully and installed on ESP32.

---

Compiling .pioenvs/esp32-flexispot-eq5/src/main.cpp.o /config/esp32-flexispot-eq5.yaml: In lambda function: /config/esp32-flexispot-eq5.yaml:130:22: warning: 'void esphome::cover::Cover::open()' is deprecated: open() is deprecated, use make_call().set_command_open() instead. [-Wdeprecated-declarations] id(desk).open(); ^ In file included from src/esphome/core/controller.h:14, from src/esphome/components/api/api_server.h:4, from src/esphome/components/api/api_connection.h:6, from src/esphome.h:3, from src/main.cpp:3: src/esphome/components/cover/cover.h:133:8: note: declared here void open();

---

I did that and up/down keys now working !

Success.

[IamMattM]

I still can't see the STOP button in HA. Will look at that next (and adding Preset4 to the yaml) ...;-) Quite pleased with the outcome in the end.

[Scoff123]

Well done :) Good result there. I will revert my code back to the original as well in that case, for the open/close/stop.

Are you still getting any of the rST messages displaying on the keypad LCD, or have they stopped now? I was wondering if that is something to do with the height going out of bounds or something like that, and so the controller required a soft recalibration by putting the legs all the way down maybe?

If you manage to add the preset4 to the yaml, would you mind posting it in here as well please?

if there's anything I can check or test in regards to your stop button not appearing in HA, I'm happy to help - just let me know!

[IamMattM]

I got Preset4 on EQ5 keypad to work from HA.

However, supporting it from keypad is a bit more challenging for my knowledge. The keypad.h only checks the fourth byte but it should do a check on combination of fourth and fifth bytes to be able to distinguish Preset4 from the Empty command - Both have byte#4at 0x00

[IamMattM]

Well done :) Good result there. I will revert my code back to the original as well in that case, for the open/close/stop.

Are you still getting any of the rST messages displaying on the keypad LCD, or have they stopped now? I was wondering if that is something to do with the height going out of bounds or something like that, and so the controller required a soft recalibration by putting the legs all the way down maybe?

If you manage to add the preset4 to the yaml, would you mind posting it in here as well please?

if there's anything I can check or test in regards to your stop button not appearing in HA, I'm happy to help - just let me know!

Sure. Will share the three files and post a video to show EQ5 is supported reasonably well.

[Scoff123]

I've just tried compiling using the newer lambda format of the ESPHome code (https://esphome.io/components/cover/index.html), so that I'm no longer using the deprecated version:

id(desk).open(); => id(desk).make_call().set_command_open().perform();
id(desk).close(); => id(desk).make_call().set_command_close().perform();
id(desk).stop(); => id(desk).make_call().set_command_stop().perform();

I'm no longer getting the warnings during compile, and have successfully flashed to my ESP32 board. I can't however test this, as I have nothing wired up yet. Would you mind updating your yaml to include this revised version, and checking to see if the up and down buttons on the keypad still work correctly?

[IamMattM]

@Scoff123 : Fantastic - Those newest Lamba commands do work with keypad UP/DOWN keys and no compile warnings either.

Here are the latest files for EQ5 that work well for me (incl Preset4 from HA, no more rST keypad messages)

https://drive.google.com/drive/folders/1MgeNHxeG5XQShUc6OGoT1LHJDNu98LrI?usp=sharing

Whats is not working: 1) from keypad not working: would need change to keypad.h to use two bytes 4+5 in order to distinguish Preset4 command from "Empty" command

2) 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...

[Scoff123]

Great, thanks for testing that - glad it works and has removed the deprecated warnings during compile.

So it sounds like we are almost there and fully compatible. Hopefully we can figure out a revised keypad header file to incorporate the check of bytes 4 and 5.

I'm just waiting on my keystone Jacks to arrive so I can wire up my board and test and up/down lockup issue, given I have the stop button present in HA. We can then rule that out as a cause if it still happens.

I take it you've tried removing your eq5 integration from your esphone integrations in HA, and then re-adding it? Can't think why else the standard stop button would be missing from a cover, unless it was a glitch while adding it in HA 🤔

[IamMattM]

e it you've tried removing your eq5 integration from your esphone integrations in HA, and then re-adding it? Can't think why else the standard stop button would be

Yes, indeed. Almost there. Not too bad an outcome. Would be great if someone knowledgeable could adapt the code to decode byte 4+5 to support Preset4 from keypad. I can live without it but it would be great to sort it out nevertheless....

I'll post a couple of pics of the wiring between ESP32 and the two keystone RJ45 jacks in the 3D printed enclosure.

I did remove and reload the entire ESPHOME id and gave it a new name but that cover stop button is not showing.Odd.

I will have a look at other covers that I have integrated (for example a garage door cover that shows the stop button)

All posted there: https://drive.google.com/drive/folders/1MgeNHxeG5XQShUc6OGoT1LHJDNu98LrI?usp=drive_link

Good luck and thanks for your help.

[david-romero]

Hi @IamMattM!

Thank you so much for your research and great work. I'd like to implement this approach and the first thing I need is to buy the hardware. I think I need the following hardware:

• 2 RJ45 Sockets: Amazon
• ESP32: Amazon
• Wiring: Amazon

Am I right? Thank you in advance!

[IamMattM]

@david-romero

David,

It might be more convenient to use/buy the following ? :

1) Keystone RJ45 sockets (pack of x5 , Euro 9.99) Amazon RJ45 keystone

• I did not have a punch tool but the following wire stripper worked a treat because of the notch:

You might already have this as part of cheap soldering iron kits available like this one (Euro 18.69): Amazon soldering kit with wire cutter as punch tool

2) ESP32 - Yep, the one you pointed to would work.

3) Wires (free from old 0.5m ethernet cable ?): any standard ethernet cable that you can sacrifice , should already have the necessary wires inside with the benefit of the colour coding already matching the keystone Mode B wiring colours. It will also allow to test the connections with the "rescued" RJ45-end cable end clicked into the Keystone socket.and be certain that all connections are made good - A bit like in the picture above .

If you do not have any spare cable that you can cut to "steal" the coloured wires inside, then maybe this cheap one : 0.5m ethernet lead

[david-romero]

Thank you so much @IamMattM.

So the shopping list would be:

• Keystone RJ45 sockets (pack of x5 , Euro 9.99) Amazon RJ45 keystone
• ESP32: Amazon

I have some old ethernet cables. 😄

Have I had to solder something? Why do you suggest buying a soldering kit? Does the RJ45 keystone need to be soldered?

[IamMattM]

@david-romero

David, I suggested the soldering kit because 1) You get this wire stripper tool that can be used to "push" the ethernet wires into the keystone (no soldering at this end) (otherwise you would need to acquire a tool called a punch tool )

2) You also get a soldering iron+solder to solder the other end of those wires onto the actual ESP32 pin header (you might even need to solder the ESP32 pin header if it does not come pre-assembled....)

Your initial choice of RJ45 connectors would have more than likely also required at least some soldering at the RJ45 end as the pin diameter would NOT have been suitable for Dupont-style sockets

[Scoff123]

I'm going to order the 3D Printed enclosure online as i can't stretch to buying a printer right now, but I bought a pack of 5 VCE Keystone jacks like the ones that @IamMattM linked above, and have miles of spare ethernet cable :) I'll be doing the wiring once I have the enclosure and fitted the keystone jacks to get the lengths correct. I take it there were no changes to any of the wiring / colour diagrams posted above? Your google drive pictures seem to indicate not, but thought I better check before I start connecting things together.

[IamMattM]

@Scoff123

No changes since posting those pictures of the wiring in the G.drive.

I added to the G.drive a 3D-printable "keystone blank face" that someone had shared online -Works well withthe enclosure, and looks a bit neater.

In case you order the enclosure from somewhere, consider also asking them to add that small blanking face for the middle port.

[Scoff123]

@IamMattM Great thanks for confirming 👍

[iMicknl]

@IamMattM (and others) would you be willing to contribute your knowledge and designs to this repository? So that people don't have to scroll through all comments in this issue.

Your work looks great and this will help many people further.