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
discovery of new thing will reset the baudrate of the BV2010/10 #726
Comments
????? Please provide the logs as this is not a problem that I personally have, and others do not report this issue so I can only guess what is wrong with your system without the logs. |
These are the logs scanning for new things without adding a new thing and the baudrate is reset to 57600 |
Nothing here is changing the baud rate. The dongle stays working throughout this process so clearly nothing changed. |
@cdjackson thanks for looking into this, here is a new log file with extended logging settings. here is the full log file: logs2.txt |
There is a discovery of USB devices that was added by German Telekom a few years ago, but my understanding is that this should not update the configuration of an existing thing. That said, it does seem to be based on your report. @wborn I'm wondering if this is a bug in the core? The discovery provides configuration for the thing, but if the user has instantiated the thing, and changed the configuration, the core shouldn't update this config. I thought the core was meant to use the representation property to stop this happening - this is set as the port name, so assuming the port is not changing, I would have expected the core not to update the configuration of an instantiated thing? Or am I missing something? |
I had a look at the discovery code and it could be that the You can enable debug logging on For network based things I can imagine it could be useful to also update existing things e.g. to update IPs or ports etc. |
In the past the binding was able to check to see if a thing existed and not update, but that function caused an issue (I forget what - circular dependencies or something I think) and was removed, so now the binding has no way to know if the thing exists and just has to rely on the core to manage this…
… On 16/01/2022, at 11:40 PM, Wouter Born ***@***.***> wrote:
I had a look at the discovery code and it could be that the PersistentInbox always updates existing things based on new discovery results. See: PersistentInbox.java#L254-L264 <https://github.com/openhab/openhab-core/blob/0dbc2b2ef428d1691907b0c7a85dce9c2f4a9b67/bundles/org.openhab.core.config.discovery/src/main/java/org/openhab/core/config/discovery/internal/PersistentInbox.java#L254-L264>
You can enable debug logging on org.openhab.core.config.discovery.internal.PersistentInbox to check my hypothesis. 🙂
—
Reply to this email directly, view it on GitHub <#726 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH6IQY7V5B7Y667223RWW3UWKODPANCNFSM5LXKR42A>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.
|
Yes it was a bit easier to only create discovery results for new things in the past using the But it is still possible to track the created existing things in your binding whenever |
Interesting point - not something I’d considered but I see there are calls in the factory class when a thing is removed. To ensure this works, the core would need to guarantee that all things are instantiated before the discovery service is started - is that the case? If notches will still be a problem if background discovery starts before the things are created as the handler factory will not be able to build the list of things.
I’ll take a look to see if I can link the factory and discovery handler anyway.
|
@wborn - thinking about this some more, doesn't it make more sense to do this in the core than in every binding. I personally can't see the case when the discovery system should ever override the configuration that a user has set when they instantiated the thing. Or maybe there is there a case where discovery can update IP addresses or something like that? In my bindings where I have devices that can change address I manage this in the thing handler, but maybe it's a valid use case? In the "old days" of OH2, the discovery service was only meant to discover the existence of a thing and add it to the inbox - if that's still the case, then I don't see a use case for discovery services updating the configuration of existing things.... I'm not necessarily against adding the internal check in the binding - it looks easy enough with a static method and I already track the creation/removal - but I personally think unless there's a use case for the discovery changing an instantiated things configuration it might be better placed in the core. |
This code for updating existing things using discovery results seems to go back to 2014, as it was first introduced in eclipse-archived/smarthome#52 So it will probably introduce other issues if we'd remove it today. A reusable solution that can be used by all bindings would make sense to me. Another workaround could be to make it possible to disable the discovery service using configuration. |
This issue has been mentioned on openHAB Community. There might be relevant details there: |
I also read in eclipse-archived/smarthome#3975 (comment) that new discovery results are used for updating the locations in existing astro/weather binding things. |
Maybe it is possible to detect this custom firmware somehow and then create a discovery result with the right configuration in the discovery service? |
I'm also facing this issue, but it's not just the baud rate that is overwritten, pretty much all settings are reverted back to their defaults: baud rate, high/low ram, join type. I worked around it by manually creating the bridge in the interface and placing the discovered one in the ignore list |
I'm not keen on this. When we first implemented this discovery I was keen not to open the serial port to try and perform more detection. To do this means (obviously) opening ports - this can conflict with other operations. Eg if the thing is already instantiated, then it will prevent the thing starting (ok, it could be retried, but with all the problems around nrjavaserial I prefer not to continually open the port trying different speed options). 56k and 115k are not the only speeds in use so it's just not (IMHO) a very elegant solution. |
I am having big troubles with my current OpenHab 3 + Zigbee setup. After a lot of trials and failure I decided to upgrade the firmware of my Bitron video stick ( https://github.com/grobasoz/zigbee-firmware/blob/master/EM3587/NCP_USW_EM3587-LR_678-115k2.ebl ) After upgrade stop/start of openhab then changing controller with 115200 bauds put the controller back online.
I did not identify yet if this value is coming back from backup. Switching back the value to 115200 bauds brings the controller back online. I tried to change the baud value in And, same behavior as @joerg1985 a click on 'scan' button of the webUI reset the speed value :
Openhab 3.2.0 currently running, so I assume it includes 22f4e89
|
I face unfortunately the same issue on 3.3.0.M1 |
This issue has been mentioned on openHAB Community. There might be relevant details there: |
I'm being hit heavily by this bug also |
Me too. This is something there should be at least a workaround for. |
I actually managed to work around this by:
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/ledvance-smart-outdoor-zigbee-pairing-but-not-working/135974/3 |
I tried this way and the USB device actually comes as online immediately, but when changing the bridge for the devices they get GONE status immediately... |
I will remove discovery from the binding to resolve this. |
Outline
I am using the BV2010/10 zigbee coordinator with a custom firmware. The stock firmware was to old to work with newer devices
(https://www.openhab.org/addons/bindings/zigbee/). The custom firmware is configured to use a baud rate of 115200 with software flow control.
It is possible to change the baud rate in the configuration of the ember coordinator. This makes the 'thing' to go into 'online' mode and the known things are going into 'online' mode.
As soon as the the discovery of a new 'thing' is started, the baud rate of the coordinator is reset to the default value of 57600. This makes the coordinator go into 'error' mode and the discovery of the thing fails.
Configuration
Logs
The text was updated successfully, but these errors were encountered: