My Nexa Bridge (not X) won't find any devices #34
Comments
|
Hi. You're probably correct about the timeout. You could try modifying the configurations: ha-nexa-bridge-x/custom_components/nexa_bridge_x/const.py Lines 25 to 29 in d718a7e
It's the POLL_TIMEOUT that seems to be hit here. Try increasing it and restarting HA. Sadly I don't have access to a Legacy bridge setup, so I cannot look into the performance issues that this product seemingly has. More info: |
This comment was marked as outdated.
This comment was marked as outdated.
|
Kind of strange that In any case, you probably don't have to mess around with api calls. Since you have so many nodes set up, you probably just have to increase the timeout. If this solves the issue it might be worth looking into increasing it by default for Legacy users. |
|
Yes, you where right. removing the ending slash produced expected output! |
This comment was marked as outdated.
This comment was marked as outdated.
|
Sadly, still times out like #32 I see. Just like in Try something much higher, like: I'm going to have to think a little bit on this one and see if there is not a more efficient way of handling the polling on Legacy bridges. From looking at logs reported in this repo it seems that the bridge randomly gets super slow to respond. The X does not exhibit any issues like this (and also does not need to be polled in the same way). You've provided some good data here, and maybe there's something in here that gives me some pointers. |
|
I would be very interested in seeing if setting Probably still need to set |
andersevenrud
added
bug
|
Could you provide a sample of I'm currently contemplating disabling the value polling on legacy bridges and rely entirely on the websocket broadcasting. This comes with one downside however: the initial sensor values when HA starts up will not be up to date and there is no fallback in case a websocket does not publish updated values. Edit: This also might mess with the setup procedure because of lack of values...I have to set up a test environment for this myself. There might be a way to get around this with doing some kind of pause between calls on setup to prevent request flooding and timeouts... or just force readings to be zero by default. However, this would take care of all of the timeout stuff because nodes does not need to enumerated. Would you mind testing this on your setup ? It's just a matter of commenting out (or remove) the following block of code: ha-nexa-bridge-x/custom_components/nexa_bridge_x/nexa.py Lines 336 to 339 in d718a7e |
|
You've really excelled here. Apologies for my limited coding skills. Could the issue possibly be related to the number of entities? I had around 64 units, but these units were somewhat artificial or of inferior quality. Several years ago, my temperature sensor inexplicably duplicated, and I'm unsure why. Interestingly, I noticed a duplicate of one of my rooms in the web interface but not in the app. I didn't pay much attention to it as everything seemed to be functioning fine. I've been managing this setup for years, and it was only yesterday that I realized, "Hey, I need to upgrade to a home automation system," and suddenly time caught up with me. By the way... it appears that timing isn't the only crux of the matter. See... despite removing numerous units, the problem persists. I'm confident that if my unit were clean, it would progress. DOne removed: Done I will soone add results |
This comment was marked as resolved.
This comment was marked as resolved.
|
I created a branch with some changes to reflect what I wrote in my previous comment, but hopefully without crashing (i.e.
No worries. I probably should apologise for assuming that anyone creating an issue here has coding experience... HA is one of the places that kind of blurs the lines when it comes to experience 😅 |
This comment was marked as outdated.
This comment was marked as outdated.
You've hit the nail on the head here. This is the bottleneck of the legacy bridge. To get all the current/previous values every single node has to be polled ( There is a websocket running on the bridge that pushes all latest values as they are updates, but the rate on this data is set on the node (device). Which means in some cases it can be hours between new values. A good example is one of my temperature sensors that only updates with a threshold of 1 degree C. So on a hot summer day it basically stays the same until the sun goes down. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
Thanks! Okay. Since it's getting a bit late here I think I just have to put this down and get back to you tomorrow. I'll have a proper development environment to simulate all of this so you don't have to be a guinea pig. |
|
No worries. Late here as well! You are doing great! |
|
This outcome isn't quite a success. However, I've eliminated all temporary and fake sensors, as well as some scheduled tasks. After reverting to your original code, Nexa now detects 8 devices and 9 entities. There seemed to be some obstacle, potentially related to sensor dependencies rather than legacy device, but I can't confirm for sure. Timing if you have a lot of sensors/entities to run through... sure. But I'm almost postive about different sensor tables. Log |
That's at least some good news.
I think there is an underlying issue with the legacy bridge API relating to repeated calls. Since you've removed nodes etc. there amount of calls goes down, which kinda confirms my suspicion -- well, at least a potential bottleneck. Might be more stuff going on here; like your actions could have freed up some resources. Pretty hard to get a concrete answer here since there are no way to grab debug logs from the bridge (without doing hardware hacking). |
|
I just set up a development environment and isolated my changes in https://github.com/andersevenrud/ha-nexa-bridge-x/pull/35/files I got home way later than anticipated, so have not yet been able to test everything, but I did not get the errors you provided in the log dumps when running with these changes 🤔
So this is a bit strange. I would recommend trying again, but grab the code yourself (from the PR link above). A little bit safer than me providing alternative links that gets outdated quickly, etc. You can press the three horizontal dots button on each file and do "View File" from the dropdown menu to get everything so you can copy/paste it. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
After some more thought I implemented another behaviour for legacy bridge. The value polling is now sequential and only happens upon initialisation (or when the integration is set up). This process comes with it's own timeout as well so that the first poll has a much longer timeout than the subsequent ones. I've also updated the default timer values: ha-nexa-bridge-x/custom_components/nexa_bridge_x/const.py Lines 24 to 28 in 41cf1b6 This combination most certainly will eliminate any stress, and therefore hopefully get away from the bottlenecks of the bridge. The only downside is that if the websocket connection for some reason gets disconnected for long periods of time, things could get out of sync in HA... However, the chances of this should be extremely small (unless I have made a big oof in the code somewhere for reconnections, etc). Also, since subsequent value polls are no longer performed there is a potential edge-case here where nodes that fails discovery won't get any initial value. This will be logged as an error though, so keep an eye out. The PR has been updated with this.
I kinda have an idea on how to work around this as well by keeping track of failed nodes, but hopefully it won't come to this because introducing even more states is something I wanna avoid. Edit: We can also experiment with enabling re-polling as usual if my changes seems to work without errors in your logs too. If the bottleneck is gone then there's no need for any of this custom stuff 🙏 |
|
That's quite wild... I also just completed a fresh install on a Raspi 5 I just got. A same that your still having these issues. The latest release of this integration does not actually contain any of the stuff I've tried to make your legacy bridge work. If you could try applying the changes in the following PR and give that a go: #35 . I'm kinda contemplating souring one of these legacy bridges (at least if there's one for cheap) so you don't have to spend time messing around with manual edits and potentially waste time. |
The device setup in HACS took a while, possibly due to a timeout issue, but eventually, it was configured with the correct IP address and in legacy mode. The Hub was successfully added and detected the name of my Nexa Bridge as "NexaB." However, despite this, the setup repeatedly fails.
Upon inspecting the logs, it appears that the GET request does not receive any response.
HA Logs
But if I browse http://192.168.1.2/v1/info i get:
Postman Log
For http://192.168.1.2/v1/nodes/1082 i get:
Postman Log
The text was updated successfully, but these errors were encountered: