The drop should happen really low level. I am not sure any Hubitat log will show anything.
If you can help, perhaps shutdown those Sylvania bulbs (and all its hub if any) for some period of time. I do not know how long. I would let you use your judgement to determine whether this is the one that cause the packet drop.
You can try to shutdown devices that you added one by one if the count still increase until the configuration before you are adding devices.
My goal is to make sure whether there is a bad device out there in the field. I always assume until today that packet drop should only be caused by interference. I have never thought that it is due to some devices send out bad packets.
If you find a device that cause the packet drop let me know for my record. The next thing is to let it run. I want to know if there is any long term impact when the sensor is subjected to this type of environment.
i added 5 zigbee devices yesterday. seems like none of them are a children to this. i am going to take this out and see if everything continues working normally.
Please let me know about the packet drop count. Yours is still relatively low. At this point, it is just curiosity for me. I do not want to get too obsessive on it as it is a wireless connection after all. There is bound to be some problem. Zigbee upper level protocol will compensate for that.
I also do not know whether packet drop will eventually cause issue. The sensors may just operate fine with that count.
In regard to children, Zigbee end devices are sticky. They will find new parent only when they encounter failure based on my observation. I can force those devices to connect to the sensor by shutting down all zigbee router/coordinator except for the sensor and the end devices for 15 minutes. I do not recommend to do this. I did this once or twice for testing purposes only. I would let the zigbee form its mesh naturally. If an end device not associating to this router, it meant that it found a better parent.
Then, there may be a question about the usefulness zigbee router without children. Yes, the still help in the zigbee mesh network. As a neighbor, it can help with broadcast packets for example.
The more device you add, the more traffic in the network. If there is a bad device in the network, It will increase the count of dropped packet. This is my curiosity. Is this behaviour is caused by one device that is going rouge? Or is it just a weak device try to connect to the sensor? I am more worried about rouge devices in the network.
The decision of an end device to connect to which router/coordinator is not determine by the router (sensor). The end devices will find the first ideal router or coordinator to connect to. It could sound unlikely that none of them will connect to the sensor. However, I could happen. After a while, if it encounter too many issue with the current parent, it will switch over to a new router. In this case, the sensor could potentially be the parent. This is why I personally let the mesh decide. Some people say this process is called self healing.
The packet drop certainly will hurt. This also happen with all wireless protocol. However, the upper level layer of any protocol from Zigbee, Wifi and bluetooth has some way to minimize the impact to the application layer. For example, in wifi, there are a lot of packet drops, with tcp/ip on upper layer, we rarely impacted that each particular packet being dropped.
I am not even 100% sure about it is the issue. I heard from someone in ST seeing the packet drops and mentioned about that sylvania as possibility. So I thought I ask you if you have the same device in your network.
BTW, based on your images, the sensor is still in the network ,right? It is still reporting attributes.
FYI, the sensor is currently not the parent of your devices. The unicast communication from the hub to the devices and vice versa does no go through the sensor. The zigbee commands are typically carried through unicast packet. The sensor probably do not play any role in this case. The sensor could help in handling broadcast packets in your case.
@ogiewon, @bangali. I have another curiosity question. I notice that you guys have more than a handful of reset count for just less than one week operation. Do you guys take the sensor on or off quite a bit? or Do you have power outages?
Mine is kept on one outlet. Most of my sensor are only reseted once.
The data is reset when you shutdown the sensor. If you have the sensor powered all the time, it will roll over based on the size of variable it is stored on.
Someone as ST point to me the DH may need capability "Sensor" so it show up in app like ActionTiles and WebCore. I just update the DH in github with this suggestion. I do not know if we need one here. I just add it in case that this capability help for the sensor to work with as many app as possible.
.
