I have tried & implemented successfully light switch tutorial from scratch as per https://www.silabs.com/community/wireless/zigbee-and-thread/knowledge-base.entry.html/2019/01/07/zigbee_3_0_tutorial-FUTT
I'd like to thank RonB for that amazing tutorial. It helped me understand how projects are created from base.
Next up, I wanted to get temperature sensor reading from the switch node to be reported to the light node.
I created two new endpoints with - 1. HA Remote on Light (Temperature Cluster Client) (EP 2) and 2. HA Temperature Sensor(Temperature Cluster Server) on Switch (EP2).
I want temperature server to report to client periodically & when there is a change in attribute.
If RonB could make a similar tutorial, I'd be the most happiest! Else following are my questions.
1. How to read temperature sensor after enabling SI Temperature Plugin.
2. How to do the binding. Which device will be Bind Initiator and which will be Bind Target.
3. Which callbacks will be required?
4. Where can I learn more about the reporting mechanism except from SI UG102 No simple explanations anywhere I could Find.
5. As I am new to Zigbee Networking, Can any one suggest some books which will help me get the basic concepts cleared, and also help me with Z3.0?
Sorry for so many questions.
我是用EFR3213P的模块进行找网动作，发现当设备发送beacon request 时，网关无beacon 发出，表明网关并没有接收到beacon request，
我希望在找网时，能够在一个信道停留发送beacon request 时，能够多发送几个（当前，一个信道只能够发送一个beacon reqeust），请问
Dear friends, everyone!
Device or terminal Join the coordinator, the coordinator's callback that function? This way I can know which device is connected to the network.
GPIO_PinModeSet(gpioPortF, 2, gpioModePushPull, 0);
GPIO_PinModeSet(gpioPortF, 0, gpioModePushPull, 0);
We did suffered with GatewayHost 6.5.0 for few weeks.
We found the end device can't join after several cycles of joining/leaving devices( each cycles we join 10 devices and leave them all ).
All end devices are NO router function.
But when we added one plug with router function, those end devices will join successfully.
Please give your advice.
The PDF, ZigBee Overview & Concepts,
Page 23 says that the network address may change over time. I am very confused.
When the Network Address (node ID) will change? How does it change? Does the node ID change if the node does not leave the network? Does it change if no new device join in?
Hi Silicon labs team,
I am novice for your reference board, SDK and simplicity studio so that I want to ask some basic questions.
Here is my reference board(EFR32 Mighty Gecko Starter Kit) and the link of my reference board(https://www.silabs.com/products/wireless/mesh-networking/efr32mg-mighty-gecko-zigbee-thread-soc)
Do you have any SDK that combine with the Zigbee and BLE for the reference board of EFR32 Mighty Gecko Starter Kit? Or You just have only one of them(Only Zigbee or Only BLE)?
Could you provide the link and teach me how to download the SDK to your IDE(Simplicity studio) If you have both(Zigbee + BLE) ?
During development of our Zigbee application based on the EFR32MG12P432F1024 MCU we have discovered some strange behavior. Unfortunately the communication range between the sleepy end node and the coordinator is very short (around 6m) during the first connection. Once they are connected, the communication range is acceptable (>25m).
We are using the connection manager plugin on the sleepy end node, the tx power is set to the maximum +19dB on both side, also we tried the tx boost mode to gain some more distance, but without any significant results.
The outcome of the first connection is unpredictable. Sometimes the connection is successful from this 6m test range, but this happens only very rarely. Usually the end node will not find the network, or it will somehow connect to it, but it will not get to the binding stage.
This also affects the power consumption of the end node. If it can not join because it can not see the network, it will go to sleep based on the algorithm of the connection manager plugin. But if the connection process get stuck because of the high data loss, the end node can stay powered on permanently. This is critical in the final application, we would like to avoid this.
Do you have any idea why the communication range is significantly shorter during the network find/connection stage? Can you give any advice or solution to increase it?
I have updated a coordinator to version 6.5.3 and wished to pair a device, however an unexpected Mgmt_Permit_Joining_rsp with status 0x80(INV_REQUESTTYPE) is returned and the device does not pair. The Mgmt_Permit_Joining_req is send to the coordinator via sendUnicast frame of EZSP prootocol. In previous version(6.4.1) there was no such problem. Also when the Mgmt_Permit_Joining_req is broadcasted everything works as expected.