Help figuring out possible support for CB38M2D(PB)-2 about loctekmotion_iot HOT 110 OPEN

@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

from loctekmotion_iot.

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

from loctekmotion_iot.

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

from loctekmotion_iot.

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?

from loctekmotion_iot.

@IamMattM Great thanks for confirming 👍

from loctekmotion_iot.

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?

from loctekmotion_iot.

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.

from loctekmotion_iot.

I think I found your issue:

If I look at <IO23=Blue_EQ5> 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.

from loctekmotion_iot.

I think I found your issue:

If I look at <IO23=Blue_EQ5> 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!

from loctekmotion_iot.

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.

from loctekmotion_iot.

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.

from loctekmotion_iot.

from loctekmotion_iot.

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.

from loctekmotion_iot.

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

from loctekmotion_iot.

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

from loctekmotion_iot.

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?

from loctekmotion_iot.

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

from loctekmotion_iot.

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.

from loctekmotion_iot.

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

from loctekmotion_iot.

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

from loctekmotion_iot.

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

from loctekmotion_iot.

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 <desk_height_sensor.h> and <desk_keypad.h>
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.

from loctekmotion_iot.

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.

from loctekmotion_iot.

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

from loctekmotion_iot.

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.

from loctekmotion_iot.

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.

from loctekmotion_iot.

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

from loctekmotion_iot.

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 :)

from loctekmotion_iot.

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

from loctekmotion_iot.

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 :

from loctekmotion_iot.

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?

from loctekmotion_iot.

@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:54][D][script:077]: Script 'screen_timer' restarting (mode: restart)
[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:01][D][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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

from loctekmotion_iot.

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.

from loctekmotion_iot.

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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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][script:077]: Script 'screen_timer' restarting (mode: restart)
[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

from loctekmotion_iot.

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

from loctekmotion_iot.

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

from loctekmotion_iot.

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?

from loctekmotion_iot.

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

from loctekmotion_iot.

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

from loctekmotion_iot.

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?

from loctekmotion_iot.

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();
"

from loctekmotion_iot.

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.

from loctekmotion_iot.

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.

from loctekmotion_iot.

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!

from loctekmotion_iot.

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

from loctekmotion_iot.

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.

from loctekmotion_iot.

@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...

from loctekmotion_iot.

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 🤔

from loctekmotion_iot.

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.

from loctekmotion_iot.

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!

from loctekmotion_iot.

@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

from loctekmotion_iot.

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?

from loctekmotion_iot.

@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

from loctekmotion_iot.

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.

from loctekmotion_iot.

@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.

from loctekmotion_iot.

@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.

from loctekmotion_iot.

@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 !

from loctekmotion_iot.

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!

from loctekmotion_iot.

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!

from loctekmotion_iot.

@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.

from loctekmotion_iot.

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.

from loctekmotion_iot.

@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

from loctekmotion_iot.

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.

from loctekmotion_iot.

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

from loctekmotion_iot.

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!

from loctekmotion_iot.

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

from loctekmotion_iot.

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?

from loctekmotion_iot.

@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:

from loctekmotion_iot.

@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/[email protected]
    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...

from loctekmotion_iot.

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!

from loctekmotion_iot.

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 ?

from loctekmotion_iot.

Sure, here are a couple of pics-

from loctekmotion_iot.

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.

from loctekmotion_iot.

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 ?

from loctekmotion_iot.

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.

from loctekmotion_iot.

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

from loctekmotion_iot.

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.

from loctekmotion_iot.

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?!

from loctekmotion_iot.

@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...
esphome/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.

from loctekmotion_iot.

@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 esphome/issues#4516 and a PR esphome/esphome#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...

from loctekmotion_iot.

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

from loctekmotion_iot.

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

from loctekmotion_iot.

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.

from loctekmotion_iot.

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.

from loctekmotion_iot.

@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

from loctekmotion_iot.

@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.

from loctekmotion_iot.

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

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

from loctekmotion_iot.

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

from loctekmotion_iot.

from loctekmotion_iot.

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

from loctekmotion_iot.

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:

from loctekmotion_iot.

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?

from loctekmotion_iot.

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 ?

from loctekmotion_iot.

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

from loctekmotion_iot.

@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.

from loctekmotion_iot.

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

from loctekmotion_iot.

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

from loctekmotion_iot.

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.

from loctekmotion_iot.

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.

from loctekmotion_iot.

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.

from loctekmotion_iot.