Zigbee, Trafri, Fyrtur, Obscura

hcardwell · May 30, 2022, 5:29pm

This is pretty obscure, and is really only just barely an OpenHAB thing. Posting here in case someone can help.

TLDR: Cannot seem to get Tradfri Remote Zigbee bind targets working using the OpenHAB Zigbee binding.

Some coarse info:

OpenHAB 3.2.0-1 via package on Ubuntu 20.04
Zigbee via native binding and Nortek HUSBZB-1 (EM3581)
Ember coordinator
IKEA Fyrtur blind working great via the OpenHAB Zigbee binding
IKEA Tradfri Blind Remote

Long post for some useful information I did not see elsewhere in my extensive Google / forum reading. Skip down to Problem for where I got stuck.

Early last year I added a few IKEA Fyrtur blinds in my house, which was technically my first foray into Zigbee devices. I have historically homogenized on Z-Wave for all home automation stuff where possible, using the zwave binding. I originally was using the IKEA Tradfri Gateway and connecting it to OpenHAB via the Tradfri Binding.

My Tradfri Gateway (probably just a bad unit) became decreasingly stable over the 1+ year it was in-use. It got bad enough that I put it behind a Z-Wave outlet and wrote a rule in OpenHAB to bounce it when it went offline. Since the remotes still controlled the blinds even with the gateway offline fixing it was not a super high priority.

Recently I decided to move all the blinds and remotes over to OpenHAB’s direct control, removing the IKEA Gateway / Coordinator from the mix. There were two paths to doing this as I understood it. One using Zigbee2MQTT to operate the Zigbee network, accessed from OpenHAB through the MQTT binding. The other using the native Zigbee binding. I went the native Zigbee binding route.

Getting the blinds to join and be controllable was an adventure of its own. I had upgraded my HUSBZB-1 to firmware 6.7.8.0 via this project. With that firmware I had recurring issues with the devices going offline. I eventually found and upgraded the stick to 6.7.10.0 via the firmware on this site. I performed the upgrade directly with the Zigbee binding from the firmware here:

openhab> zigbee firmware /tmp/NCP_USW_EM3581_6710-57k6-W.ebl

With that done, the blinds, remote, and repeater from the Fyrtur package join the network fine and stay online.

Skipping a few steps (and I can elaborate for those trying to replicate that success in the thread if desired), I got to the point of wanting to configuring the Tradfri Remote to directly talk to the blind. The basics of this are outlined in the zigbee2mqtt here.

My Problem:
I cannot seem to get the equivalent to that process to work via zigbee commands on the OpenHAB console, and I do not understand the errors.

The Zigbee binding sees the devices just fine:

  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

When freshly admitted to the network. the default bindtable for the remote device had the coordinator for all his bindings:

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

I have edited the table to set the blind as the bind target for those three clusters:

zigbee bind 0008 43252/1 60576/1
zigbee bind 0006 43252/1 60576/1
zigbee bind 0001 43252/1 60576/1
zigbee unbind 0008 43252/1 
zigbee unbind 0006 43252/1 
zigbee unbind 0001 43252/1

The remote is firmware version 2.2.010, which according to the Zigbee2MQTT docs only supports address targets, not group targets.

After making the change, the remote is still not directly controlling the blinds. In debug mode, the OpenHAB console reports this when events are generated from the device when I press up or down on it:

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

2022-05-29 21:57:28.052 [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=01], messageTag=00, status=EMBER_SUCCESS, messageContents=]
2022-05-29 21:57:28.053 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX STA: msgTag=00 state=RX_ACK
2022-05-29 21:57:28.054 [DEBUG] [transaction.ZigBeeTransactionManager] - notifyTransactionProgress: TID=00, state=RX_ACK, outstanding=0

So it looks like it sends out a broadcast, but the payload is empty?

Lastly, it seems like the remote has client cluster support for 0102 but that cluster is not usable with the zigbee bind command. That might not be a thing, but it made me scratch my head. Some partial output from the ‘zigbee endpoint 43252/1’ command:

Output Clusters   : (Client)
   0003 Identify
     - APS Security disabled
   0004 Groups
     - APS Security disabled
   0006 On/Off
     - APS Security disabled
   0008 Level Control
     - APS Security disabled
   0019 Ota Upgrade
     - APS Security disabled
        S       0 r-- IEEE_ADDRESS              Upgrade Server ID
        S       1 r-- UNSIGNED_32_BIT_INTEGER   File Offset
        S       2 r-- UNSIGNED_32_BIT_INTEGER   Current File Version                     Sun May 29 21:33:27 EDT 2022 570492465
        S       3 r-- UNSIGNED_16_BIT_INTEGER   Current ZigBee Stack Version
        S       4 r-- UNSIGNED_32_BIT_INTEGER   Downloaded File Version
        S       5 r-- UNSIGNED_16_BIT_INTEGER   Downloaded ZigBee Stack Version
        S       6 r-- ENUMERATION_8_BIT         Image Upgrade Status
        S       7 r-- UNSIGNED_16_BIT_INTEGER   Manufacturer ID
        S       8 r-- UNSIGNED_16_BIT_INTEGER   Image Type ID
        S       9 r-- UNSIGNED_16_BIT_INTEGER   Minimum Block Request Period
        S      10 r-- UNSIGNED_32_BIT_INTEGER   Image Stamp
   0102 Window Covering
     - APS Security disabled
   1000
     - APS Security disabled

It is worth noting that what the remote presents as channels to OpenHAB is also really strange, and no changes are ever noted when I create Items tied to the channels. I do not actually care about that, but it came as some surprise.

Sorry for the War and Peace volume of text here. I have spent most of the weekend trying to get this to behave. I am extremely close to what I wanted originally (blind control via OpenHAB works great) with the remote also sending commands to the blinds. I can see the commands supported through the binding easily enough:

openhab> zigbee cmdsupported 43252/1 0006
Supported generated commands for client cluster On/Off (0006)
CommandId  Command
       0  OffCommand
       1  OnCommand
       2  ToggleCommand

Supported received commands for client cluster On/Off (0006)
CommandId  Command

I just cannot seem to get them mapped to a binding target on the blind, presumably to destination cluster 0102? Or are commands only sent between “like” clusters?

Thanks for reading and for any suggestions.

smitopher · May 30, 2022, 7:02pm

I curious, what do 6.7.10 and perhaps 7.0.1 offer? 7.0.1 Release notes
I’m fat, dumb, and happy on 6.7.8

smitopher · May 30, 2022, 7:13pm

@chris
Would you upgrade a HUSBZB-1 to 7.0.1?

hcardwell · May 30, 2022, 7:37pm

I will confess I did not realize there was a 7.x build for this chipset. Having said that, it does not appear to be a problem with the USB stick. The commands for manipulating the bind table on the remote are working. I am also pretty sure they’re working correctly since I have to “wake” the remote device when I am apply the changes and viewing them, per-command.

It looks like something potentially incomplete in the Zigbee SDK (com.zsmartsystems.zigbee) that the openHAB binding uses that is implemented in the underlying SDK that Zigbee2MQTT uses (herdsman). But that is speculation on my part based on a potentially-incomplete understanding.

But, for example, in OpenHAB there appears to be no way to specify a group target for an “openhab:zigbee bind” command–just an address. Where as the MQTT front-end talking through herdsman allows it.

Additionally, as you can see in the DEBUG log above, the remote is transmitting to cluster group 0102–but when I attempt to use any bind commands using that cluster group, the OpenHAB Zigbee binding reports that cluster is not found on the device. But it is listed in the dump later in my post.

Thanks for the input though. I’ll have a look around for a 7.0.1 firmware build for this chipset.

chris · May 31, 2022, 4:20am

I’m not sure I have a lot of suggestions, but it should be possible to bind your client cluster in the remote, to the server cluster in the device. I’ve recently been configuring my system here to do exactly that (not with Ikea equipment, but with Schneider light switches) and it worked fine using the console.

If the devices have both client and server on the same endpoint, that might be an issue. You can use “in:123” or “out:123” to select one or the other specifically.

Yes, you can only bind like clusters - ie a device can only send an ON command from the OnOffCluster client, and this will be received by the OnOffCluster server (or vice versa). You can’t send a level control command to an onoff cluster.

chris · May 31, 2022, 4:21am

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.

chris · May 31, 2022, 4:28am

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.

hcardwell · May 31, 2022, 11:23pm

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

chris · June 1, 2022, 3:38am

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

hcardwell · June 1, 2022, 12:16pm

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.

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

chris · June 1, 2022, 7:22pm

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

hcardwell · June 1, 2022, 8:45pm

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

hcardwell · June 1, 2022, 11:53pm

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

chris · June 2, 2022, 12:25am

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

chris · June 2, 2022, 12:32am

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

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).

hcardwell · June 2, 2022, 12:45am

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

hcardwell · June 8, 2022, 6:38pm

@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

chris · June 8, 2022, 8:32pm

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 .

hcardwell · June 11, 2022, 3:49pm

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.

chris · June 11, 2022, 7:29pm

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.