BJ 6711 U relay state not updated #49
Comments
I'll move the conversation off the forum for this - it'll be easier to track... Is there now an XML generated in the |
|
Just for my reference... Device information... Bind / Reporting commands [Level control]... Frames observed -: |
|
There are two xml files, I guess you're only interested in the |
|
Thanks - they should be the same. The most recent version I changed the name from zigbee-network, to add the coordinator uid to the end so that there can be more than one coordinator without conflict. |
|
From the above it seems that the binding and reporting are configured (for the level command at least - I've not looked through every channel yet)... Can you tell me what time you changed the relay position manually? (probably not ;) ). Alternatively, can you provide a short log that basically just shows what happens when you press the button. |
|
Should be at the end of the previous log. However, here's what's in the log when pressing the button a couple of times (not much though I'm afraid): |
|
I don't know if it's relevant, but the physical switch actually has two buttons (or maybe two sides is more appropriate). Right side is for turning the relay on, left side for turning it off. |
|
This logging isn't related to the device :( . I guess that means the device isn't sending anything. Hmm - something else is wrong as the TX queue is increasing in size. Can you ZIP up the log again please so I can take a better look? Thanks. |
That doesn't sound good :) I've attached a log from restarting OH earlier today until now. However, I had set the log level to |
|
Thanks. So, good news, and bad news... Firstly, the log doesn't show the error that I was looking for - the TX queue seems to be stalled and you will need to restart the binding to solve this. If this happens again, please post the log (the indicator is the log entry Good news though - I do see the commands in your log that I suspect are from the switches - it's from just after the log you attached above. It looks like they are using the ZLL profile so are bing dropped by the binding (easy issue to solve) - I need to decode the messages to see what they are - I think they are the reports I was looking for so there's some hope :) If I provide you a debug version are you able to give it a try? |
Ok, thanks for the info. I'll restart OH with debug log level and if I notice something like that I'll post the log.
Nice 👍
If you could provide a jar I'll be happy to test it. I haven't set up an OH development environment, so unfortunately I can't build myself. |
|
A test version is here. Let me know if this works, and if not please provide another short log showing any messages from the device... |
|
Thanks Chris, I'll test it and report back. Regarding the issue with the growing TX queue, this has happened again since the last restart. |
|
Thanks. What hardware/software are you using as a matter of interest (shouldn’t matter, but useful to know just in case).
… On 3 Dec 2017, at 13:42, weakfl ***@***.***> wrote:
Thanks Chris, I'll test it and report back.
Regarding the issue with the growing TX queue, this has happened again since the last restart.
Here's a full debug log since the last OH restart:
oh_zigbee_binding_debug_03122017_1434.log.zip <https://github.com/openhab/org.openhab.binding.zigbee/files/1524772/oh_zigbee_binding_debug_03122017_1434.log.zip>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQz_ly7LUAjcA5Wgtdb4x-OAzAXyiks5s8qVAgaJpZM4Qzpso>.
|
|
Raspi with stretch: |
|
Unfortunately it's not working with the test version either. Here's a brief timeline of what I did: And the log: |
|
Just to make sure I've used the right version, the link you posted above was broken but I figured the correct URL should be |
|
I've fixed the link, but looks fine (seems if I don't add http on the front of the link, github assumes it's a local address!). Anyway, with these logs, I don't see the ZLL messages I saw before, so the version doesn't matter. In your original log, they might not have been directly linked to the button presses as I'm not sure they were at the same time given you originally didn't post them as something that happened when the button was pressed. Your log when you said you changed the switch was at 11:44:04 to 11:44:34, but the ZLL frames are at 11:45:23 so I guess it's not linked and we're back to the "nothing is being sent" situation :( |
I'm afraid you're right as I don't see any Do you think polling could work to update the relay state in OH, even if the state update wouldn't be immediate? Another route might be the switch attached to the relay. I'm still a bit puzzled by those. I was expecting the switches to be discoverable as separate zigbee devices (just like the battery powered switch), but they're not showing up in the inbox. Especially because some of the switches have two/four rockers with the top rocker switching the relay and the other rockers being usable for scenes... Maybe you'll be able find out more when you receive the switch you've ordered. Anyway, thank you so much for taking the time to look into the issue! |
|
I thought one of the advantages of zigbee would be some kind of "back channel" compared to cheaper 433 mhz relays.
Well, this is something that ZigBee does have, so there’s two possibilities - one is that I’m not configuring the switch correctly, or the other is that the switch doesn’t support this. The switch is responding to both the Bind and ConfigureReporting commands, so I think it supports them. I do see something a bit strange with the response, so I’ll check this to make sure I’m not sending something wrong.
Do you think polling could work to update the relay state in OH, even if the state update wouldn't be immediate?
Yes - I can add this - the device is reporting when polled so it will work.
Another route might be the switch attached to the relay. I'm still a bit puzzled by those. I was expecting the switches to be discoverable as separate zigbee devices (just like the battery powered switch), but they're not showing up in the inbox.
The inbox will show devices - so 1 physical device = 1 thing. If there is separate functions to a device, these will then be shown as separate channels.
This device has 2 endpoints - I’m not currently handling the client clusters and these are on the second endpoint so we should be able to look at these as well. Give me a day or two to look at this as it will require a small amount more work.
Maybe you'll be able find out more when you receive the switch you've ordered.
That arrived this morning, but unfortunately it’s not so useful as it seems likely it only speaks ZLL - I need to find more time to play with that though. I have some other devices that might do a similar thing so I might power up one of them.
Anyway, thank you so much for taking the time to look into the issue!
You’re welcome - and thanks for the debugging…
I will look at a few more things and will get back to you...
|
|
Great, so there's still hope :)
One note about the battery powered switch. You should be able to "pair" it with a ZLL device like a HUE bulb. |
Always (well, for now ;) ). I've found a small bug, but it only confirms that the device is responding correctly to the ConfigureReporting command and the above is incorrectly displayed - it doesn't change anything though...
Yep, I know that, but that's not what I wanted to do (but thanks). That said, if I can do this with a Hue bulb, and use the remote to control the bulb, it might help debug the reporting... I'll try this out... |
|
If you get a chance, please give this version a try. It will hopefully give you another switch channel (switch out) - it probably won't do anything, but if it sends any commands (or anything!!) when you click the switch, I'd be interested to see the log... Thanks. |
|
Thanks for the update Chris, I gave it a quick try. However, I accidentally made an interesting discovery reverting to the snapshot version. I even double checked to make sure I wasn't fooled by item persistence:
So on OH startup the relay/item state seems to be initialized correctly? |
|
Ok, thanks for testing - I’ll tae another look at this.
Yes - it will show correct status on status. As mentioned earlier the polling was working in the log - the binding polls on initialisation so that it knows the status.
|
|
I got my ands, and ors mixed up which is why it reduced the channels rather than adding them. I’ll update and provide a new test shortly...
|
|
Here's another version to test... Again, I don't expect it to work - you should get an extra channel this time I hope and I'd be interested to see what the log shows (if anything) when you click the buttons. |
|
Thanks Chris, and sorry for the late reply. I got caught up at the office today... The new test version was quite a success, but maybe not as expected :) As I've mentioned I have two relays installed, one with a 1-channel switch attached and one with a 2-channel switch. I created some dummy switch items and started pressing buttons. I think the switches which are turning the relay on/off didn't do anything, but maybe you can take a look at However, the second channel on the 2-channel switch definitely does something: It didn't change the state of the switch item attached to the chanel, but it is obviously sending messages 👍 |
|
Thanks - this is roughly what I expected (although I’ve not thought through the issue about the 2 button switch). I was expecting to see this response below though, so that’s good. I’ll try and take a better look at this tomorrow and work out what’s next.
Thanks.
… On 5 Dec 2017, at 20:24, weakfl ***@***.***> wrote:
Thanks Chris, and sorry for the late reply. I got caught up at the office today...
The new test version was quite a success, but maybe not as expected :)
As I've mentioned I have two relays installed, one with a 1-channel switch attached and one with a 2-channel switch.
The 1-channel relay got one new channel, the 2-channel relay got two(!). All are Switch (out) channels.
I created some dummy switch items and started pressing buttons. I think the switches which are turning the relay on/off didn't do anything, but maybe you can take a look at
this log <https://github.com/openhab/org.openhab.binding.zigbee/files/1532771/zigbee_debug_05122017_2118.log.zip> to make sure. There were some TelegesisReceiveMessageEvents, but I think they were unrelated.
However, the second chanel on the 2-channel switch definitely does something:
1:06:50.021 [DEBUG] [egesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 52 58 3A 37 39 36 43 2C 30 31 30 34 2C 30 31 2C 30 42 2C 30 30 30 36 2C 30 33 3A 11 D9 01 2C 2D 33 38 2C 46 46
21:06:50.035 [DEBUG] [egesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=31084, profileId=260, destinationEp=1, sourceEp=11, clusterId=6, messageData=11 D9 01, rssi=-56, lqi=255]
21:06:50.049 [DEBUG] [ongle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=31084, profileId=260, destinationEp=1, sourceEp=11, clusterId=6, messageData=11 D9 01, rssi=-56, lqi=255]
21:06:50.063 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=31084/11, destinationAddress=0/1, profile=0104, cluster=6, addressMode=null, radius=0, sequence=0, payload=11 D9 01]
21:06:50.075 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=CLUSTER_SPECIFIC_COMMAND, manufacturerSpecific=false, direction=CLIENT_TO_SERVER, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=217, commandId=1]
21:06:50.088 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: OnCommand [On/Off: 31084/11 -> 0/1, cluster=0006, TID=D9]
21:06:52.540 [DEBUG] [egesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 52 58 3A 37 39 36 43 2C 30 31 30 34 2C 30 31 2C 30 42 2C 30 30 30 36 2C 30 33 3A 11 DA 00 2C 2D 34 31 2C 46 46
21:06:52.551 [DEBUG] [egesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=31084, profileId=260, destinationEp=1, sourceEp=11, clusterId=6, messageData=11 DA 00, rssi=-65, lqi=255]
21:06:52.562 [DEBUG] [ongle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=31084, profileId=260, destinationEp=1, sourceEp=11, clusterId=6, messageData=11 DA 00, rssi=-65, lqi=255]
21:06:52.573 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=31084/11, destinationAddress=0/1, profile=0104, cluster=6, addressMode=null, radius=0, sequence=0, payload=11 DA 00]
21:06:52.582 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=CLUSTER_SPECIFIC_COMMAND, manufacturerSpecific=false, direction=CLIENT_TO_SERVER, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=218, commandId=0]
21:06:52.589 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: OffCommand [On/Off: 31084/11 -> 0/1, cluster=0006, TID=DA]
It didn't change the state of the switch item attached to the chanel, but it is obviously sending messages 👍
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ3zCQrSMdXzbzRThsTjuUZ4VrHB8ks5s9aaagaJpZM4Qzpso>.
|
Well, the relay was reporting two channels before you introduced channel consolidation (on/off + level). After consolidation on/off was gone and only the level channel was left. Now both channels are back :)
Yep, the second button on the switch with no load is now working, nice work. Already controlling the terrace awning with it ;) EDIT:
|
Strange - so there is an on/off and a dimmer channel? I'll try and set up one a device here that might allow me to test at least a bit. |
Yep. We've talked about this, my guess is that BJ is using the same firmware for the simple and the dimmable relays, maybe with some minor modifications. It doesn't make much sense, both channels are just switching the relay on and off. Btw, I've ordered one of the dimmable relays too. I guess it should work out of the box, but I'll let you know. |
|
Yep - I’m just surprised that the channel consolidation in the binding has allowed both the switch and the dimmer.
Btw, I've ordered one of the dimmable relays too. I guess it should work out of the box, but I'll let you know.
Let’s see ;) I suspect it might be the same...
|
Maybe it hasn't and the additional on/off channel(s) I'm seeing are from the client (the attached button)? |
|
There’s only 1 channel converter though - this one converter handles both the client and server. It shouldn’t matter therefore which cluster caused it to be created (client or server)...
… On 21 Jan 2018, at 21:34, weakfl ***@***.***> wrote:
I’m just surprised that the channel consolidation in the binding has allowed both the switch and the dimmer.
Maybe it hasn't and the additional on/off channel(s) I'm seeing are from the client (the attached button)?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ_K_WVpoaEK0dv_2cxQDKGVEtoDBks5tM61kgaJpZM4Qzpso>.
|
|
I'm having trouble with the battery-powered switch, I can't get it to join anymore, or at least it doesn't show up in the Inbox. Could you please take a look at the log Chris? I have no idea what's going on :( EDIT: Is it possible the coordinator thinks the device is still part of the network and doesn't add it to the inbox? Is it possible to remove a device manually? |
|
The issue here is solved with this change (zsmartsystems/com.zsmartsystems.zigbee#189 <zsmartsystems/com.zsmartsystems.zigbee#189>), but I’m not 100% sure it’s in the latest version of the binding. The Telegesis driver wasn’t processing messages from the dongle that are reporting new devices so sometimes (like this log) it’s not detecting the new device through some of the other mechanisms. I’ll check tonight that this is in the binding.
|
|
Thanks Chris. I've tried version 2.3.0.201801232258 of the binding, but the switch is still not added to the Inbox. Here's a log: zigbee_issue49_20180124095420.log.zip |
|
The device seems to join multiple times, so it keeps changing network address. I don't know why it's doing this - I might check with Silabs. |
|
Yep. I've noticed that the switch is also communicating with the other routers (relays) in the network, but didn't know if that's normal. |
|
The parent is always the same, so I don't think that is the issue. The binding isn't handling the changing of the address this quick - it's changing faster than it is running the discovery (every 7 seconds)... |
|
You are right, it still is getting a new network address every few seconds: Out of curiosity, why does the coordinator assign a new network address for the same mac address? |
|
Good question. I would have expected it would reuse the same address if it reconnects to the same parent. For me though this in itself isnt the issue - it seems to me that possibly the join isn't completing each time so it is restarting.
As a matter of interest, can you tell me what the device is? I know you've probably told me previously it we've looked at a few topics on this issue now ;)
…Sent from my iPhone
On 24 Jan 2018, at 14:06, weakfl ***@***.***> wrote:
You are right, it still is still getting a new network address every few seconds:
zigbee_issue49_20180124144039.log.zip
Out of curiosity, why does the coordinator assign a new network address for the same mac address?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
It's a 6735 battery powered transmitter. I think you have one of these yourself? |
|
Btw, I‘ve added and removed the switch multiple times with previous versions, so I‘m not sure why it doesn‘t work anymore. |
|
Can you reset the switch completely? I wonder if it's not leaving the network and the coordinator is getting confused or something. In theory, when you delete the thing, the binding ought to send a leave command to the device, but I've noticed recently that it doesn't always respond to that... |
|
I've always reset the switch before trying to add it. What I could try is resetting the coordinator and start from scratch. Let me know if I should try that. |
|
Worth a try if you like - it would be interesting to see if it changes anything. |
|
I tried to start from scratch, but that didn't work out the way i was hoping :) Now the relays are not found either. The behaviour is the same, they're permanently getting a new network address. I made a backup but didn't consider that the relays would be removed from the network when deleting them in PaperUI... |
|
Removing the coordinator and adding it back again did the trick. All devices were found immediately, even the Tradfri from #93 |
Just to be clear, what do you mean by this? Did you reset the coordinator and add the thing back in? Devices do have a maximum number of children they can handle directly - I think they will not allow joining if they are out of "slots", and the joining device would then be expected to join via another router. I personally wouldn't have expected to see what we saw here though where it seemingly joins, then rejoins... I opened a ticket with Silabs yesterday so let's see what they say. |
I removed the coordinator thing in OH and added it back. The only noticeable change was the channel, which was 28 before removing the coordinator and "auto" after adding it again (I never changed the channel, no idea why it was 28).
I only have 4 devices in the network. From what I've read other users have far more than that. |
|
I've opened PR #116 in case you want to add the BJ devices to the readme. All fully working now. |
|
@cdjackson I've meanwhile got confirmation from the deCONZ developers that they have the same problem with the BJ dimmers/relays and it doesn't look like BJ will provide a firmware that fixes the issue (device not sending reports on dimmer/relay state change). So it looks like the only workaround would be to make the polling/report interval configurable. If it's ok with you I'd close this issue and open a feature request? |
|
Thanks for the feedback - yes, let's close and open an enhancement request. |
As discussed in the community thread, the state of the Busch-Jaeger 6711 U relay does not get updated in OH if the physical switch is used to change its state.
Here's the requested log:
oh_zigbee_binding_debug.log.zip
I've also changed the state of the relay to on/off twice. First time via OH, second time via the physical switch, should be at the end of the log.
The text was updated successfully, but these errors were encountered: