-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
[Busch-Jaeger 6735/01] Device becomes offline/unreachable #124
Comments
If you can provide a "full" startup log it might be useful at least to see what is happening there at least. |
Thanks Chris!
|
I forgot: |
Update: the switch removed itself from the network again (it was offline in PaperUI when it happened). So looks like that's caused by changes in newer versions of the binding. Btw, your changes to the startup code are quite noticeable, it's a lot faster now! |
By this do you mean you think the binding is removing the device from the network? I don't think this is the case, and I don't think there has been anything like this added to the binding. If this is what you think is happening though, then I'd need to see a log showing how the binding is removing the device. |
I first thought the device is initiating the removal,
Do you need a longer part of the log? |
Maybe the part before this - this just seems to show ZigBee stuff - not the information from the core as to why this was triggered. There's two ways that I know of for a device to leave the network and that's if the thing is deleted, or if a specific leave command is sent. Neither of these are new - the binding has always done this, but the question is why it now seems to have started sending these requests. I assume you are not deleting the thing in HABmin/PaperUI or sending configuration somewhere that is causing this?? |
Stupid me!!! Of course I copied exactly the part of the log where I actually removed the thing myself to make it responsive again 😞 So there's nothing coming from the binding, the device is just leaving: |
As you say, there's no real clue what's happening here. I assume that before it decided to leave it had been working ok? I wonder if the device leaves if there's no communications for a certain time? I think it would be strange as it means if you have a power cut for many hours, then all your devices leave. One thing I did change recently was the default polling period- it was increased recently to further reduce needless network congestion. Otherwise I'm not sure why it would just leave... |
I'm not sure yet, but it looks to be leaving only when it is also offline in PaperUI. Or at least it will leave pretty fast after a OH restart when it seems to lose connectivity for whatever reason. I still have to capture a debug log after it has been working ok though. It's currently working fine after I've re-added it yesterday.
I don't think the polling interval is an issue as it's still working. If it was an issue I would expect it to have left the network meanwhile. Did you notice anything unusual in the startup log? I don't understand why the device is shown as offline in PaperUI after a restart but On/Off commands are still showing up in the log (although not firing any OH events). |
From a quick look at the startup log, it seems that the device initially didn't respond, but once you started pressing the button on the device, it started to respond again (although not 100% reliably). Possibly this is a battery device management issue (it seems battery devices are a pain everywhere!). |
Thanks for looking into it Chris. Device is still working atm so I'll let debug logging on and see how things develop. Maybe a firmware update will help, we'll see. How exactly do you examine these logs? I'm always looking for the IEEE and network address of the device I'm interested in but couldn't spot anything unusual. What else should I look for? |
At the moment I’m just using a log viewer with the ability to highlight based on certain rules. It’s not great, but it’s ok if I know what I’m looking for… I did start to write a log viewer similar to the ZWave one but this isn’t working yet…
Filtering on IEEE or NW address is fine - it’s broadly what I do. I would like to always show the IEEE address on all log entries so we have a consistent view, but there are a few entries where this isn’t available within the scope at the time of the log...
… On 31 Jan 2018, at 08:44, weakfl ***@***.***> wrote:
Thanks for looking into it Chris. Device is still working atm so I'll let debug logging on and see how things develop. Maybe a firmware update will help, we'll see.
How exactly do you examine these logs? I'm always looking for the IEEE and network address of the device I'm interested in but couldn't spot anything unusual. What else should I look for?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#124 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ8V4gn9HdKZFDAuowVURE1T4QMfFks5tQCfagaJpZM4RwdJw>.
|
Thanks for the info Chris. Regarding the issue at hand: the device is still responsive after a week. If it is a general issue with management of battery powered devices we should see similar problems with the ST motion sensors, which is not the case. So I think we can close here? |
@cdjackson thoughts? |
Ok, let's close this and if there's future issues or comments we can open another issue. I'm sure there are improvements needed in the binding but we should keep issues specific if possible. |
I've noticed that the battery-operated BJ control element becomes unresponsive after working just fine for maybe a day, or immediately if restarting OH.
I think you mentioned something that sounded a bit similar with another battery powered device (I think a ST motion sensor)?
Currently I have to remove the device in PaperUI and add it back to make it work again.
I still have to gather a debug log and will post it as soon as I can catch it. So far I can only say that the device doesn't respond to the node discovery request on restart:
The text was updated successfully, but these errors were encountered: