Open iMicknl opened 1 year ago
Hey @iMicknl,
thanks for providing this updated version of the code. The improvements look really good. First observations:
update_interval: 0ms # update in every loop() iteration
in number "Desk Height" does what you intended, but is that really necessary?General comment: It seems like more and more devices will be potentially supported by your project, and each will have their own caveats. My HCB223A-1 seems to be a good example. Should we capture those differences in a table of sorts?
Thanks a lot for your extensive feedback, @ThomDietrich!
On my specific device the wake screen command and the PIN20 method do not work, however, "child lock" (which seems not supported) wakes up the device (and produces the current desk height) - so thank you!
The wake command does not work here as well. What do you mean with PIN20 doesn't work? PIN20 is set to ALWAYS_ON
(high) to allow the ESP32 to control the desk.
update_interval: 0ms # update in every loop() iteration in number "Desk Height" does what you intended, but is that really necessary?
This floods the log indeed, and I need to have a better look here. It needs to be at least 0.5s, in order for the number template to be updated with the height of the desk height sensor.
A preset button will send the desk on its way. This can be stopped by e.g. shortly pressing the Up or Down button. Could you add a "Stop" button?
Good one! Perhaps we could make the cover.stop button behave like this. I am not sure how often you want to cancel a preset command?
A binary_sensor that indicates that the desk is currently moving would be great
In theory the cover
entity should have such a status already. We need to have a look if this is currently missing and if so, if this could be added.
You've used the name "Desk Height" twice. Yes not a technical issue, more of an intuitive ick
Do you have any suggestions for a better name / structure? The issue here is that one is a sensor and the other one is a number entity (that is still a bit buggy).
PIN20 is set to ALWAYS_ON (high) to allow the ESP32 to control the desk.
Oh! I didn't know that. Compare here: https://github.com/iMicknl/LoctekMotion_IoT#execute-a-command
Maybe you want to add a description to the README? I wouldn't know because on my device the pin does not have a purpose, i.e., ALWAYS_OFF
does not change any behavior.
It needs to be at least 0.5s, in order for the number template to be updated with the height of the desk height sensor.
I get that. My first thought was a delta/throttle filter but glad I tested it: Filters are only supported by sensors. One option i can think of is to disable direct updates and do the following:
id: "desk_height"
on_value:
then:
- component.update: set_desk_height
I've tested the solution and it works as expected.
I am not sure how often you want to cancel a preset command?
Probably very seldom but to me it feels like this action is missing from the options offered in HA. I would expect the Stop button to stop all movements, be it preset or cover actions. Yes the cover has this function but I generally like to offer slightly redundant but purposeful options. Makes integration in e.g. automations or a Lovelace dashboard a lot easier.
In theory the cover entity should have such a status already. We need to have a look if this is currently missing and if so, if this could be added.
I thought so as well but doesn't seem like it 🧐 Apparently this can be achieved via - cover.template.publish:
> id: desk_cover
> current_operation: OPENING
but it didn't make a difference in a quick test.Anyhow, for the same reasons as above, I'd vote for a dedicated binary_sensor (ideally in addition to the cover publishing "opening")
Do you have any suggestions for a better name / structure?
Good challenge. Nope can't think of one. Let's leave as is.
Not really a bug but this triggers my internal perfectionist. Any idea how to sync those two? Simple round
ing didn't work for me.
[10:52:06][D][sensor:094]: 'Desk Height': Sending state 67.80000 cm with 1 decimals of accuracy
[10:52:06][D][number:012]: 'Desk Height': Sending state 67.800003
[10:52:06][D][sensor:094]: 'Desk Height': Sending state 67.70000 cm with 1 decimals of accuracy
[10:52:06][D][number:012]: 'Desk Height': Sending state 67.699997
BTW, ESP8266 GPIO pins are also tolerant to 5V inputs. e.g. https://www.tablix.org/~avian/blog/archives/2022/05/a_footnote_about_esp8266_5v_tolerance/
Oh! I didn't know that. Compare here: https://github.com/iMicknl/LoctekMotion_IoT#execute-a-command Maybe you want to add a description to the README? I wouldn't know because on my device the pin does not have a purpose, i.e., ALWAYS_OFF does not change any behavior.
Interesting. So in your case you don't have PIN20 connected to your ESP + no PIN20 in your config?
Thanks for your other improvements, I will give it a try and update the startpost when I am done.
BTW, ESP8266 GPIO pins are also tolerant to 5V inputs. e.g. https://www.tablix.org/~avian/blog/archives/2022/05/a_footnote_about_esp8266_5v_tolerance/
Thanks, @jamesmyatt! Not sure why I had so many stability issues when using the ESP8266 with the same config. Perhaps the combination of 5V + no hardware UART causes these stability issues. Multiple users reported similar behavior with ESP8266, but I wasn't able to pin point the issue.
Interesting. So in your case you don't have PIN20 connected to your ESP + no PIN20 in your config?
Historically motivated I have it connected and configured as internal switch as per your default config. However I can confirm that the switch does not have any effect, i.e. neither ALWAYS_OFF
and ALWAYS_ON
, as well as switching during runtime will interrupt normal operation.
Imho, let's state that PIN20 shall be connected and configure it as ALWAYS_ON
as a simplified default. We can still leave a comment "not needed by all controllers" as a comment.
I'd suggest a different name other than "Virtual Screen", which at least I can't relate to. How about "Remote Control Pull-up"?
Minor additional comment: In your code some name
and id
settings are quoted, not all. None of them need quotes.
Slightly tangent but maybe relevant for docs? As I am using an ESP32-C3 my setup uses GPIO21 as TX, GPIO20 as RX. Some dev boards also don't offer all pins. I suggest to add a remark that users should check the pinout of their specific board.
Suggest renames:
switch_alarm
-> switch_alarm_off
button_alarm
-> button_alarm_set
button_alarm
: entity_category: config
Thanks @ThomDietrich, I will make the changes. And actually hope to soon have a beta branch where everyone can easily contribute.
Thanks @iMicknl for the rework! With the new code, ESP Home runs very stable on an ESP32 chip! So far I haven't noticed any more crashes. Good work!
I still observed three features that don't quite match the expected behaviour.
1) If the height is selected via HA using the slider, the desk always moves a little too far, i.e. to slightly too high positions when going up and to slightly too low positions when going down.
2) If the 4 seat positions are selected via HA (Preset 1, Preset 2, Sit, Stand), the desk height is not updated. This can only be done manually if a) I press the button "Wake Screen" while the display is still on. b) when the display is off, one presses the "Memory" button.
3) update_interval: 0ms
seemed a bit brutal to me - this spammed my log until the ESP Home frontend (within homeassistant) crashed. Is it possible to increase this value to 250 - 500 ms?
Thanks for the feedback, @j3mu5! Great to hear that this runs stable on your ESP32.
Dear @iMicknl , it is an honour for me to contribute by testing and giving feedback! :)
I also don't find it essential that the table hits the exact height when set by the slider. As you say, this works perfectly with the presets. I don't find repeated adjustment with up and down (like other implementations) an improvement. I have one further idea: How about subtracting (upwards movement) or adding (downwards movement) a certain, user selectable offset (1-2 cm) from the target size. This would at least compensate for the error somewhat. The difference between the target and the actual value is unfortunately variable; between 1 and 2 cm in my case.
It is the Flexispot E7 with a Wemos D1 mini 32. I have connected the cables as follows: GND White-Brown +5V (VDD) Brown GPIO17 Green GPIO16 White-Blue GPIO23 Blue
Cool, thanks @ThomDietrich
My Flexispot E7 also don't update height when clicking presets
@brumouta do you use the pin-out and config from above?
Im using an esp8266 (lolin nodemcu), with the pins from the main branch but this new yaml.
On Sun Oct 15, 2023, 04:31 PM GMT, Mick Vleeshouwer @.***> wrote:
@brumouta https://github.com/brumouta do you use the pin-out and config from above? — Reply to this email directly, view it on GitHub https://github.com/iMicknl/LoctekMotion_IoT/issues/67#issuecomment-1763440726, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJNJG6BX7QWZGHP5YXGLCTX7QFVTAVCNFSM6AAAAAA5OQUES2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGQ2DANZSGY. You are receiving this because you were mentioned.Message ID: @.***>
@brumouta if you would be able to use the pin-out from this branch (if it isn't the same), would be great. It should work for your device as well.
It should be moving the rx and tx to gpio13 and gpio 15 and leaving pin20 where it is?
I meant the pin-out on the side of your desk mainly, doesn't matter much how you link it to your ESP. The original approach has multiple options for pin outs on the desk side.
Hey @iMicknl
thanks for the updated version of the code, it made it so much easier for me to implement the project at my desk.
As I'm a total newbie with ESPs and HA I could assist in improving the documentation if needed, just let me know if I can help with that, by the way the reference to the ESPWebtools made the implementation a lot easier for me.
The issue with the desk height not being updated when using the presets as @j3mu5 mentioned I can confirm, this also occurs on my E8 (HS13B-1) with ESP32 Dev.
@iMicknl yeah, i'm using the same pins that @j3mu5 is using. I can try tomorrow the new config, and the number from 1 to 8 is basically following the image from main branch right? Or it's just inverted here, because it's basically the same thing from the opposite side.
@iMicknl what's stopping the merge of v2 branch into main? Seems like it already is a big improvement, even if further improvements can come through individual discussions as we had them here
@ThomDietrich time to finish the instructions and polish everything! 😁.
& I would like to add passthrough configurations as well.
@iMicknl yeah, i'm using the same pins that @j3mu5 is using. I can try tomorrow the new config, and the number from 1 to 8 is basically following the image from main branch right? Or it's just inverted here, because it's basically the same thing from the opposite side.
@brumouta, it is the same as https://github.com/iMicknl/LoctekMotion_IoT?tab=readme-ov-file#hs01b-1 from the main branch. The main branch has different pinouts, and it seems this specific pin-out works on all devices.
This version of esphome config works much better than the ones fro repo. I modified to add keypad passthrough and it seems to work really well. I used .h file and sensor snippets from repo - probably not the best way of implementing it, but works nonetheless. My desk was bought from elzap.eu with HS13B-1 controller.
https://gist.github.com/l7ssha/c6d989396a560f895ee3c770815a650a
@iMicknl yeah, i'm using the same pins that @j3mu5 is using. I can try tomorrow the new config, and the number from 1 to 8 is basically following the image from main branch right? Or it's just inverted here, because it's basically the same thing from the opposite side.
@brumouta, it is the same as https://github.com/iMicknl/LoctekMotion_IoT?tab=readme-ov-file#hs01b-1 from the main branch. The main branch has different pinouts, and it seems this specific pin-out works on all devices.
Wait, this is one is the same as the other one based on RJ45 colours, but the pins order are inverted, now I'm more confused
Works good (also with pass-through). One thing i noticed is that ESP is showing height logs each loop cycle. Hopefully it doesn't try to update sensor in HA with this frequency, but only on change.
@formatBCE this is something that I still need to change, currently it spams the log.
This version of esphome config works much better than the ones fro repo. I modified to add keypad passthrough and it seems to work really well. I used .h file and sensor snippets from repo - probably not the best way of implementing it, but works nonetheless. My desk was bought from elzap.eu with HS13B-1 controller.
https://gist.github.com/l7ssha/c6d989396a560f895ee3c770815a650a
@l7ssha
can you share your wiring? i have CB28M1B-1 + HS01B-1 but cant get it to work with passtrough
This version of esphome config works much better than the ones fro repo. I modified to add keypad passthrough and it seems to work really well. I used .h file and sensor snippets from repo - probably not the best way of implementing it, but works nonetheless. My desk was bought from elzap.eu with HS13B-1 controller.
https://gist.github.com/l7ssha/c6d989396a560f895ee3c770815a650a
@l7ssha
can you share your wiring? i have CB28M1B-1 + HS01B-1 but cant get it to work with passtrough
WDYM, code in that gist works.
@formatBCE my initial post here only explains the wiring for non pass through. I think that @tobit6795 is looking for an example of the wiring when you use pass through.
Hi, sorry to bust into this issue like this.
I started out with the flexispot_ek5.yaml example, modified it to work with my Flexispot E7 and am now adopting the changes from your code. So far, I have run into some issues and had some questions:
In the current readme-file there seems to be an error concerning the pin map of the Flexispot E7. It looks like the pin map is inverted, like @brumouta already mentioned. See here for more information: #58 @iMicknl Is this expected when using a RJ45 breakout board? Additionally I think it would be a lot better to list the pin number of the RJ45 instead of the color of the wires as they aren't really useful when using a breakout board and can also be different from cable to cable. Furthermore, I think adding another collum with the labels of the motor controller (not the control panel) would make sense and prevent mixing up of TX and RX pins.
In other words, I would change this (Pins mirrored on E7):
ESP8266 | Loctek Motion (HS13B-1) | Loctek Motion Cable Color (HS13B-1) | Ethernet cable color (T568B) |
---|---|---|---|
GND | GND | Blue | White-Brown |
D6 | RX | Green | White-Blue |
D5 | TX | Black | Green |
D2 | PIN 20 | Red | Blue |
Into this (pins corrected for E7):
Motor controller CB38M2J(IB)-1 | Control panel HS13B-1 | Loctek Motion Cable Color (HS13B-1) | Ethernet cable number | ESP32 |
---|---|---|---|---|
GND | GND | Blue | 7 | GND |
TX | RX | Green | 5 | GPIO 16 (RX) |
RX | TX | Black | 6 | GPIO 17 (TX) |
Pin 20 | PIN 20 | Red | 4 | GPIO 23 |
+5V | +5V | ? | 8 | Voltage regulator (if available) |
Note: I don't know if the colors from the Loctek Motion Cable are also inverted for the E7
Another thing that has already been mentioned is the usage of a logic level shifter. While the EPS32 apparently can handle a 5V input, I doubt it's going to be healthy. So a logic level shifter would definitely make sense. The problem is, which one? It would be nice if we could make a table or something like that, listing the experiences of people who already used them. For example, is a I2C logic level shifter able to convert the signals fast enough?
Additionally, do we actually know that the motor controller uses 5V for UART? My multimeter isn't capable of verifying that, as it constantly shows 2V between TX and GND on the controller. Can somebody verify that it's actually using 5V. Possibly someone with an oscilloscope? I'd rather not fry the controller of the desk than the ESP32...
@CoderTobi please don't look at the current pin-outs of the README, the reason this issue exists is to get rid of the existing pin outs. Have you tried the pin-out from this issue?
The new pin-outs will not use the cable color of LoctekMotion/Ethernet cables anymore, since this is not too clear and error prone. Easiest is to use the pinout number of the ethernet cable. This should be enough to get a working desk controller.
Is it possible to limit the update rate? I'm getting about 50 messages/s to my mqtt server when nothing is happening.
I tried unsuccessfully to update set_desk_height
whenever desk_height
changes, but can't seem to get it to work.
Edit: Temporary solution to make it shut up: Disable the number
component by adding internal: true
, and set log level to INFO. This is especially chatty on MQTT as it updates the name/debug
with every log string as well`
Is it possible to limit the update rate? I'm getting about 50 messages/s to my mqtt server when nothing is happening.
I tried unsuccessfully to update
set_desk_height
wheneverdesk_height
changes, but can't seem to get it to work.
Yeah I guess author said it should be fixed. Cached somewhere inside or so. Because it bombs with updates
Can't stop the desk using the cover control when moving using a preset; works fine if movement was started using the cover control.
Can't move the desk to a preset if starting from the maximum height. To reproduce, press up and wait until desk hits top, then use a preset.
I'm still getting long floats (eg. 99.099998
) in the number component on HA even though I see the step
/accuracy_decimals
are set.
Using MQTT instead of Esphome API, desk with a CB28M1B-1 control box.
For now, you can remove the number entity and your logs won't be flooded. The update interval there is the issue. Need to update this push, instead of pull.
time to finish the instructions and polish everything! 😁.
Hey @iMicknl, your call but I personally believe that you should just merge as is and additional changes, like to readme can be addressed step by step. Didn't we already resolve the number updates issue?Let's merge :)
@ThomDietrich agree, however the README isn't fully updated yet. Main blocker was to find some time to do this, but hopefully I can do it this week. Just changed the YAML linked above to include the component.update
to no flood the logs.
I am still not sure why multiple users face the following:
If the 4 seat positions are selected via HA (Preset 1, Preset 2, Sit, Stand), the desk height is not updated.
This works like a charm for me with the YAML + wiring above. (without passthrough).
Can't stop the desk using the cover control when moving using a preset; works fine if movement was started using the cover control.
This is normal behavior. You can cancel your movement by selecting the same, or another, preset again.
Hey @iMicknl, regarding the component.update
change to the number entity. I just realized that you can change the update_interval: 0ms
to a literal update_interval: never # will be updated by another component
. Pretty neat. Thought you might wanna add that
Hi,
I've been trying to get this system to work, but with limited success.
I have a CB38M2J(IB)-1 control box and a (HS13A-1) touch panel. By control box has 2 RJ45 ports, one is used by the touch panel, the other is now connected to the ESP.
I use an ESP8266, with the pinout described above. Since I don't have HomeAssistant, I added MQTT support by just adding these lines:
mqtt:
broker: 192.168.178.57
client_id: esp_desk
topic_prefix: esp_desk
The issue I have is: None of the values get updated when using the touch panel, specifically the desk height. But The ESP seems to be connected correctly, because: When rebooting the ESP, the desk height gets updated once, and correctly. It shows the height the desk is at. But changing the height via touch panel, or using any of the preset buttons, does not seem to have any effect on the ESP, as MQTT does not receive any messages with updated values (other than the Wifi signal strength).
Any idea how to solve this? Can we somehow "see" the serial data that the ESP receives?
IIRC there's a line you can comment out to see the raw uart data.
Is this issue specifically related to the version here or does it also occur with the main version?
I only tried with this new "v2" version of the ESPHome script, I haven't tried the version from the main branch.
I have a feeling that although my control box has 2 RJ45 ports, the one with the ESP doesn't receive any updates done by the key panel connected to the other port.
I tried this: With the ESP connected, I just removed PIN20, then changed the desk height via key panel, and reconnected PIN20 to the ESP. Almost immediately, the new height was published via MQTT.
I have a feeling that although my control box has 2 RJ45 ports, the one with the ESP doesn't receive any updates done by the key panel connected to the other port.
I have seen multiple reports on this, but I can't reproduce this.. My control box has 2 RJ45 ports and when I manually change the height via the keypad, I see the values change via my ESP32.
Related to your testing with pulling the PIN20. Have you tried turning the PIN20 on/off via the ESP?
@iMicknl How would I do that? (This is my very first ESP, and I'm not at all familiar with ESPHome).
Look for this part of the code:
switch:
- platform: gpio
name: Serial Control Pull-Up # "PIN20" of desk controller
pin:
number: GPIO9 # might be different for your setup
mode: OUTPUT
restore_mode: ALWAYS_ON
entity_category: config
internal: true
Change the last line to internal: false
. You will see a new switch turn up in Home Assistant.
I don't have Home Assistant, but I added an MQTT command to toggle the PIN20 switch.
If i toggle the switch off for at least 2 seconds, and then on again, the height data packages are being processed (I enabled the debug logging in height_sensor.h
), and if the hight has changed it is being published.
But if I don't "touch" the virtual switch, and change the height of the table, no debug messages regarding height are being processed.
Thanks for this project. I really appreciate the work that has been done.
Just as a note. I had to download the height sensor C implementation and use it with 'includes:' as the 'external_components:' entry does not work for me. (compile error) Am I missing something?
I have the same issues with the reporting of the desk height. (Two RJ45 ports that seem to report different things.) Will do some testing and share my findings if I got something interesting.
best regards
Seems to work fine!
My control box is a "CB38M3B(IB)-1". I found out my ethernet wiring is the other way around, but this might be my own fault. I only have RX/TX connected now and all looks good. If I use the original controller it also updates the esp status.
Is it possible to adjust the alarm (timer)?
Also I would like to change the behavior of the up and down buttons to "momentary", the same as the desk itself. Would this be possible?
I tried this on my standing desk with the HS13A-1 controller and a second RJ45 port and it worked instantly - what took the longest was getting the ESP32 into flash mode.
Is this the same as the version in the v2.1 branch, which looks like it's the latest? https://github.com/iMicknl/LoctekMotion_IoT/compare/main...v2.1
I am working on improving this repository. The main goal is to make it easier to get started, by providing only two configurations and a more updated README + configuration. In order to achieve this, all feedback and contributions are welcome.
Main goal:
desk_height_sensor.h
(load from custom component)Long term:
Changes
Pin-out
In the past we have discussed multiple pin-outs, but it seems that multiple pin-outs can be supported by the same desk.
You can change the ESP32 pin-out mapping, but don't forget to change the pin number in the YAML.
My setup, no soldering required.
Configuration
office-desk-esp32.yaml
The following secrets should be part of your ESPHome config:
encryption_key
,wifi_ssid
andwifi_password
.Feedback
Any feedback and contributions are welcome! For example the work above adopted for pass through configurations.