Zigbee, Trafri, Fyrtur, Obscura

Not at the moment. There have been quite a few problems with the latest firmware from Silabs so I’ve been avoiding it until now. I do have a client that wants to use this though so am going to have to compile up an NCP to test so I may have more information soon.

In general though I don’t see a great need at the moment to change from a recent 6.x version.

If I understand correctly you are simply trying to bind from one device to another. That doesn’t really use the ZSS library - other than to configure the binding.

Of course, it’s always possible there’s a bug, but this exact code (with different devices) is used a lot in commercial systems (and zigbee certified systems).

Please can you provide a short summary of what you are trying to do, then the console output as you do it - and also please use the zigbee bindtable command to view the table at each step as it’s not possible from the information you provide in your initial post to see the results of each step after you ran the bind and unbind commands.

My apologies, and thank you again for helping me with another weird issue.

Big picture objective: have the IKEA remote linked in my OP control 1 or more blinds even if the coordinator is offline. I know this works, because the Tradfri gateway configures them to do just that.

As I understand it, I need to configuring the bindtable on the remote to send updates directly to the blind. Before I cleared it, the bind table on the remote had three entries, all with the OpenHAB coordinator as the destination. The clusters were 0001, 0006, and 0008. Strange, but okay.

My nodelist reiterated for awareness:

openhab> zigbee nodes
Total known nodes in network: 4
Network  Addr  IEEE Address      Logical Type  State      EP   Profile                    Device Type                Manufacturer     Model  
      0  0000  000D6F0017207B20  COORDINATOR   ONLINE
  14202  377A  804B50FFFE807FEE  ROUTER        ONLINE      1  ZIGBEE_HOME_AUTOMATION     RANGE_EXTENDER             IKEA of Sweden   TRADFRI Signal Repeater
                                                         242  ZIGBEE_GREEN_POWER         0061                                                
  43252  A8F4  804B50FFFE241D2D  END_DEVICE    ONLINE      1  ZIGBEE_HOME_AUTOMATION     WINDOW_COVERING_CONTROLLER  IKEA of Sweden   TRADFRI open/close remote
  60576  ECA0  804B50FFFE095D6C  END_DEVICE    ONLINE      1  ZIGBEE_HOME_AUTOMATION     WINDOW_COVERING_DEVICE     IKEA of Sweden   FYRTUR block-out roller blind

As you can see, this Zigbee setup is literally my POC for the Fyrtur setup without the Tradfri Gateway and I have nothing else involved.

Starting this post, bindtable for the remote is thus, from my fiddling:

openhab> zigbee bindtable 804B50FFFE241D2D
Binding table for node 43252 [804B50FFFE241D2D]
Src Address          | Dest Address         | Group | Mode    | Cluster
804B50FFFE241D2D/1   | 804B50FFFE095D6C/1   |       | Address | 0006:ON_OFF

Decoded, Src is the REMOTE and Dest is the BLIND, for the ON_OFF cluster. This does nothing. Which is somewhat expected. I can paste in the results if you wish, but I have retained the output from “zigbee fingerprint” from both the remote and the blind. And I can see that the blind does not have cluster 0006 (ON/OFF) as a “Server [Input]” cluster.

My understanding is that I need to use cluster 0102 “Window Covering” for this control communication, as that appears to be the only cluster that is in the input list on the blind and the output list (again, from “endpoint” or “node”, also pasted in below) on the remote.

So I remove my incorrect entry from the bindtable on the remote:

openhab> zigbee unbind 0006 43252/1 60576/1
Success response received.

openhab> zigbee bindtable 804B50FFFE241D2D
Binding table for node 43252 [804B50FFFE241D2D]
--- Empty

openhab>

So far, so good. Now the bind table for the remote is empty. So now I should be adding that binding on cluster 0102, since it’s listed in the endpoint as being output from the remote:

openhab> zigbee bind 0102 43252/1 60576/1
Error: Exception during command execution (IllegalArgumentException): A cluster specified by 0102 is not found for endpoint 1
openhab>

If I tell it to use “out:0102” I get the same error:

openhab> zigbee bind out:0102 43252/1 60576/1
Error: Exception during command execution (IllegalArgumentException): A cluster specified by out:0102 is not found for endpoint 1

But when I examine 43252/1 (which is the remote), I get this:

openhab> zigbee node 804B50FFFE241D2D
IEEE Address     : 804B50FFFE241D2D
Network Address  : 43252
Node Descriptor  : NodeDescriptor [apsFlags=0, bufferSize=82, complexDescriptorAvailable=false, manufacturerCode=117C, logicalType=END_DEVICE, serverCapabilities=[], incomingTransferSize=82, outgoingTransferSize=82, userDescriptorAvailable=false, frequencyBands=[FREQ_2400_MHZ], macCapabilities=[REDUCED_FUNCTION_DEVICE], extendedEndpointListAvailable=false, extendedSimpleDescriptorListAvailable=false, stackCompliance=22]
Power Descriptor : PowerDescriptor [currentPowerMode=RECEIVER_ON_IDLE, availablePowerSources=[MAINS], currentPowerSource=MAINS, powerLevel=FULL]
Associations     : []
Endpoints        :
            1    : Profile     ZIGBEE_HOME_AUTOMATION
                 : Device Type WINDOW_COVERING_CONTROLLER
                   -> BASIC
                   -> POWER_CONFIGURATION
                   -> IDENTIFY
                   -> ALARMS
                   -> POLL_CONTROL
                   -> 0x1000
                   -> 0xFC7C
                   <- IDENTIFY
                   <- GROUPS
                   <- ON_OFF
                   <- LEVEL_CONTROL
                   <- OTA_UPGRADE
                   <- WINDOW_COVERING
                   <- 0x1000
Neighbors        :
Routes           :

Clearly shows WINDOW_COVERING as an “out” in his profile. Same sort of thing is shown with more verbosity from the fingerprint command.

For symmetry, here’s the blind:

openhab> zigbee node 804B50FFFE095D6C
IEEE Address     : 804B50FFFE095D6C
Network Address  : 60576
Node Descriptor  : NodeDescriptor [apsFlags=0, bufferSize=82, complexDescriptorAvailable=false, manufacturerCode=117C, logicalType=END_DEVICE, serverCapabilities=[], incomingTransferSize=82, outgoingTransferSize=82, userDescriptorAvailable=false, frequencyBands=[FREQ_2400_MHZ], macCapabilities=[REDUCED_FUNCTION_DEVICE], extendedEndpointListAvailable=false, extendedSimpleDescriptorListAvailable=false, stackCompliance=22]
Power Descriptor : PowerDescriptor [currentPowerMode=RECEIVER_ON_IDLE, availablePowerSources=[MAINS], currentPowerSource=MAINS, powerLevel=FULL]
Associations     : []
Endpoints        :
            1    : Profile     ZIGBEE_HOME_AUTOMATION
                 : Device Type WINDOW_COVERING_DEVICE
                   -> BASIC
                   -> POWER_CONFIGURATION
                   -> IDENTIFY
                   -> GROUPS
                   -> SCENES
                   -> POLL_CONTROL
                   -> WINDOW_COVERING
                   -> 0x1000
                   -> 0xFC7C
                   <- OTA_UPGRADE
                   <- 0x1000
Neighbors        :
Routes           :

It clearly has WINDOW_COVERING (which is 0102) as an input.

Maybe I am dumb, but why does the command not let me insert it into the bind table?

Does that help provide clarification? Am I doing it backwards and I should be manipulating the bind table on the blind rather than the remote? I assume the device that needs to transmit the message is what is needed to be changed.

Ninja edit. I don’t understand why several commands (fingerprint, endpoint, node) all show the 0102 cluster on both devices, and yet:

openhab> zigbee attsupported 43252/1 0102
Error: Exception during command execution (IllegalArgumentException): A cluster specified by 0102 is not found for endpoint 1
openhab> zigbee attsupported 60576/1 0102
Error: Exception during command execution (IllegalArgumentException): A cluster specified by 0102 is not found for endpoint 1
openhab> zigbee cmdsupported 43252/1 0102
Error: Exception during command execution (IllegalArgumentException): A cluster specified by 0102 is not found for endpoint 1
openhab> zigbee cmdsupported 60576/1 0102
Error: Exception during command execution (IllegalArgumentException): A cluster specified by 0102 is not found for endpoint 1
openhab>

Same flavor of error that stops the bind command from even trying. That’s why I am wondering if there is something broken in the library that implements those console commands, which I thought was not in your code but in com.zsmartsystems.zigbee? Unless that’s also you and I didn’t notice.

Thanks again!

Howard

That’s expected and not so strange. Most people use these to send commands to OH, so this is why this binding is made.

You are not using the correct notation here. 102 is considered a decimal number - the window covering cluster is 258 in decimal, or 0x102 in hexadecimal. so you can use one of the following -:

zigbee bind out:258 43252/1 60576/1
zigbee bind out:0x102 43252/1 60576/1

Yes, that’s also me :slight_smile:

D’oh. To be completely fair to me, there was zero syntactic sugar to indicate that to me, and I was starting from a position of total Zigbee ignorance. Had any of the clusters I had eyeballed contained an [a-f] digit I would surely have noticed. On the up-side, we collectively answered the “am I dumb” question, which I appreciate you not quoting. :neutral_face:

I will dig at this some more, but that actually touches on the other thing I mentioned in my original post. OpenHAB is not getting events from the remote when I create Items for the available Thing channels. I assumed that was something hinky with the remotes and why they were explicitly excluded from the compatibility list in your docs.

I cannot try the bind table change again until I am home this evening since I need to wake the remote for it to accept the bind commands. Though I am eager enough for closure that I might leave work early.

As long as I am abusing your generosity with your time, I have a related question. What is the syntax for bind with a group destination? Newer versions of the IKEA remote (that I have not yet tested) evidently require group targets. Looking at the terse help for the bind command did not provide a clue for that. I briefly fiddled, but I bet there’s a decent chance I made the same mistake and the group ID is hex and I can just specify a destination as 0xd00f where that’s the ID in hexadecimal of the created group rather than an endpoint specification? While the “nodes” command shows both the hex and decimal values the group command does not and it did not occur to me it could be one or the other.

I’ll reply back with what I suspect will be success later this evening. When complete (since I could find no evidence of this being documented) I’ll write up some docs for the end-to-end process to do what I am doing for posterity.

Howard

You’re right. It’s not an issue with Zigbee - just the way the console interprets it.

However there is also a clue in the docs in the console section where it talks about how to define nodes -:

Nodes and endpoints are often required as arguments in commands and can typically be entered in decimal or hexadecimal node number with a decimal endpoint - e.g. 0x1234/1, or 4660/1 - both of these describe the same node/endpoint.

I’ll try and make this clearer though.

What do you mean by this? If you enable debug logging, do you see the events, or there’s absolutely nothing received from the device?

I’d need to check if the device is specifically defined as a static thing type - we’d need to know exactly what the device is and how it identifies itself. The problem with remote controls is they are all different so there needs to be a static definition of how to manage the commands or it won’t work.

Good question. Let me check this. Group support was only added reasonably recently to the ZSmart System library to support a specific gateway. I’ll try and look at this later - if I don’t respond in the next couple of days, ping me :slight_smile:

With your adjustment I completely updated the remote:

openhab> zigbee bindtable 804B50FFFE241D2D
Binding table for node 43252 [804B50FFFE241D2D]
Src Address          | Dest Address         | Group | Mode    | Cluster
804B50FFFE241D2D/1   | 804B50FFFE095D6C/1   |       | Address | 0006:ON_OFF
804B50FFFE241D2D/1   | 804B50FFFE095D6C/1   |       | Address | 0102:WINDOW_COVERING
804B50FFFE241D2D/1   | 804B50FFFE095D6C/1   |       | Address | 0001:POWER_CONFIGURATION
804B50FFFE241D2D/1   | 804B50FFFE095D6C/1   |       | Address | 0008:LEVEL_CONTROL

Even with that setup the blind is still not responding. For the sake of desperation I tried this as well, doing the reverse on the blind:

openhab> zigbee bind in:0x102 60576/1 43252/1
Success response received.

openhab> zigbee bindtable 804B50FFFE095D6C
Binding table for node 60576 [804B50FFFE095D6C]
Src Address          | Dest Address         | Group | Mode    | Cluster
804B50FFFE095D6C/1   | 000D6F0017207B20/1   |       | Address | 0102:WINDOW_COVERING
804B50FFFE095D6C/1   | 000D6F0017207B20/1   |       | Address | 0001:POWER_CONFIGURATION
804B50FFFE095D6C/1   | 804B50FFFE241D2D/1   |       | Address | 0102:WINDOW_COVERING

That did not help and I removed it back out. I realize now I am asking questions about a device rather than the binding, but any additional thoughts? I strongly suspect the very next thing you’re going to say is to get a Zigbee sniffer set up. I have not done that yet. The device notes on the Zigbee2MQTT site for this specific remote say it only actually supports group binding targets, which might explain it still not working… and makes more pertinent my question about that syntax. I will probably move the Zigbee dongle to another box and see if I can instrument what they’re doing to it with their setup.

Yes, debug logs show Zigbee packets (only broadcast though, no unicast at all) but nothing on the Thing/Item side. The remote shows in OpenHAB, Thing Type reports “Generic ZigBee Device”. It did fully enumerate and was in the add UI with the correct name, and “Thing Properties” has “TRADFRI open/close remote” for modelID. Available channels are just a Dimmer and some battery fields. The Dimmer is the useful (?) one and gets no updates when I press things. Items bound to the battery channels get convincing values.

Debug packets from when I had the coordinator in the bind table still:

2022-05-29 21:57:24.922 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspMessageSentHandler [networkId=0, type=EMBER_OUTGOING_BROADCAST, indexOrDestination=FFFF, apsFrame=EmberApsFrame [profileId=0104, clusterId=0102, sourceEndpoint=1, destinationEndpoint=255, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=00], messageTag=00, status=EMBER_SUCCESS, messageContents=]
2022-05-29 21:57:24.923 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX STA: msgTag=00 state=RX_ACK
2022-05-29 21:57:24.924 [DEBUG] [transaction.ZigBeeTransactionManager] - notifyTransactionProgress: TID=00, state=RX_ACK, outstanding=0

That’s pressing “up” on the remote.

Howard

Shame on me. It is actually in the README for the ZSS library.

I tried the documented syntax and the results did not appear to work. It added the bind to the coordinator address instead:

openhab> zigbee group ADD 100 60576/1
Group updated ZigBeeGroup [groupId=100, label=office_blinds, members=[ZigBeeGroupMember [ieeeAddress=804B50FFFE095D6C, endpointId=1]]]

openhab> zigbee bind 0x102 43252/1 #100
Success response received.

openhab> zigbee bindtable 804B50FFFE241D2D
Binding table for node 43252 [804B50FFFE241D2D]
Src Address          | Dest Address         | Group | Mode    | Cluster
804B50FFFE241D2D/1   | 000D6F0017207B20/1   |       | Address | 0102:WINDOW_COVERING

I just had a look at the source and the bind command doesn’t currently support group addresses. If you can, can you raise this as an issue in the ZSS library github repo and I will try and look at this in the near future

If you’ve configured the out cluster from the remote, to the in cluster (0x102) on the blinds, as it seems you have, then I’m going to assume this is the issue. I guess someone wrote that statement for a reason :slight_smile:

I think that’s all we can do now. As above, if you’ve configure the binding correctly (and it seems so) then we have to assume that the remote is sending the command to the blind. A sniffer would only allow us to confirm this, but it must be highly likely.

So this comes back to getting the binding command to work with group addresses. As above, please open a request on the ZSS repo and we can address it there. Most of the code there is auto generated so I need to think about how to support this. I might try and hack something together as a test - there is another (non openHAB) console application in the ZSS repo which we might use for testing (it all exactly the same commands - the command handlers are used in the OH console).

Issue opened as requested. Thanks again for the excellent support and responsiveness.

1 Like

@chris For some closure:

IKEA supports OTA upgrades for the remotes. I used Z2M to upgrade them since it made it one-click-easy. Once upgraded to the current firmware (2.3.079) the remotes correctly support address targets in their bind tables (including multiples).

With the remotes upgraded, I was able to use the ZigBee binding and the “zigbee” console commands you have implemented to achieve the desired result. As threatened above, I will document everything out in the next few days and post it since I could not find all the information in any other single location.

It looks like the reason the old firmware remotes were not sending events to the coordinator is that the old firmware only supported group targets. When joined at least, there was not a valid group containing the coordinator address registered as a valid target on the remotes–I assume because group targets are not supported? So even the outputs of the “zigbee bindtable” command appear to have been misleading on the old firmware.

Again, once upgraded, Items created against IKEA remote Things in OpenHAB correct receive events.

Group support would still be useful, but at least for my immediate needs I got to an alternate solution.

Regards,
Howard

Thanks for the update - also quite interesting and useful information.

I will still look at adding the group support to the console - it won’t get lost as we have the ticket open :slight_smile: .

1 Like

Hopefully my last query on this as I work on my write-up, @chris.

Any idea why the Items show the battery level as 1/2 of the real value? This happens on both the remotes and the blinds themselves and is a total head-scratcher for me.

Reference Item, created and linked to a blind’s battery channel in the GUI. I promose, no dirty .items files for this test.

Real value for that guy:

They all do that. Freshly, completely charged batteries show as 50% charged when I create and link the items.

Am I dumb again? Obviously I can make a map to transform it, but I feel like I am just not understanding something here.

I would guess that the devices are reporting in percent and are therefore non-compliant to the standards. The binding divides the value received from the device by 2, so if it reports in percent (0-100) rather than as per the standards( 0-200) then you’ll get a max value of 50% displayed.

The ability to bind to groups in the console should be implemented soon - it’s now implemented in the libraries, and once the binding is updated to use the new library, it will be available.

2 Likes

Awesome. Thanks! I got the Git notification when you merged it in, and I scanned through it briefly whilst remembering that I do not have a very good relationship with Java. I did post a tutorial of my current implementation here in case someone wants to replicate my success you enabled. I can update it once the group bind capability trickles down to the prod releases of OpenHAB.

Thanks again!

2 Likes

Thanks @hcardwell - I just saw your tutorial and appreciate this a lot :+1:. I might add a link to this in the binding docs so it doesn’t get lost in the forum.

@chris
Anything interesting happen with your testing of firmware?

No - it worked fine, but nothing really to report. The system should generally be ok with versions up to 7.0.x, although the binding now has less ability to change some parameters so things like network size tables will now depend a lot more on how the firmware was configured at compile time.