These "harmless" errors are from a type of non-useful message typically occurring during the pairing process that the driver isn't coded to handle.
I will be updating the drivers to ignore that type of message without throwing an error. Thanks for the report!
Yes, I've seen the same, in past when I changed my hub's ZigBee channel, though a couple of Xiaomi / Aqara devices managed to change over by themselves. Manually rejoining the devices sped up the process of bringing them all over onto the new channel.
One thing to realize is that a repeated value will not generate an event. Only when a newly reported value is different from the previously reported value will an event be generated.
Otherwise, the frequency of temperature / humidity / pressure reports is entirely set by the hardware, and completely out of the control of the device driver as the sensors won't accept any normal ZigBee commands to adjust reporting.
Also, I can say that in my experience, some ZigBee Repeater devices drop messages from Xiaomi / Aqara devices, despite allowing those Xiaomi / Aqara devices to remain connected to the ZigBee network. This issue can even manifest in only some messages being dropped, particularly when a number of messages are sent rapid fire, as is the case with the Temp/Humidity sensors, which normally send temperature / humidity / pressure reports at the same time.
I notice from your post with the output from getChildAndRouteInfo that for example, your "Kids Bath TH 2" is routing via a "Vero bed". I don't know what the "Vero bed" is, but if it's not in the list of reported compatible routers/repeaters in the OP of my other thread here, I'd be suspect of that router device possibly dropping some of the Temp/Humidity sensor's messages.
The multiple rapid open/close issue has been mentioned before, by @gavincampbell, here.
I explained some possible reasons for this in the next post, and after that I tried some modifications to the code to filter out extra unnecessary open/close events. @gavincampbell came up with a better solution that seemed to work, but I never had a chance to roll it into a full release update of the driver code.
It sounds like I should revisit that modified code...
