Keen Home Vents, ZHA, and Battery Life

I recently moved my Keen smart vents from the Keen software and smart hub to a flashed Sonoff Zigbee bridge with ZHA and HomeAssistant. I worked up custom automation (Node Red with some custom JavaScript for determining when to trigger the vents) and it does everything I’ve ever wanted the Keen software to do: alert me of low batteries, allow both heating and cooling set points for each room, integrate with my Ecobee sensors without constantly losing its connection to the Ecobee web service… but it seems to have killed the battery life of the vents, as the batteries are now lasting on the order of 1-2 weeks.

Is there a way for me to find out how often (if at all) they’re being polled for their status, and to minimize that polling if it’s happening? I know I’m not sending them open/close events too often, because the code I wrote to do that doesn’t send the vents messages when they’re already at (within a margin of error) the positions they need to be, and I’ve verified that that part of the automation works.

Is it possible that, by querying the HomeAssistant data structure in Node Red for their positions, I am actually causing the vents themselves to be polled? I had assumed that data structure just gave me the last data that was received, at whatever frequency that naturally happens.

Any suggestions would be helpful. Thanks!

1 Like

For ZHA events that are captured by ZHA but not sent to traditional HA sensors, you can use the event (be careful of plurals) viewer in HA, see picture below for a Aqara Cube that is included in ZHA HA zigbee network, but is not mapped to any sensors in HA (other than it’s battery level). See the blueprint work in this forum that a lot of folks are doing to capture and use ZHA events for devices and controllers like Aqara Cube. If you devices are doing same, then you can perhaps use HA automations to monitor and control your zigbee devices. I don’t think that most zigbee devices do ‘polling’ behavior as a way of communications. There maybe some that do this, but I believe for the most part zigbee devices do a ‘push’ model. I am experimenting with some simple code to watch my ZHA network, perhaps it might offer you some ideas as well. Good hunting!

If you are simply requesting attributes and states from Home Assistant to gather data, then the device is not being “polled” as a result of that. However, if you are setting the device to be, for instance, “open” even when it’s already open, this will consume some power from the device. If you are making any kind of service call at all where the device is concerned, it could be using some power.

I have a similar setup using Keen Vents (4 of them) and ZHA with a HUSBZB-1. I went through a set of batteries every 6-12 months, depending on how frequently I was opening and closing the vents.

@dmzimmerman I’ve tried adding my Keen 4x10 vents to HA via the ZHA add on. They connect and show a recent last connected/communicated state, but whenever I try to use the open/close vent buttons (via Lovelace or in the entity itself), nothing happens.

It’s like the vent is connected and reporting state/temp/etc, but not actually responding to any open/close commands.

Was there anything special you had to do to get these to work?

No, I didn’t have to do anything special; when I added them, they just immediately worked (and, as a nice bonus, were exported to HomeKit as blinds, so I can control them via the Apple Home app too - though that control seems a bit flakier than just doing it directly through Lovelace).

I have occasionally seen them un-pair themselves - in particular, when running out of battery, sometimes when they power up again they start looking to pair instead of re-connecting to the already-paired network - which is weird… but thankfully, if I pair them again through ZHA, they’re immediately recognized and regain their old “identities” in HomeAssistant, so I don’t have to mess with configurations, etc.

OK, good to know. It appears that the default lovelace card used to open/close these does not work. I added a new node red flow that included an inject which called the open_cover and close_cover commands for my vents and they work fine.

Would you be able to share your custom node red flow for these vents? I’d be really interested in seeing it so I’m not reinventing the wheel to integrate these vents with my ecobee sensors.

Seconded, I’m very interested, @dmzimmerman

OK, see I haven’t had time to write a README for it or anything, but in summary:

  • I created many input numbers and groups for configuration (and simultaneous control of multiple vents), which you can infer from the code
  • the JavaScript files there correspond to the scripts inside the Node Red nodes with custom scripts, it’s just easier to edit them outside Node Red and then copy/paste them, so I kept them separate
  • the YAML file goes in HomeAssistant’s config/packages.
  • the heat_cool_settings directory (and its contents, customized for your setup of course) goes in HomeAssistant’s config/.
  • I didn’t write any code for battery alerts myself, for that I use the wonderful package at, described here

Hopefully you find this helpful; feel free to ask questions. One thing I like about it is that the ramping of vent open/close is customizable; currently, I have it set to close the vents to position 8 (very nearly closed, but still letting enough air in to make it not super noisy) when the room is within the desired temperature range, to 50 when the room is within a degree of the temperature range, and to 100 when it is further than a degree off - but that was really just an experiment on my part, and I haven’t done any further experiments to find whether there are better numbers or ranges to use there (if you find any, let me know!).


Thank you for sharing this!
May I ask if the Node-RED separate flow that you have to Store heat and Cool settings meant to store to the separate from the heat_cool_settings directory? It seems to point to the vent-settings directory…

I believe I actually do use the vent-settings directory… it’s possible that I made that consistent everywhere after I uploaded this version of the flows. I should probably throw a revised version up on GitHub, because I actually found a bug in it once the weather got warmer where it wouldn’t actually work properly for A/C…

1 Like

Thank you so much!
I made some changes on my end once downloaded. Changed the open position from 100 to 99—this makes the motion of the vent smooth and deliberate and prevents the backlash on larger vents mounted on the ceiling duct openings.
Next for me to figure out is how to use the offset from the set point on the thermostat (as in I want this room -3ºF cooler as opposed to set it to 72ºF) instead of the absolute temperature control as well as the accumulation counter to prevent too many vents for being in a closed position, as to avoid extra noise and the pressure.

How is this coming along? Been searching and doesn’t seem to be a lot out here for automating smart vents on HA. Would love to get my keen vents off smartthings and brought over to HA.

I have actually made a lot of mods to the dmzimmerman posted solution to fit my situation, including the modification to add both the set point and offset modes, as well as the high-pressure protection stuff (however awkward it may be) it all of this seems to work quite well for me.
I have not yet branched it out (though I have submitted a brach on the GitHub adding the documentation to the existing version, though it has not yet been approved)
I will do this after cleaning up and documenting better then where it is now.

I’d love to see the modifications you’ve made; it sounded like you were saying you created a pull request on GitHub, but I don’t see one; I’d be happy to merge it in if you made one.

I apologize for not having had time to document it better myself.

As I am really new to this, it is possible that I simply used the GitHub wrong
I just added a proposal for new file

As I said, I’d love to see the changes you made. I see that you forked my repo on GitHub; if you want me to incorporate the changes, you should make a pull request on the original repo, with your branch from your forked repo. Right now it looks as though you made a pull request on your own repo, which I can’t do anything about (but, of course, you could merge it into your own main branch).