[Deprecated] Xiaomi / Aqara / Opple Drivers with Presence!

Awesome...Thank You Muchly for supporting my requirement to keep the dear Wifey adequately informed of our pooch's potty habits!

Are you going to add support for Aqara Smart Plug?

Yes

Can you tell when?

When I have time, don't have a lot of that for writing drivers lately. Think there is another driver written by someone else for that one, but not sure.

1 Like

There is this driver that @markus was referring to:

4 Likes

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.

Yes it shows as degrees C in event log for device.

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.