I'm handling the Smartthings Zigbee motion sensor and i know this is IAS Zone device.
I read an question-answer and they said, "Before you get the information from the sensor, you need to enroll first."
(zigbee motion detect sensor usage)
so i tried to send 'write attribute command' to the sensor to enroll first on my python code like this,
data='\x00' + '\xaa' + '\x02' + '\x00\x10'+'\xf0'+'my MAC address'
('02' means write attribute command, '0010' means attribute of the Zone setting, 'f0' means data type-IEEE address)
this raw data format is from the 'zigbee cluster library' document.
but the sensor gave me 86 status, which means UNSUPPORTED_ATTRIBUTE
well, i think the command is wrong and my assumptions are,
-the format is wrong.
-the values i used is wrong.
-or both.
If you have any idea or any little hint, you can help me. thanks to read!
For most Zigbee security devices (IAS) you need to use these steps
You must advertise that you support the IAS cluster client when receiving a MatchDescriptorRequest (this one depends on product)
Write your IEEE address to the IAS CIE Address attribute (cluster 0x0500, attribute 0x0010)
Send a ZoneEnrollResponse with status ENROLLED to the device (some devices may require that you "trip" them and wait for them to send the ZoneEnrollRequest first)
For your packet format, Zigbee uses network byte order. I think your attributeId should be \x10\x00. This will matter for for the IEEE address as well.
Related
I am working on making a custom controller for an aquarium light. I was able to figure out how to adjust the light's internal clock, and I was able to capture some of the communication, and I found this timecode 545f0d31574d52565951607631 which translated to ascii from hex becomes T_ 1WMRVYQ`v1. I know for sure it's the timecode, because it works as expected.
Anyone know what it is? Is it BLE specific? anyone know how to alter it?
I'm pretty sure the first 4 numbers are not part of the code, but a indicator for the device.
Edit:
It is BLE. I should have been more clear. It does most of the transmission on UUID 1000, with the characteristic uuid being 1001. The device doesn't have a built-in clock that I can see. It turn's on and off at the times I specify in the developer’s app. After a power failure, it "resets" to midnight. I know that value is the timecode, because when I input it using gatter tools, I can see the light reacts accordingly. I added a photo of it updating. –
You hint that that this is a Bluetooth Low Energy (BLE) device.
If it is BLE, then the UUID of the characteristic might be in the 16-bit UUID Numbers document. If it is a custom characteristic, then it will not. Official characteristics have the base address of 0000xxxx-0000-1000-8000-00805F9B34FB and only the four missing values are documented.
The specification for how time can be shared over BLE is documented in the GATT Specification Supplement if it is a Bluetooth SIG adopted characteristic.
It might be helpful if you update the question with what this values gives as the value on the light's internal clock.
The output string is:
▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒~▒▒ffx▒f▒x▒x`▒x▒x▒x▒`▒x~x▒▒x▒▒x````▒````▒x~xx▒x▒f`▒x▒
And I know that over RS232 the output should look similar to:
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿSITE NAME,24/07/18,13:15:00,60,0.000,0.000,2.911,2585,
The time may change, as well as the last two numbers but the rest of the string should be consistent. Is there a way to figure out the character set that was used?
It is written in RS-485 Wikipedia as follows.
Protocols
RS-485 is not a protocol; it's simply an electrical interface. Although many applications use RS-485 signal levels, the speed, format, and protocol of the data transmission is not specified by RS-485. Interoperability of even similar devices from different manufacturers is not assured by compliance with the signal levels alone.
If the specifications of the device you are trying to connect are not documented, you only have to look it up with a measuring instrument such as an oscilloscope?
Your Problem might be having selected the wrong baud rate. Check your manual!
I try to use beacon(HM-10) to broadcast my sensor's data, but there is a problem that I use a loop to write AT commands, after a while, it doesn't respond anything.
Here is the part of the code:
String pre = "AT+MARJ0x";
int sensorData = 0;
loop () {
sensorData = getSensorData(); // always returns 100 ~180
String atCommand = pre + sensorData; // ex: AT+MARJ0x100
BTSerial.print (atCommand);
delay (200);
}
It initially work successfully about 3-mins, and then it doesn't work and can't be sent any at commands.
Can anybody help me fix this problem?
What you are trying is not possible with an Ibeacon.
All you do is set-up the major number of Ibeacon data in your HM-10device over and over again with sensor data.
major number is a part of the Ibeacon data spec:
(source: https://developer.mbed.org/blog/entry/BLE-Beacons-URIBeacon-AltBeacons-iBeacon/)
Data Spec:
IBeacons broadcast four pieces of information:
A UUID that identifies the beacon.
A Major number identifying a subset of beacons within a large group.
A Minor number identifying a specific beacon.
A TX power level in 2's compliment, indicating the signal strength one meter from the device.
This number must be calibrated for each device by the user or manufacturer.
A scanning application reads the UUID, major number and minor number and references them against a database
to get information about the beacon;
the beacon itself carries no descriptive information - it requires this external database to be useful.
The TX power field is used with the measured signal strength to determine how far away the beacon is from the smart phone.
Please note that TxPower must be calibrated on a beacon-by-beacon basis by the user to be accurate.
For a HM-10 device AT-commands are normally only used to set-up the device, not for sending data.
Google some examples and learn how to setup communication between BLE devices.
I am using XBee Digimesh Modules in API-Mode to send data between different industrial machines allowing them to share data, information and commands.
The API-Mode offers some basic commands, mainly to perform addressing and talk with the XBee Module itself in order to do configuration, etc.
Sending user data is done via a corresponding XBee API-Command which allows to send user-defined data with a maximum payload of 72 Bytes.
Since I want to expand this communication to allow integration of more machines, etc. I am thinking about how to implement a basic communication system that's tailored perfectly to the super small payload of just 72 Bytes.
Coming from the web, I normally would use some sort of JSON here but that would fill up the payload very quickly.
Also it's not possible to send a frame with lot's of information since this also fills up the payload very quickly.
So I came up with a different way of communicating. Instead of transmitting frames packed with information, what about sending some sort of Messages like this:
Machine-A Broadcasts: Who's there?
Machine-B Answers: It's me I am a xxx-Machine
Machine-C Answers: It's me I am a xxx-Machine
Machine-A now evaluates the replies and decides to work with Machine-B (because Machine-C does not match As interface):
Machine-A to B: Hello B, Give me some Value, please!
Machine-B to A: There you go: 2.349590
This can be extended to different short messages. After each message the sender holds the type of message in a state and the reply will be evaluated in relation to the state / context.
What I was trying to avoid was defining a bit-based protocol (like MIDI) which defines all events as bit based flags. Since we do not now what type of hardware there will be added in the future I want a communication protocol that's very flexible and does not need a coordinator or message broker, etc.
But since this is the first time I am thinking about communication protocols I am curious to know if there might be some existing frameworks that can handle complex communication on a light payload.
You might want to read through the ZigBee Cluster Library specification with a focus on the general commands. It describes a system of attribute discovery and retrieval. Each attribute has a 16-bit ID and a datatype (integers of various sizes, enumerated types, bitmaps) that determines its size.
It's a protocol designed for the small payloads of an 802.15.4 network, and you could potentially based your protocol off of a subset of it. Other ZigBee specifications are simply a list of defined attributes (and commands) for a given 16-bit cluster ID.
Your master device can go through a discovery process to get a list of attribute IDs, and then send a request to get values for multiple IDs in one shot. The response will be packed tight with a 16-bit ID, 8-bit attribute type and then variable length data. Even if your master device doesn't know what the ID corresponds to, it can pass the data along to other systems (like a web server) that do know.
When using a non beaconing Zigbee network, I know that the 802.15.4 spec defines the use of CSMA-CA to control when two devices get access to a channel to make sure no two nodes "step on each others toes" so to speak. My understanding is that very simply, it requires each node to "listen before talking". Is that correct? Is there more information on the Zigbee implementation of this? In other words, where do I go to learn more about how to program a Zigbee chip to implement the same?
Also, if i have 20 end nodes sending data asynchronously to one coordinator, is the channel access mechanism enough to ensure that they do not broadcast at the same time and flood the coordinator? If five nodes (for example) attempt to broadcast at the same time, how will mutual exclusion be ensured? Where can I get some details on that?
Thanks
Rishi
The maximum size of a 802.15.4 packet is 1024 bits of payload. So the maximum duration of the frame (running in standard 250kbps rate on the 2.4GHz band) is about 5ms when you take preamble etc into account. If your end devices are polling at 1 poll/second it should easily manage 20 end nodes I think. If it gets too much the exponential backoff should ease the collision rate.
I'm sure you've seen these when searching, but just in case:
http://www.prismmodelchecker.org/casestudies/zigbee.php
http://www.dagstuhl.de/Materials/Files/07/07101/07101.FruthMatthias.Slides.pdf
http://www-public.it-sudparis.eu/~gauthier/Tools/802_15_4_MAC_PHY_Usage.pdf