Holy mackerel! That's a lot!!
I notice this with both temperature and humidity on one of my sensors as well, but it's one that I've kept outdoors (covered, but outdoors) and just figured the weather finally got to it. It did it even when I took it inside for a while (wasn't sure if sub-0-degrees C temperatures were special; I know they've been problematic before). None of my other sensors--all of which have remained indoors the whole time they've been in use--have been doing this.
I'm not sure exactly how these two anecdotes would connect unless perhaps the bathroom has excessive humidity on occasion or it's very near a water source (I wouldn't doubt that there's been condensation on or at least near my outdoor sensor at some point). I told myself that at this price, I don't care too much...but I am trying to figure out how to get the several-hundred-degrees-below-zero readings out of my Home Assistant history graphs. 
1 Like
Yep, I bought 100 on Alibaba with two day DHL shipping. I've got 4 Hubitats and one zigbee2mqtt system. 24 condos and 30,000 sq ft.
1 Like
All the surrounding values are normal. It would report in something like "37.5, 38.0, 37.5, 37.0, 654.4, 37.5, 37.0 etc" It shows up almost every hour and the correct humidity is reported almost right after as well. So its like this message is a status message of some sort.
The raw command is always the same when it send in that weird reading. Its doing it on all of my sensors so I'm wondering if its something that was changed in 2.1.7. I'm usually running the latest beta but that one is now released to all.
For now I just filter out that value so it doesn't affect me, but something to keep an eye out for. I only noticed it because my bathroom fan automation was kicking in randomly and this is the reason why.
Just out of curiosity, have you had any issues with those sensors?
- falling off the Zigbee mesh (i.e. not reporting every hour)?
- just going "off the air"?
No more dropouts since increasing the mesh from 6 to 11 routers per building. Not sure if my heterogeneous mixture of routers has anything to do with it.
4 IKEA plug outlets per building
6 CC2531 routers per building
1 Aqara plug per building paired only as a device
Parent child parameters
EzspGetParentChildParametersResponse [childCount=0, parentEui64=0000000000000000, parentNodeId=65535]
Child Data
Neighbor Table Entry
[IKEA RouterPlug 206, 09A2], LQI:223, age:3, inCost:5, outCost:7
[DIY Router 204, 1472], LQI:255, age:3, inCost:1, outCost:1
[DIY Router 203, 3856], LQI:254, age:3, inCost:1, outCost:3
[DIY Router 201, 769A], LQI:255, age:3, inCost:1, outCost:1
[IKEA RouterPlug 205, 7A5A], LQI:234, age:3, inCost:5, outCost:7
[DIY Router Spare 202, 81E0], LQI:253, age:3, inCost:3, outCost:5
[IKEA RouterPlug 202, A9FE], LQI:255, age:3, inCost:1, outCost:5
[IKEA RouterPlug 201, C426], LQI:254, age:3, inCost:1, outCost:7
[DIY Router 206, DF76], LQI:250, age:3, inCost:3, outCost:7
[AqaraPlug Router 205, E4FF], LQI:187, age:3, inCost:7, outCost:0
Route Table Entry
status:Active, age:64, routeRecordState:0, concentratorType:None, [AqaraPlug Router 205, E4FF] via [DIY Router 206, DF76]
status:Active, age:64, routeRecordState:0, concentratorType:None, [DIY Router 206, DF76] via [DIY Router 206, DF76]
status:Active, age:64, routeRecordState:0, concentratorType:None, [DIY Router 201, 769A] via [DIY Router 204, 1472]
status:Active, age:64, routeRecordState:0, concentratorType:None, [DIY Router 203, 3856] via [DIY Router 203, 3856]
status:Active, age:64, routeRecordState:0, concentratorType:None, [DIY Router Spare 202, 81E0] via [DIY Router 201, 769A]
status:Unused
status:Unused
.......
Notice how the Hubitat prefers CC2531 (DIY) routers
1 Like
Well here's an indication of how busy I've been since the summer: My hub is still running 2.1.5.124, though I could swear I had updated to 2.1.6.
Anyhow, I've looked through all the release notes of 2.1.6 and 2.1.7 and see nothing that would indicate a change to the Zigbee stack, which is the only thing I can think of that would alter how messages received from the sensor are parsed.
I've backed up some hours of old logs from a couple of my T/H sensors, and will now update to 2.1.7.125 to see if there's a change. My suspicion is that there may be some messages which are part of the hourly check-in that were previously filtered out but are now passed on to the driver as of firmware 2.1.7. If true, then I just need to add code to filter out the non-useful messages that are producing the out-of-bounds values.
I'll report back when I've seen enough logs to know either way.
1 Like
I'm on 2.1.7 and have ~15 of the temp/humidity sensors. I haven't received any weird readings (humidity or temperature). Since going to 2.1.7.
I know that doesn't help @gavincampbell, but I thought another data point may be useful.
2 Likes
Definitely helps.
Interestingly enough, three of my sensors eventually had their battery die and I replaced the batteries.. I just looked at my past logs and have not seen it report on those threerecently. However my two other sensors are still kicking the error every now and then.
Just a wild thought but wonder if its related to the battery about to die. I'm going to keep an eye on things and see if these other two sensors are going to die any time soon.
I am on Xiaomi Temperature and Humidity Sensor and using Version 0.8.2 of the driver by veeceeoh.
I notice that after adding it to Hubitat, the sensor stops reporting readings 1-2 hours later. For example, after adding the sensor at 5AM, I receive readings whenever there are changes in temperature/humidity. This goes on until 1-2 hours later when it goes silent.
I tried to use 'Discover Devices' and Hubitat was able to detect the sensor and readings are reported fine but this time, the readings only lasted for 30 minutes or so.
Battery level is 100% and I had removed and re-added the sensor as well.
Just wondering if there's any step I had missed out:
- Activate device discovery on Hubitat
- Long press button on Xiaomi temperature sensor
- Hubitat found sensor and tried to add it (in my 2nd attempt to re-add the sensor, I had also short press the sensor repeatedly to keep it awake)
Appreciate any advice, thanks!
Are your zigbee repeaters Xiaomi compatible? Very few are.
The Hubitat controller is just a metre away from the sensor.
Let me try putting the sensor side by side and see whether it's due to signal loss. Thanks!
Do you have any Zigbee repeaters, though? Distance is not the only criteria Zigbee devices use when choosing their routes, and there's no guarantee that the first they choose is the one they'll stay with (though I have yet to see a Xiaomi device of mine change, some people say they have--I do see standard Zigbee devices change), nor is there any guarantee that being close to the hub means they will route directly to it (though it is a logical assumption with that small of distance).
Given people's experiences above and in the other thread on this subject, I'd recommend that all your Zigbee repeaters be "Xiaomi-friendly."
I do have zigbee devices that act as repeaters around the house, i.e. IKEA Trådfri power outlets which I understand they are Xiaomi friendly. Just that the sensor is nearer to to Hubitat than to the repeaters.
Again, thanks for the input - I will also troubleshoot by removing and re-adding the sensor by placing it close to the repeater (on top of doing the same with the sensor closer to Hubitat).
What zigbee channel are you using? And do you have any other line powered zigbee devices (non-ikea) in the same network?
I am on zigbee channel 11.
I did the below troubleshoot and Hubitat is receiving battery, temperature and humidity updates regularly now. I suspect for the initial pairings, the sensor is not choosing the appropriate routing.
- Delete sensor from Hubitat
- Placed sensor next to Hubitat controller and initiated pairing
- Sensor added successfully.
- Monitor sensor for half a day; Receiving updates with no irregularity
- Moved sensor to midway between Hubitat and original location; Receiving updates with no irregularity for half a day
- Moved sensor to original location; Receiving updates with no irregularity for a day so far
While searching around i found this ST repo for aqara devices it has the Aqara B1 curtain motor driver, any chance it can be ported to HE
Besides that fact that (my) life has been / is too busy to allow me to work on any device drivers at the moment...
I see methods used in that SmartThings device handler that I'm not familiar with. In order to port the code to a Hubitat driver, I would need to be able to do fairly extensive testing to get it working. This requires that either a) I own or have an Aqara B1 Curtain motor in my possession, or b) I work with an owner of an Aqara B1 Curtain motor who doesn't mind working with me to do quite a lot of device driver beta testing.
I am a system admin with a little coding skill, I can definitely work along in beta testing. whatever you need am in. at your own base everyone definitely has his own life.
Thank you for reply and I appreciate your efforts.
I have
3 Aqara B1 Motor
All my house is equipped with Aqara light Neutral switches ( double & single ) maybe 50 devices
3 Aqara human sensor
3 Aqara Door and human sensor
all their drivers are from this page and working like a charm.
My Zigbee mesh is rock solid as all those light switches are acting as repeaters.
I put one neutral switch on my HE network and it trashed my zigbee network. Removed it and everything was ok again. I'm interested on how you are using these on HE or have you not paired them to HE yet.
Non neutral ones are fine.
