Subscribing is a smart move!
You can subscribe to this board after you log in or create your free account.
Invite a Co-worker
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
Link copied. Please paste this link to share this article on your social media post.
As discussed in previous article (https://powersolutionscommunity.schneider-electric.com/docs/DOC-2699), we have been so far sending on/off and level control commands from the Can2Go to the ULTI switches and dimmers. At the same time, we have been pulling the current status on a constant basis and synchronized things to avoid conflicts with the commands.
This worked fairly well, however it had two big disadvantages:
1) Response time in the app was not great when switching from the wall to update the status in the app.
2) The Zigbee traffic was pretty heavy as we kept pulling the status all the time.
To solve this problem, the ZCL offers the reporting command. Our Can2Go box provides the Lua.zcl.send_configure_reporting_command function in order to configure the reporting so that every time a change is made on the switch or dimmer, it immediatly let our Can2Go box know.
Easy, you're starting to think: just a function call away!!!! However, it's not that simple! For the reporting to work, you need to bind the devices together so that the "reporter" knows where to send its new status. Note that you can actually bind a switch/dimmer to multiple devices! Unfortunately (and this is where things are starting to get fishy), binding is not done by the ZCL but by the ZDO and currently Can2Go does not offer a way to access the ZDO binding commands. (we've been asking for it though!!) 🙂
In order to do the binding, you will actually need a USB Zigbee device and a small piece of software to do the binding. [beware, this is not for the faint hearted!]. Luckily for us, Schneider Electric do provide a USB Zigbee stick that will just do that (the reference is WHC2_5921).
You will need to plug that on a PC (sorry no Mac or VM success, but it actually runs even on Windows 8.1).
Next, you need to join your USB stick to your zigbee network. Just open up the zigbee network on the Can2Go by checking the "Permit Join Broadcast" and click on Save.
Then on your USB key, you just press the setup button. Two extra comments: if it was already part of a network, you will have to remove it first. Second, it seems that once unplugged from the computer, it seems to lose the zigbee network, so you will have to re-add it.
Final comment, if you have difficulty, you can use Zoolkit to join/leave the zigbee network easily. It's especially practical if you have many zigbee network in your office environment.
Once you've join the network, you will need to use an awesome little app developed internally by the awesome Mark Van den Broeke. (DLL Test App) that gives you a DOS like command line to do pretty much anything on a zigbee network.
Unzip the files and run the exe. (yes, it works on Windows 8.1 too and this comes as is. Do not expect any bug fix, changes...).
First you will need to find out which COM port your zigbee device is attached to. To do that, just do the command: "serial list".
You will get the com port on which your Zigbee USB device is plugged.
Then you need to connect to your device. Just type: "serial open comX" (where comX) is the port that was just listed.
From there, the tool can let you do direct ZCL commands. For example, to use the on/off cluster, you need to connect to the switch doing "zcl addr u <short id> <destination id>".
Then, just use the zcl onoff command; for example "zcl onoff toggle" will toggle the light on and off.
To do the binding, as we said earlier, you need to do a "zdo bind" command. The format is as followed:
zdo bind i <switch short id> <switch extended id> <switch destination id> <cluster id> <can2go extended id> <can2go destination id>
Note that all the parameters are in Hex!!! Let's review them all:
-- switch short id: you can retrieve it by using the zcl.lookup_node_short_id_by_extended_id(<extended id>) method in your Can2Go box. Note that the number returned will be a decimal value so do remember to convert that to hex before using it in our little tool
-- switch extended id: this is the Mac Addr written on the side of your switch (just remove the ":")
-- switch destination id: this is 10 for a single gang switch/dimmer or 10 and 11 for the 2-gang version. Remember to convert that to hex, so it ends up as a and b.
-- cluster id: 6 for the on/off cluster and 8 for the level control (dimming) cluster. Note that for a dimmer you will have to bind both clusters!!!!
-- can2go extended id: this is the extended node id that you can find in the Can2Go zigbee configuration
-- can2go destination id: not exactly sure why, but it should be 3!
And you're done!
Let's recap all the commands for a dimmer:
serial list (to find out which com port to use)
serial open <com port> (to connect to the USB Zigbee dongle)
zdo bind i <switch short id> <switch extended id> <switch destination id> 6 <can2go extended id> 3 (to bind the on/off cluster)
zdo bind i <switch short id> <switch extended id> <switch destination id> 8 <can2go extended id> 3 (to bind the level control cluster)
And it will look just like this:
The hard part is over! Now we only have to run our ZCL commands in lua to specify and configure our reporting command.
For the on/off cluster registration here is an example:
error_code, error_msg = zcl.send_configure_reporting_command(
shortId, -- destination_short_id
extendedId, -- destination_extended_id
destinationEndPoint, -- destination_endpoint
0x0006, -- cluster_id
0x0000, -- attribute_id
0x10, -- attribute_data_type : ZCL_BOOLEAN_ATTRIBUTE_TYPE
0x0000, -- minimum reporting interval
0x0300, -- maximum reporting interval: 5mins
0x01, -- reportable change
0x0104 ) -- application_profile
The comments should be pretty self explanatory and you can refer to the ZCL specification if you need greater details. The only one worth really mentioning is the maximum reporting. If you set it to 0x0000 then the reporting will only happen when a change occurs.
The attribute type needs to match what is specified in the ZCL spec, so 0x10 for the on/off cluster and 0x20 for the dimming.
You're done!
Next will be to integrate this with the script of the previous article and your solution will be complete and solid! We will post that in a future article.
Hope this helps! 😉
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.