I wrote up an app and set of device types that allow you to use your SmartThings hub to control a Hunter Douglas PowerView Hub without requiring the extra Hunter Douglas RemoteConnect feature.
I’ve been running this integration now for about 5 months now and have found it to stable. It allows me to:
discover shade and scene already configured via PowerView
control my PV shades and PV scenes via the ST app
add my PV shades to ST scenes and other automations
use both Google Home and Alexa to execute voice control of my shades
This is great information. I wrote a similar plugin for HomeBridge to integrate my shades with HomeKit. I only have the roller shades though. No vanes.
I was trying to work with somebody remotely to integrate their shades that had vanes but we never got it working. Your explanation pretty much told me why.
If you want to integrate the roller shades let me know. I think it should be as easy as looking for type=5 and then you only have to worry about position1 and poskind1 to roll them up and down.
Have you ever had any issues where the shades were not reporting their position? I run into this as well.
Gavin, when I was sniffing the traffic from my IOS PowerView app, I noticed that they always sent a querystring param of refresh=true to the hub like:
http://powerview-hub/api/shades/1234?refresh=true (see API)
This is what I use in my device handler and I’ve never had an issue where the info was out of sync. I did not attempt to sniff the RF traffic from the hub to shade so I don’t know if using the refresh=true actually forces a live request from the shades (and whether this results in faster power drain over time due to an increase in requests).
As for the roller shades, I believe this handler will work as-is because the ST on/off capability is linked to posKind1: 1 with position1 values between 0 and 65535 because the Sillhouette shades also have standard roller functions. I don’t have roller-only shades though, so I can only speculate.
Thanks for the info. I’m going to try add the refresh parameter to my code so that if it returns no position to try again. That way I won’t constantly poll the blinds and drain the battery. Like you I assumed that is what would happen.
I’m not good at sniffing traffic so everything I did was put together from info I would find on the net. There is even a jog, updatebattery and calibrate command you can add to your API list if you like. I’ll just paste the curl commands I used as you can figure out what it was. Hopefully this helps.
This is great @johnvey - I am relatively new to the platform and installed your smartapp and device. Right now I am using it in tandem with Clang’s smartapp / DTH for different use cases - yours offers more functionality in some areas (e.g. your DTH exposes a dimmer like functionality in ActionTiles which is very useful) while his currently does expose battery levels, jog and calibrate.
Any thoughts on when you would be able to integrate your latest rev 855 APIs into the service manager and device handlers? In particular, I would be interested in:
Battery levels
Jog / Calibrate functionality
Most importantly (to me at least) - the ability to report ‘on’ and ‘off’ states as a switch attribute in addition to levels. Right now when integrating my HD shades into ActionTiles, they show as a question mark (image attached). According to their forum which I am linking below it is because your device handler does not return switch level on/off attribute. It would be great if for the shades for example, you would be able to return ‘on’ for raised and ‘off’ for down. I know it is a bit tricky as these are relative values per calibration of each shade but they do show up as a 0% to 100% range on the dimmer side attribute - perhaps a preference selector to determine if on/off is reported for the shade level or for the vane? - ActionTiles Question Mark Behavior .
Just had my Hunter Douglas Powerview shades installed a few weeks back and using IFTTT is getting a bit old and when I saw this post became super excited about integrating everything within Smartthings The only difference I can see from your setup is that I was given the PowerView V2 Hub. The hub discovers and outputs my shades and scenes but yields a banner at the top that “There was a problem processing your request. Please try again later.”
The app will complete and load up the shades/scenes in my devices but none function. Looking at the debug logs I see a few access denied from the initial load but none of the items function within. No errors I can see when I try to activate one of them either. Any thoughts? Is the framework on V2 different where your code wouldn’t be compatible?
@Michael_S24 Looking at the UUIDs, I’m guessing that the “access denied” error is being generated by some other downstream process in generally adding devices to ST. Can you identify what components -246f807499fb and -ae39-fc5075d00717 are?
I don’t have a v2 PV hub so I can’t say whether the API is or isn’t the same (my blind guess is that it adds hooks for better HomeKit integration). The v1 hub is a pretty dumb unauthenticated HTTP server so if they added even a modicum of security, that might explain an access denied error.
@johnvey Unfortunately I couldn’t find either of the components you mentioned (-246f807499fb and -ae39-fc5075d00717).
Not a coder but I’m thinking this may be the case too. Also, not sure how much of a need there is for others to integrate Hunter Douglas with ST. Will likely move forward with Harmony Activities but find the integration a little clunky.
@smurf I’ve updated the device handler as follows:
added a jog tile in the shade device handler (you may have to scroll down)
added battery percentage reporting tile
wired up the switch on/off status to the shade up/down state, where anything greater than 0% is considered “on”
I didn’t add the “calibrate” function because the right UI would need to exist in the SmartApp (and not the device handler) because there needs to be some explanation and confirmation screen. Given that the feature should only be used rarely, I’m not inclined to pursue it unless there is some high demand for it.
Let me know if this addresses most of your requests.
I updated my DH’s with the latest code and first thing I noticed is that my shades kept doing a jog every X amount of seconds. I think it happens every time the refresh command was called.
I haven’t had time to look into it but I had to revert to the previous code to stop it from happening.
Same here - I think you are correct @GavinCampbell , the refresh / poll event invokes a jog action.
@johnvey - Have you experienced the same issue? In reality, the jog is not that critical of a function and I, for one, can easily live without it. It was the switch attributes and the battery levels that were my main focus.
Also, the frequency by which the shades jog, makes me wonder - even if the jog command would not be invoked, is polling at such rate not draining the shades batteries - these are such a pain (and financial drain) to replace so I am very sensitive to the energy consumption aspect of these integrations. What is everyone’s opinion here?
@smurf@GavinCampbell thanks guys for trying it out. I’ve turned off the force request for the battery level so there should no longer be any jog side effect from refreshing. (I’m not sure why I didn’t notice this behavior before.)
In a previous change, I dialed back the most aggressive polling from every 1 minute to every 3 hours. If you are seeing any kind of refreshing at less than 3 hour intervals, you should either go into the device update page (click the gear icon) or delete/reinstall. The polling in SmartApps is a bit opaque so I can’t offer any kind of automated way of updating.
As for the long term question of “is the battery level going to be accurate without forcing a full battery check?”, I’m going to assume that the shades will update themselves every once in a while so the DTH will get that in due time. I will monitor mine to see if the percentage changes; if you guys could do the same, that would be helpful.
Thanks. I will give it a shot later when I have a free moment.
The battery levels aren’t something that you need to refresh often anyways. I figure when they first are setup you can force a refresh and after that just update whenever they are presented. We won’t see big changes from one update to another.
Another DH I was working with, I just grabbed the battery info whenever it was sent by the device. This meant that at first it wouldn’t see anything for about an hour but after that it didn’t need to force updates.
@GavinCampbell yes the current design is that there is no independent polling for battery. I’m just pulling the battery info from the data that comes back in the response from any shade command. The 3 hour interval is to keep ST updated if the shades are moved by the Powerview app or remote.
@smartie I don’t have access to a v2 hub so I can’t verify. Hunter Douglas says that the v2 hub supports Alexa directly (https://www.hunterdouglas.com/operating-systems/motorized/powerview-motorization/works-with) so that might be enough to tide you over. Obviously this will not help any with Webcore, but if that’s critical then perhaps try falling back to the IFTTT method (and ignoring this DTH).
The release notes for the other drivers on that page, like the Crestron and Control4, do indicate that they have been updated to work with v2 hubs. When I have time, I’ll try to unpack/decrypt that source code to see what was updated with v2.
