I'm making a source code, so that I can get an alarm information from the IAS sensor device.
I'm using the smartthings motion sensor and Xbee device to make a communication between the sensor and my computer.
I'm wondering the step to handle the IAS Zone device
well, let me show you how i understand this.
there are 2 types of devices, the CIE(coordinator), and the IAS Zone device(like motion, fire etc)
the CIE sends a 'enroll' message to the IAS Zone device
confirm success on the response message from the IAS Zone device
the CIE sends again a 'response' message to the IAS Zone device with ZoneID
after that, the CIE can get the alarm data from the IAS Zone device
I think step 4 is not correct.
Could anyone let me know the detail about it?
how to enroll and what is the 'response' message for the IAS Zone device, and what is the Zone Id and how to handle the ZoneID?
I'm focusing on the concept, not how to use method like 'EnrollRequestResp()'
Thanks
A bit late, but I hope it helps someone in the future.
there are 2 types of devices, the CIE(coordinator), and the IAS Zone device(like motion, fire etc)
Yes.
the CIE sends a 'enroll' message to the IAS Zone device
No.
CIE must write (using Write Request) to cluster 0x0500, attribute 0x0010, data type IEEE address, value CIE's 64-bit address (be careful, format is little endian).
CIE receives Write Response, indicating (hopefully) success.
NOTE: everything below happens only when the address has changed (!!!). To trigger the change again, change the address to 0x0000000000000000 (which is incidentally also the way to un-enroll the IAS Zone Device) and then back to CIE's.
CIE receives Zone Enroll Request
CIE sends Zone Enroll Response
You can then confirm that end device in enrolled by issuing Read Request on cluster 0x0500, attribute 0x0000 (ZoneState).
Related
I have experimenting with Bluez 5.50 Bluetooth Stack, Here i have some confusion about procedure Auto-connection using Whitelist.
Suppose,
Device A - Advertiser
Device B - Scanner
Add Advertisers(Device A) Bluetooth address as white list in Scanner(Device B)
Device A will advertise with "Connectable Un-directed" adv type & default adv params
Device B will start scanning with "Accept only PDUs from device in white list" configuration
If B scans A's address, than explicitly B will send connection request to A(Without sending Connection create command)
What is basic difference between paired device & white listed device ?
The white list can be used both when just scanning as well as when connecting.
Note that the packet exchange during advertising is this, when the central device is just scanning:
Advertiser sends ADV_IND.
Scanner sends SCAN_REQ.
Advertiser sends SCAN_RSP.
When the central device has a pending initiation (i.e. connection attempt) to a peripheral, the packet exchange is this:
Advertiser sends ADV_IND.
Initiator sends CONNECT_IND.
The connection is now established.
Note the timing between between to packets in the flow above is 150 microseconds (T_IFS), which is quite quick. If the advertiser does not detect SCAN_REQ, it does not send SCAN_RSP. If it also does not detect CONNECT_IND, it does not enter the connection state, but continue to advertise. There is a need to have a white list because the host would not be quick enough to decide if the packet should be dropped or not. Therefore the white list is implemented directly in the Bluetooth controller hardware.
A central device using the white list, will simply drop any ADV_IND having an address that cannot be found in the white list. Therefore no SCAN_REQ or CONNECT_IND is sent in this case.
"Auto-connect" therefore refers to when the initiator is constantly looking for ADV_IND packets where the sender's address is in the white list. If one is found, a CONNECT_IND is sent and the connection gets established, resulting in an "LE Connection Complete" event. Using the white list is the only way to have two or more pending connections, since otherwise you need to specify exactly one target address when initiating a connection. (Although a workaround sometimes used when the white list cannot be used, for example if it is too small to contain all desired addresses, is to let the central first perform a scan, then initiate a connection to the target addrerss, with some short timeout. This introduces latency as at least two ADV_INDs must be sent.)
Paired/Bonded device is a completely different thing. It means that both devices have stored in its database, information about the remote device, such as encryption keys, client characteristic configuration descriptor state, gatt db cache. Bonded devices are usually listed in a user interface as well.
When the white list is used when establishing connections, you can have addresses in this list of non-bonded devices. You can also have bonded devices which you do not currently want to connect to, which are then not included in the white list.
What I've written above is general BLE without any specific Bluetooth stack in mind. BlueZ might have certain conditions/flows when the white list is used.
What are the cases Access point disconnect station without sending disassociation or deauthentication to station?
I guess it would be pretty strange...the AP is meant to send a disassociation to any connected station. The only possibility that springs to mind is failing to find "clear air" while sending the disassociation.
I.e. AP decides to disassociate a station. The MAC layer receives the request to disassoc the station, and puts it in a queue. Every time the AP attempts to send the disassoc frame there is something else sending, and the AP does not pass the collision avoidance check. Eventually the request in the MAC layer times out.
I know that MIC and CRC exists with ble data packet but i don't know if checking integrity is available with ble devices or i have to implement a code that offer this .
For timestamp , can i get the time from ble devices to know when the message is sent .
CRC and MIC are part of the data packets and checked already on Link Layer level. You do not need to implement extra code in your appliccation to do this checking.
Data packets from a BLE device do not automatically contain a time stamp. Note that many peripheral devices do not even have a clock and thus can't know the current time.
If you want to have a time stamp with your message, you typically have two options:
1) You log the time on the central device; in this case, the time stamp is the time of the incoming read response/notification/indication. This has the advantage that it is easy to implement, but you lose the information when the data was actually collected, which may be important if there is a relevant time discrepancy between collection and receiving of the data.
2) You log the time on the peripheral device and send it as additional data together with the original message (for example, adding a few bytes at the end of the message that represent the date and time). This is the recommended approach, but you have to be able to define the messages sent by the peripheral device. If you only have control over the central, this option is not possible.
I read in some places that advertising packets are sent to every one in the distance range. However, should the other device be scanning to receive them or it will receive it anyways?
The problem:
let's say I'm establishing a piconet between 5 or 6 BLE devices. At some point I have some connections between the slaves and one master. Then if one of the devices get removed/shut off for a few days I would like it to reconnect back to the network as soon as turned on.
I read about the autoconnect feature but it seems when you set it true, the device creates a background scanning which is actually slower (in frequency) than the manual scanning. This makes me conclude that for the autoConnect to work the device which is being turned on again needs to advertise again, right? Therefore, if autoconnect really runs a slow scan on background so it seems to me that you can never receive the adv packets instantly unless you're scanning somehow. Does that make sense?
If so, is there any way around it? I mean, detect the device that is comming back to the range instantly?
Nothing is "Instant". You are talking about radio protocols with delays, timeouts, retransmits, jamming, etc. There are always delays. The important thing is what you consider acceptable for your application.
A radio transceiver is either receiving, sleeping or transmitting, on one given channel at a time. Transmitting and receiving implies power consumption.
When a Central is idle (not handling any connection at all), all it has to do is scanning. It can do it full time (even if spec says this should be duty cycled). You can expect to actually receive an advertising packet from peer Peripheral the first time it is transmitted.
When a Central is maintaining a connection to multiple peripherals, its transceiver time is shared between all the connections to maintain. Background scanning is considered low priority, and takes some of the remaining transceiver time. Then an advertising Peripheral may send its ADV packet while Central is not listening.
Here comes statistical magic:
Spec says interval between two advertising events must be augmented with a (pseudo-)random delay. This ensures Central (scanner) and Peripheral (advertiser) will manage to see each other at some point in time. Without this random delay, their timing allocations could become harmonic, but out of phase, and it could happen they never see each other.
Depending on the parameters used on Central and Peripheral (advInterval, advDelay, scanWindow, scanInterval) and radio link quality, you can compute the probability to be able to reach a node after a given time. This is left as an exercise to the reader... :)
In the end, the question you should ask yourself looks like "is it acceptable my Peripheral is reconnected to my Central after 300 ms in 95% of cases" ?
I have a problem with my CC2531 USB Dongle. I use it as a Zigbee coordinator. I can see all the devices inside my PAN, but IAS zones are not communicating with it. When I change the state of contact switch, or Motion sensor, I don't get data in my gateway app. But, I have IAS remote controller, and in my gateway application i get data on TCP port when i click remote controller button. I read something about Enrollment function on coordinator, but I don't really understand what it means. I guess that problem is that I don't have IAS CIE and I need my CC2531 to act like one.
Does anyone have idea what to do? Do I need to flash other firmware or change something in config files. I am quite new in this so I don't really know what is important, so if you need some additional info please ask.
IAS Devices work slightly differently than other Zigbee devices in that they are "locked" to a CIE node. This basically means that commissioning IAS devices requires the following steps
Write your USB dongle's IEEE/MAC address to the IAS CIE attribute on the device
If the device is "trip to pair", trip the sensor and it will send in a ZoneEnrollRequest message, to which you respond with a ZoneEnrollResponse with a status of SUCCESS
If the device does not require "trip to pair", you can just directly send a ZoneEnrollResponse message after writing the IAS CIE attribute.
Out of curiosity, which brand of sensors are you testing with?