Thanks a lot!
i just changed over to your drivers for my temp humidity sensors.
in the logs it would be nice to have the sensor name "living room temp" or someway to tell which sensor reported a change. if this isnt too much trouble.
2020-06-17 08:31:13.440 pm [info]Sending temperature event (Temperature: 72.0 °F, old temp: 71.2, change: 0.8)
[dev:392]2020-06-17 08:25:06.624 pm [info]Sending humidity event (Humidity: 46.6%, old hummidity: 49.90%, change: 3.30%)
the veeocee drivers reported as.
2020-06-17 07:55:29.389 pm [info]temp 3 toyroom: Humidity is 49.9%
just fyi.... the KONKE branded sensors seem to work with your temp humidity drivers.
- model: 3AFE220103020000
- modelType: unknown
- manufacturer: Konke
I have been testing out this Aqara Temperature Sensor driver for a few weeks now on my experimental system. It seems to work well and probably better than the older Xiaomi driver. However I am noticing one flaw. Every now and then a reading will arrive as degrees C instead of degrees F. I also noticed when I first paired the sensors the first reading was in degrees C instead of degrees F. This wouldn't make much difference to us in the wintertime, but during summertime it means heaters turn on. See Kitchen graph below
This would be as expected since the default is Celsius, that it reports as Celsius once it has been set to Fahrenheit, that is an odd one. For that to happen the setting to use F must be unavailable to the driver or the built-in Celsius to Fahrenheit method must fail (not likely). With that said, it obviously is happening, looking at the code it shouldn't, so I will have to think about what I can do (without changing the default) to ensure it doesn't.
1 Like
I'll think about adding it, have not seen the use, but maybe as a setting... You can always see it by selecting that device from the device number to the left. I do see your point, maybe I'll add it if I come up with an easy and simple way.
I thought there was some speculation that these erroneous reports were low battery or a check-in or something like that. I don't know if I can find the source, but I believe this was discussed in the veeceeoh driver thread somewhere.
I am not a coder by any means, so maybe I am way off base here.
Just checked the battery level and it shows 97% which is what I would expect since it was a new from box sensor a few weeks ago
Yes, it could be, though this is within range (22C), I will add the raw value to the temperature event in the next release, that way it will be easier to track the source of the issue. If the temperature is below -50C or above 100C it would be ignored, those are the ranges that have been identified as what is sent when there are errors.
@chrscngr are you running the latest version of my drivers? Is the unit in the event log C for the 22 degree event?
driver version v0.7.1.0613
Seems to have expired that data from the log already. Maybe older logs are stored someplace?
Yes, the logs don't go far back, I'm talking about the event logs (the history of events for the device). In there it will show under the column Unit.
That means the setting for using F is ignored, this requires some investigation into the why, this should never happen. The code selecting conversion based on that setting is very simple and straight forward, so something else is amiss.
// In Preferences:
input(name: "tempUnitDisplayed", type: "enum", title: styling_addTitleDiv("Displayed Temperature Unit"), description: "", defaultValue: "1", required: true, multiple: false, options:[["1":"Celsius"], ["2":"Fahrenheit"], ["3":"Kelvin"]])
input(name: "tempOffset", type: "decimal", title: styling_addTitleDiv("Temperature Offset"), description: styling_addDescriptionDiv("Adjust the temperature by this many degrees."), required: false, range: "*..*")
input(name: "tempRes", type: "enum", title: styling_addTitleDiv("Temperature Resolution"), description: styling_addDescriptionDiv("Temperature sensor resolution (0..2 = maximum number of decimal places, default: 1)<br/>NOTE: If the 2nd decimal is a 0 (eg. 24.70) it will show without the last decimal (eg. 24.7)."), options: ["0", "1", "2"], defaultValue: "1", required: false)
// This is the method doing the conversion:
private List sensor_data_getAdjustedTempAlternative(BigDecimal value) {
Integer res = 1
BigDecimal rawValue = value
if(tempRes != null && tempRes != '') {
res = Integer.parseInt(tempRes)
}
String degree = String.valueOf((char)(176)) // Creates a degree character
String tempUnit = "${degree}C"
if (tempUnitDisplayed == "2") {
value = celsiusToFahrenheit(value)
tempUnit = "${degree}F"
} else if (tempUnitDisplayed == "3") {
value = value + 273.15 // Kelvin
tempUnit = "${degree}K"
}
if (tempOffset) {
return [tempUnit, (value + new BigDecimal(tempOffset)).setScale(res, BigDecimal.ROUND_HALF_UP), rawValue]
} else {
return [tempUnit, value.setScale(res, BigDecimal.ROUND_HALF_UP), rawValue]
}
}
Could it be related to a power glitch? I was installing an HDMI audio extractor on the surround sound system at that time. The Hubitat is on the same circuit breaker.
No, that sounds unlikely, this is something with the platform or how the driver is using the platform. The setting "tempUnitDisplayed" is for some reason not available to the driver logic. I will think it over and probably post a question to the community later today regarding what they think may be the issue. It would of course be better to know if this happens more than once? It could be that the hub was busy with some DB reads at the time and didn't retrieve this value? Maybe it was just an unlucky coincidence?
Ok, seems like a good plan. I'll watch more closely for this again. I saw it once before on a different Hubitat, however that one is 150 miles away so more difficult to diagnose
Once posting this for feedback from others it would help to know if this happened more than once and have the logs to prove it. It sure is an odd issue. The temperature event is only sent from one place in the code, and the unit setting is only ever read in that one location above. It is not complex logic, it would be trivial to write a mathematical proof to show this code is correct if the underlying code can be assumed to be correct. It's an interesting one to get to the bottom of though, so let us continue.
Back when I used to write Linux drivers, we used mutex or semaphore to lock access to things. Maybe there is something like that avaiable?
Not in HE drivers, not in Apps either, not real ones, and these preferences are automatically loaded from the database by the system, not much that can be done differently as far as I know. I understand what you mean, but that way of writing is not available to us in HE, and probably shouldn't be anyway, it isn't that type of system.
1 Like
