I did it one device at a time but in hindsight you could look at what is connecting to the environment sensor with your Xbee see if there are any odd transmision levels and start with those first.
@bangali, The only issue that I see on your stat is PacketDrop. We have not been able to narrow down this issue. Packet drop happen in my network as well. However, they are very small. Maybe, I got 1 or 2 in a month.
I can only guess that the packet drop is due to probably interference or weak signal from one of your device. However, there could be other issue that is more specific to your network.
In regard to TXFail and TXRetry, I do have much larger error in my case as well. I do expect this. They are stat from mac level transmission. It is not TX fail at Zigbee APS level. At mac level, wireless communication will have error. At higher level, the protocol will have retry mechanism. All cluster level code probably would not know that there is a drop in packet. Excessive number of TX error can cause delay in packet transmission. However, they have to be excessive.
Based on your yesterday and today data, you have about 200 to 300 mac packet error. I think those are not out of ordinary.
Thank you.
thanks i will give that a shot.
i now have 2 xbees roughly on opposite corners of the house. since putting these in i have not had any zigbee devices drop off including xiaomi devices. general signs are the network seems to be very stable.
as more and more users use these sensors its likely that others will also run in to this issue ... so it would be good to get to the bottom of this.
let me try what @NoWon suggested and see if i can find which devices are routing thru the env sensor and if any of them have odd transmissions.
fair point. if i can nail down the packet drops i would be less worried about the tx stats. lets see how it goes … will update once i have more data.
thanks all.
Yes, This is always a concern with any devices. I agree that It is good to get to the bottom of it. @NoWon go all the trouble of starting from scratch and add up one device at a time to find the offending device. It is an example of how to find the issue. This is one way of finding a conflict. Another is as suggested by @NoWon, you can analyze the graph and look for potential issue by looking the neighboring devices. I would not want you to reconfigure your devices for this effort if it is not possible. However, it may not be possible to do without "process of elimination" troubleshooting. In any case, I hope you can find the issue without blowing up your network.
Yes. I am more concern about the packet drop. They are excessive compare to what I observe. I have a lot of these sensor obviously. They are not even close to see what you saw with yours in packet drop department. I have one router that has been up for 3 months. There is not a single drop on that one.
You mention about an issue with OSRAM to me in this thread. After reading the link, the issue related to buffer overflow. A packet come out of overflow potentially will be an invalid packet (for example, crc can be wrong). At mac level, 802.15.4 has CRC filed in the frame to be check against. When it arrive at the environment sensor, this will be count as dropped packet. This is a possibility.
1 Like
If the property children in the diag report is working, then none of them are...
Children in this case should represent the count of devices that call this device it's parent, aka it's router.
thanks @mike.maxwell that makes sense with both the xbees around.
@iharyadi is there a way to turn off the routing functionality and simply use as a sensor for light, humidity and pressure?
We do not have enough space to load both end device and router firmware into the module. However, this is an interesting idea. If enough people want a end device firmware, I would like to accommodate it.
However, going back to "looking for root cause of the issue", I prefer to look at the offending device (or issue) and fix it there. If a device in your network causing issue, wouldn't you want to know about it?
being able to change firmware to an end device to create a presence sensor (you would not want a router as a presence sensor) would be a nice option and give people even more options for one device.
Since your environmental sensor appears to be more sensitive and can detect drop packets so well using it for network interference detection is another idea.
Being able to select router or end device is an interesting idea for me. If the device can store both firmware, I would be happy to accommodate it. With this platform, the more realistic goal is to make 2 different module (one with routing capability and one without).
Normally, in zigbee, a DC/AC powered device should be a router although it is not mandatory. I also briefly read if the device is very restricted in resources (RAM or Storage). they should also be an end device. If a device can be a router based on power and resources availability, a cluster type (be that a presence, on/off switch, etc) do not typically be considered as a factor for device type. This idea is a good input for me. It is something that I can use moving forward when playing around with new idea. I will consider take the device cluster when determining a device should be an end device or not.
2 Likes
How are you programming the zigbee module? Can you let us know the toolset you're using for development with this zigbee module?
thanks,
TI CC2530 has their own development ecosystem based on variety of tool. One of the zigbee implementation is based on their z-stack.
Thanks Iman! Now I just have to wait for DigiKey to send me the XBee module. This is the longest I've ever waited for an order from them. I once ordered a component from DigiKey at 10pm, thinking it would take a few days. To my complete shock, a courier was handing me my part at 7:30am the next morning, and I hadn't paid for overnight shipping.
Thank you for letting me know. I hope you find it useful.
1 Like
I know I'm going to have fun. Thanks for the great work. Do you buy the boards or do you have the capability to etch, coat and silk screen your own boards? Are you adding the surface mount components? It's nice work, either way!
I buy the board from PCBway. I do not have capability to manufacture them. I have small reflow oven that I can use to solder the smt/smd component.
Oh, that's so nice. I would love that capability.
Just getting around to playing with this (Still waiting for my Xbee 
).
The driver state showed temp in Fahrenheit when I paired it, but the adjustment scale is Celsius. My HE location settings were set to Fahrenheit, when I installed it, so I had change my location settings to Celsius, and click "Save" in the driver settings, then I could change my location temp scale back to Fahrenheit without affecting the sensor, but if you click "Save" again while you're back on Fahrenheit in the location settings, it will revert back to Fahrenheit scale (makes sense to me). Not sure if that sticks after reboot though. I'll find out once todays hub update drops in.
Would be nice to have a way to switch that in the driver. Just thought I would share this if anyone else it playing with Iman's Environment Sensor and wants to view a different scale.
BTW @iharyadi, minor thing, but Celsius is misspelled in the driver. 
Thank you. I just fix it in github.
The zigbee speak Celsius for temperature. This is the value that the sensor send in order to be compliance with zigbee. At this moment, It is easier for me to work with Celsius during the adjustment. In long term, I do understand the confusion for all of us that use Fahrenheit locale. I will find a time to figure out in the future to make the adjustment GUI setting in the locale of the user.
