Keen vent driver bug?

🛎️ Get Help
1

@mike.maxwell Is there any plans to revisit the Keen vent drivers? I'm running the latest firmware with KeenectLite for the Keen vents. I'm not sure if this is a new issue, but whenever the setLevel() api is called, it does not set it to the value that is passed in. It's off by 1.

I see in my logs if the app calls setLevel(100), it'll trigger another event with level 99. Recently with the latest firmware, one of my vents is cycling from 100 to 99 to 83, then the Keenect Lite app will set it back to 100 again, which triggers 99, then 83, over and over. This is using Binary level-setting algorithm in Keenect Lite. There's nothing in the code that should cause this behavior other than the initial call to setLevel(100), but the log output shows the Level event handler getting triggered 3 times (100, 99, 83).

And like others, the battery life is very short, to say the least. Not sure why that is.

2

Do the logs show what is calling the 83? Also, does the vent actually move? Keenect does check that when a move happens and that the vent actually moved close to the command value.

3

It doesn't show any app code setting the level. It only shows the handler being called. The vent does move to set the level. This is how I noticed something was wrong because the vent kept changing the level over and over and so I looked into the logs to see what was going on.

In fact, it's happening right now. It's going 100 -> 99 -> 81 now.

app:7212020-01-29 07:24:53.194 am infostate.VentOpeningMap after = [Vent Brandon:81]

app:7212020-01-29 07:24:53.189 am infostate.VentOpeningMap = [Vent Brandon:99]

app:7212020-01-29 07:24:53.179 am infoRunning ventHandler for Vent Brandon value: 81

app:7212020-01-29 07:24:42.736 am infostate.VentOpeningMap after = [Vent Brandon:99]

app:7212020-01-29 07:24:42.727 am infostate.VentOpeningMap = [Vent Brandon:100]

app:7212020-01-29 07:24:42.721 am infoRunning ventHandler for Vent Brandon value: 99

app:7212020-01-29 07:24:37.706 am infostate.VentOpeningMap after = [Vent Brandon:100]

app:7212020-01-29 07:24:37.701 am infostate.VentOpeningMap = [Vent Brandon:81]

app:7212020-01-29 07:24:37.697 am infoRunning ventHandler for Vent Brandon value: 100

app:7212020-01-29 07:24:37.034 am infoSet Vent Vent Brandon to 100

app:7212020-01-29 07:23:54.474 am infostate.VentOpeningMap after = [Vent Brandon:81]

app:7212020-01-29 07:23:54.463 am infostate.VentOpeningMap = [Vent Brandon:99]

app:7212020-01-29 07:23:54.455 am infoRunning ventHandler for Vent Brandon value: 81

app:7212020-01-29 07:23:44.034 am infostate.VentOpeningMap after = [Vent Brandon:99]

app:7212020-01-29 07:23:44.025 am infostate.VentOpeningMap = [Vent Brandon:100]

app:7212020-01-29 07:23:44.019 am infoRunning ventHandler for Vent Brandon value: 99

app:7212020-01-29 07:23:39.070 am infostate.VentOpeningMap after = [Vent Brandon:100]

app:7212020-01-29 07:23:39.062 am infostate.VentOpeningMap = [Vent Brandon:81]

app:7212020-01-29 07:23:39.057 am infoRunning ventHandler for Vent Brandon value: 100

app:7212020-01-29 07:23:36.977 am infoSet Vent Vent Brandon to 100

4

2 things:
turn on logging for the vent.
Set keenect logging to need help for this zone.

The recursive call to set vent might be the issue...

5

Nothing I can do about this, it's a mechanical device with a very simpe linkeage, it will never report back exactly what it was set to.

As far as battery life, can't help this either, but you might give lithium a try.

6

Yeah, In Keenect, I look for +-7. It is an artifact from the code I inherited from ST. I've always debated removing the recursive call that I got from the original Keenect. any thoughts are welcome.

7

I think it might be an issue with Binary mode. I have two zones and only one was doing the "hunting". I switched the "bad" one to non-binary and so far I have not seen the same issue . I took logs with it running in aggressive (I'm trying to reduce the amount of changes to see if that helps with battery life which is why I tried Binary mode) but it hasn't done the "hunting" like before. I'll keep monitoring.

8

That's too bad that Keen vents aren't accurate. I wasn't sure if the driver was causing this "hunting" between the ask, the offset, and the invalid value.

Yep, I'm trying lithium batteries to see how long they last.

9

When I was using mine while initially developing keenect I found that trying to run some sort of proportional control code didn't improve temperature control vs using one static value for open and another for closed. Point being, the less you command the vents the longer the battery life is going to be.

10

I agree. I was using the "Binary" mode which should just do Open/Close, but that's where I was running into this "hunting" problem on one of my zones. I'd like to get it to work so that there isn't so much net traffic to wear out the battery.

11

I'm thinking my vent is the problem. I just watched the vent bounce off the 100 mark to some lower position, which is what's probably causing the recursion since the position is greater than 7 away from 100. Stupid cheap actuators!

1 Like
12

I have mine set to min 10 and Max 90, so I might never see that issue.

13

Yeah, I assumed these vents would be accurate in the setting, but since it's not, I'm learning how to work around that.

1 Like
14

Hi @napalmcsr I made a few code changes that you might want to consider.

In Initialize(), I added this code after getting current zone temp so that activeSetPoint is not null initially:

debuglog "Set active set point"
def span = (state.zoneColdSetpoint - state.zoneHeatSetpoint) / 2;
state.activeSetPoint = state.currentTemperature < (state.zoneColdSetpoint - span) ? state.zoneHeatSetpoint : state.zoneColdSetpoint

For Binary mode, rather than compute the opening, I just hard coded this into CalculateVent():

if (VentControlType == "Binary") {
    VentParams.ventOpening = VentParams.tempDelta > 0 ? VentParams.MaxVo : VentParams.MinVo
} else {
  VentParams.ventOpening = Math.round(VentParams.tempDelta*VentParams.ventSlope.toInteger()+VentParams.ventIntercept.toInteger())
}

SetFanVentParams() needs to set maxVo = fanVO and I set minVo = 10. For error params, I set all values to 50 except slope and tempDelta.
SetVent() needs to check if newVo is null. I just wrapped the if (!PauseZone) logic with if (newVo).

15

Did anyone here ever get decent battery life out of their vents? I don't even move mine, using out-of-box drivers, and they die in 1-2 weeks. In lab testing, I can trigger the vent hundreds upon hundreds of times in a single day without even budging the battery life. (Starts at 90% on fully-charged lithium batteries.)

16

@JasonJoel has reported the same several times.

What are your "lab" testing conditions? Which controller are you using - Hubitat or Keen hub?

17

I'm waiting for Flair vents to go on sale. I got tired of changing batteries as well. My existing Flairs are still running on the same C batteries that came with them almost 3 years ago.

1 Like
18

Connected directly to HE -- I do not own the Keen hub. I set up an RM to trigger every 60 seconds, then determine if it actually moved. I got to 1,000 moves and decided to stop, since clearly this has nothing to do with actual motor usage. It's some strange massive phantom drain.

My guess is, since I've noticed these things losing connection to the hub, where a battery re-seat regains link, that when it gets 'lost' like that, the battery takes a dump. Probably bad coding in the vent itself.

1 Like
19

I did set up a new test that moves once an hour. This should give me some solid data, and represent possible real-world usage. Let's see exactly how many days it lasts.

Maybe the secret is to send regular commands or refreshes to keep it from "falling asleep." I dunno.

20

I used to do a refresh every 15 min, I still get a year on batteries. I think there are some lemon vents, personally. I had one that wouldn't move yet reported that it did move! When they work, they work, when they don't, you have no idea why.