Keen Vent 'issue'

🛎️ Get Help
1

I'm using the in-box Keen Vent driver.

After replacing batteries that died, I turned on debug and clicked Configure to make sure everything was working as expected.

When I did, I noticed I got a lot of CatchAll messages in the log. Is this normal (I wouldn't think so, but I'm not a zigbee guy).

Also, there is no event for battery, for instance, after hitting configure. Maybe that is as expected, too, but I would have thought the switch, battery, and level events in the log would have made device events...

dev:1542019-03-27 05:04:46.627 pm infoXavier Bedroom Smart Vent battery is at 100%

dev:1542019-03-27 05:04:46.620 pm debugparseReportAttributeMessage: read attr - raw: 25260100010A21002064, dni: 2526, endpoint: 01, cluster: 0001, size: 0A, attrId: 0021, encoding: 20, command: 01, value: 64

dev:1542019-03-27 05:04:46.617 pm debugparse: read attr - raw: 25260100010A21002064, dni: 2526, endpoint: 01, cluster: 0001, size: 0A, attrId: 0021, encoding: 20, command: 01, value: 64

dev:1542019-03-27 05:04:43.175 pm infoXavier Bedroom Smart Vent is 100%

dev:1542019-03-27 05:04:43.173 pm debugparseReportAttributeMessage: read attr - raw: 25260100080A000020FE, dni: 2526, endpoint: 01, cluster: 0008, size: 0A, attrId: 0000, encoding: 20, command: 01, value: FE

dev:1542019-03-27 05:04:43.171 pm debugparse: read attr - raw: 25260100080A000020FE, dni: 2526, endpoint: 01, cluster: 0008, size: 0A, attrId: 0000, encoding: 20, command: 01, value: FE

dev:1542019-03-27 05:04:42.167 pm infoXavier Bedroom Smart Vent is on

dev:1542019-03-27 05:04:42.162 pm debugparseReportAttributeMessage: read attr - raw: 25260100060A00001001, dni: 2526, endpoint: 01, cluster: 0006, size: 0A, attrId: 0000, encoding: 10, command: 01, value: 01

dev:1542019-03-27 05:04:42.159 pm debugparse: read attr - raw: 25260100060A00001001, dni: 2526, endpoint: 01, cluster: 0006, size: 0A, attrId: 0000, encoding: 10, command: 01, value: 01

dev:1542019-03-27 05:04:41.563 pm infoXavier Bedroom Smart Vent is 100%

dev:1542019-03-27 05:04:41.562 pm debugparseReportAttributeMessage: read attr - raw: 25260100080A000020FE, dni: 2526, endpoint: 01, cluster: 0008, size: 0A, attrId: 0000, encoding: 20, command: 01, value: FE

dev:1542019-03-27 05:04:41.559 pm debugparse: read attr - raw: 25260100080A000020FE, dni: 2526, endpoint: 01, cluster: 0008, size: 0A, attrId: 0000, encoding: 20, command: 01, value: FE

dev:1542019-03-27 05:04:40.539 pm infoXavier Bedroom Smart Vent is on

dev:1542019-03-27 05:04:40.535 pm debugparseReportAttributeMessage: read attr - raw: 25260100060A00001001, dni: 2526, endpoint: 01, cluster: 0006, size: 0A, attrId: 0000, encoding: 10, command: 01, value: 01

dev:1542019-03-27 05:04:40.532 pm debugparse: read attr - raw: 25260100060A00001001, dni: 2526, endpoint: 01, cluster: 0006, size: 0A, attrId: 0000, encoding: 10, command: 01, value: 01

dev:1542019-03-27 05:04:33.664 pm debugparseCatchAllMessage: catchall: 0104 0403 01 01 0040 00 2526 00 01 115B 07 01 00

dev:1542019-03-27 05:04:33.662 pm debugparse: catchall: 0104 0403 01 01 0040 00 2526 00 01 115B 07 01 00

dev:1542019-03-27 05:04:32.040 pm debugparseCatchAllMessage: catchall: 0104 0403 01 01 0040 00 2526 00 01 115B 07 01 00

dev:1542019-03-27 05:04:32.036 pm debugparse: catchall: 0104 0403 01 01 0040 00 2526 00 01 115B 07 01 00

dev:1542019-03-27 05:04:30.616 pm debugparseCatchAllMessage: catchall: 0104 0402 01 01 0040 00 2526 00 00 0000 07 01 00

dev:1542019-03-27 05:04:30.614 pm debugparse: catchall: 0104 0402 01 01 0040 00 2526 00 00 0000 07 01 00

dev:1542019-03-27 05:04:30.451 pm debugparseCatchAllMessage: catchall: 0104 0403 01 01 0040 00 2526 00 01 115B 07 01 00

dev:1542019-03-27 05:04:30.426 pm debugparse: catchall: 0104 0403 01 01 0040 00 2526 00 01 115B 07 01 00

dev:1542019-03-27 05:04:28.995 pm debugparseCatchAllMessage: catchall: 0104 0402 01 01 0040 00 2526 00 00 0000 07 01 00

dev:1542019-03-27 05:04:28.994 pm debugparse: catchall: 0104 0402 01 01 0040 00 2526 00 00 0000 07 01 00

dev:1542019-03-27 05:04:28.568 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0B00

dev:1542019-03-27 05:04:28.566 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0B00

dev:1542019-03-27 05:04:27.563 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0A00

dev:1542019-03-27 05:04:27.561 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0A00

dev:1542019-03-27 05:04:27.382 pm debugparseCatchAllMessage: catchall: 0104 0402 01 01 0040 00 2526 00 00 0000 07 01 00

dev:1542019-03-27 05:04:27.380 pm debugparse: catchall: 0104 0402 01 01 0040 00 2526 00 00 0000 07 01 00

dev:1542019-03-27 05:04:26.949 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0B00

dev:1542019-03-27 05:04:26.947 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0B00

dev:1542019-03-27 05:04:26.541 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0900

dev:1542019-03-27 05:04:26.540 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0900

dev:1542019-03-27 05:04:25.936 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0A00

dev:1542019-03-27 05:04:25.935 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0A00

dev:1542019-03-27 05:04:25.542 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0800

dev:1542019-03-27 05:04:25.541 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0800

dev:1542019-03-27 05:04:25.354 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0B00

dev:1542019-03-27 05:04:25.351 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0B00

dev:1542019-03-27 05:04:24.927 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0900

dev:1542019-03-27 05:04:24.926 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0900

dev:1542019-03-27 05:04:24.343 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0A00

dev:1542019-03-27 05:04:24.341 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0A00

dev:1542019-03-27 05:04:23.918 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0800

dev:1542019-03-27 05:04:23.916 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0800

dev:1542019-03-27 05:04:23.322 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0900

dev:1542019-03-27 05:04:23.320 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0900

dev:1542019-03-27 05:04:22.305 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0800

dev:1542019-03-27 05:04:22.304 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0800

dev:1542019-03-27 05:04:20.258 pm debugparseCatchAllMessage: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0700

dev:1542019-03-27 05:04:20.257 pm debugparse: catchall: 0000 8021 00 00 0040 00 2526 00 00 0000 00 00 0700

dev:1542019-03-27 05:04:19.891 pm warnconfigure...

2

Yes, just turn debug logging off.
Let me know if the battery reports don't eventually show up...

3

Interesting that you mention that...

I have 4 vents. None of them have reported a battery % since December/January... That's one of the reasons I thought I would do 'configure' again after I replaced batteries.

I'll keep my eyes open to see if they do now, though.

4

I'll poke at one of mine and see what's up...
That driver hasn't received any attention in over a year, maybe it needs some help...

5

So I left debug on on one of them. No battery, temp, or vent pressure updates yet (the 3 things I used to see periodically update in ST), but I do see this every 10 min or so:

dev:1542019-03-27 07:05:40.307 pm debugparseCatchAllMessage: catchall: 0000 0006 00 00 0040 00 2526 00 00 0000 00 00 0FFDFF040101190000

dev:1542019-03-27 07:05:40.305 pm debugparse: catchall: 0000 0006 00 00 0040 00 2526 00 00 0000 00 00 0FFDFF040101190000

dev:1542019-03-27 06:55:31.433 pm debugparseCatchAllMessage: catchall: 0000 0006 00 00 0040 00 2526 00 00 0000 00 00 0EFDFF040101190000

dev:1542019-03-27 06:55:31.431 pm debugparse: catchall: 0000 0006 00 00 0040 00 2526 00 00 0000 00 00 0EFDFF040101190000

dev:1542019-03-27 06:45:22.017 pm debugparseCatchAllMessage: catchall: 0000 0006 00 00 0040 00 2526 00 00 0000 00 00 0DFDFF040101190000

dev:1542019-03-27 06:45:22.015 pm debugparse: catchall: 0000 0006 00 00 0040 00 2526 00 00 0000 00 00 0DFDFF040101190000

6

Pressure and temp are intentionally disabled as they are worthless, I have miles of rants on ST a few years back about this, my only concern is battery reporting at this point.

7

Understood. I'll watch for a while more.

@mike.maxwell Do you know what you set the battery reporting to in your driver? Or did you leave it at default?

A lot of the ST drivers explicitly set it (and set the temp/pressure reporting much slower because they aren't very useful).

For battery:

def configCmds = [
    // configure report commands
    // [cluster] [attr] [type] [min-interval] [max-interval] [min-change]
    //battery - type: int8u, change: 1

"zcl global send-me-a-report 1 0x21 0x20 60 3600 {01}", "delay 200",
"send 0x${device.deviceNetworkId} 1 1", "delay 1500",
"zdo bind 0x${device.deviceNetworkId} 1 1 0x0001 {${device.zigbeeId}} {}", "delay 500"
]

return configCmds
8

The standard battery config for our drivers is 1 percent change, min interval 1 second, max at 18 hours...
I don't know if this driver was updated to this or not.

9

OK, fresh join using the stock driver, battery, level and switch all reported initial states after join completed.
manual refresh updates the same attributes.
battery reporting is set to 1% change, min:3600, max:43200 seconds, these are device defaults, the driver isn't setting them in configure.

10

Thanks for checking!!!

So should one see a battery update event every 43200 seconds (max), even if still 100%? Or will it only generate a new event if different than last value?

I ask, because I didn't see any battery events for months, let alone every 12 hours. Maybe the device kept reporting 100% for some reason - possible device, not driver, issue.

I replaced batteries 23 hours ago, no battery events in the device event log on any of the 4 vents I have.

11

this ^, and the way our eventing commits work, if the current value matches the previous value, and no apps have subscribed to battery with filterEvents: false, the event is binned...
It will still log to live logging however, just no event in the DB.

I've been struggling personally with the same observational issue you've reported...
Given the infrequency of battery reports in general, I'm considering changing the driver sendEvent to force a state change, need to do some testing first...

12

For what it is worth, I always make infrequent reports either log.info or do a state change.

Otherwise you can't ever see them if you need to - debug logging turns off after 30 min...

13

In our standard logging options, the descriptionText logging option displays the values that are submitted to sendEvent, debug logging isn't required to display these on the live logging page.

14

Ah, good point.

And now that I look in the log, I do see battery reports from the vents (all 100%, which is why there are no device events).

I'll make a reminder to check in 2 weeks and see if any of them come off 100%.

Two have lithium batteries. On those it wouldn't surprise me if they stay 100% base don the voltage drain curve on lithium.

The other two have regular alkaline, so I would expect them to show a battery % change at some point.

15

@mike.maxwell

OK, I'm definitely having issues with Keen vents in Hubitat... Could be a vent problem, or maybe not? Don't know yet, but since all 4 of my vents do the same thing I don't THINK it is a vent issue (been wrong before though).

Came home from the long weekend, wondering why one room was hot. Looked in Hubitat, vent showed 100%. visibly looked at the vent, and it was mostly closed. Tried to stroke it in Hubitat, wouldn't move.

Checked the batteries. Dead. But battery shows as 100% in Hubitat.

Went to another Keen vent, tried to move it from Hubitat. Nothing. Check batteries - dead. Show 100% in Hubitat.

Went to a 3rd Keen vent, tried to move it from Hubitat. Nothing. Check batteries - dead. Show 100% in Hubitat.

This is the same thing that happened a few months ago. After I replaced batteries that time I made sure and hit "configure" again on every vent to see if it would make a difference. It didn't.

Is there any way to tell these things are actually working without visual inspection???

Because from the Hubitat side, level changes show up in the event log even when the vent doesn't actually move. In fact, I couldn't see anything from the Hubitat side that would indicate the vent isn't actually moving...

If temperature or pressure created events I guess one could do an alert on that (no event within X time = alert), but those attributes don't populate in the in-box driver.

And obviously battery % isn't a valid measure either as none of them moved off 100%. I guess if every battery report (or at least one every X hours) created an event you COULD do it on battery reports, but that is not how it works today.

16

@mike.maxwell

Well, all of my Keen vent batteries lasted a whopping 3 weeks this time... So this is 5 sets of batteries in a row that died in just a few weeks... And all 5 times the battery % never moved off of 100% in HE.

According to one of the vents, it moved exactly 7 times before the battery died - so it is not dying because I'm moving them too much.

Any thoughts? Anything else I can try? I still can't figure out if this is a driver, device, or use issue.

17

And I thought I had it bad with one that moves, but doesn't report the move...

18

Since the Battery % reporting clearly doesn't work correctly, and the in-box driver doesn't expose temp or pressure reports thus you can't look at last activity, I guess I'll need to start periodically polling them, too.

I'm trying one of the ported ST drivers on 1 of my 4 vents this go around. Will see if it does anything different than the other 3 I guess...

1 Like
19

OK, on 1 of my 4 Keen vents I'm now using the Yves Racine DTH from smartthings.

  1. I fixed the temperature reporting to work with HE
  2. Made battery reporting a state change
  3. But pressure reporting doesn't work at all - on demand or periodic reporting sends nothing to the hub at all. As that uses a manufacturer specific cluster, I'm not sure if the issue is the driver or a platform issue that it is never sending the read attr for that at all.

I'm not real worried about the pressure reporting, though. I really wanted the temperature reporting to work, so that I could use the HE device activity field as a proxy for battery being dead. Automatic temperature reporting is set to 5 minutes (same as smartthings, so that alone shouldn't cause a battery issue) , so no more temp updates for a few hours = battery is dead).

That coupled with making the battery report a state change should help narrow down whether the device simply isn't sending battery reports, or if it is and they are always 100%... Easier for me than sitting around sniffing packets all day.

20

I think I would be inclined to try running wires down inside the duct to some point where the duct was accessible for plug in power???? Just a thought.