-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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/6736/6737: Make polling interval configurable #7733
Comments
When connecting it to the mains adapter, do you see anything being logged in the z2m debug log? See this on how to enable debug logging. |
Maybe the logs I posted in the other thread are enough? A log with the new "ember" driver is here https://github.com/Koenkk/zigbee2mqtt/issues/22249#issuecomment-2203469708 and with "ezsp" hiere https://github.com/Koenkk/zigbee2mqtt/issues/22249#issuecomment-2206748334. Look for the device named "K: Trafo-Bedienelement-Kombi links" and address "0xd85def11a10049b0". This is a 6736 (two rows) panel mounted on a 6710U mains adapter (contrary to the 6711U relay and the 6715U dimmer, which have to be polled). |
Implemented it, it's now configurable and the default is 60 seconds. Changes will be available in the dev branch in a few hours from now. |
Possible side effect? Slight delay when operating the uppermost row (wired directly to the relay/dimmer) by Zigbee, see https://github.com/Koenkk/zigbee2mqtt/issues/22249#issuecomment-2221918095 |
You will have to enable |
@Ra72xx Are you sure about this? Panels which are mounted on a mains adapter do not have a switch endpoint. Therefore no polling should be performed by z2m. Anyway I think the configurable poll interval is an excellent idea. I have also added a few more of these BJ devices and I have also noticed slowdowns ever since. The 5 seconds were way too aggressive I think. |
Well, as I now run the patched version, I cannot post any more logs ;-). However, I think in the logs I posted previously, the panels mounted on the mains adaptor made regular appearences. |
Turning a light on and off again with Zigbee leads to the following log entries, and also an error in the end, works however. There is only a slight (1-3 secs) delay relatively often between Zigbee command and execution.
|
I think this does not have anything to do with this issue. However I can think of a few things here:
|
However, this cannot be the reason of the delay IMHO, because my delay occurs when operating the relay over Zigbee, not by manually using the panel. Using the panel reacts fast enough for me even without direct binding. |
I post a feature request because of @Nerivec 's advice in a Z2M bug thread (Koenkk/zigbee2mqtt#22249 (comment)):
These Busch-Jaeger panels (see https://www.zigbee2mqtt.io/devices/6735_6736_6737.html, in the non-battery-powered variant) are to be mounted on different sockets, either a relay, a dimmable switch or a pure mains adaptor as a mere power source.
When mounted on a relay or a dimmer element, the upper row of the panel directly operates the underlying relay/dimmer. This means that the Zigbee network is neither needed nor used in this scenario. The disadvantage is that Z2M is not informed if the switch has been operated manually and has to poll the network for the current state.
This seems to happen every five seconds and in my use case with 9 of such devices leads to so much network traffic that e.g. the "ember" driver is unable to operate reliably (#22249).
I don't know if there is an more elegant solution to this problem, but what would at least help would be:
The text was updated successfully, but these errors were encountered: