Awesome! I did already add 0402 to the inClusters line. And I have a valueTile in the device type. I guess the next step is to put the tile's settings back to temperature. I changed quite a few things with it trying to get the "on" and "off" to display there. Somehow was able to get it to say temperature (the word temperature), on it but I'm not sure what I did there...
This looks really cool! I wanted to use XBees for something like this, but I guess I'll use ZigBees instead so I can use SmartThings devices, instead of having to make everything from scratch.
Okay I have the temperature of one of my Prop / ZigBee devices showing up in SmartThings now. I created a SPIN object for the temperature cluster (0x402) that responds to the read attribute request. I then created a SmartThings Device type that would query the cluster and ask it to send attribute 0x0000 (Current Temperature).
The SPIN object may be a bit cryptic as it is called from a parent object but it should help with the packet syntax. Take look at the ReadAttribute method that is what you will need to incorporate into your code. If your still stuck please let me know I will be happy to post the whole SPIN program. The only reason I didn't is it does a bunch of other stuff not related to Temperature reporting and my confuse people.
I think the SmartThings custom device type may have been tripping you up the most. I think the sample you were working from was not a complete device type. It didn't have any of the poll methods or data conversion. I rewrote it based on other samples and stuff I have put together. Please understand I'm not a JAVA guy so this device type has a long way to go. But it should get you pointed in the right direction.
Here is my SPIN object:
''***********************************************
'' ZCL_Temperature
'' ZigBee Temperature measurement Cluster ID 0x0402 See Page 250 of ZigBee Cluster Library (ZCL)
'' Author: John.Rucker@Solar-Current.com
'' Copyright (c) 2015 Solar-Current.com, Inc.
'' See end of file for terms of use.
''***********************************************
''-----------------REVISION HISTORY-----------------
'' 1 - 1/18/2015 Created by John Rucker
dat
Temperature Word $0000 ' Temperature setting
MaxTemperature Word $0000 ' Max Temperature Value
MinTemperature Word $0000 ' Min Temperature Value
OBJ
zb : "ZigBeeAPI" ' Object is placed here as a stub allowing access to the ZigBeeAPI object.
Pub RouteCmd (zbPktPtr, ReturnBufAdd, MaxReturnBufSize) | frmType, seqNum, cmdID, attributeID
frmType:=seqNum:=cmdID:=attributeID:=0
'***************************************
' Routes execution based on FrmType and CmdID
' zbPktPtr is a the address of a buffer containing the payload of the ZigBee packet to process
' ReturnBufAdd is the address of a byte sized buffer to place the response bytes into
' Return is passed back from called method
'***************************************
frmType := byte[zbPktPtr][0] ' Frame Type is bit 0 and 1 of Byte 0 P14 of ZCL. if cmd = 00 command is defind in table 2.9 P16, if cmd = 01 command is defind in the cluster's cmd list
frmType &= %00000000_00000001 ' Bitwise (&) with a mask to make sure we are looking at last bit
seqNum := byte[zbPktPtr][1] ' Transaction seq number can be any value used in return packet to match a response to a request
cmdID := byte[zbPktPtr][2] ' Command ID Byte P16 of ZCL
byte[@attributeID][0] := byte[zbPktPtr][3] ' Attribute ID Word(little endin) P126 of ZCL
byte[@attributeID][1] := byte[zbPktPtr][4]
if FrmType == 0 ' Command is profile wide command
case CmdID
$00: return ReadAttribute(attributeID, seqNum, ReturnBufAdd, MaxReturnBufSize) ' Read attribute
return FALSE
Pub _Temperature
return Temperature
Pub _MaxTemperature
return MaxTemperature
Pub _MinTemperature
return MinTemperature
Pub SetTemperatue(TempVal)
Temperature := TempVal
if Temperature > MaxTemperature
MaxTemperature := Temperature
if Temperature < MinTemperature
MinTemperature := Temperature
Pub ResetMinMax
MaxTemperature:=MinTemperature:=Temperature
Pri ReadAttribute(Attribute, seqNum, BufAdd, MaxBufSize) | BufSize
'***************************************
' Reads Attribute Number creates response and places it in BufAdd
' Attribute = Attribute to report on
' seqNum = sequence number used in creating response packet
' BufAdd = Pointer to a byte sized buffer to place the response packet in
' MaxBufSize = Maximum Size of buffer
' Returns true if successful false if error
'***************************************
if Attribute == $0000 ' Read MeasuredValued
BufSize := 9 ' BufSize is the size of the response pkt placed inside the BufAdd buffer in bytes
if BufSize > MaxBufSize
return -1
ByteFill(BufAdd, 0 , MaxBufSize) ' Clear Buffer
byte[BufAdd][0] := $18 ' Fame Control $18 = direction is from server to client, disable default response P14 of ZCL
byte[BufAdd][1] := seqNum ' Set the sequence number to match the seq number in requesting packet
byte[BufAdd][2] := $01 ' Command Identifer $01 = Read attribute response see Table 2.9 on page 16 of ZCL
byte[BufAdd][3] := byte[@Attribute][0] ' Attribute Identifier (2 bytes) field being reported see figure 2.24 on page 36 of ZCL
byte[BufAdd][4] := byte[@Attribute][1]
byte[BufAdd][5] := $00 ' Status 00 = Success
byte[BufAdd][6] := $29 ' Attribute Data Type $29 = Signed 16-bit integer, see table 2.16 on page 55 of ZCL
byte[BufAdd][7] := byte[@Temperature][0] ' Set the Temperature as the value to send
byte[BufAdd][8] := byte[@Temperature][1]
zb.TX(zb._PktIEEEAddHi, zb._PktIEEEAddLo, zb._PktNetAdd, zb._PktDEP, zb._PktSEP, zb._PktProfile, zb._PktCluster, bufAdd, BufSize)
return TRUE
return FALSE
Here is the SmartThings custom device type:
metadata {
// Automatically generated. Make future change here.
definition (name: "Temperature Sensor", namespace: "JohnRucker", author: "JohnRucker") {
capability "Temperature Measurement"
capability "Sensor"
capability "Refresh"
capability "Polling"
fingerprint profileId: "0104", deviceId: "0008", inClusters: "0000,0003,0004,0402"
}
// simulator metadata
simulator {
for (int i = 0; i <= 100; i += 10) {
status "${i}F": "temperature: $i F"
}
for (int i = 0; i <= 100; i += 10) {
status "${i}%": "humidity: ${i}%"
}
}
// UI tile definitions
tiles {
valueTile("temperature", "device.temperature", width: 2, height: 2) {
state("temperature", label:'${currentValue}°',
backgroundColors:[
[value: 31, color: "#153591"],
[value: 44, color: "#1e9cbb"],
[value: 59, color: "#90d2a7"],
[value: 74, color: "#44b621"],
[value: 84, color: "#f1d801"],
[value: 95, color: "#d04e00"],
[value: 96, color: "#bc2323"]
]
)
}
standardTile("refresh", "device.refresh", inactiveLabel: false, decoration: "flat") {
state "default", action:"refresh.refresh", icon:"st.secondary.refresh"
}
main(["temperature"])
details(["temperature", "refresh"])
}
}
def parse(String description) {
log.debug "Parse method received: $description"
Map map = [:]
if (description?.startsWith('catchall:')) {
map = parseCatchAllMessage(description)
}
log.debug "Parse returned $map"
def result = map ? createEvent(map) : null
return result
}
private Map parseCatchAllMessage(String description) {
Map resultMap = [:]
def cluster = zigbee.parse(description)
switch(cluster.clusterId) {
case 0x0402:
// temp is last 2 data values. reverse to swap endian
String temp = cluster.data[-2..-1].reverse().collect { cluster.hex1(it) }.join()
def value = getFahrenheit(temp)
resultMap = getTemperatureResult(value)
break
case 0x0406:
log.debug 'motion'
resultMap.name = 'motion'
break
}
return resultMap
}
def getFahrenheit(value) {
def celsius = Integer.parseInt(value, 16)
return celsiusToFahrenheit(celsius) as Integer
}
private Map getTemperatureResult(value) {
def linkText = getLinkText(device)
if (tempOffset) {
def offset = tempOffset as int
def v = value as int
value = v + offset
}
def descriptionText = "${linkText} was ${value}°${temperatureScale}"
return [
name: 'temperature',
value: value,
descriptionText: descriptionText
]
}
def poll(){
log.debug "Poll is calling refresh"
refresh()
}
def refresh() {
log.debug "sending refresh command"
def cmd = []
// Read Destination EP 0x38, Cluster 0x0402 Attribute ID 0x0000 (Current Temperature)
cmd << "st rattr 0x${device.deviceNetworkId} 0x38 0x0402 0x0000" // Read Current Value
cmd // Send Command
}
I wanted to use XBees for something like this, but I guess I'll use ZigBees instead so I can use SmartThings devices, instead of having to make everything from scratch.
Electrodude, we are using xBees for this its just the ZigBee version of them. At the beginning of this thread I spell out the hardware list that works best. All you need is an xBee Pro ZB SMT http://www.digikey.com/product-searc...BP24CZ7PIS-004 its about $28. You will need to solder some pins to it so you can plug it into your bread board. I also talk about that at the beginning of this thread.
If you have worked with xBees in the past your in great shape all the hardware is the same. If you haven't used them in API mode that will require a little ramp up speed by you can follow my sample code to get you started.
Electrodude, we are using xBees for this its just the ZigBee version of them. At the beginning of this thread I spell out the hardware list that works best. All you need is an xBee Pro ZB SMT http://www.digikey.com/product-searc...BP24CZ7PIS-004 its about $28. You will need to solder some pins to it so you can plug it into your bread board. I also talk about that at the beginning of this thread.
If you have worked with xBees in the past your in great shape all the hardware is the same. If you haven't used them in API mode that will require a little ramp up speed by you can follow my sample code to get you started.
Yeah, it's just that I have four unused non-ZB XBees that I was hoping to be able to use.
Do you know how similar API mode for ZigBees is to that of normal XBees? There's a library for normal XBees that can do API mode that I like and have a modified version of on the OBEX, and if the two protocols are similar enough, I might merge them into one library.
Yeah, it's just that I have four unused non-ZB XBees that I was hoping to be able to use.
Do you know how similar API mode for ZigBees is to that of normal XBees? There's a library for normal XBees that can do API mode that I like and have a modified version of on the OBEX, and if the two protocols are similar enough, I might merge them into one library.
I think they are very similar. I know the feeling I have a handful of old xBees as well.
Hi John. I have been working on this on and off through the week and just wanted to say thank you! for your reply post concerning the temperature addition.
At this point I can press the refresh tile on the ST app and receive the temp reading once. The second refresh does not work, and the program hangs. (Once is better then nothing. I was happy!)
I have been reluctant to ask for help because although I am running into wall after wall, I am learning and these tiny steps tend to stick with me. Also I have been unusually busy at work, so time is partitioned and limited.
I will try to get together a readable path of the code that I am using at the moment to submit for help as soon as I can.
Until then, I want to thank you. The code examples (on the spin side and the ST side) is so very well documented! The time to include the page numbers from the ZB cluster library( I now have a hard copy on my desk) alone says volumes about how helpful of a person you are!
Hi John this is pretty good , i like ti communicate with HA profile based temparature sensor , can you gouide me how to bild a api packet on Xbee S2C with HA profile .
Hi John this is pretty good , i like ti communicate with HA profile based temparature sensor , can you gouide me how to bild a api packet on Xbee S2C with HA profile .
Hey John, I've been reading your posts on this forum and the Smartthings forums, thank you for sharing your knowledge, you're the best!
I'm involved with a group that wants to make a simple wireless application (basically a switch), that is low power (you're aforementioned accomplishment of running your system for over a year with two AA batteries is our goal) and interfaces with Smartthings. We are total beginners and are hoping you can help direct us down the right path to learn what we need (we have coding and circuits knowledge but our dev board experience is limited to Arduino).
We began attempting this with the ATmega256RFR2 Xplained Pro and the ATmega256RFR2 ZigBit Xplained Pro Extension along with the Bitcloud SDK. Atmel's documentation was very confusing to us however and we couldn't even get to a point that the hub recognized a device (unknown or otherwise).
The implementation you've outlined here seems much better us because it compartmentalizes things more. We can program the Xbee and verify it is working and then program the propeller, connect them, and verify they work together. (The Atmel hardware had both an MCU and a RF transceiver on the same board so they it seems they have to be programmed simultaneously).
So we are going to switch to using the hardware you recommend and we have some questions:
1. Why do you get the Surface Mount Xbee and then solder through hole connections instead of purchasing the through hole Xbee in the first place?
2. If we get a Non-pro Xbee of the same series will it work identically save for a shorter range?
3. If we use your XCTU program to program the Xbee and successfully connect to the hub (as in, have it identify it as "unkown" as another forum poster was able to do) can we assume the Xbee to be programmed correctly and essentially ignore programming it and using XCTU going forward in the project?
4. Why choose propeller over other MCUs?
5. We want to understand what's going on so we can make our own changes. As far as I understand, you've uploaded SPIN code to run on the propeller for the initial pairing process between the Xbee and the hub (you gave an extremely helpful explanation of this already, thank you). But in the future we will have to write our own SPIN code to give our project any kind of functionality. So my questions here are:
a) Can you direct us to where we can begin learning about programming Propeller boards?
b) Do you think that if we read the Zigbee spec and Zigbee Cluster Library, and closely analyze your well documented code that we will be able to understand how this all functions? Or is there a better route/ additional reading?
Sorry for the long post and long list of questions and thank you again
Hey John, I've been reading your posts on this forum and the Smartthings forums, thank you for sharing your knowledge, you're the best!
So we are going to switch to using the hardware you recommend and we have some questions:
1. Why do you get the Surface Mount Xbee and then solder through hole connections instead of purchasing the through hole Xbee in the first place?
2. If we get a Non-pro Xbee of the same series will it work identically save for a shorter range?
3. If we use your XCTU program to program the Xbee and successfully connect to the hub (as in, have it identify it as "unkown" as another forum poster was able to do) can we assume the Xbee to be programmed correctly and essentially ignore programming it and using XCTU going forward in the project?
4. Why choose propeller over other MCUs?
5. We want to understand what's going on so we can make our own changes. As far as I understand, you've uploaded SPIN code to run on the propeller for the initial pairing process between the Xbee and the hub (you gave an extremely helpful explanation of this already, thank you). But in the future we will have to write our own SPIN code to give our project any kind of functionality. So my questions here are:
a) Can you direct us to where we can begin learning about programming Propeller boards?
b) Do you think that if we read the Zigbee spec and Zigbee Cluster Library, and closely analyze your well documented code that we will be able to understand how this all functions? Or is there a better route/ additional reading?
Sorry for the long post and long list of questions and thank you again
1) The Surface Mount xBee has upgraded hardware with more memory. This allowed Digi to put more ZigBee functions on the chip. If you don't use the SMT chip you wont be able to bind your radio to the SmartThings hub and in addition to a few other features that aren't supported with with the through hole version. Its not a big deal to solder the pins on. I do that still today even if my board is all SMT I like having the radio in a socket.
2) Yes the non xBee Pro SMT version will work great for you. It has less power and is much less expensive. It is the chip I use in my battery powered projects.
3) The answer to this question is changing monthly. Here is the deal. I use the XCTU program to configure the security settings of the ZigBee radio. To join SmartThings you radio has to be configured to adhere to the ZigBee Home Automation security profile. This is what all my setting do I make through the XCTU program are for. That however will only get you on the network (if SmartThings is told to allow new devices to join) it doesn't get you registered with the SmartThings cloud. To do that you have to send and respond to several ZigBee packets (see my June 2016 Nuts and Volts article). So the XCTU program isn't going to get you completely connected to SmartThings. You need your microcontroller for that.
4) The Propeller is an awesome low end microcontroller that is much more powerfully than an Adriano. The Propeller allows me to control a circuit down to clock edge precision! If I need a higher end solution I go with a Raspberry Pi. I have found those two platforms allow me to tackle just about any project!
5) As for learning the Propeller I wold order one of the the education kits and start building circuits. You will find this community extreamly helpful with an unbelievable pool of talent!! I will do everything I can to help (time permitting)!!
Thanks so much for the response! We have ordered the supplies and are starting the propeller learning process. I'm sure we'll be back with questions soon.
I would just like to say like Spencer I have been reading your posts and thanks to you I have successfully managed to create a smartthings platform on the ARM mbed written in C/C++.
1. Why do you get the Surface Mount Xbee and then solder through hole connections instead of purchasing the through hole Xbee in the first place?
May I just say on this point as long as they are a S2C xbee you can use either through hole or surface mount. As well as either pro or standard. I have implemented my program on both a standard through hole and a pro through hole.
Hey John,
Very nice post. I'm involved in a Pi contest (the Raspberry kind) and I was looking at adding a Propeller board to the mix, since I have them on hand, as a controller for a feeder system and your post is very much inline with what I was looking to do. I'm using OpenHAB which is an Open Source Smart Home program that does not require a Internet connection so everything is kept local. I have BLE, MQTT, EnOcean and ZigBee (by way of Philips Hue) devices in the mix but I am really looking at adding a Prop board with perhaps a ZigBee or another interface. I'll have a look-see what you have posted and see if it will work for my project.
Another thought, (perhaps a bit off topic) in reference to the switch question, would be to use a Prop chip in an Energy Harvesting manner, in that using a non battery or power source device to power the Prop for just long enough to fire off a data packet. I have some EnOcean switches in the mix that when clicked, generate enough energy to power the Micro in a transmitter to send a signal to a receiving unit on the Pi. This is all wireless and battery-less so it would be interesting if the Prop could be used in a similar manner.
Hey John,
Another thought, (perhaps a bit off topic) in reference to the switch question, would be to use a Prop chip in an Energy Harvesting manner, in that using a non battery or power source device to power the Prop for just long enough to fire off a data packet. I have some EnOcean switches in the mix that when clicked, generate enough energy to power the Micro in a transmitter to send a signal to a receiving unit on the Pi. This is all wireless and battery-less so it would be interesting if the Prop could be used in a similar manner.
Jon
That is great question. There is a post on this forum that talks about the amount of current it takes to boot and then run a propeller and it may be too much for this project unless you add a battery. If you have some specs on your EnOcen switches I would love to see them. I just haven't worked with them so I'm only guessing they can't produce enough power. The prop needs a pretty good sip of power to boot up and get its self into a low current sleep mode. I have a prop with a xBee running off of a single 9v alkaline battery that has been running for 11 months now reporting the TDS water quality of my home's water supply. When it boots up it very briefly takes 49mA to get connected to the hub and everything setup (that includes powering on the TDS sensor and taking a reading). It then switches off the external crystal and runs on the internal clock. I get a 24hr average current usage of 80uA. That 80uA includes hourly ZigBee reports to SmartThings of the TDS value. A ZigBee report requires several milliamps of current but only for a fraction of a second. I think this is all too much for an energy harvesting solution. I know there has been some talk about this but I think most people end up going with a SOC designed specifically for this purpose! The ZigBee radio has to support ZigBee GreenPower to take advantage of a battery-less solution. I'm pretty sure Digi's radios don't support the GreenPower spec so we would be looking at some other ZigBee radio.
In case your interested here is the chart of my home's TDS water value from this sensor https://thingspeak.com/channels/86862. It doesn't have a years worth of data as I wrote the smartapp that sends the data from SmartThigns to ThingsSpeak back in April.
We got it working! The hub connects to and identifies our object and we are successfully controlling it with most of the functionality we want. We can't thank you enough for your advice on this forum and your well commented code.
We were able to do this with a through-hole Xbee (https://www.sparkfun.com/products/11217) with only a few minor issues to work out which I want to ask about. We also have the non-pro SMT version you recommended so if you think the struggles we are having may be related to our use of the through-hole Xbee then we can easily make the switch.
Our first issue is this: it seems that the propeller must be plugged into our computer in order to perform the initial joining process with the hub. After the initial joining process we can then unplug the propeller from the computer and it continues to control the output and communicate with the hub just fine but if it loses power we have to plug it into the computer to reconnect again. We aren't sure why simply pressing the reset button on the propeller is different from plugging it back in. Is this to be expected?
Our second issue is that we are having a hard time determining how much current the system uses. We have two AA batteries connected to a 5V step up regulator which then powers the propeller. We have tried connecting an ammeter between the AA batteries and the regulator but when we do so this causes the propeller to reset over and over (and the current read jumps up an down, maybe due to the propeller constantly rebooting). Any idea what our problem may be here? What is your method for measuring current usage?
Hey John,
Our first issue is this: it seems that the propeller must be plugged into our computer in order to perform the initial joining process with the hub. After the initial joining process we can then unplug the propeller from the computer and it continues to control the output and communicate with the hub just fine but if it loses power we have to plug it into the computer to reconnect again. We aren't sure why simply pressing the reset button on the propeller is different from plugging it back in. Is this to be expected?
Our second issue is that we are having a hard time determining how much current the system uses. We have two AA batteries connected to a 5V step up regulator which then powers the propeller. We have tried connecting an ammeter between the AA batteries and the regulator but when we do so this causes the propeller to reset over and over (and the current read jumps up an down, maybe due to the propeller constantly rebooting). Any idea what our problem may be here? What is your method for measuring current usage?
Depending on the propeller board you are using sometimes they will reset themselves if you continue to echo text into a prop plug that is not powered and connected to your PC. I can think of a couple of things, first try it without out the prop plug connected to your board. Better yet, rem out all the log / debug commands. You will also want to remove the pst object as no one is using it. I do this as a habit on all battery projects as you want your code to be as efficient as possible.
As for measuring the current put your current meter in-line from the battery to the board. You will want to remove the prop plug completely when measuring current as parasitic current from the plug will give you false readings. I don't know why your circuit would reboot when the meter is in place. It may be related to the first problem and remarking out the debug commands may solve this too.
Hello John,
Thanks so much for sharing, this is a great project to learn about Zigbee and Xbee! I've been working on implementing this on a Microchip PIC32 platform which has been great because it's forced me to really understand some of the nuances of the software and protocol. This has been my first experience with Zigbee and the reams of information in the various specs, and it's been slow going but I seem to be getting there. So here is my question: It's my understanding that the project is supporting the HA Profile. As I read the HA profile (ZCL Table 7.1), it appears that two ZCL general clusters are to be supported 1) Basic cluster 2) Identification cluster. However, I only see the basic cluster implemented in the software. Also, when referencing the basic cluster documentation (ZCL Table 3.8) it says that the ZCLVersion and PowerSource attributes are mandatory but they are not implemented anywhere, although ManufactureName/ModelIdentifier etc. are. I'm simply trying to understand if I'm missing something or if the project is not 100% HA Compliant (i.e. it's simply a demo of hooking w/ Smartthings). Either one is fine, I'd just like to make sure I get it. Any light you can shed would be helpful. Thanks!
Your not missing anything. Yep those attributes are not in this example. This was intended to be a get you going project and back two years ago when I published this SmartThings didn't care about the extra attributes. You should be able to add them pretty easily if you made it this far. If you do add them please share the results back with this forum.
Thanks for the demo John. I have successfully connected this to my SmartThings hub and able to control the LED. I will be trying to add some features over the next few months to eventually be able to control multiple binary outputs and read multiple inputs.
sorry for reopening an old post, but I was hoping to try get some help.
Read about the XBee exploits here, and I am trying sort out some ZigBee lighting issues.
I have two networks; one Lightify pro with just under 70 devices and 100 endpoints, and the other Lightify home with 34 devices, and not sure how many endpoints that equates to.
The lightify pro system, at least, is based on Delta Electronics ZigBee Controller (fccid H79DFZM-E8210), which is an includes an Silicon Labs EM3587 SoC ZigBee solution.
Essentially the same family as the EM 357 that the XBee S2C is based on.
The first step in this, for me, was to get my XBee identified on my network. I can join it, with the settings below and putting the gateway into joining mode, but the commissioning software for the Lightify gateway does not recognise it.
My guess here is that the XBee is not 'approved' from whatever internal 'white list' there is press by Osram.
I can still connect to the network, however, and have access to API frame control so can issue requests for specific information from devices on the network. Means I can also map the network as you demonstrated in the Smartthings Forum. However the device (a GU10 bulb) I'm after troubleshooting does not show up in the network map even though it still 'works'.
The XBee settings in XCTU required for this (from the default settings) are
ZS=2
EE=1
EO=1 (no key needed as Lightify supports broadcast in the clear for joining devices)
AP=2
AO=3
These settings work for Osram Lightify home and Pro, but not me Phillips Hue v2 gateway (dunno why)
My initial thought was that the OSram gateway does not recognise the XBee as a specific device class, so I tried changing the 'DD' setting via XCTU to 0x00000210 which should identify it as a colour changing light bulb, but it still does not identify with the gateway as such.
The other issue with this is that when I query the XBee, logged into the network, with a ZDO Active Endpoints Request, there are none reported, so when you perform a ZDO Simple Descriptor request there is no end point defined. So it doesn't appear as anything. And adding the DD to the NJ doesn't seem to affect this.
So even tho' set to appear as an extended colour changing bulb, it doesn't actually seem to report this, so gateway won't recognise it.
My next thought was that perhaps I needed to change the 'manufacturer code' and make the XBee appear as an Osram made device, but I can't figure out how to do that.
Bottom line is, I'm not stuck.
What I want to do is to try and have the XBee play a passive receiver on my network to try and allow to packet sniff whats going on with Wireshark.
Reason being I'm getting devices dropping out of the network for no good reason, and although they still repsond to network switches (as in lights on, lights off) they are no longer configurable. And to reintegrate them into the network requires the specific device to be reset, then the entire group to be broken down and remade.
My home was to packet sniff and try identify what these devices were doing when they dropped from the network as my suspicion is that the gateway is inappropriately removing their 16 bit addresses from its list, so no longer recognising it, but the device is still listening. So what I expect to see is the gateway making multiple network requests to the device, and the device making act's, but not being registered by the gateway; this the repeats.
thats the thought, anyway.
Plan is to use an RPi3 to sniff as I can the XBee is on a USB module but my Mac can't be configured to read a USB port for Wireshark.
Hi John,
sorry for reopening an old post, but I was hoping to try get some help.
Read about the XBee exploits here, and I am trying sort out some ZigBee lighting issues.
I have two networks; one Lightify pro with just under 70 devices and 100 endpoints, and the other Lightify home with 34 devices, and not sure how many endpoints that equates to.
The lightify pro system, at least, is based on Delta Electronics ZigBee Controller (fccid H79DFZM-E8210), which is an includes an Silicon Labs EM3587 SoC ZigBee solution.
Essentially the same family as the EM 357 that the XBee S2C is based on.
Andy
XDAndy, I wonder if the Osram Lightify Pro and Osram Home use the ZigBee Light Link profile instead of the ZigBee Home Automation profile SmartThings and others use. If so, you won't be able to join a non certified ZigBee Light Link device to their network. For a ZigBee device to join a ZigBee Light Link network it has to have an unique encryption key that is maintained by the vendor. For example, you can't join an xBee to a Phillips hue hub. The Phillips hub uses the ZigBee Light Link profile. However, you can join hue bulbs to a ZigBee Home Automation network and just turn off your Hue Hub.
I'm not sure an xBee ZB is going to work well with WireShark. The ZigBee sniffers I have worked with are tied pretty close to their hardware. Free-scale makes one and you have to use their ZigBee radio as they need to operate down at the 802.15.4 network level.
Thanks for the demo John. I have successfully connected this to my SmartThings hub and able to control the LED. I will be trying to add some features over the next few months to eventually be able to control multiple binary outputs and read multiple inputs.
Hey that sounds fantastic! Its good to see others working with this. For some reason my ZigBee posts have been getting attention lately both here and on the SmartThings forum for some reason..
XDAndy, I wonder if the Osram Lightify Pro and Osram Home use the ZigBee Light Link profile instead of the ZigBee Home Automation profile SmartThings and others use. If so, you won't be able to join a non certified ZigBee Light Link device to their network. For a ZigBee device to join a ZigBee Light Link network it has to have an unique encryption key that is maintained by the vendor. For example, you can't join an xBee to a Phillips hue hub. The Phillips hub uses the ZigBee Light Link profile. However, you can join hue bulbs to a ZigBee Home Automation network and just turn off your Hue Hub.
I'm not sure an xBee ZB is going to work well with WireShark. The ZigBee sniffers I have worked with are tied pretty close to their hardware. Free-scale makes one and you have to use their ZigBee radio as they need to operate down at the 802.15.4 network level.
Hi John,
and thank you for taking the time to reply.
yep, the Osram's use ZLL for the home, and Zigbee Pro/ZLL for the Pro gateway. But, according to Osram it doesn't make a difference as the protocols are interoperable, and the pro gateway in particular should configure itself to the connecting device.
I think there may be a limitation is that if the device is HA then it must connect as an end device rather than a router, but I might have that wrong.
In any event, the current s2c firmware should support both as its the 2007 Pro firmware.
As for the pre-shared key, Lightify supports the key being transmitted unencrypted to devices when joining, so no key should be needed, and indeed doesn't appear to be.
However the HA key you detail works when I enter that as well. There is also the ZLL master key thats been seeded to reddit, but I haven't gotten that to work as yet.
For the most part when I monitor query devices the seem to respond in HA profile (profile ID 0x0104) when I make certain requests, but the frame generator is trying to use profile 0xC105, however inter web seems to report profile ID for ZLL should be 0xC05E, which I also see occasionally.
Basic point of where I am at is that my XBee can join the network, is being registered by the coordinator and given a 16 bit address, seems to receive select traffic from the network that is routed to it, but isn't being identified by the commissioning software.
My hope was to spoof the network into accepting a device ID and manufacturer ID by setting the XBee as having an end point, but I only seem to get it to join in router mode; any attempt to set it up as an endpoint causes the connection to fail.
I missed the but where you said (back in 2014)
Even more Details:
When a ZigBee device joins a network (this is how SmartThings works) an identification process occurs. The ZigBee Home Automation spec defines several ways devices can discover each other and figure out how to talk to one another using ZigBee Device Objects (ZDO). SmartThings uses three sets of ZDO clusters to identify devices when they join a network. The first thing that happens after a device has been allowed to join a network is it should send out a device announce packet (ZDO Cluster 0x0013) this is received by the SmartThings hub. Next the hub will send out a request for active end points supported by this new device by sending a ZDO Cluster 0x0005 packet to the new device. The device is expected to respond back with a list of its end points in a ZDO cluster 0x8005 formatted packet. Now each end point is queried for a profile ID, Device ID, and a set of supported clusters on that end point (ZDO 0x0004 & 0x8004 are used for this). At this point SmartThings knows what your device is and what it can do so it starts to look for a device driver to match it with (they call this the foot printing process).
And my hope was I could handle the ZDO responses to the coordinator from the XBee itself without using a third party device.
Now I could use the RPi, but I've no idea how similar that is to your propeller board, or whether your code is transposable to it directly.
I feel as if I am almost just 'there' .... but can't quite reach where I want to be.
Frustrating, not helped by my utter lack of understanding about all this.
Just to make sure I understand what's going on. Your Osram's hub is allowing ZigBee devices from both the Light Link and Home Automation profiles to join it? And you are joining your xBee ZB (S2C) to the home automation profile but not using the public HA key to do so? I haven't worked with the Osram hub but there is no way in heck it should allow a ZigBee HA network to be formed without a network key exchange during the join. There is a lot of stuff going on here that doesn't make sense to me!! Let me clarify a couple things that are throwing me off.
The ZigBee Home Automation profile and Light Link profile are basically security definitions devices must follow before being allowed to join a network. I can only talk about the Home Automation profile as that is were I have spent most of my time. Inside the ZigBee coordinator (I guess the Osram hub in your case) is a trust center that manages two sets of encryption keys. The first key is the publicly available Home Automation key. This is the key you have to have configured in your xBee to join a Home Automation network. When a ZigBee device tries to join a home automation network the trust center in the hub will communicate with the new device encrypting the conversation with the publicly available key. If everything looks okay security wise it will give the new device a unique network key (the 2nd key). From now on the ZigBee device will use this new network key to encrypt all its communications to and from the hub. Well almost all packets will be encrypted. There will be some network routing traffic that is not encrypted that flows between routers and the coordinator.
When you say you can join your xBee to the home automation network without a key then your not joining a home automation network. There is just no way unless they are not conforming to the home automation profile. I wonder if your joining some other ZigBee network or your xBee is miss-configured and forming its own ZigBee network.
There are a few other things that give me pause. One is you say your seeing network traffic and you are getting a 16 bit network address. Well that can happen if your xBee is forming its own network as well. But if you only have one xBee you shouldn't be receiving any traffic so that bit doesn't make sense unless you have more than one xBee and they have formed their own network.
It is absolutely possible for the Osram hub to support both a Light Link and Home Automation profiles. It is also possible the server software inside their hub only pays attention to devices that join with the Light Link profile. Home automation devices may be allowed to join but they don't do anything with them.
As for my propeller code porting over to the Raspberry Pi. Well the short answer is no there is not an easy migration over. However, I have documented the heck out of the code and you should be able to rewrite it in whatever language you are going to use on the Pi. Several people have used my code to create libraries for the Arduino so someone may have done it for Python or Node.Js on the Pi.
FYI There is a ongoing conversation over on the SmartThings forum about tweaking my ZigBee library for the Propeller and turning it into a easy to use ZigBee API On Chip (ZAOC) for makers. The ZAOC would be a propeller that sits between your raspberry pi and the xBee radio. You would communicate with it by sending standard strings back and forth. It would take care of all the packet formation and data manipulation required to send and receive standard ZigBee HA traffic all the way down to the cluster / attribute level.
Comments
valueTile("temperature", "device.temperature", width: 1, height: 1){ state("temperature", label:'${currentValue}') }and I found these in the temperature example. I have them commented out at the moment:
//private String parseName(String description) { // if (description?.startsWith("temperature: ")) { // return "temperature" // } //} //private String parseValue(String description) { // if (description?.startsWith("temperature: ")) { // return zigbee.parseHATemperatureValue(description, "temperature: ", getTemperatureScale()) // } //}Thanks.
The SPIN object may be a bit cryptic as it is called from a parent object but it should help with the packet syntax. Take look at the ReadAttribute method that is what you will need to incorporate into your code. If your still stuck please let me know I will be happy to post the whole SPIN program. The only reason I didn't is it does a bunch of other stuff not related to Temperature reporting and my confuse people.
I think the SmartThings custom device type may have been tripping you up the most. I think the sample you were working from was not a complete device type. It didn't have any of the poll methods or data conversion. I rewrote it based on other samples and stuff I have put together. Please understand I'm not a JAVA guy so this device type has a long way to go. But it should get you pointed in the right direction.
Here is my SPIN object:
''*********************************************** '' ZCL_Temperature '' ZigBee Temperature measurement Cluster ID 0x0402 See Page 250 of ZigBee Cluster Library (ZCL) '' Author: John.Rucker@Solar-Current.com '' Copyright (c) 2015 Solar-Current.com, Inc. '' See end of file for terms of use. ''*********************************************** ''-----------------REVISION HISTORY----------------- '' 1 - 1/18/2015 Created by John Rucker dat Temperature Word $0000 ' Temperature setting MaxTemperature Word $0000 ' Max Temperature Value MinTemperature Word $0000 ' Min Temperature Value OBJ zb : "ZigBeeAPI" ' Object is placed here as a stub allowing access to the ZigBeeAPI object. Pub RouteCmd (zbPktPtr, ReturnBufAdd, MaxReturnBufSize) | frmType, seqNum, cmdID, attributeID frmType:=seqNum:=cmdID:=attributeID:=0 '*************************************** ' Routes execution based on FrmType and CmdID ' zbPktPtr is a the address of a buffer containing the payload of the ZigBee packet to process ' ReturnBufAdd is the address of a byte sized buffer to place the response bytes into ' Return is passed back from called method '*************************************** frmType := byte[zbPktPtr][0] ' Frame Type is bit 0 and 1 of Byte 0 P14 of ZCL. if cmd = 00 command is defind in table 2.9 P16, if cmd = 01 command is defind in the cluster's cmd list frmType &= %00000000_00000001 ' Bitwise (&) with a mask to make sure we are looking at last bit seqNum := byte[zbPktPtr][1] ' Transaction seq number can be any value used in return packet to match a response to a request cmdID := byte[zbPktPtr][2] ' Command ID Byte P16 of ZCL byte[@attributeID][0] := byte[zbPktPtr][3] ' Attribute ID Word(little endin) P126 of ZCL byte[@attributeID][1] := byte[zbPktPtr][4] if FrmType == 0 ' Command is profile wide command case CmdID $00: return ReadAttribute(attributeID, seqNum, ReturnBufAdd, MaxReturnBufSize) ' Read attribute return FALSE Pub _Temperature return Temperature Pub _MaxTemperature return MaxTemperature Pub _MinTemperature return MinTemperature Pub SetTemperatue(TempVal) Temperature := TempVal if Temperature > MaxTemperature MaxTemperature := Temperature if Temperature < MinTemperature MinTemperature := Temperature Pub ResetMinMax MaxTemperature:=MinTemperature:=Temperature Pri ReadAttribute(Attribute, seqNum, BufAdd, MaxBufSize) | BufSize '*************************************** ' Reads Attribute Number creates response and places it in BufAdd ' Attribute = Attribute to report on ' seqNum = sequence number used in creating response packet ' BufAdd = Pointer to a byte sized buffer to place the response packet in ' MaxBufSize = Maximum Size of buffer ' Returns true if successful false if error '*************************************** if Attribute == $0000 ' Read MeasuredValued BufSize := 9 ' BufSize is the size of the response pkt placed inside the BufAdd buffer in bytes if BufSize > MaxBufSize return -1 ByteFill(BufAdd, 0 , MaxBufSize) ' Clear Buffer byte[BufAdd][0] := $18 ' Fame Control $18 = direction is from server to client, disable default response P14 of ZCL byte[BufAdd][1] := seqNum ' Set the sequence number to match the seq number in requesting packet byte[BufAdd][2] := $01 ' Command Identifer $01 = Read attribute response see Table 2.9 on page 16 of ZCL byte[BufAdd][3] := byte[@Attribute][0] ' Attribute Identifier (2 bytes) field being reported see figure 2.24 on page 36 of ZCL byte[BufAdd][4] := byte[@Attribute][1] byte[BufAdd][5] := $00 ' Status 00 = Success byte[BufAdd][6] := $29 ' Attribute Data Type $29 = Signed 16-bit integer, see table 2.16 on page 55 of ZCL byte[BufAdd][7] := byte[@Temperature][0] ' Set the Temperature as the value to send byte[BufAdd][8] := byte[@Temperature][1] zb.TX(zb._PktIEEEAddHi, zb._PktIEEEAddLo, zb._PktNetAdd, zb._PktDEP, zb._PktSEP, zb._PktProfile, zb._PktCluster, bufAdd, BufSize) return TRUE return FALSEHere is the SmartThings custom device type:
metadata { // Automatically generated. Make future change here. definition (name: "Temperature Sensor", namespace: "JohnRucker", author: "JohnRucker") { capability "Temperature Measurement" capability "Sensor" capability "Refresh" capability "Polling" fingerprint profileId: "0104", deviceId: "0008", inClusters: "0000,0003,0004,0402" } // simulator metadata simulator { for (int i = 0; i <= 100; i += 10) { status "${i}F": "temperature: $i F" } for (int i = 0; i <= 100; i += 10) { status "${i}%": "humidity: ${i}%" } } // UI tile definitions tiles { valueTile("temperature", "device.temperature", width: 2, height: 2) { state("temperature", label:'${currentValue}°', backgroundColors:[ [value: 31, color: "#153591"], [value: 44, color: "#1e9cbb"], [value: 59, color: "#90d2a7"], [value: 74, color: "#44b621"], [value: 84, color: "#f1d801"], [value: 95, color: "#d04e00"], [value: 96, color: "#bc2323"] ] ) } standardTile("refresh", "device.refresh", inactiveLabel: false, decoration: "flat") { state "default", action:"refresh.refresh", icon:"st.secondary.refresh" } main(["temperature"]) details(["temperature", "refresh"]) } } def parse(String description) { log.debug "Parse method received: $description" Map map = [:] if (description?.startsWith('catchall:')) { map = parseCatchAllMessage(description) } log.debug "Parse returned $map" def result = map ? createEvent(map) : null return result } private Map parseCatchAllMessage(String description) { Map resultMap = [:] def cluster = zigbee.parse(description) switch(cluster.clusterId) { case 0x0402: // temp is last 2 data values. reverse to swap endian String temp = cluster.data[-2..-1].reverse().collect { cluster.hex1(it) }.join() def value = getFahrenheit(temp) resultMap = getTemperatureResult(value) break case 0x0406: log.debug 'motion' resultMap.name = 'motion' break } return resultMap } def getFahrenheit(value) { def celsius = Integer.parseInt(value, 16) return celsiusToFahrenheit(celsius) as Integer } private Map getTemperatureResult(value) { def linkText = getLinkText(device) if (tempOffset) { def offset = tempOffset as int def v = value as int value = v + offset } def descriptionText = "${linkText} was ${value}°${temperatureScale}" return [ name: 'temperature', value: value, descriptionText: descriptionText ] } def poll(){ log.debug "Poll is calling refresh" refresh() } def refresh() { log.debug "sending refresh command" def cmd = [] // Read Destination EP 0x38, Cluster 0x0402 Attribute ID 0x0000 (Current Temperature) cmd << "st rattr 0x${device.deviceNetworkId} 0x38 0x0402 0x0000" // Read Current Value cmd // Send Command }If your still stuck don't be shy!!
Electrodude, we are using xBees for this its just the ZigBee version of them. At the beginning of this thread I spell out the hardware list that works best. All you need is an xBee Pro ZB SMT http://www.digikey.com/product-searc...BP24CZ7PIS-004 its about $28. You will need to solder some pins to it so you can plug it into your bread board. I also talk about that at the beginning of this thread.
If you have worked with xBees in the past your in great shape all the hardware is the same. If you haven't used them in API mode that will require a little ramp up speed by you can follow my sample code to get you started.
Yeah, it's just that I have four unused non-ZB XBees that I was hoping to be able to use.
Do you know how similar API mode for ZigBees is to that of normal XBees? There's a library for normal XBees that can do API mode that I like and have a modified version of on the OBEX, and if the two protocols are similar enough, I might merge them into one library.
I am stuck....
Hi John. I have been working on this on and off through the week and just wanted to say thank you! for your reply post concerning the temperature addition.
At this point I can press the refresh tile on the ST app and receive the temp reading once. The second refresh does not work, and the program hangs. (Once is better then nothing. I was happy!)
I have been reluctant to ask for help because although I am running into wall after wall, I am learning and these tiny steps tend to stick with me. Also I have been unusually busy at work, so time is partitioned and limited.
I will try to get together a readable path of the code that I am using at the moment to submit for help as soon as I can.
Until then, I want to thank you. The code examples (on the spin side and the ST side) is so very well documented! The time to include the page numbers from the ZB cluster library( I now have a hard copy on my desk) alone says volumes about how helpful of a person you are!
Happy ZigBee_HA!
traVis.
Take a look at my latest's article in Nuts and Volts it breaks out how to create packets for your xBee ZB.
I'm involved with a group that wants to make a simple wireless application (basically a switch), that is low power (you're aforementioned accomplishment of running your system for over a year with two AA batteries is our goal) and interfaces with Smartthings. We are total beginners and are hoping you can help direct us down the right path to learn what we need (we have coding and circuits knowledge but our dev board experience is limited to Arduino).
We began attempting this with the ATmega256RFR2 Xplained Pro and the ATmega256RFR2 ZigBit Xplained Pro Extension along with the Bitcloud SDK. Atmel's documentation was very confusing to us however and we couldn't even get to a point that the hub recognized a device (unknown or otherwise).
The implementation you've outlined here seems much better us because it compartmentalizes things more. We can program the Xbee and verify it is working and then program the propeller, connect them, and verify they work together. (The Atmel hardware had both an MCU and a RF transceiver on the same board so they it seems they have to be programmed simultaneously).
So we are going to switch to using the hardware you recommend and we have some questions:
1. Why do you get the Surface Mount Xbee and then solder through hole connections instead of purchasing the through hole Xbee in the first place?
2. If we get a Non-pro Xbee of the same series will it work identically save for a shorter range?
3. If we use your XCTU program to program the Xbee and successfully connect to the hub (as in, have it identify it as "unkown" as another forum poster was able to do) can we assume the Xbee to be programmed correctly and essentially ignore programming it and using XCTU going forward in the project?
4. Why choose propeller over other MCUs?
5. We want to understand what's going on so we can make our own changes. As far as I understand, you've uploaded SPIN code to run on the propeller for the initial pairing process between the Xbee and the hub (you gave an extremely helpful explanation of this already, thank you). But in the future we will have to write our own SPIN code to give our project any kind of functionality. So my questions here are:
a) Can you direct us to where we can begin learning about programming Propeller boards?
b) Do you think that if we read the Zigbee spec and Zigbee Cluster Library, and closely analyze your well documented code that we will be able to understand how this all functions? Or is there a better route/ additional reading?
Sorry for the long post and long list of questions and thank you again
1) The Surface Mount xBee has upgraded hardware with more memory. This allowed Digi to put more ZigBee functions on the chip. If you don't use the SMT chip you wont be able to bind your radio to the SmartThings hub and in addition to a few other features that aren't supported with with the through hole version. Its not a big deal to solder the pins on. I do that still today even if my board is all SMT I like having the radio in a socket.
2) Yes the non xBee Pro SMT version will work great for you. It has less power and is much less expensive. It is the chip I use in my battery powered projects.
3) The answer to this question is changing monthly. Here is the deal. I use the XCTU program to configure the security settings of the ZigBee radio. To join SmartThings you radio has to be configured to adhere to the ZigBee Home Automation security profile. This is what all my setting do I make through the XCTU program are for. That however will only get you on the network (if SmartThings is told to allow new devices to join) it doesn't get you registered with the SmartThings cloud. To do that you have to send and respond to several ZigBee packets (see my June 2016 Nuts and Volts article). So the XCTU program isn't going to get you completely connected to SmartThings. You need your microcontroller for that.
4) The Propeller is an awesome low end microcontroller that is much more powerfully than an Adriano. The Propeller allows me to control a circuit down to clock edge precision! If I need a higher end solution I go with a Raspberry Pi. I have found those two platforms allow me to tackle just about any project!
5) As for learning the Propeller I wold order one of the the education kits and start building circuits. You will find this community extreamly helpful with an unbelievable pool of talent!! I will do everything I can to help (time permitting)!!
This sounds like an awesome project!
I would just like to say like Spencer I have been reading your posts and thanks to you I have successfully managed to create a smartthings platform on the ARM mbed written in C/C++. May I just say on this point as long as they are a S2C xbee you can use either through hole or surface mount. As well as either pro or standard. I have implemented my program on both a standard through hole and a pro through hole.
Again thanks for all the help?
Very nice post. I'm involved in a Pi contest (the Raspberry kind) and I was looking at adding a Propeller board to the mix, since I have them on hand, as a controller for a feeder system and your post is very much inline with what I was looking to do. I'm using OpenHAB which is an Open Source Smart Home program that does not require a Internet connection so everything is kept local. I have BLE, MQTT, EnOcean and ZigBee (by way of Philips Hue) devices in the mix but I am really looking at adding a Prop board with perhaps a ZigBee or another interface. I'll have a look-see what you have posted and see if it will work for my project.
Another thought, (perhaps a bit off topic) in reference to the switch question, would be to use a Prop chip in an Energy Harvesting manner, in that using a non battery or power source device to power the Prop for just long enough to fire off a data packet. I have some EnOcean switches in the mix that when clicked, generate enough energy to power the Micro in a transmitter to send a signal to a receiving unit on the Pi. This is all wireless and battery-less so it would be interesting if the Prop could be used in a similar manner.
Thanks,
Jon
That is great question. There is a post on this forum that talks about the amount of current it takes to boot and then run a propeller and it may be too much for this project unless you add a battery. If you have some specs on your EnOcen switches I would love to see them. I just haven't worked with them so I'm only guessing they can't produce enough power. The prop needs a pretty good sip of power to boot up and get its self into a low current sleep mode. I have a prop with a xBee running off of a single 9v alkaline battery that has been running for 11 months now reporting the TDS water quality of my home's water supply. When it boots up it very briefly takes 49mA to get connected to the hub and everything setup (that includes powering on the TDS sensor and taking a reading). It then switches off the external crystal and runs on the internal clock. I get a 24hr average current usage of 80uA. That 80uA includes hourly ZigBee reports to SmartThings of the TDS value. A ZigBee report requires several milliamps of current but only for a fraction of a second. I think this is all too much for an energy harvesting solution. I know there has been some talk about this but I think most people end up going with a SOC designed specifically for this purpose! The ZigBee radio has to support ZigBee GreenPower to take advantage of a battery-less solution. I'm pretty sure Digi's radios don't support the GreenPower spec so we would be looking at some other ZigBee radio.
In case your interested here is the chart of my home's TDS water value from this sensor https://thingspeak.com/channels/86862. It doesn't have a years worth of data as I wrote the smartapp that sends the data from SmartThigns to ThingsSpeak back in April.
We got it working! The hub connects to and identifies our object and we are successfully controlling it with most of the functionality we want. We can't thank you enough for your advice on this forum and your well commented code.
We were able to do this with a through-hole Xbee (https://www.sparkfun.com/products/11217) with only a few minor issues to work out which I want to ask about. We also have the non-pro SMT version you recommended so if you think the struggles we are having may be related to our use of the through-hole Xbee then we can easily make the switch.
Our first issue is this: it seems that the propeller must be plugged into our computer in order to perform the initial joining process with the hub. After the initial joining process we can then unplug the propeller from the computer and it continues to control the output and communicate with the hub just fine but if it loses power we have to plug it into the computer to reconnect again. We aren't sure why simply pressing the reset button on the propeller is different from plugging it back in. Is this to be expected?
Our second issue is that we are having a hard time determining how much current the system uses. We have two AA batteries connected to a 5V step up regulator which then powers the propeller. We have tried connecting an ammeter between the AA batteries and the regulator but when we do so this causes the propeller to reset over and over (and the current read jumps up an down, maybe due to the propeller constantly rebooting). Any idea what our problem may be here? What is your method for measuring current usage?
Thanks again!
Depending on the propeller board you are using sometimes they will reset themselves if you continue to echo text into a prop plug that is not powered and connected to your PC. I can think of a couple of things, first try it without out the prop plug connected to your board. Better yet, rem out all the log / debug commands. You will also want to remove the pst object as no one is using it. I do this as a habit on all battery projects as you want your code to be as efficient as possible.
As for measuring the current put your current meter in-line from the battery to the board. You will want to remove the prop plug completely when measuring current as parasitic current from the plug will give you false readings. I don't know why your circuit would reboot when the meter is in place. It may be related to the first problem and remarking out the debug commands may solve this too.
Glad its working you have come a long way!!
Thanks so much for sharing, this is a great project to learn about Zigbee and Xbee! I've been working on implementing this on a Microchip PIC32 platform which has been great because it's forced me to really understand some of the nuances of the software and protocol. This has been my first experience with Zigbee and the reams of information in the various specs, and it's been slow going but I seem to be getting there. So here is my question: It's my understanding that the project is supporting the HA Profile. As I read the HA profile (ZCL Table 7.1), it appears that two ZCL general clusters are to be supported 1) Basic cluster 2) Identification cluster. However, I only see the basic cluster implemented in the software. Also, when referencing the basic cluster documentation (ZCL Table 3.8) it says that the ZCLVersion and PowerSource attributes are mandatory but they are not implemented anywhere, although ManufactureName/ModelIdentifier etc. are. I'm simply trying to understand if I'm missing something or if the project is not 100% HA Compliant (i.e. it's simply a demo of hooking w/ Smartthings). Either one is fine, I'd just like to make sure I get it. Any light you can shed would be helpful. Thanks!
sorry for reopening an old post, but I was hoping to try get some help.
Read about the XBee exploits here, and I am trying sort out some ZigBee lighting issues.
I have two networks; one Lightify pro with just under 70 devices and 100 endpoints, and the other Lightify home with 34 devices, and not sure how many endpoints that equates to.
The lightify pro system, at least, is based on Delta Electronics ZigBee Controller (fccid H79DFZM-E8210), which is an includes an Silicon Labs EM3587 SoC ZigBee solution.
Essentially the same family as the EM 357 that the XBee S2C is based on.
The first step in this, for me, was to get my XBee identified on my network. I can join it, with the settings below and putting the gateway into joining mode, but the commissioning software for the Lightify gateway does not recognise it.
My guess here is that the XBee is not 'approved' from whatever internal 'white list' there is press by Osram.
I can still connect to the network, however, and have access to API frame control so can issue requests for specific information from devices on the network. Means I can also map the network as you demonstrated in the Smartthings Forum. However the device (a GU10 bulb) I'm after troubleshooting does not show up in the network map even though it still 'works'.
The XBee settings in XCTU required for this (from the default settings) are
ZS=2
EE=1
EO=1 (no key needed as Lightify supports broadcast in the clear for joining devices)
AP=2
AO=3
These settings work for Osram Lightify home and Pro, but not me Phillips Hue v2 gateway (dunno why)
My initial thought was that the OSram gateway does not recognise the XBee as a specific device class, so I tried changing the 'DD' setting via XCTU to 0x00000210 which should identify it as a colour changing light bulb, but it still does not identify with the gateway as such.
The other issue with this is that when I query the XBee, logged into the network, with a ZDO Active Endpoints Request, there are none reported, so when you perform a ZDO Simple Descriptor request there is no end point defined. So it doesn't appear as anything. And adding the DD to the NJ doesn't seem to affect this.
So even tho' set to appear as an extended colour changing bulb, it doesn't actually seem to report this, so gateway won't recognise it.
My next thought was that perhaps I needed to change the 'manufacturer code' and make the XBee appear as an Osram made device, but I can't figure out how to do that.
Bottom line is, I'm not stuck.
What I want to do is to try and have the XBee play a passive receiver on my network to try and allow to packet sniff whats going on with Wireshark.
Reason being I'm getting devices dropping out of the network for no good reason, and although they still repsond to network switches (as in lights on, lights off) they are no longer configurable. And to reintegrate them into the network requires the specific device to be reset, then the entire group to be broken down and remade.
My home was to packet sniff and try identify what these devices were doing when they dropped from the network as my suspicion is that the gateway is inappropriately removing their 16 bit addresses from its list, so no longer recognising it, but the device is still listening. So what I expect to see is the gateway making multiple network requests to the device, and the device making act's, but not being registered by the gateway; this the repeats.
thats the thought, anyway.
Plan is to use an RPi3 to sniff as I can the XBee is on a USB module but my Mac can't be configured to read a USB port for Wireshark.
Can you offer any advice?
kind regards
Andy
XDAndy, I wonder if the Osram Lightify Pro and Osram Home use the ZigBee Light Link profile instead of the ZigBee Home Automation profile SmartThings and others use. If so, you won't be able to join a non certified ZigBee Light Link device to their network. For a ZigBee device to join a ZigBee Light Link network it has to have an unique encryption key that is maintained by the vendor. For example, you can't join an xBee to a Phillips hue hub. The Phillips hub uses the ZigBee Light Link profile. However, you can join hue bulbs to a ZigBee Home Automation network and just turn off your Hue Hub.
I'm not sure an xBee ZB is going to work well with WireShark. The ZigBee sniffers I have worked with are tied pretty close to their hardware. Free-scale makes one and you have to use their ZigBee radio as they need to operate down at the 802.15.4 network level.
Hey that sounds fantastic! Its good to see others working with this. For some reason my ZigBee posts have been getting attention lately both here and on the SmartThings forum for some reason..
Thanks for the update!
Hi John,
and thank you for taking the time to reply.
yep, the Osram's use ZLL for the home, and Zigbee Pro/ZLL for the Pro gateway. But, according to Osram it doesn't make a difference as the protocols are interoperable, and the pro gateway in particular should configure itself to the connecting device.
I think there may be a limitation is that if the device is HA then it must connect as an end device rather than a router, but I might have that wrong.
In any event, the current s2c firmware should support both as its the 2007 Pro firmware.
As for the pre-shared key, Lightify supports the key being transmitted unencrypted to devices when joining, so no key should be needed, and indeed doesn't appear to be.
However the HA key you detail works when I enter that as well. There is also the ZLL master key thats been seeded to reddit, but I haven't gotten that to work as yet.
For the most part when I monitor query devices the seem to respond in HA profile (profile ID 0x0104) when I make certain requests, but the frame generator is trying to use profile 0xC105, however inter web seems to report profile ID for ZLL should be 0xC05E, which I also see occasionally.
Basic point of where I am at is that my XBee can join the network, is being registered by the coordinator and given a 16 bit address, seems to receive select traffic from the network that is routed to it, but isn't being identified by the commissioning software.
My hope was to spoof the network into accepting a device ID and manufacturer ID by setting the XBee as having an end point, but I only seem to get it to join in router mode; any attempt to set it up as an endpoint causes the connection to fail.
I missed the but where you said (back in 2014)
And my hope was I could handle the ZDO responses to the coordinator from the XBee itself without using a third party device.
Now I could use the RPi, but I've no idea how similar that is to your propeller board, or whether your code is transposable to it directly.
I feel as if I am almost just 'there' .... but can't quite reach where I want to be.
Frustrating, not helped by my utter lack of understanding about all this.
Andy
The ZigBee Home Automation profile and Light Link profile are basically security definitions devices must follow before being allowed to join a network. I can only talk about the Home Automation profile as that is were I have spent most of my time. Inside the ZigBee coordinator (I guess the Osram hub in your case) is a trust center that manages two sets of encryption keys. The first key is the publicly available Home Automation key. This is the key you have to have configured in your xBee to join a Home Automation network. When a ZigBee device tries to join a home automation network the trust center in the hub will communicate with the new device encrypting the conversation with the publicly available key. If everything looks okay security wise it will give the new device a unique network key (the 2nd key). From now on the ZigBee device will use this new network key to encrypt all its communications to and from the hub. Well almost all packets will be encrypted. There will be some network routing traffic that is not encrypted that flows between routers and the coordinator.
When you say you can join your xBee to the home automation network without a key then your not joining a home automation network. There is just no way unless they are not conforming to the home automation profile. I wonder if your joining some other ZigBee network or your xBee is miss-configured and forming its own ZigBee network.
There are a few other things that give me pause. One is you say your seeing network traffic and you are getting a 16 bit network address. Well that can happen if your xBee is forming its own network as well. But if you only have one xBee you shouldn't be receiving any traffic so that bit doesn't make sense unless you have more than one xBee and they have formed their own network.
It is absolutely possible for the Osram hub to support both a Light Link and Home Automation profiles. It is also possible the server software inside their hub only pays attention to devices that join with the Light Link profile. Home automation devices may be allowed to join but they don't do anything with them.
As for my propeller code porting over to the Raspberry Pi. Well the short answer is no there is not an easy migration over. However, I have documented the heck out of the code and you should be able to rewrite it in whatever language you are going to use on the Pi. Several people have used my code to create libraries for the Arduino so someone may have done it for Python or Node.Js on the Pi.
FYI There is a ongoing conversation over on the SmartThings forum about tweaking my ZigBee library for the Propeller and turning it into a easy to use ZigBee API On Chip (ZAOC) for makers. The ZAOC would be a propeller that sits between your raspberry pi and the xBee radio. You would communicate with it by sending standard strings back and forth. It would take care of all the packet formation and data manipulation required to send and receive standard ZigBee HA traffic all the way down to the cluster / attribute level.
http://forums.parallax.com/discussion/166074/propeller-smartthings-custom-device-handler#latest