-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Desk height and all other entities always eventually become unknown in Home Assistant #28
Comments
I'm seeing this too with 1.0.0 but in my case re-plugging the Upsy Desky doesn't bring the entities back. HA can't see any entities from it anymore besides Status LED and Re-Detect Encoder. I've also done a factory firmware flash and its made no difference. I can still operate the Upsy Desky from its web UI. I've got this connected to a Fully Jarvis desk. |
I ended up completely removing my upsy desky from HA to get it working again. |
That's strange, were the old entities "unknown" or "unavailable"? |
@grahamwetzler In the history of the entities which become "unknown", do they become "unavailable" for a brief time beforehand? |
I'm not sure. Earlier today I moved away from the ESPHome configuration method and flashed 0.4.1 from the Github releases and it's been fine. |
It took a week of but it just happened to me on version 0.4.1. The entities all became unavailable then unknown. I guess I'll try version 1.0 again and see if it happens there. |
Unfortunately this is still happening on the version 1.0 file I downloaded from the Github release. Even using the reboot from the web ui does not bring back the entities in Home Assistant. The only way to temporarily get it to work is to replug the RJ45 connector. |
Sorry to leave you hanging here. If you're still experiencing this issue, I would suggest powering the device with an external USB power supply. Since the entities first become unavailable (indicates the device is totally unreachable) this suggests to me that your desk's control box may not be able to provide enough current to keep the Upsy Desky powered. Providing the additional power supply via USB-C will resolve this. Let me know how it goes. If you still experience this after plugging in a USB-C power cable, try installing the debug firmware from the releases. Grab |
I believe I've come up with a workaround. I added an automation where any time the desk height becomes unavailable, I trigger a button press on the re-detect decoder button. |
Unfortunately my workaround did not work. Even if provided with an extra source of power via the USB-C port, it still goes completely unresponsive where the only fix is to unplug/replug the RJ-45 connector. I'm going to try the debug firmware again and hopefully something will show up in the log. |
I do see an issue right away. When first started, |
Can you provide the information that appears in the "Device Info" sensor? I'm interested in the reset reason. It sounds like it might be restarting in the middle of the control box sending messages, and fail to detect the correct protocol. If you are familiar with ESPHome, you can also customize the configuration of the height sensor to always use the Also, what is the model number for your keypad? |
This info?
I have this keypad |
Oh I see,
|
Thanks for that. I'm not seeing any abnormal reset reason, which is strange. Can you try out this firmware? It bypasses detection and forces it to use the If possible, please keep the web UI open until the issue occurs, this way we have the full logs from start to finish as well. If it doesn't work, then I suspect this may be a hardware fault of some kind; I can send you out another unit in that case. It could also be some difference in how the control box talks to your specific keypad — I have the same control box as you, but a very slightly different model of keypad. So I could purchase the one you have and do some testing myself. |
Thanks, I installed that firmware |
Unfortunately the current height and other entities are still going unknown after a few days. Once I press a key on the desk, the height does come right back at least. |
Coming here to report that this problem is still occurring on Version 2.0.0 of the firmware. I have a Fully Jarvis desk setup and I can control the desk for a while, and then the Upsy goes offline. No explanation why. |
I'm also seeing this issue with similar logs. I have the same keypad. ESPHome appears to frequently disconnect from a wireless connect to the device, but I'm not sure that's related:
|
@brettinternet can you confirm whether the state is changing to |
@tjhorner The Home Assistant state is I am seeing the Home Assistant device's Logbook show a few of the entities (Preset #) "became unknown" every few minutes or so. Some of the other entities (Set Preset #, Status LED) show "became unavailable". Desk Height however remains "unknown". Could this be related to the ESPHome disconnects as well? The device is on a separate IOT VLAN than my homelab VLAN but I don't have any issues with any other device. Home Assistant runs on the host network mode in a docker container. Each VLAN has access to communicate. An mDNS repeater listens on all the interfaces. |
@brettinternet Thanks for the info. How often do you see the entities becoming Could you also confirm your control box model number? |
Since multiple people have run into this issue, I created this guide just now to assist in log collection etc: https://upsy-desky.tjhorner.dev/docs/troubleshooting/connection-issues/ |
Here are some details: ControllerUplift FRM053-2. The desk is almost 2 years old. KeypadFRM066 "Advanced Comfort Angled Keypad". Device Info
Yesterday I noticed the device was labeled as "offline" in ESPHome despite being able to connect to it via ESPHome and view the logs. It looks like this is sometimes an mDNS issue (despite running the ESPHome container in network_mode "host" and having an mDNS repeater). As a workaround, I added a manual IP in the ESPHome config and now the device remains labeled as "online". wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
manual_ip:
static_ip: <upsy desky static IP>
gateway: <gateway>
subnet: <subnet> This appeared to stabilize the connection for much longer than a mere few minutes as I was experiencing before. Only just now, almost a full day later, have I seen the entities revert back to The first two lines of the logs below represent when the Desk Height becomes
After adding the debug options, here are the complete logs: https://gist.github.com/brettinternet/5883a606cef3024fe4237492b7e419af The issue appears to be related to a reboot, and one reboot the values are unknown. It continues to reboot with the debug configuration options you suggested. Here's my full ESPHome config now: substitutions:
name: upsy-desky-76d87c
packages:
tj_horner.upsy_desky: github://tjhorner/upsy-desky/firmware/stock.yaml@v2.0.0
esphome:
name: ${name}
name_add_mac_suffix: false
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
manual_ip:
static_ip: <upsy desky static IP>
gateway: <gateway>
subnet: <subnet>
logger:
level: DEBUG
debug:
update_interval: 5s
text_sensor:
- platform: debug
device:
name: "Device Info"
sensor:
- platform: debug
free:
name: "Heap Free"
block:
name: "Heap Max Block"
loop_time:
name: "Loop Time" |
Hi everyone, I've got some more details that hopefully brings us closer to a fix. One person experiencing this issue was able to capture a backtrace at the time of disconnection, and it appears that the BLE component is to blame, but not in the way initially thought. Here is the trace:
Initially, I thought the BLE component may be interfering with the Wi-Fi component since they share the same antenna and were causing connection issues. But as evident by the stack trace, it's actually a firmware crash. There are some issues with similar stack traces in the ESPHome repo itself (e.g., esphome/issues#4901) and the conclusion appears to be that the device is running out of RAM. This is not surprising to me, due to the overhead of the Arduino framework and all the components the stock firmware has. I will dig a little deeper into this to verify that this is indeed the cause, but I'm just happy that we aren't flying blind anymore! I suspect a solution to this may involve trimming down the stock firmware and offering a sort of "build your own Upsy Desky firmware" tool where one can include extra features from ESPHome if one wishes. In the meantime, I will try to replicate the issue with this new information and report back. |
@tjhorner So if i were to disable the bluetooth proxy feature, it should hopefully not crash? I'm going to try it out right now and ill get back to you on the outcome after a while testing. |
Hi everyone. I just published v3.0.0 of the firmware which includes changes that are likely to solve this issue. Please read the release notes and try it out: https://github.com/tjhorner/upsy-desky/releases/tag/v3.0.0 Thanks! |
Running version 1.0.0 with an Uplift Desk (FRM053-2). After a day or so all of the entities in Home Assistant become unknown. The buttons still work to change the desk height though. The only way to temporarily fix this is to re-plug the Upsy Desky.
I don't see any useful logs to add.
The text was updated successfully, but these errors were encountered: