zigbee4java
zigbee4java copied to clipboard
tlaukkan
Support for ZigBee LightLink profile
- Single CC2531 flashed with the latest Z-Stack Home firmware.
- Started up successfully in Zigbee Console, using the zigbee4java default channel / panID.
- ZigBee LED light (Ti ZLight2 RGB) with unknown configuration.
Is there any way to detect and pair with this light, without first knowing its MAC address? I can put the device in pairing mode (it blinks to indicate) but issuing 'listen' on the zigbee4java console never produces a result.
Do I need to re-flash the CC2531 with Packet Sniffing firmware and use Ti RF Studio software to packet sniff and first retrieve the MAC Address of my light devices (I have several)? Even if so, is there another way? How would this work on a large scale ZigBee installation - it seems unwieldy if all MAC addresses need to be known ahead of time. If possible, shouldn't some deeper scanning and pairing functionality be included in zigbee4java?
Thanks, I have been unable to do any testing until now because of my lack of knowledge on the above. I have ordered a second CC2531 as advised by the documentation.
Hi
@chris-hatton
It sounds like your light might be working according to ZigBee LightLink -profile as it has pairing mode where you bring devices close to controller and pair them by pushing pairing button. In case of home automation there is no proximity pairing on the specification level as far as I know.
However the HomeAutomation controller and devices may have buttons controlling whether their firmware will initiate and respond to joining to network.
If your light devices support HomeAutomation profile you need to check whether they are security enabled by default or if they support both secure and not secure networking. The controller has to be in security enabled mode of they device requires that and vice versa.
Finally at least my Philips Hue Bulbs required using of correct channel (11) for them to join the network after which I could switch the entire network to different channel and the bulbs followed. So you may need to check which is the channel the devices listen by default.
After these things are in order your devices should join the network automatically when you switch them on when they are in the range of the controller or other networked devices able to relay messages. As said earlier the lights may have buttons for example which you need to press to enable them to join the network. Having a sniffer will make it easier to follow what is happening.
If your lamps are only supporting LightLink profile you will need LightLink profile controller. zigbee4java currently supports only HomeAutomation profile. If you would in this case consider expanding zigbee4java support to LightLink your mileage may vary. zigbee4java should have pretty much the required serial interface commands and clusters implemented but profile is hardcoded to be HomeAutomation in outbound messages. I know that at least earlier TI firmware building projects container support for LL profile but whether ready firmware like for HA profile exists I do not know. The catch with LL profile is that it has shared secret key used in the pairing and this key is shared only with certified LL device manufacturers. If someone has more knowledge on the LL profile and TI please share.
Best regards, Tommi
@chris-hatton
Oh and should you go the LightLink way I would be interested to join you in this quest as I have some LL profile lights as well.
Br, Tommi
@tlaukkan
Moi Tommi,
Thanks for your helpful explanation.
Having gained some new knowledge of the difference between HA and ZLL profiles; I remembered one of the three Z-Stack Home firmware flavours was called '-Secure-LinkKeyJoin'. That sounds rather like a description of ZLLs commissioning... So I tried it, and it worked!
I used the LinkKeyJoin firmware and performed a button press on both the CC2531 dongle and ZLL device. The device registration data appeared in ZigBee Console - the ZLL device had been commissioned.
I was then able to repeatedly turn the light on and off, and change its colour. However after attempting the link procedure again, I hit a limitation of zigbee4java. The light stopped working, and I think I see why:
It is observable that either the dongle or zigbee4java persists information about known devices; because even when I powered off (unplugged) both the dongle and light, and re-ran zigbee4java, the light was still shown by 'list' after powering on only the dongle. When I try to re-commission the light with the touch-link procedure, zigbee4java hits a NotImplementedException at the point where the dongle reports the device join, this time with a new, different address. It seems zigbee4java is missing implementation to update the address for a known device, it just halts, and so never re-establishes a network route for commanding the device. I remain unable to control the light!
Sorry if the above is vague. I am going to investigate and, once clearer on the details, hope to come back with proposed fix for devices which change their address: something which seems quite legal for a ZLL device.
In conclusion it is great news that Ti have integrated 'TouchLink' commissioning into the Z-Stack firmware. This will provide a basis for much closer interoperability between HA/ZLL devices. It may not be too difficult to take full advantage of this in zigbee4java.
Great news!
I did not expect that things would work out so well without code changes. For now you can try to delete network.json before startup in the console directory which should rediscover the network for you. In the case of address update of node we can either consider removing and readding the node or updating the node data in zigbee4java network model.
-Tommi
Just to let you know guys, the ZLL spec allows you to also "Classically Join" which means a ZLL bulb can classically join a HA network without having to touchlink.
Just a quick introduction, I work for NXP ZigBee department and I am going to start integrating the NXP JN516x into a branch. Hopefully this will give me a quick understanding with the code and i can start to help out with the profiles and clusters.
@chris-hatton I read that all ZLL devices must be compatible with HA standard too. I haven't looked specifically at the Zlight firmware but with the Zstack home it will work with or without the link key. I know zigbee4java also works when the short address changes, so I'm not sure where you get NotImplementedException.
I have noticed that some devices only scan the primary channels 11,15,20,25. These channels are also chosen to have less WiFi interference so it's good to use one of these.
Another thing is that for joining you should have the device close to the coordinator, something like < 2 meters. One joined you can move it further away.
@d1g2w3 That is very interesting adding support from NXP. I have not used your ZigBee ICs but I have read your documentation and it looks very good. The zigbee4java is designed around the TI Ztool interface, so this will need to be replaced with the NXP interface.
Just to let you also know that the way zigbee is going into a combined ZHA ZLL called lighting and occupancy (ZLO).
Integration with ZLL is probably of interest to the project.
Kind regards
Danny Watson On 22 Mar 2015 16:01, "presslab-us" [email protected] wrote:
@chris-hatton https://github.com/chris-hatton I read that all ZLL devices must be compatible with HA standard too. I haven't looked specifically at the Zlight firmware but with the Zstack home it will work with or without the link key. I know zigbee4java also works when the short address changes, so I'm not sure where you get NotImplementedException.
I have noticed that some devices only scan the primary channels 11,15,20,25. These channels are also chosen to have less WiFi interference so it's good to use one of these.
Another thing is that for joining you should have the device close to the coordinator, something like < 2 meters. One joined you can move it further away.
@d1g2w3 https://github.com/d1g2w3 That is very interesting adding support from NXP. I have not used your ZigBee ICs but I have read your documentation and it looks very good. The zigbee4java is designed around the TI Ztool interface, so this will need to be replaced with the NXP interface.
— Reply to this email directly or view it on GitHub https://github.com/tlaukkan/zigbee4java/issues/21#issuecomment-84626373.
Welcome Danny
We are looking forward to your work with JN516x integration. I am curious, what kind of integration interface does JN516x have? Would be great if you can link the specification.
Best regards, Tommi Laukkanen
Hi Tommi,
Its the same interface as the TI serial device but likely to be a different protocol baud rate etc.
The application note is located here http://www.nxp.com/documents/application_note/JN-AN-1194.zip We have just done a press release for a new JN5169 chip which will also support a new control bridge (ZigBee device). The only thing i'm not sure of is if it supports none coordinator mode (it should, if not the application note can be modified and added as a resource on here).
It shouldn't be too difficult apart from adding an interface pattern (if it isn't already coded like that) to both devices.
Kind Regards,
Danny Watson
On 22 March 2015 at 20:30, Tommi S.E. Laukkanen [email protected] wrote:
Welcome Danny
We are looking forward to your work with JN516x integration. I am curious, what kind of integration interface does JN516x have? Would be great if you can link the specification.
Best regards, Tommi Laukkanen
— Reply to this email directly or view it on GitHub https://github.com/tlaukkan/zigbee4java/issues/21#issuecomment-84694871.
@chris-hatton @tlaukkan After updating to the latest master I too am seeing the NotImplementedException when the device changes the short address.
07:43:05 671 WARN The device #25305 (00:12:4B:00:04:12:6A:56) has been found again with a new network address 46097 sun.reflect.generics.reflectiveObjects.NotImplementedException at org.bubblecloud.zigbee.network.discovery.EndpointBuilder.changedNetworkAddress(EndpointBuilder.java:234) at org.bubblecloud.zigbee.network.discovery.EndpointBuilder.inspectNode(EndpointBuilder.java:209) at org.bubblecloud.zigbee.network.discovery.EndpointBuilder.inspectNewEndpoint(EndpointBuilder.java:248) at org.bubblecloud.zigbee.network.discovery.EndpointBuilder.run(EndpointBuilder.java:311) at java.lang.Thread.run(Thread.java:745)
Just wanted to mention I fixed the NotImplementedException here: https://github.com/tlaukkan/zigbee4java/commit/247dd8404ef818e6ebf3023bdf406745d22dbe80
I'am looking for an alternative to the Hue Bridge an I saw that this lib seams to be implemented in OpenHAB. So I did some tests if the library is able to control my hue lights. I've reset some of my Hue bulbs using a living colors remote (By pressing the on and scene 1 button) and tried to add them using the gateway-server example. Here are my results:
- I successfully paired one of my newer Hue bulbs and was able to control them. (The bulb had to be very near the TI usb stick)
- I also have a few older LivingColors lights, but I wasn't able to pair them. I think those lights doesn't support the network join. (The Hue bridge also doesn't see them even if they are reset) On my Hue bridge I was able to add them using a LivingColors remote. (I had to pair all hue lights to the remote, reset the bridge using the remote and then pair the remote with the bridge) Will something like this also be possible with this library?
- I also have a few Hue Tap switches, but I wasn't able to add them. (When adding the switches to the Hue bridge I have to press the big button for 10 seconds) Is it possible to add those switches somehow using the library? If no one has such a device I could provide a pcap file containing the packets from one of my switches.
