Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Zigbee Information
I watched the XCTU video. It looks pretty comprehensive and should be quite useful as a spelunking tool.
Dean Roddey
Explorans limites defectum
Good luck exploring!

I didn't get my other Zigbee development devices, but I did make further progress on the XBEE.

I can validate the XBEE will be able to send (and force) a device bind to a remote endpoint (a prerequisite to attribute reporting). In addition, I've been able to remotely configure attribute reporting on the DoorLock so it will notify me of lockstate event changes (instead of polling it).

Obviously a lot more work is/would be required for a production quality integration, but very very promising that all the critical pieces are working with XBEE.
So you don't need a master controller to implement those types of bindings, i.e. any module can ask that any other module report to it?
Dean Roddey
Explorans limites defectum
Here is what I know:

1) Device binding can be done through a process or done direct. The scenario where you'd want a more "negotiated" binding process is the Light Switch / Light Bulb example. Both of these devices can be on the Zigbee network, but offer to bind independently of any centralized controller (Switch->Bulb). In this case, an endpoint to endpoint relationship can be established. (If you're not aware of the convention endpoint vs device - suggest you catch up. A device "Light switch" could have many endpoints, which are separate than the clusters. )

To support a "negotiated" binding process, there is some coordination involved on both devices binding, but I haven't read it into detail to speak to involvement of the coordinator.

In addition to coordinated binding, you can establish bindings more directly by issuing a bind command. As far as I can tell (sections of the spec I've read and what I interpret), you can have a third party device (controller if you want to call it) establish all the bindings between devices. So, with the light switch and bulb example, you could write a utility/device to send all the necessary binding commands to third party associate light switch and bulb.

2) Binding will add the association to endpoints to share relationships of which clusters are shared within the network. What I'm not certain about (as I haven't tested it), if you can establish reporting configuration from a third party device/endpoint. The ZCL payload to configure reporting does not provide a source/destination. So it either works one of two ways:

A) When you send a configure reporting to the endpoint, provide a direction (either send the report or expect to receive), the endpoint will utilize the endpoint address that came from the endpoint that sent the command.

B) When you send a configure reporting to the endpoint, provide a direction, the endpoint will utilize the local binding table to determine who the reports should go to.

I'll have a few more development/test devices coming in to validate this, but if I had to guess, I'd expect it acts more like option B.

Finally, all of my commands have originated from the Zigbee network coordinator. I don't know if the coordinator has more "permission" to issue bindings, but I haven't crossed any language in the Zigbee documentation stating it's a requirement.
I think it's probably a given that we'd have to deal with situations where the XBee guy is not the coordinator, it's just providing an on ramp to the Zigbee network for the automation system, but something else owns the network.

But it would be VERY nice if the automation system, in such situations, could figure out and execute the necessary binding commands to insure that everything out there reports to him what he needs in order to stay up to date, and not require the user to do it via some other device that's the actual coordinator.

I've done enough reading to grok the endpoint vs. device thing. You can see where Z-Wave, when they split off from Zigbee, more or less took that concept and created the 'command class' concept from it, i.e. a given device can contain a motion sensor, temp sensor and humidity sensor. Each of them are separately addressable 'sub-devices', so they correspond roughly to end points.

Unfortunately, I guess in their desire to simplify, they excluded the possibility of more than one instance of a particular type of 'end point' in a device. Later, they added a work around for that, but by that time lots of multi-devices already existed. And code that doesn't understand that new scheme so even new devices have failed to use it. This causes no end of stupidity when trying to do a Z-Wave driver.

Zigbee has clearly done a better job on that, with all end points being numbered and separately identifiable by the automation system. So you always know what incoming messages are targeting.
Dean Roddey
Explorans limites defectum
I'm in complete agreement with your first statement. I'll test this once I get all my devices in and report back.

1) My DIO to ZigBee DoorLockController works great. I can use any relay type device to lock/unlock ZigBee door locks. Really great for interfacing with legacy systems to manage door locks in the house. I have it working with one door lock, have two more on order. Will eventually scale this out to support 6 locks at my house and control via an access control system.

2) Still waiting on an order for a Home Automation kit from Silicon Labs. I have another development kit from them but loading the HA 1.2 firmware isn't as easy as I thought. Silicon labs built in a license key for the firmware. Once I get my officially licensed kit, I'll see if I can transfer the license over to the 3 additional development boards I have.

3) Contemplating buying the Ember development kit to get access to firmware programmer and HA library. Hasn't been a requirement, but would definitely allow some slick/rapid integration without building out all the code like XBEE.

Moving slower than I wanted to as I found out my pool controller went dead. Great excuse for installing an Hayward Omnilogic. Will probably work on this next and integrate into CQC.

Very busy weekend. Two more locks showed, my Raspberry PiFace Digital 2 arrived, and had to get it all working.

1) Had to extend and merge various online C# / Windows 10 implementations of Raspberry PiFace to support individual pins and interrupt notifications.
2) Enabled multiple lock support on my code. Found library issues with the Microsoft Zigbee code (sequence numbers weren't being calculated correctly and received collisions)
3) Other gremlins/ghosts that caused Visual Studio Debugger to detach / stop for no reason. Thought this was related to some multithreading/async stuff I was doing - but not the case....

Finally worked through the issues and was able to use the PiFace buttons (1-4) to trigger lock/unlock events and update the Output/LED on PiFace to show if locked/unlocked (on locked, off unlocked).

Next up:
Buy 3 more door locks, buy two zigbee routers (I have a feeling I'll hit an issue here with the zigbee code I'm using), and convert some of the variables/settings to XML.

Long term:
Build a mini web server to allow remote configuration and other zigbee activities in real time (Add locks, remove locks, discover endpoints, manage pins, etc.)
Was any progress made towards a ZigBee driver using the XBee USB adapters? I have two of these the older and newer adapter and there's also the CID USB from SmartenIT that has direct AT serial access to the coordinator to make integration easier.

Having ZigBee would be great as there are many devices that are only available for ZigBee with either no z-wave counterpart or very bad one's (Line Voltage Thermostats being one big one) and there's a lot of ZigBee sensors that are very high quality and ZigBee sensors are just FASTER than Z-wave as well.
Zigbee is a big problem, because it's a huge chicken and egg. It would be a huge effort to support, but there's so little stuff out there to justify it. And, since there's not much support, there's less justification to make the devices.

It's made worse by the fact that Zigbee, as it has been, was very disjoint wrt to home automation, and there's a new scheme available now but very few devices that support it. Anyone starting these days it would only make sense to support the new scheme, but there again, that would be just as big an effort and even fewer devices to justify it.
Dean Roddey
Explorans limites defectum

Possibly Related Threads…
Thread Author Replies Views Last Post
  XM Radio Channel Information Driver Jonathan 168 43,730 09-16-2013, 04:20 PM
Last Post: DaveB
  Zigbee RCS Thermo Driver Dean Roddey 14 5,090 06-10-2013, 09:07 PM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)