Hunter Douglas API

A Note of Thanks!... for the creators of this App. I built a new home and went with the PowerView+ (Wired) shades with newest smart hub. I have 22 shades and 2 Power Boxes (Each can run a max of 16 shades). Being able to integrate into my Hubitat ecosystem is fantastic, so much more capable that using their mobile App. It is also nice to be able to control individual shades without creating Scenes for each. The syntax for Alexa with only their App is screwy. I discovered individual shades from Hubitat, then created Groups in Alexa and now can say "Alexa Open/Close Deck Shades" Much better. :smiley:

*** For anyone considering the PowerView+ Shades... There is a know bug in the system that will not save the devices paired to the Power Box if it loses power! Not cool... Currently HD Engineering is taking the position that a UPS shoudl be in front of each Power Box (Already did that) because warranty does not provide for servce to re-program all of the shades. Not a big deal if you only have a few shades, but if you are me and have 22 shades, several 20+ ft. up it is not okay. Just got this info yesterday and will be in touch with HD next week. ***

Thank you very much for the information about having to make sure a Maximum Voltage value is set in Preferences then click "Save Preferences. This fixed my issue.

For any reading this please note that there was a value already in this field I re-entered it and saved it this fixed the issue.

Thank you once again.

Hi @1522shaw can you please help me analyse the JSON payload from your above quoted post? To be specific the payload shows your shades as 'type:79' -- can you confirm if those are 'DuoLite Lift' shades? And if not what model are they? Also can you please say if they are bottom up / top down, single / dual rail, and with / without tilting vanes? Many thanks in advance..

Out of curiosity - is anyone successfully using scenes with this driver? I've tried and the app shows the scene was activated (the shade positions look right) but the physical shades don't move. I tried this using curl from a terminal as well and see the same behavior so this is not an app problem but something related to the HD API; I'm wondering if I'm just unlucky and this works for others or if this is a known problem.

I have been using scenes with the driver. I have 5 blinds and use scenes on 4 of those blinds daily.

Interesting. Would you mind sharing the blind types and firmware versions? We just installed these and they are duette (mix of top down/bottom up and just bottom up). I tried three different scenes and failed for all - the powerview app shows the blind as if it moved but the blind actually did nothing.

I have all duette top down bottom up blinds. Firmware version 2.3.3147. I did have issues at first with some blinds working and some not. I added 2 repeaters and moved the hub around till I got all the bilnds to respond to the iPhone app. My scenes mostly work. The blind in the guest room likes to go up in the morning but not down at night all the time.

That matches what we have; I just rebooted the hub and it started working. Fingers crossed that’s a byproduct of initial setup noise and not something ongoing.

I had the installer out today to replace the hub (which we suspected was bad) and add in a few repeaters to shore up the signals. Much to my dismay, about 5 hours later the new hub "died" in the same manner the old one had; the app (and API) accept commands and the API response shows things 'moved' but the reality is the hub doesn't blink any activity lights nor does any blind move. As was the case before, rebooting the primary hub resolved it.

The installer seemed to indicate they have customers using Home Assistant which leads me to believe that's stable. It seems to just poll the /api/shades endpoint whereas this driver seems to poll each shade discretely (using /api/shades//) and I wonder if I'm somehow triggering some issue with the number of requests sent?

Would folks mind sharing how many blinds they have connected and whether or not they are polling via this app (setting on the app page)? We currently have 16 blinds and I had left polling enabled.

I'm currently testing with just the PowerView automation and have disabled polling to try to remove the Hubitat from the equation so if it's stable at least I know where to start.

I have 3 out of 11 connected, and I do have polling on

I have 5 blinds, 2 repeaters, 12 scenes with polling on.

thanks for the responses. I came across some old bugs in the PowerView hub related to missing '?' in the URL causing it to hang but that seems to have been fixed (based on some testing at least). The polling only appears to poll (enabled) shade info and repeater data (not sure what adding those to HE allows) so the amount of load/traffic this would generate is directly proportional to the number of shades actually enabled.

@cgmckeever - have you ever had polling set up for all 11? (e.g., were all 11 added to HE) I'm grasping at straws but wonder if there's some threshold where the PowerView hub radio is unhappy; since each poll results in a request to each blind staggered by 1s but asynchronously I wonder if latent responses stack up and cause problems.

I havent. I just got it all configured a week or two ago, and only needed it to close the first level blinds, and havent gone much past that. I think 3 was the max I had/have.

I only use scenes, I have my standard 'open at this level' and 'close' .... and they appear to work.

Your hub(s) are getting fried somehow? or is just more overwhelmed and you need a reboot? I can see if it is getting slammed polls it might jam up, esp. if a reboot clears it for you.

I have had it where things start to no be responsive, but they clear up after a while. This was mainly when I was first testing the controls out, and I might have slammed it.

Can you disable the HE integration, and then slam the crap out of the API via curl on some loop? See if you can recreate a DDOS on your blinds or something?

Then you know its a combo of how the HE integration is and how the hub handles things ..?

I'm using scenes for all the Rule Machine interactions but if polling is enabled it polls all blinds with a ?refresh=true query which forces the PowerView Hub to query the blind directly (vs. use hub cached values; per the API doc) and so my hypothesis is the RF responses are somehow slamming the PowerView Hub "at some point" - it works for somewhere between 6-9 hours (as far as I can guess) and then seems to just stop sending commands to the blinds but behaves like it is; the hub caches values it thinks it sent but the blinds never move and the little activity light on the hub doesn't blink. Rebooting it fixes it for another chunk of time. It never seems to recover on its own w/o the reboot.

I've disabled the HE integration and set up basic automation schedules in the PowerView app and so far things are stable which leads me to think it's the HE integration but I'd like to figure out why so I can solve it as I much prefer all my automations in one place and I want to link some of the routines together (e.g, HE knows when I'm upstairs and can set some of our TD/BU blinds to TD for privacy).

You're thinking along the same lines I was - set up some script to call the API over and over again and see what happens. I can probably craft it in such a way that I can ramp up the number of blinds polled as well (though I'll have to deal w/ either forking a process/subshell or threading to do this the same as HE would). Guess that's my next step unless someone else here has seen something similar :slight_smile:

1 Like

Change that and see what happens?

that's definitely a reasonable first start. I've done that (and disabled hourly battery refresh too for now) and we'll see how it goes. I also threw together a python script to behave the same as this app (async poll all blinds every 5 minutes with a 5s interval between requests) so if this works then I can use that script to see how many blinds cause this to fall over. The PowerView API doc does not elaborate on how often the hub refreshes the cache but I'd guess (based on the iOS app behavior) it's not very often. That said, if this proves to be the problem I'm seeing then it seems reasonable to just have any rule using a blind to refresh it prior along with a delay to wait for the new positions.

Not quite following? Turn off polling, have the rule due a refresh with a delay after so it updates .. I think I just talked myself through it :wink:

I feel from what you said, that ?refresh=true is over aggressive in general and should be changed but more definitely if your test shows that it is choking the hub

@rvrolyk are you syncing repeaters? Im not syncing repeaters. I dont even know why I would want to sync repeaters.

No, I don't have any of our repeaters added (and like you, I'm not sure why I'd want to). But I am syncing all 16 blinds and in another month we're almost doubling that so I'd love to get this solved before then :slight_smile:

All,
I am working on the following changes to the Hunter Douglas app:

  • group polling of devices
  • option to control polling of repeaters
  • option to control forced refresh polling

I should have the changes done soon.