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.
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.
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.
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.
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!
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.
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.
Great. Thanks Iman! Canada is a mixed bag when it comes to measurements. Pretty much all Celsius, but some of us still use Fahrenheit for inside temps (well, I do anyway). Of course I'm a mixed bag too. American living in Canada, whom can no longer judge outside temp in Fahrenheit, but I set my home thermostat and all the sensors in Fahrenheit.
I have one of sensors and I just noticed the °F report. I wish we (US) had converted to metric, °C and 24:00 clock when I was in grade school. We were told then there would be conversion to metric but I guess it was too hard.
Story I heard (I was just a kid at the time, and don't recall) was in '75 the US fed adopted metric as the preferred measurement system, and so Canada moved on it, as the US is their biggest trading partner. But by the 80's it hadn't taken hold in the US, but Canada had already changed everything over (for the most part). I'm ex-print industry, and inches is still used, largely due to trade with the US.
Canada being roughly the population of California, wasn't going to spend their minimal tax revenue (in relation to the US) to tear down the changes that had already happened and were already taking hold here, so they stuck with it (except in print ).
Now, as far as internal ambient temperatures for heating are concerned, I much prefer Fahrenheit, because the increments are finer. A 1 °C rise is 1.8 °F. But I'm a Yankee, so there you have it.
Hi, I've had some time to play with your sensor. The communications and functions seem to work well, however I have a question regarding the illumination sensor.
Today outside in the brightest sun we will likely get in New England, the illumination sensor seemed to saturate at 65.1. When some clouds moved in it dropped only about 0.04 At this point I have never entered an illumination factor.
description: "Adjust illuminace base on formula illum / Factor"
No factor entered read: 65.1
I entered a factor or 2, the display then read: 14068
I entered a factor of 10, the display then read: 2813
So I don't understand how the factor works and how to enter a number that is meaningful.
Another observation Hubitat would not display the input description text if a factor was entered, but would if there was no factor. Don't know but I would guess this is Hubitat.
).
