Support for Keen Home Vents

[staraxis]

Hi I was wondering if there are any plans to support the Keen Home Smart Vents. I just got mine the other day and I would like to pair and use them with my Raspbee. I'm not really sure what the next steps would be but I'm willing to help as I can.

There is already some information here: https://github.com/yracine/keenhome.device-type about how they could be paired with a smartthings bridge.

The reason for this is it appears that there is a deconz component being developed for Home Assistant and it would be great to integrate these with HA.

Let me know if there's anymore info I can provide. Thanks!

[staraxis]

Does anyone know if this solution would work, or something similar for deconz? http://help.keenhome.io/3rd-party-integrations/connect-smart-vents-to-wink

I'm happy to provide any info I can to get his up and running.

[staraxis]

I have successfully paired a vent with the raspbee and I can see some data in the cluster info tab. What information would I need to provide to get a cover.cpp created or something similar. I would even be happy if they showed up in the webapp as a light so that I can integrate it in to homeassistant. More than willing to assist!

Let me know what info to provide and where to get it. Thanks

[staraxis]

@manup when you have a chance, would you be able to assist with this or provide me with any direction as to how I can get this moving? Your help is much appreciated!

[manup]

Hi @staraxis I think at first it would be helpful to play with the clusters On/Off, Level Control and Pressure measurement to learn how the device works. You can do this directly in deCONZ Cluster Info Panel and see how (if) the vent reacts. We should then figure out how to show the device in the REST API, light might be possible but is too hacky I guess.

[staraxis]

Thanks @manup. I can play with the device using the Cluster Info and it also seems to correctly read all data such as air temp and pressure. The on/off switch and toggle work Off = Closed vent On = Open to last position. In the Level Control section I can select the position of the vents using a number anywhere between 0 (closed) to 254 (fully open) in the Move to Level subsection. As I mentioned all other info is available such as battery level, battery type, manufacturer etc.

Let me know what more I can do. Cheers!

[staraxis]

Hi @manup is there anything more I can provide so this can be included in a new release? Thanks

[manup]

The provided information should be enough to get a working implementation, currently I'm not sure how to present the device via REST API. Functionality is like a dimmable light but that would be odd.

Maybe we should add a more generic /actuators endpoint in the classical actuators and sensors definition, for sensors we already have that (/sensors). The Resource and ResourceItem C++ classes build a perfect base for such an approach.

Code needs to be refactored to be more modular, with different handlers for various /actuators/<id>/type definitions. The /lights and other /type-foobar endpoints can still coexist, and forward to the /actuators endpoint and act as filter for the specific type.

@ebaauw what do you think?

[ebaauw]

I have been thinking about this one...

Functionality is like a dimmable light but that would be odd.

Indeed, exposing the vent control as a light resource would be odd, especially using state.bri for level. On the other hand, it will be easy to implement...

Code needs to be refactored to be more modular, with different handlers for various /actuators//type definitions

If you're serious about refactoring the API endpoints, I would go all the way:

• Use a single /devices endpoint for all ZigBee devices (nodes);
• Expose each ZigBee device under /devices/address, where address would be the ZigBee MAC address of the device (stripped from : and 0x);
• Expose each endpoint under /devices/address/endpoint, where endpoint would be the ZigBee endpoint number (in hex, without the 0x);
• Expose each (supported/whitelisted?) cluster under /devices/address/endpoint/cluster , where cluster would be the ZigBee cluster number (in hex, without the 0x), or the cluster name from the ZCL;
• Expose the read-only attributes under /devices/address/endpoint/cluster/state. A GET on state would return an object with a key per (supported/whitelisted?) read-only attribute, which would be the ZigBee attribute number (in hex, without the 0x), or the attribute name from the ZCL;
• Expose the read-write attributes under /devices/address/endpoint/cluster/config. A GET on configwould return an object with a key per (supported/whitelisted?) read-write attribute, which would be the ZigBee attribute number (in hex, without the0x), or the attribute name from the ZCL. A PUT on config` would take a similar object as body;
• Expose each (supported/whitelisted?) command under
  /devices/address/endpoint/cluster/commands/cmd, where cmd would be the ZigBee command number (in hex, without the 0x), or the command name from the ZCL. A get on commands would return the supported/whitelisted commands. A PUT on commands/cmd would take an object as body, with a key per (supported/whitelisted?) command parameter;
• We'd need separate top-level endpoints for ZigBee groups and for non-ZigBee resources created by the REST API plugin (rules, schedules, CLIP sensors, resourcelinks, configuration).

We could maintain "convenience" /lights, /sensors endpoints for backwards compatibility, and compatibility with the Hue bridge. E.g. /lights/id with uniqueid address-ep would be mapped to /devices/address/ep/0006 (for state.on), /devices/address/ep/0008 (for state.bri), and /devices/address/ep/0300 (for the colour attributes).

While it's a big change from the current API structure, the advantage of using a /devices structure would include:

• Easily extensible with newly supported devices, clusters, attributes, commands. I'm thinking Toggle, but also configuring attribute reporting and bindings; and ZDO stuff, neighbour reporting, etc.;
• Provides more insights to the REST API client what they're doing on the ZIgBee network (instead of obfuscating how a single PUT of a light state results in three ZigBee commands);
• A more modular setup of the REST API plugin, where all the ZigBee interaction would be exposed 1:1 to the /devices layer, and translations to REST API values would be in convenience layer.

[ebaauw]

We also need something similar to support turning on the siren or strobe for IAS devices with an IAS WD cluster.

[staraxis]

Has there been any more thinking on how this might be implemented in deCONZ? I'm happy to test anything and provide feedback to better refine it. @manup @ebaauw

[staraxis]

Any word on this one @manup? Sorry to be a pain but this would be amazing if these vents could be supported! Thanks

[manup]

Any word on this one @manup? Sorry to be a pain but this would be amazing if these vents could be supported! Thanks

No worries and please always feel free to push issues, sometimes they get unseen between all the issue traffic.

I'm thinking a lot about the sensor/actor topic in general recently.
As @ebaauw suggested I also favour a /devices endpoint were we provide all devices.

There are still some questions remaining to figure out. Therefore I think meanwhile as hack we should just add the vent as light (will later become just a device with subtype level controllable output) to be controllable. And the sensors as usual under /sensors.

[staraxis]

Hi @manup that sounds good to me and I can provide feedback for any issues as they arise. Exposing it as a light works for me as I can easily integrate into home assistant.

[ebaauw]

@staraxis, what's the manufacturer code (on the node info panel in the GUI)? We'd need that to whitelist the vent to expose the temperature and pressure sensors (incl. the battery).

@manup, I don't think its a good idea to expose the vent as a light: it's battery-powered. We probably need the sensor delayed read mechanism instead of the poll manager. Or maybe it supports attribute reporting on the OnOff and Level Control clusters? @staraxis can you try and configure that through the deCONZ GUI?

[staraxis]

Hi @ebaauw I have added some information below, hopefully it covers all that you have suggested. It seems to support attribute reporting through various places. I have also added the power configuration info at the bottom. Let me know if I'm on the right track with the info I've provided.
Here is the manufacturer code and some other info.

Attribute info from the OnOff cluster.

Level Control

Poll control

Temperature measurement

Pressure measurement

Power configuration

[manup]

@manup, I don't think its a good idea to expose the vent as a light: it's battery-powered. We probably need the sensor delayed read mechanism instead of the poll manager. Or maybe it supports attribute reporting on the OnOff and Level Control clusters? @staraxis can you try and configure that through the deCONZ GUI?

I totally missed that it is battery powered.

But according this it seems to support reporting:

https://github.com/yracine/keenhome.device-type/blob/master/devicetypes/keensmartvent.src/keensmartvent.groovy

Overall the groovy file gives a good overview what the device supports and what needs to be done.
I recon control commands should be queued relative to the incoming attribute reports.

[ebaauw]

I recon control commands should be queued relative to the incoming attribute reports.

This sounds like a serious refactoring of the poll manager to deal with always-on devices vs devices that only wake up periodically, regardless whether they're lights or sensors. I'm afraid that's a bit too much for me to handle.

Do you know if there is like a Wake-on-LAN equivalent in ZigBee? I noticed the Hue motion sensor responds to read attributes most of the time, even if I don't wake it explicitly. Or would it simply keep the radio on in some ultra low power state?

The power descriptor in the Info panel is no longer updated in the GUI (since after 2.04.35 or so - at the same time the battery symbol disappeared (I'm still hoping for its return (hint)). Is there a way to force-read the power descriptor? I've been wondering what the Hue motion sensor would report for Power Mode.

[staraxis]

Hi @manup let me know when this is up and running so I can test and then close the issue! Cheers

[apmon]

Would it by any chance be possible to initially just expose the temperature and pressure sensors as normal sensors as an intermediary step?
This might allow to monitor the system for a while to see how best to write the automation rules in home assistant for when it is actually possible to control the vents.

[ebaauw]

Could you please post a screenshot of the Basic cluster as well? We’d need the Model ID.

[staraxis]

Hi @ebaauw is this what you are after?

[ebaauw]

@staraxis Yes, thanks.

I whitelisted the Keen Home Vent in my latest PR. That should be enough to expose a ZHATemperature and a ZHAPressure sensor, including config.battery. Lacking a vent myself, I cannot test this, so please let me know if this works (list the sensor resources).

I also added support for Level Controllable Output devices and make an exception for the battery-powered Vent. I think this should be enough to create a light resource with state.on and state.level. Again, I cannot test this myself, so please list the light resource here as well. Since you were able to control the vent using the deCONZ GUI, it might just work through the REST API. I also whitelisted the Vent to setup attribute reporting for state.on and state.level.

[apmon]

Great, thank you very much.

I was able to compile your pull request and it looks like it is partially working. I now see the temperature sensor and pressure sensor and the light in the rest api, and I can get them read through the deconz homeassistant plug-in. In fact I can indeed even control the vent through home-asistant now and it reacts as fast as I would expect from setting the brightness in home-assistant until I see the vent change.
However, the temperature and pressure sensors even though they do show up, I haven't seen them report data yet and both have a "last updated non/ value null" reading so far.

"16":{"config":{"battery":null,"offset":null,"on":true,"reachable":true},"ep":1,"etag":"70bf24c5a1ac1472749cc5d73cf9bd2b","manufacturername":"Keen Home Inc","modelid":"SV01-610-MP-1.4","name":"Temperature 16","state":{"lastupdated":"none","temperature":null},"swversion":"1.0.23","type":"ZHATemperature","uniqueid":"00:22:a3:00:00:12:76:61-01-0402"},"17":{"config":{"battery":null,"on":true,"reachable":true},"ep":1,"etag":"70bf24c5a1ac1472749cc5d73cf9bd2b","manufacturername":"Keen Home Inc","modelid":"SV01-610-MP-1.4","name":"Pressure 17","state":{"lastupdated":"none","pressure":null},"swversion":"1.0.23","type":"ZHAPressure","uniqueid":"00:22:a3:00:00:12:76:61-01-0403"}

I don't currently have a screen connected, so I can't see if the values are reported correctly in the GUI at the moment. I will also let it sit here for a while to see if they will eventually report them selves.

I did have to re-pair the vent with deCONZ for it to show up, but I presume that is normal?

[ebaauw]

However, the temperature and pressure sensors even though they do show up, I haven't seen them report data yet and both have a "last updated non/ value null" reading so far.

deCONZ relies on attribute reporting, so the sensors periodically push their values to the gateway, instead of the gateway polling the sensors. This reporting needs to be setup first, which deCONZ should do automatically. However, for battery-powered devices this is tricky, as they can only be configured while not sleeping. It’s best to keep them awake during pairing, by interacting with them manually. Sometimes restarting deCONZ helps, sometimes I setup reporting manually, see #340 (comment).

I did have to re-pair the vent with deCONZ for it to show up, but I presume that is normal?

Yes.

[ebaauw]

This reporting needs to be setup first, which deCONZ should do automatically.

My bad, I forgot to also whitelist the vent for attribute reporting. This should be fixed in v2.05.16.

[apmon]

Thank you! It now mostly seems to work. In fact the controlling the vent, and reading the temperature sensor seems to work without issues so far, with the values updating as frequently as expected.
The pressure sensor on the other hand currently doesn't seem to update. If I manually read the pressure data in the deCONZ, it correctly shows up in home assistant, but then doesn't update and after 24 hours or so the value drops to 0. (I didn't repair the vent again after your latest changes)

[ebaauw]

Re-pairing the vent shouldn’t be necessary - deCONZ checks and, when needed, sets up attribute reprting after each restart. It sounds like attribute reporting for the Pressure cluster hasn’t yet been setup. You might try and restart deCONZ to see if it sets this up this time. Or try and setup attribute reporting manually, see above.

[staraxis]

Thanks for all the work @ebaauw and @manup on this. My vents are available through Home Assistant now with temp and pressure reporting. I haven't seen the pressure issues that @apmon has noticed but I'll keep an eye out. Lastly, do you think that this will eventually be supported as a "cover" rather than a "light" in future? It would be great if that were to occur - but I'm definitely not complaining and I appreciate the help! Just in time for Winter here in Aus. Thanks!

[staraxis]

I'm going to close this issue as the vents are working as expected. Thanks for all the help. It would be great to get this supported as a cover so I'll open another issue. That way other cover devices can be supported natively as well.