[RELEASE] Aeotec TriSensor 8 community driver

⚙️ Custom Apps and Drivers Custom Drivers
,
1

Aeotec TriSensor 8 Z-Wave 800 Driver for Hubitat

Description

This is a custom driver for Aeotec TriSensor 8 that is intended to be used instead of the driver available on Aeotec support pages. This custom driver improves following aspects:

  • S2 included sensor is fully supported,
  • most parameters defined in the manual are configurable, including new parameters added in 2.8.4 firmware update.

Notes

  • The driver has been tested on Aeotec TriSensor 8 from EU distribution with firmware version 2.8.4 (shows as 2.0.8) and securely paired with Hubitat.
  • To take full advantage of parameters to configure LED behavior, make sure you update the firmware of the sensor. Firmware can be downloaded at: Update TriSensor 8 to V2.8.4 : Aeotec Help Desk

Screenshots

image
image1920×1036 122 KB

Changelog

  • V0.1.0 - 19.06.2025: Initial working version.
  • V0.1.1 - 25.06.2025: Safeguard against logging level set when using Aeotec Support's driver.

Installation
It is recommended to install through Hubitat Package Manager by searching for Aeotec TriSensor 8. Alternatively, you can download the code and install it manually.

Download

1 Like
2

I can't get the LED to stop lighting up. I changed the parameter a couple days ago and it still is flashing at any event. Also there's a bunch of errors in my log

image
image882×448 109 KB

3

Hello. I reproduced the issue, and it happens if you set "Warn" or any other non-default logging level on the driver from Aeotec Support and then switch to my driver. I will deliver later the safeguard for this in next version of the driver, but you can easily fix this on the current driver by simply selecting a different log level.

Just go the "Preferences" section and set all your preferences to your liking AND also set the Log Level at the bottom to Info, Warn, or any supported option.

This issue should not occur because the code on this line should have handled the wrong setting format and use a default value instead. @jtp10181, I took the logging straight from your drivers. Did you encounter this issue that the parsing would throw an exception instead of being set to default?

Map getLogLevelInfo() {
    Integer level = settings.logLevel != null ? settings.logLevel as Integer : 1 // THIS LINE
    Integer time = settings.logLevelTime != null ? settings.logLevelTime as Integer : 30
    return [level: level, time: time]
}
4

Have not looked at the code for either driver but it looks like maybe the other driver was using the same settings name as me, but they are saving a string in there instead of a number. I think that's maybe where the error comes in, it is expecting a number and not the string value of 'warn'.

I have not encounter that before and I don't think my code was built to handle a string. That example code just does a null check and goes to default if null, it does not check for invalid values. Some of my newer drivers will set it to debug automatically when configure is run, which would fix it. But that also relies on people actually running the configure command.

5

@jtp10181 This fixes it:

Map getLogLevelInfo() {
    Integer level
    try {
        level = settings.logLevel != null ? settings.logLevel as Integer : 1
    } catch (Exception e) {
        level = 1
    }

    Integer time
    try {
        time = settings.logLevelTime != null ? settings.logLevelTime as Integer : 30
    } catch (Exception e) {
        time = 30
    }

    return [level: level, time: time]
}
1 Like
6

Hello @TommyBoy, a new version v0.1.1 which has a safeguard against your scenario is now available. You can update it through HPM.

7

Thank you! I'm in the process of migrating to zwave-js, so the hub is a bit occupied. Hopefully I can report back tomorrow about the fix. Appreciate the help.

8

Personally, I suggest to use legacy ZipGateway for the time being, because, unfortunately, there are a lot of bugs in the ZW-JS implementation in Hubitat resulting in some of devices and drivers on my hub not working correctly, usually around S2 supervision aspects or more obscure command classes.

What I did is this: I switched to ZW-JS, updated the firmware of the ZW chip to the newest one, and then reverted to the ZipGateway. Whenever I need to update firmware of a device, I temporarily switch to ZW-JS and then revert back. But this is only my personal suggestion.

1 Like
9

Thanks for the insight, I thought I'd give JS a try to see if there's anything for me to be gained or lost. The jury is still out.

My LED notifications are still flashing on the Aeotec for some strange reason even after I updated the driver.

10

You need to go to preferences and save again with LED option set disabled. Also you don't need to wait for the wakeup period. You can take the sensor and press the button inside for 3 seconds until it flashes blue, and it will do a wakeup.

1 Like
11

Looks like you mostly just used a bunch of my library code to facilitate a new zwave driver. How did that work out? I am glad someone was able to use parts of it.

1 Like
12

This is actually a second driver I built this way. I made minor simplifications here and there, but the best thing is that I can easily separate the "common" and "generic" code from what is specific for a particular device. Your Universal Z-Wave Scanner helped me a lot, especially that I am not really a Groovy developer and did not even touch it before (with maybe the exception of some Jenkins scripts ages ago). Also, Hubitat's developer documentation is very limited, and with a lack of SDK, it's pretty much the only way forward - to work on and borrow from existing drivers.

Thank you for your great work!

1 Like
13

You are correct. I hadn't pressed the button long enough for the call back to the mother ship to trigger. Once I did it responded as designed. Thanks for the help.