Please provide link to antenna, or similar. Thanks.
Antenna like this should work.
Or you can search for 2.4GHz 50 Ohms Ipx antenna.
BTW, I will send you my own antenna with your sensor module. You should not need a new antenna unless you want to explore different kind of antenna.
I forget to mention the meaning of RSSI and ResetCount on DTH.
RSSI is receiving RSSI value from last packet received. It is not a transmitting RSSI value. TI chip provide RSSI value on receiving mac packets. RSSI value could be from different devices which may have different distance and power. The value can jump around especially when you have many devices connecting to it.
ResetCount is count of how many time sensor is rebooted (power off). This is not a number of time sensor is factory reset. I use this number to know if I have power issue that may cause the sensor to reboot itself.
Iman, can you please provide the GitHub settings for auto update of the DTH if available?
I do not quite understand the auto update part. If you can help me with some information about the auto update, let see what I can do.
OK it isn’t really auto update. What you do is click the button in the IDE that says “update from repo” so when this info is provided, and you change the code, it shows by change of color and a symbol along side. Below is the example.
Thank you. There is a problem at this time with the IDE, so I can’t update. I get the Internal System error message. I sent request to support.
The number of Children reported is up and down. Most of the time it reported just 1, and sometimes it reported 2 or 3. This afternoon it even reported 5. However, the Neighbor reported is always zero. I have more than 30 ZigBee devices. The repeater should see some neighbors, right? Any clue?
The neighbor count is typically not zero. At least, it is zero not in my home. However, it is possible to have 0 neighbor because it is possible that the all it can get communication with is the children. When neighboring device become a child, it is taken out of the neighbor count. A child decides to associate to this router or other router in your zigbee network.
Yours is a PCB version. One you may want to do is to try to re-position the sensor to be vertical. I am told by the zigbee manufacture, the PCB antenna has radiation pattern perpendicular to the antenna.
To set your expectation, the PCB antenna is designed for smaller coverage. When you are building the mesh with this type of radio, you may need several of them to eventually form a good and dense mesh. In addition, typically we will be dealing with wall and etc. This is where having multiple routers/repeater will help.
I changed the board orientation from vertical (antenna coil horizontal) to horizontal (antenna coil vertical). The Received Signal-Strength Indicator RSSI improved from -73dBm to -64dBm. I will wait for couple days to see if the repeater will get some neighbor.
It actually works pretty good. Reporting sensors.
Packet drop can be caused because its surrounded Sylvania color bulbs repeaters but very inconsistent repeaters.
I am glad with the result you are seeing.
I see a couple member here have really high packet drop. Mine and some of post form other members have very low packet drop.
I am concerned about them. Packet drop count is an incomming packet statistics. I think this due to some sort of interference. Do you have 2.4Ghz wifi overlapping the zigbee band? Other zigbee devices with the same frequency would not cause packet corruption hence packet drop. Unless, the Sylvania send incompatible or corrupted packet.
If you can afford to test shutting down the Sylvania temporarily, please help do so. I am courious while the Sylvania is off, would your packet drop keep going up? This is not urgent. However, if you can find a time to do this, it would help me.
I’m planning Friday to do some xctu mapping with xbee that should show even more than shutting Sylvanias.
Sylvanias are unfortunately difficult to access and turn off.
I am interested in making some of these myself for a couple of places in my house. Is there a GitHub repo with the PCB files and device handlers for these?
Here is the DTH for the sensor.
I have not decided to make the project open source. I do not know where it is going at this point other than it is a hobby. Is there a hope to commercialized it for me? Yes, I am hoping. However, we all know how far hope is from reality. There is not any business plan for me at this plan.
Meanwhile, If you are interested on testing the sensor, I can make a few of mine available to you. I do request $15 donation for each sensor. I just want to share the experience with the module in the other houses. This cost is to recover buying bme280, light sensor, Zigbee radio. If you are interested, send me a PM.
I do not see any packet drop, but I do see fairly high (>8k) TX Fail and TX retry. Also expected neighbor count to be a count of devices/routers that are not children, but that doesn’t seem to be the case. what causes neighbor to increment?
The neighbor count can change overtime especially if there are some weak devices from the perspective of the sensor somehow. The neighbor count is simple. If it get a packet from new device, it check if it is from one of its entry in the neighbor table. If it is not in the table, it will increase the count. After a timeout, if a packet from a neighbor is not heard again, it will decrease the count. This is as simple as that. I do not expect this to be stable count in every environment(house).
Children can go up and down too. It is more deterministic. I have ST presence sensor. This ST presence can stick to this sensor. It will cause the child to increment. When you leave the house, the child count can decrease as well.
The TX Fail & Retry will increase. The bigger your network is the more TXFail/TXRetry. If you have one pair of devices in the network, there error should be small. If the 2.4GHZ band that zigbee channel use is clean,
you will have lower failure. However, we leave in imperfect world. I would not spend too much getting this number down. The upper layer Zigbee protocol should have retry mechanism to compensate for it. This attribute is important when you have a base number of failure per period of time. When they jump, it does tell you something in your network may be wrong.