Add Aqara TVOC Sensor Support

[sieren]

This PR introduces initial support for the Aqara TVOC Sensor which is ready to be merged into deCONZ (see dresden-elektronik/deconz-rest-plugin#4704 & dresden-elektronik/deconz-rest-plugin#5213)

Added additional support for Eve Room 2 (VOC/PPB) here: simont77/fakegato-history#114 which needs a merge + a version update prior to this PR.

Here's the API Output for this sensor:

"34": {
        "config": {
            "battery": 100,
            "offset": 0,
            "on": true,
            "reachable": true
        },
        "ep": 1,
        "etag": "cb8e9bed30885775af163d2ca8c89caf",
        "lastannounced": null,
        "lastseen": "2021-08-31T13:58Z",
        "manufacturername": "LUMI",
        "modelid": "lumi.airmonitor.acn01",
        "name": "Temperature 34",
        "state": {
            "lastupdated": "2021-08-31T13:58:56.488",
            "temperature": 2173
        },
        "swversion": "2020",
        "type": "ZHATemperature",
        "uniqueid": "54:ef:44:10:00:10:5a:55-01-0402"
    },
    "35": {
        "config": {
            "battery": 100,
            "offset": 0,
            "on": true,
            "reachable": true,
            "temperature": 2173
        },
        "ep": 1,
        "etag": "29172525839c5c7fcd76a552ff011bed",
        "lastannounced": null,
        "lastseen": "2021-08-31T13:58Z",
        "manufacturername": "LUMI",
        "modelid": "lumi.airmonitor.acn01",
        "name": "Humidity 35",
        "state": {
            "humidity": 5765,
            "lastupdated": "2021-08-31T13:58:56.488"
        },
        "swversion": "2020",
        "type": "ZHAHumidity",
        "uniqueid": "54:ef:44:10:00:10:5a:55-01-0405"
    },
    "36": {
        "config": {
            "battery": 100,
            "on": true,
            "reachable": true,
            "temperature": 2173
        },
        "ep": 1,
        "etag": "e28b84f21b4987d48e526359b3fb1b62",
        "lastannounced": null,
        "lastseen": "2021-08-31T13:58Z",
        "manufacturername": "LUMI",
        "modelid": "lumi.airmonitor.acn01",
        "name": "AirQuality 36",
        "state": {
            "airquality": "excellent",
            "airqualityppb": 9,
            "lastupdated": "2021-08-31T13:00:01.979"
        },
        "swversion": "2020",
        "type": "ZHAAirQuality",
        "uniqueid": "54:ef:44:10:00:10:5a:55-01-000c"
    }
}

[ebaauw]

Sadly I did not manage to get Eve Room simulation working for this.

Haven't looked into that one before. Note that Eve is very picky on the accessory, services, and characteristics and won't display the history, unless it finds everything it's looking for. Note that Homebridge Hue still uses the fakegato-history library, instead of the History service delegates from Homebridge Lib. I plan to change that, when moving to dynamic platform accessories (see #4).

The sensor seems to report values in PPB unlike Eve Room (v1). Therefore an adjustment to PPM might be neccessary and potentially accounting for the offset of 450ppm on Eve Room v1?

I would expect ppm to be ppb divided by 1,000 (1,000 parts per billion would be 1 part per million). However, with the reported value of 9, that would be 0.009. Not sure what you mean by offset of 450ppm.

I was looking for more information on Eve Room v2, but from the looks of it this seems to be missing from fakegato right now and I couldn't find the characteristics either.

You would need access to the device, and use HMCatalog to check the services, characteristics, and history parameters. It's a nice device, but a bit too expensive for my taste. I won't be buying the current version; maybe if the next, if it supports Thread.

Here's the API Output for this sensor:

Why on Earth did they expose config.temperature on the ZHAHumidity and ZHAAirQuality resources?

[sieren]

Sadly I did not manage to get Eve Room simulation working for this.

Haven't looked into that one before. Note that Eve is very picky on the accessory, services, and characteristics and won't display the history, unless it finds everything it's looking for. Note that Homebridge Hue still uses the fakegato-history library, instead of the History service delegates from Homebridge Lib. I plan to change that, when moving to dynamic platform accessories (see #4).

Ah good to know. I noticed it was using fakegato.

The sensor seems to report values in PPB unlike Eve Room (v1). Therefore an adjustment to PPM might be neccessary and potentially accounting for the offset of 450ppm on Eve Room v1?

I would expect ppm to be ppb divided by 1,000 (1,000 parts per billion would be 1 part per million). However, with the reported value of 9, that would be 0.009. Not sure what you mean by offset of 450ppm.

I believe everything below 450ppm was considered "UNKNOWN" in terms of Air Quality in the Eve Room v1.
However, as I continued my investigation after opening this PR, it actually does show PPB for some odd reason (and therefore is expecting PPB data).

I was looking for more information on Eve Room v2, but from the looks of it this seems to be missing from fakegato right now and I couldn't find the characteristics either.

You would need access to the device, and use HMCatalog to check the services, characteristics, and history parameters. It's a nice device, but a bit too expensive for my taste. I won't be buying the current version; maybe if the next, if it supports Thread.

I actually own this device. The key difference to Room v1 isn't just the characteristics, but the different data-stream for Logging. AFAIK there is no support for this in Fakegato-History just yet (e.g. simont77/fakegato-history#107 ) and this needs to be reverse-engineered.
I've started looking into this, but didn't make much headway. Some of the bytes (Temp/Humidity) align with the other types, but ppb seems to be reported differently and the overall stream is larger.
I think I've seen you took part in the effort of reverse-engineering the data-stream a few years back? I'll see if I can set some time aside and dump an example to my computer so it can be more readily dissected.

Here's the API Output for this sensor:

Why on Earth did they expose config.temperature on the ZHAHumidity and ZHAAirQuality resources?

Good question indeed.

[ebaauw]

I think I've seen you took part in the effort of reverse-engineering the data-stream a few years back?

Yeah, see: simont77/fakegato-history#75.

The key difference to Room v1 isn't just the characteristics, but the different data-stream for Logging.

The Eve Room 2 likely uses a different data type in the history entries than the first-gen Eve Room. I've seen the same for the Eve Energy.

[sieren]

@ebaauw I managed to get it up and running with complete Fakegato support after quite a bit of trial and error.
There's an open PR over in the Fakegato Repo now: simont77/fakegato-history#114 and I've force-pushed this branch to make use of this API.

[sieren]

@ebaauw this is ready for review now as my PR for Eve Room 2 support has been merged into fakegato-history and is live.
Been extensively testing it with the unit for the past week and it works great.

[ebaauw]

I think it looks good functionally. Some remarks on the code style; please run standard and fix the findings.

Do I understand correctly that the history entry only needs voc (and computes the quality from that), but the Air Quality Sensor service needs both VOC Density and Air Quality characteristics? And the air quality is already reported by the device/computed by deCONZ?

[sieren]

Sounds good, I'll add these changes asap. Sorry for the semicolon slipups, my C++ background sometimes comes through ;)

As for future-proofing this for other sensors, what do you suggest is the best approach here? Maintaining an array and using includes(..) to check if it's in a room2 array? I suppose there are a few ways this can be optimised in the long run, but I suppose the most near-future one is just maintaining a list of potential Room 2 devices?

[ebaauw]

As for future-proofing this for other sensors, what do you suggest is the best approach here?

Like durationKey.

homebridge-hue/lib/HueSensor.js

Line 237 in b4cd70e

let durationKey = 'duration'

Create a variable temperatureHistory, initialised to "weather", and overwritten to "room2" in the ZHATemperature and ZHAHumidity whitelist entries for the room-like sensors (the whiteliist should have a separate if-entry for the room-like sensor, instead of combining it with other Xiaomi sensors). Then set this.type.history to temperatureHistory

homebridge-hue/lib/HueSensor.js

Line 974 in b4cd70e

history: 'weather',

homebridge-hue/lib/HueSensor.js

Line 1080 in b4cd70e

history: 'weather',

[sieren]

Thanks @ebaauw , mind taking another look?

[ebaauw]

Thanks!

I'll move the definition of the air quality map out of the routine, but otherwise looking great.

[ebaauw]

@sieren, could you please have a quick check that my change didn't break anything. I don't have a room-2-like sensor to test myself.

[sieren]

@ebaauw been using homebridge master in a different home with a second aqara sensor for the past few hours and it's all working fine. 👌
(Deleted an older comment earlier which was the result of the whole setup being generally super outdated - unrelated to the recent merge)

[sieren]

[roquecarlos]

Hi guys, i have add my aqara tvoc sensor to the z2m but the homebridge give alweays this error,

`28/07/2022 23:49:54] [homebridge-z2m] Loaded homebridge-z2m v1.9.0 child bridge successfully [28/07/2022, 23:49:55] Loaded 0 cached accessories from cachedAccessories.0E79B1B83CF4. [28/07/2022, 23:49:55] [homebridge-z2m] Incorrect configuration: Entry for device is not correct: {"exclude":false,"converters":{"switch":{"type":"switch"},"occupancy":{"type":"occupancy"}}} [28/07/2022, 23:49:55] [homebridge-z2m] INVALID CONFIGURATION FOR PLUGIN: homebridge-z2m This plugin will NOT WORK until this problem is resolved. [28/07/2022, 23:49:55] Homebridge v1.5.0 (HAP v0.10.2) (homebridge-z2m) is running on port 53093

Can you guys help me?