Ah, thanks! I was looking under “cdjackson” on github, but didn’t think as far as to look for a “zsmartsystems” org 
I am still figuring out the CC2531 device and ZLL/ZHA protocols and I wrote a Python interface to control Trådfri bulbs and started looking at Xiaomi Mi sensors just to learn how it works, but then I found your code a much nicer starting point for experimenting now that I understand the basics of the ZNP stack.
@chris Does the Zigbee binding (Linear HUSBZB-1) work with any of these?
Found an old post for the IRIS sensor.
@chris I don’t know if you received my messages. Can you provide the firmware for the EM358 USB Stick somewhere?
Dear Chris
Thank you for the continuing to update the zigbee binding much appreciated.
I have downloaded your latest release (1/Sept/2017) and imported it into my development environment. It is quite obvious that you have made significant enhancements from the initial release and it is now much quicker to discover the dongle and zigbee devices. (So by the way I have solved my dongle reset problem mentioned to you a few months ago – needed to undock and dock the dongle every time I start openhab – by using a 1k5 pull up resistor attached to 3.3V and D+ at the dongle.)
The previous version successfully discovered all my develco devices
However the latest version discovers devices 1 and 2 above but do not discover the ZHWR202. Using the Paper UI and looking at the properties of the dongle after a few minutes of operation, I noticed that the ZHWR202 devices are present in the zigbee_neighbors table. Still they never appear in the inbox, even if I reset them to factory mode, and allow them to rejoin the network.
To discover what is happening with communication to these devices I enabled com.zsmartsystems.zigbee logging and analyzed the log.
The ZHWR202 responds as follows:
• TX CMD: IeeeAddressRequest [0/0 -> 49858/0, cluster=0001, TID=5D, nwkAddrOfInterest=49858, requestType=1, startIndex=0]
• RX CMD: IeeeAddressResponse [49858/0 -> 0/0, cluster=8001, TID=NULL, status=SUCCESS, ieeeAddrRemoteDev=0015BC001D0245AB, nwkAddrRemoteDev=49858, numAssocDev=0, startIndex=null, nwkAddrAssocDevList=[]]
• TX CMD: NodeDescriptorRequest [0/0 -> 49858/0, cluster=0002, TID=5E, nwkAddrOfInterest=49858]
• RX CMD: NodeDescriptorResponse [49858/0 -> 0/0, cluster=8002, TID=NULL, status=NOT_SUPPORTED, nwkAddrOfInterest=null, nodeDescriptor=null]
• (repetition removed)
• 49858: Discovery request NODE_DESCRIPTOR failed. Wait before retry.
• 49858: Ending node discovery
Thus it appears that the device does not successfully complete the discovery process and fails on the second ZDO node descriptor request.
I have analyzed the Technical manual for the ZHWR202 and it indicates the following with regards to ZigBee Device Object (ZDO)
• Application profile Id 0x0000
• Application device Id 0x0000
• Supports all mandatory clusters.
I have to assume that the device is working according to the ZIGBEE SPECIFICATION. Do you have any suggestions how we can make these devices work with your binding??
I can’t figure out how to add devices using your code. I must have missed something fundamental here. I even tried the command-line version (ZigBeeConsoleMain). I run it using the arguments CC2531 /dev/cu.usbmodem1421 230400 16 0 0 00000000000000000000000000000000 true and then use “join enable” to enable network inclusion, but I fail to include any devices. I tried the following devices:
IKEA Trådfri Remote
IKEA Trådfri E27 Bulb
Xiaomi Mi Temp/Pressure/Humidity sensor.
When using zigbee4java, device inclusion works (command line java -jar ./legacy-modules/zigbee-console-javase/target/zigbee-console-javase-3.1.0-SNAPSHOT.jar /dev/cu.usbmodem1421 16 0 true)
Output from zigbee4java:
ZigBee API permit join enable ... [OK]
> 23:00:45 189 INFO Device announcement received - Network Address: #5919, IEEE Address: 00:15:8D:00:01:A3:66:62
Node added: 00:15:8D:00:01:A3:66:62 (#5919)
> 23:00:45 190 WARN Created node object for #5919 (00:15:8D:00:01:A3:66:62) that was not available on the network
23:00:45 935 INFO Device announcement received - Network Address: #5919, IEEE Address: 00:15:8D:00:01:A3:66:62
23:00:45 936 INFO Device announcement received - Network Address: #5919, IEEE Address: 00:15:8D:00:01:A3:66:62
Device added: 00:15:8D:00:01:A3:66:62/1 (#5919)
Node discovered: 00:15:8D:00:01:A3:66:62 (#5919)
> 23:01:01 451 WARN Unknown command ID: 0x45c9
23:01:04 384 INFO Device announcement received - Network Address: #5919, IEEE Address: 00:15:8D:00:01:A3:66:62
23:01:04 384 INFO Device announcement received - Network Address: #5919, IEEE Address: 00:15:8D:00:01:A3:66:62
23:01:04 830 INFO Device announcement received - Network Address: #5919, IEEE Address: 00:15:8D:00:01:A3:66:62
> list
0) 00:15:8D:00:01:A3:66:62/1 [56765] : Thermostat
However, the Trådfri remote fails (I did not yet investigate why, and I am not that interested in getting zigbee4java running as I prefer to use with your code instead)
> 23:09:08 139 WARN ZDO_NODE_DESC_REQ FAILED on #35312 (00:0B:57:FF:FE:23:75:85)
23:09:15 487 INFO Device announcement received - Network Address: #56765, IEEE Address: 00:15:8D:00:01:A3:66:62
23:09:15 487 INFO Device announcement received - Network Address: #56765, IEEE Address: 00:15:8D:00:01:A3:66:62
23:09:16 038 INFO Device announcement received - Network Address: #56765, IEEE Address: 00:15:8D:00:01:A3:66:62
23:09:16 150 WARN ZDO_POWER_DESC_REQ FAILED on #35312 (00:0B:57:FF:FE:23:75:85)
23:09:34 437 WARN ZDO_ACTIVE_EP_REQ FAILED on #35312 (00:0B:57:FF:FE:23:75:85)
23:09:34 438 WARN Node #35312 (00:0B:57:FF:FE:23:75:85) removed from network because no endpoints have been discovered
After including from zigbee4java, I seem to get ZigbeeConsoleMain to see the devices (if I don’t reset), e.g.
23:13:05.556 DEBUG RX CMD: IeeeAddressResponse [2106/0 -> 0/0, cluster=8001, TID=NULL, status=UNKNOWN, ieeeAddrRemoteDev=null, nwkAddrRemoteDev=null, numAssocDev=null, startIndex=null, nwkAddrAssocDevList=[]]
23:13:12.027 DEBUG <-- AF_INCOMING_MSG (FE 1C 44 81 00 00 02 04 3A 08 01 01 00 8D 00 67 82 00 00 00 08 18 0C 0A 00 00 29 18 0B 3A 08 1D 86)
23:13:12.027 DEBUG Received Async Cmd: Packet: subsystem=null, length=28, apiId=44 81, data=FE 1C 44 81 00 00 02 04 3A 08 01 01 00 8D 00 67 82 00 00 00 08 18 0C 0A 00 00 29 18 0B 3A 08 1D 86, checksum=86, error=false
23:13:12.113 DEBUG RX CMD: ReportAttributesCommand [Temperature measurement: 2106/1 -> 0/1, cluster=0402, TID=0C, reports=[Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=2840]]
23:13:12.113 DEBUG <-- AF_INCOMING_MSG (FE 1C 44 81 00 00 05 04 3A 08 01 01 00 8D 00 74 82 00 00 00 08 18 0D 0A 00 00 21 8C 1E 3A 08 1D 1A)
23:13:12.114 DEBUG Received Async Cmd: Packet: subsystem=null, length=28, apiId=44 81, data=FE 1C 44 81 00 00 05 04 3A 08 01 01 00 8D 00 74 82 00 00 00 08 18 0D 0A 00 00 21 8C 1E 3A 08 1D 1A, checksum=1A, error=false
23:13:12.114 DEBUG RX CMD: ReportAttributesCommand [Relative humidity measurement: 2106/1 -> 0/1, cluster=0405, TID=0D, reports=[Attribute Report: attributeDataType=UNSIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=7820]]
23:13:12.115 DEBUG <-- AF_INCOMING_MSG (FE 25 44 81 00 00 03 04 3A 08 01 01 00 8D 00 7F 82 00 00 00 11 18 0E 0A 00 00 29 E3 03 14 00 28 FF 10 00 29 DE 26 3A 08 1D 4C)
23:13:12.115 DEBUG Received Async Cmd: Packet: subsystem=null, length=37, apiId=44 81, data=FE 25 44 81 00 00 03 04 3A 08 01 01 00 8D 00 7F 82 00 00 00 11 18 0E 0A 00 00 29 E3 03 14 00 28 FF 10 00 29 DE 26 3A 08 1D 4C, checksum=4C, error=false
23:13:12.115 DEBUG RX CMD: ReportAttributesCommand [Pressure measurement: 2106/1 -> 0/1, cluster=0403, TID=0E, reports=[Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=995, Attribute Report: attributeDataType=SIGNED_8_BIT_INTEGER, attributeIdentifier=20, attributeValue=-1, Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=16, attributeValue=9950]]
23:13:14.237 DEBUG Ieee Address for 2106 returned null
But I can’t get inclusion to work. The only output that I see is:
> join enable
23:17:02.045 DEBUG Permit join for 255 seconds.
23:17:02.046 DEBUG TX CMD: ManagementPermitJoiningRequest [0/0 -> 65532/0, cluster=0036, TID=12, permitDuration=255, tcSignificance=true]
23:17:02.046 DEBUG -> AF_DATA_REQUEST (Packet: subsystem=null, length=13, apiId=24 01, data=FE 0D 24 01 FC FF 00 00 36 00 12 30 1F 03 00 FF 01 DD, checksum=DD, error=false)
23:17:02.056 DEBUG <- AF_DATA_SRSP (FE 01 64 01 00 64)
Permit join enable broadcast success.
>
In comparison, zigbee4java does this:
join enable
DEBUG ZigBeeApi - Sending permit join with data: -1
DEBUG ZigBeeApi - Sending permit join with data: -1
DEBUG CommandInterfaceImpl - -> ZDO_MGMT_PERMIT_JOIN_REQ (Packet: length = 5, apiId = 0x25 0x36, full data = 0xfe 0x05 0x25 0x36 0x0f 0xfc 0xff 0xff 0x01 0xe4, checksum = 0xe4, error = false, errorMessage = null)
DEBUG CommandInterfaceImpl - -> ZDO_MGMT_PERMIT_JOIN_REQ (Packet: length = 5, apiId = 0x25 0x36, full data = 0xfe 0x05 0x25 0x36 0x0f 0xfc 0xff 0xff 0x01 0xe4, checksum = 0xe4, error = false, errorMessage = null)
DEBUG CommandInterfaceImpl - <- ZDO_MGMT_PERMIT_JOIN_REQ_SRSP ([254, 1, 101, 54, 0, 82])
DEBUG CommandInterfaceImpl - <- ZDO_MGMT_PERMIT_JOIN_REQ_SRSP ([254, 1, 101, 54, 0, 82])
DEBUG CommandInterfaceImpl - <-- ZDO_MGMT_PERMIT_JOIN_RSP ([254, 3, 69, 182, 0, 0, 0, 240])
DEBUG CommandInterfaceImpl - <-- ZDO_MGMT_PERMIT_JOIN_RSP ([254, 3, 69, 182, 0, 0, 0, 240])
DEBUG CommandInterfaceImpl - -> ZDO_MGMT_PERMIT_JOIN_REQ (Packet: length = 5, apiId = 0x25 0x36, full data = 0xfe 0x05 0x25 0x36 0x02 0x00 0x00 0xff 0x01 0xea, checksum = 0xea, error = false, errorMessage = null)
DEBUG CommandInterfaceImpl - -> ZDO_MGMT_PERMIT_JOIN_REQ (Packet: length = 5, apiId = 0x25 0x36, full data = 0xfe 0x05 0x25 0x36 0x02 0x00 0x00 0xff 0x01 0xea, checksum = 0xea, error = false, errorMessage = null)
DEBUG CommandInterfaceImpl - <-- ZDO_MGMT_PERMIT_JOIN_RSP ([254, 3, 69, 182, 0, 0, 0, 240])
DEBUG CommandInterfaceImpl - <-- ZDO_MGMT_PERMIT_JOIN_RSP ([254, 3, 69, 182, 0, 0, 0, 240])
DEBUG CommandInterfaceImpl - <- ZDO_MGMT_PERMIT_JOIN_REQ_SRSP ([254, 1, 101, 54, 0, 82])
DEBUG CommandInterfaceImpl - <- ZDO_MGMT_PERMIT_JOIN_REQ_SRSP ([254, 1, 101, 54, 0, 82])
ZigBee API permit join enable ... [OK]
> DEBUG CommandInterfaceImpl - <-- ZDO_MGMT_PERMIT_JOIN_RSP ([254, 3, 69, 182, 0, 0, 0, 240])
DEBUG CommandInterfaceImpl - <-- ZDO_MGMT_PERMIT_JOIN_RSP ([254, 3, 69, 182, 0, 0, 0, 240])
DEBUG CommandInterfaceImpl - <-- ZDO_MGMT_PERMIT_JOIN_RSP ([254, 3, 69, 182, 0, 0, 0, 240])
DEBUG CommandInterfaceImpl - <-- ZDO_MGMT_PERMIT_JOIN_RSP ([254, 3, 69, 182, 0, 0, 0, 240])
I probably fail to understand some difference between the two programs. @chris Could you please spot some obvious error that I am making?
To get Ikea products to work you need to use the firmware named “CC2531ZNP-Pro-Secure_LinkKeyJoin.hex” for CC2531 due to it seems to not be fully compliant with ZLL. There is new firmwares out that should fix this but products out there are probably still based on their old firmware! (https://www.smarthomegeeks.co.uk/news/ikea-tradfri-hue-work-together-now/)
To joint the remote i…
//Mattias
Ah, the two libraries might of course expect different firmwares, and the serial API might be different between the two. I will try the other one when I have the opportunity.
Actually, I have not gotten a single Zigbee device to join, either from openHAB or using the command line tool. But my understanding of the ZNP protocol is too weak to understand why one tool uses ZDO commands to enable network join and the other uses AF commands. Maybe the two firmwares expect two different approaches?
Note that my end goal is not to control IKEA stuff right now, I just wanted to test using the various Zigbee devices I had available.
No - the API is the same, although the way it works is different…
The two methods should result in the same thing - one just uses the internal ZNP API rather than the standard ZDO API. In my experience/testing, it resulted in exactly the same thing being sent OTA. The advantage of using ZDO rather than ZNP (ie the TI specific API) is that ZDO commands are universal - so it works exactly the same with TI as with Silabs or other stacks. This in turn means we can support different dongles (ie the CC2530, Ember, Conbee…).
By using the AF ZNP API I can send all commands the same and this is the same then as the other dongles (and it’s just more standard Zigbee use rather than using the TI specific commands).
Looking at the logs one thing that comes to mind with the inclusion is that TC Significance in my library is set to 1 - this is a requirement in ZB3 but maybe ZB4J might have used 0 and maybe the bulbs don’t like this? You could try changing this if you have the source compiling yourself to see if it matters.
@chris I tried to a pair a Samsung Smart thing motion sensor to the Ember (Linear) usb controller. It came up as unknown zigbee device. In the things menu, it shows a channel for temperature (sensor_temperature). How can i get a channel for motion?
Habmin shows:
Thank you for the input. Now I understand how the two methods differ. It also helps reading the Z-stack source code, where I can see that the zigbee4java ZDO call results in MT_ZdoMgmtPermitJoinRequest being called, which results in an AF_DATA_REQUEST being sent as you write. One difference, I don’t know if it is significant, is that the Z-stack sends the data to the device’s local address before the destination address if it’s a broadcast.
I think zigbee4java uses 1 for TC significance by looking at the packet dump (it’s the last 0x01 byte if I understand things correctly). Nevertheless I tried changing to false in ZigBeeNetworkManager.permitJoin, but the result was the same.
I will dig more into the source code when I have some time to spare for hacking, but with two kids at home that time presents itself rarely these days 
Update: I emulated what I thought I saw in Z-stack by issuing “join enable 0”, “join enable”, and now I get some progress:
Xiaomi sensor:
> 22:54:41.589 DEBUG <-- AF_INCOMING_MSG (FE 1C 44 81 00 00 02 04 7C 77 01 01 00 BA 00 4B FE 2E 00 00 08 18 10 0A 00 00 29 60 0A 7C 77 1D AA)
22:54:41.589 DEBUG Received Async Cmd: Packet: subsystem=null, length=28, apiId=44 81, data=FE 1C 44 81 00 00 02 04 7C 77 01 01 00 BA 00 4B FE 2E 00 00 08 18 10 0A 00 00 29 60 0A 7C 77 1D AA, checksum=AA, error=false
22:54:41.590 DEBUG RX CMD: ReportAttributesCommand [Temperature measurement: 30588/1 -> 0/1, cluster=0402, TID=10, reports=[Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=2656]]
22:54:41.590 DEBUG <-- AF_INCOMING_MSG (FE 1C 44 81 00 00 05 04 7C 77 01 01 00 BA 00 58 FE 2E 00 00 08 18 11 0A 00 00 21 C8 15 7C 77 1D 00)
22:54:41.591 DEBUG Received Async Cmd: Packet: subsystem=null, length=28, apiId=44 81, data=FE 1C 44 81 00 00 05 04 7C 77 01 01 00 BA 00 58 FE 2E 00 00 08 18 11 0A 00 00 21 C8 15 7C 77 1D 00, checksum=00, error=false
22:54:41.591 DEBUG RX CMD: ReportAttributesCommand [Relative humidity measurement: 30588/1 -> 0/1, cluster=0405, TID=11, reports=[Attribute Report: attributeDataType=UNSIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=5576]]
22:54:41.592 DEBUG <-- AF_INCOMING_MSG (FE 25 44 81 00 00 03 04 7C 77 01 01 00 BA 00 63 FE 2E 00 00 11 18 12 0A 00 00 29 D8 03 14 00 28 FF 10 00 29 75 26 7C 77 1D B9)
22:54:41.592 DEBUG Received Async Cmd: Packet: subsystem=null, length=37, apiId=44 81, data=FE 25 44 81 00 00 03 04 7C 77 01 01 00 BA 00 63 FE 2E 00 00 11 18 12 0A 00 00 29 D8 03 14 00 28 FF 10 00 29 75 26 7C 77 1D B9, checksum=B9, error=false
22:54:41.592 DEBUG RX CMD: ReportAttributesCommand [Pressure measurement: 30588/1 -> 0/1, cluster=0403, TID=12, reports=[Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=984, Attribute Report: attributeDataType=SIGNED_8_BIT_INTEGER, attributeIdentifier=20, attributeValue=-1, Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=16, attributeValue=9845]]
22:54:41.834 DEBUG Ieee Address for 30588 returned null
22:54:41.835 DEBUG 30588: Discovery request IEEE_ADDRESS failed. Wait before retry.
The Trådfri remote control seems to be added successfully now.
22:56:50.641 DEBUG 26105/1: Setting cluster BASIC as server
22:56:50.642 DEBUG 26105/1: Setting cluster POWER_CONFIGURATION as server
22:56:50.643 DEBUG 26105/1: Setting cluster IDENTIFY as server
22:56:50.643 DEBUG 26105/1: Setting cluster ALARMS as server
22:56:50.643 DEBUG 26105/1: Unsupported cluster 2821
22:56:50.643 DEBUG 26105/1: Unsupported cluster 4096
22:56:50.643 DEBUG 26105/1: Setting output clusters [3, 4, 5, 6, 8, 25, 4096]
22:56:50.643 DEBUG 26105/1: Setting cluster GROUPS as client
22:56:50.644 DEBUG 26105/1: Setting cluster SCENES as client
22:56:50.644 DEBUG 26105/1: Setting cluster ON_OFF as client
22:56:50.644 DEBUG 26105/1: Setting cluster LEVEL_CONTROL as client
22:56:50.645 DEBUG 26105/1: Unsupported cluster 25
22:56:50.645 DEBUG 26105/1: Unsupported cluster 4096
Device added:
26105/1 000B57FFFE237585 <label>
22:56:50.653 INFO ZigBee saving network state done.
22:56:50.654 DEBUG 000B57FFFE237585: Node 26105 is added to the network
Node Added IEEE=000B57FFFE237585, NWK=65F9, Type=END_DEVICE
22:56:50.662 INFO ZigBee saving network state done.
> devicelist
26105/1 000B57FFFE237585 <label>
0/1 00124B0009EB0DF4 <label>
Update 2: I emulated the above by choosing “Tools>Enable Join” (which sends permitJoin on address 0 it seems) and then quickly starting ZigBee discovery (which sends it to the broadcast address). This enabled me to get one device joined. I have, however, not been successful on a second attempt. The command line tool works well now though, even if the Xiaomi sensor seems not to be fully discovered (maybe the cheap china stuff is not fully compliant from reading earlier posts?). I am running the latest git master of everything including OpenHAB.
As discused elsewhere, this is correct - the device has a temperature sensor.
Currently I haven’t handled motion sensors but I will look to add this in the coming days.
But isn’t this just the same as sending join enable. The first command disables join, and the second one enables it?
This sends join enable to whatever device you are controlling - if it’s the coordinator, then it will be address 0. If you use the normal discovery, it sends it as a broadcast to all routers, but it’s otherwise the same method that is called.
Hello to all,
I am using zigbee binding with TI dongle and it works great for hue lights and sylvania bulbs.
I have gotten of one the Philips RWL020 dimmer/switch remotes. OpenHAB detects it and adds thing with two items: one dimmer one switch. However, when you click buttons, values in Openhab do not switch. You can just change values through openhab.
Is it currently not supported? If not, is there a plan to support these in near future?
Thanks,
Tadey
If I understand it correctly, the first command enables join on network address 0, the second one enables join in the broadcast address. This is what z-stack does as I understand it (check the ZDP_MgmtPermitJoinReq function in ZDProfile.c).
Yes - so isn’t this the same? It should be. The broadcast is sent to address 0 (it must be as that’s physically connected) and the broadcast address is “all routers”. In my experience this should result in join being enabled in the coordinator - certainly it does for every device I’ve tested here.
Yes - that’s correct… But again, this is exactly what happens in the binding when you enable discovery. I don’t understand why you need to use the specific enable to address 0 - zb4j doesn’t do this - this is a function I added specifically for a customer who wanted to enable join for specific devices only.
To be clear, you mean click the physical buttons on the device, right? Not click the UI buttons in OH?
No, and Yes…
In fact, it should work - I did add code to try to configure this, but I’m aware it wasn’t always successful. Battery devices are especially problematic in ZigBee (IMHO anyway). I do need to look at this again…
I may have misunderstood something, as I only spent an hour of two with the source code. But as I read it, zb4j uses the ZDO function which in the TI firmware sends the data packet both to the local address and the broadcast address. I was just guessing the firmware might not consider broadcasts on the loopback, but I am not sure what goes on here. Your command line tool works if I do “join enable 0” first. The firmware version is 2.7.0 IIRC.
Do you have a reference to where this is documented?
If I look at the ZDP_MgmtPermitJoinReq() documentation, it simply states that it is a macro to send the message - it takes the address as an argument, so if we were to set the address to the router bdcst address, then it should only send it to this address right? It shouldn’t send to address 0, or some other address that it decides?
It does seem very strange since the coordinator definately should respond to the broadcast address and from my testing both on TI and SL chips, it does (since they should both implement a compliant ZDO, they should be the same!).
These commands SHOULD work the same as if they are sent OTA - so if what you are saying is correct, then the TI firmware won’t respond if I send a broadcast to it OTA? I would find that hard to believe (I’m not saying you’re wrong - just trying to understand 
).
Maybe it’s a firmware issue? For me, it worked fine with the TI firmware with join enable - I never needed to do this hack with all the testing we did and clearly others here also have this working without doing this so there must be something different with your system I think?
The code is the documentation In Z-Stack 3.0.1, the source for ZDP_MgmtPermitJoinReq is Components\stack\zdo\ZDProfile.c:
afStatus_t ZDP_MgmtPermitJoinReq( zAddrType_t *dstAddr, byte duration,
byte TcSignificance, byte SecurityEnable )
{
(void)SecurityEnable; // Intentionally unreferenced parameter
// Build buffer
ZDP_TmpBuf[ZDP_MGMT_PERMIT_JOIN_REQ_DURATION] = duration;
ZDP_TmpBuf[ZDP_MGMT_PERMIT_JOIN_REQ_TC_SIG] = TcSignificance;
// Check of this is a broadcast message
if ( (dstAddr) && ((dstAddr->addrMode == Addr16Bit) || (dstAddr->addrMode == AddrBroadcast))
&& ((dstAddr->addr.shortAddr == NWK_BROADCAST_SHORTADDR_DEVALL)
|| (dstAddr->addr.shortAddr == NWK_BROADCAST_SHORTADDR_DEVZCZR)
|| (dstAddr->addr.shortAddr == NWK_BROADCAST_SHORTADDR_DEVRXON)) )
{
// Send this to our self as well as broadcast to network
zAddrType_t tmpAddr;
tmpAddr.addrMode = Addr16Bit;
tmpAddr.addr.shortAddr = NLME_GetShortAddr();
fillAndSend( &ZDP_TransID, &tmpAddr, Mgmt_Permit_Join_req,
ZDP_MGMT_PERMIT_JOIN_REQ_SIZE );
}
// Send the message
return fillAndSend( &ZDP_TransID, dstAddr, Mgmt_Permit_Join_req,
ZDP_MGMT_PERMIT_JOIN_REQ_SIZE );
}
Sounds likely. I will flash a different firmware and try again. I know I have two versions of the CC2531ZNP-Pro-Secure firmware (2.6.2 and 2.7.1) (EDIT: Double-checked the version numbers, and see below). I just assumed 2.7 was “better” than 2.6
Interesting. I’ve found something on the TI forum that also agrees with this -:
Be aware that (surprisingly for me) this doesn’t set your own PJ. I found i need to also unicast it to myself.
This is a bit strange, but I don’t think there’s any major problem with adding this to the code so I will take a look at doing this and try to confirm it doesn’t cause problems with other dongles.
I don’t have the source of ZNP installed - can you tell me what AddrBroadcast is defined as?
Cheers
Chris