Hunter Douglas API

Scenes have the Momentary, Switch and Window Shade capabilities implemented. So can control them as a switch in Alexa.

1 Like

What about dual-motion shades? In the Skill I only see the whole shade as a single device.

Is there a way to expose or set up a virtual device for the top and the bottom separately?

Realizing there's potential for bad ideas like trying to open "both" the top and the bottom to 100% or something. But I'm aiming for my wife to be able to say "Alexa, set Chris lower shade to 20%". Or "Alexa, set Chris shade upper to 50%". I can get by simplifying the shade names here to just his/hers, without the clunkier "Office Chris Upper|Lower" sort of moniker.

We do have some shades in the master bedroom that are also name labelled, because is it "left" when you enter the room, or when you're lying in bed? Yeah, voice commands are trickier than you'd think...

The Window Shade capability only supports open, close and setPosition so it can only control one direction of the shade which by default in the current driver is bottom up. I haven't had a chance to work on the shade driver to add the various shade capabilities as defined by Hunter Douglas. Unfortunately life keeps getting in the way :slight_smile:

The shade driver does expose setBottomPosition and setTopPosition as commands that can be used in Rule Machine.

1 Like

I added logic to update existing device labels if the device names changed on the PowerView hub. The new package, v1.4, is available via HPM.

1 Like

I poked at using Rule Machine and it wasn't immediately clear how I'd get to using those commands? Got a pointer to an example?

My goal, short-term, is "Alexa, set Bill Office Shade Lower to.." a percentage. I'll create whatever virtual devices are necessary.

I only need to do this on two shades, so it'll only be four virtual devices. His/hers, upper and lower. I'm assuming I'll keep the "whole" shade usable for a "close" or "off" value.

Sorry I was away this weekend so I just saw your message.

What I would do is create a virtual dimmer and expose it to Alexa via the Amazon Echo Skill app in Hubitat. Then in RM create a rule with a trigger on the virtual dimmer of "changed". For the Action to run, I would use "Run Custom Action", select "Actuator" as the capability, select your shade then select "setTopPosition" as the custom command. You should be able to use the value from the virtual dimmer in the call to setTopPosition.

Note that this all off the top of my head and I haven't actually tried a rule like this with a dimmer but I've done similar types of rules for other devices.

1 Like

Here's an example rule I threw together this morning.

Hi Sstretchh, could you message me the email of the people in charge of the API at HD? I can't find any contact info anywhere online.

Question how often does the app poll when periodic polling is enabled.

Every 5 minutes

Does activation of a scene or a shade cause it to poll prior to the automatic scheduled poll?

Yes it will poll the shades 15 seconds after scene activation to get their current state.

where's the right place in Hubitat to put something that periodically checks the battery level of the shades?

I have some that are battery powered and it'd be convenient to have something that checked them, say once a week. I would not want them checked constantly as that would likely reduce battery life.

Is there a way to change the open/close action? Most of my HD shades are top/down. That is, the top edge of the shade comes down, not the bottom edge rising (as would a 'normal' shade).

This is the JSON for the top/down shade while it is in the fully open, down position: (base64 decoded to show the shade name)

		{
			"id": 2402,
			"name": "Living Room Side Right==",
			"roomId": 30096,
			"groupId": 2458,
			"order": 0,
			"type": 7,
			"batteryStrength": 135,
			"batteryStatus": 3,
			"signalStrength": 4,
			"firmware": {
				"revision": 1,
				"subRevision": 3,
				"build": 1522
			},
			"motor": {
				"revision": 0,
				"subRevision": 0,
				"build": 128
			},
			"positions": {
				"posKind1": 1,
				"position1": 0,
				"posKind2": 2,
				"position2": 0
			},
			"aid": 3,
			"capabilities": 6,
			"batteryKind": 2,
			"smartPowerSupply": {
				"status": 0,
				"id": 0,
				"port": 0
			}
		},

I've been looking through the code and I'm not entirely clear on where edits would be suitable, as it looks like some of it is making assumptions that would be tricky to rearrange without re-writing a bunch of it (not that this is a complaint, rather I don't know how the code evolved).

Has Hunter Douglas published the full API officially anywhere?

Sorry I missed this post

If you are using the Hunter Douglas app/driver from my Github then the Hunter Douglas Powerview app already checks the battery levels no more than once an hour.

This is actually on my To Do list but I don't have any top-down blinds so I have no way of testing. I can go ahead and make the changes to the driver if you're willing to test.

Can someone else check their hub API for the timezone? Mine appears to be set wrong and the app doesn't appear to have a way to correct it?

http://ip-of-you-hub/api/userdata

Then look for the 'timezone' data. Mine is incorrectly reporting "America/Indiana/Indianapolis".

The lat/long appears to be 'sort of' correct, in that it's reporting what seems to be a geographic center of the zipcode that was entered into my account.

I mention this because that timezone does not use the same daylight savings offsets as we do here on the America/New York timezone.

The currentOffset value of -18000 is correct, as that's -5 hours.

Hub WebUI | Settings | Location and Modes

or

Hub WebUI | Location and Modes

Time Zone is in the lower left corner.

Yes, I'd be glad to give it a go.

I was looking at the driver code and can see where you're doing some select/case checking, but then it wasn't clear how the setposition sections were handling things.

Having done some coding myself in the past I recognize when code that starts doing things "one way" may need to be 'different' when a wider range of options is desired. I didn't want to start tearing into the code to learn what it's doing without asking first.

I have no single-action bottom/up shades at all (the normal kind). The two kinds I have are the 'top/down' single action, and the dual action (top/down and bottom/up). The top/down single motion is easy to handle.

The dual-action presents a different kind of problem. Treating it like a single shade is less than ideal. At least from the perspective of "simple" home automation, where everything is a simple on/off or dimmer-like kind of value. For the single-action shades it's reasonable to treat them like a light switch. But for double-action (or venetians with tilt) the analogy doesn't quite work.

And for voice control it gets even more annoying. I've got one room with five top/down shades. For the most part they can be considered two groups. They're two on the side of the room, three on the front. I could call them "Living Room Shades Side" and "Living Room Shades Front". They're actually "Living Room Shades Side Left|Right" and "Living Room Shades Front Left|Center|Right".

The dual-action shades are in the home office, alongside his/her desk positions. So they're named "Bill Office" and "Chris Office". But here the control gets more tedious. Because they're more like two shades each. There's a top/down and a bottom/up. But what's "open" for these? Open fully retracted upward? Or fully descended? We do use both kinds of opening depending on a whole range of conditions like light level, weather or personal preference/mood.

I can send you the JSON dumps from my devices if that'd help. Just getting the top/down units to handle open/close appropriately would be a good start. I'm open to discussion on the dual-action conundrum.

I'm talking about the Hunter Douglas shade controller hub, not the Hubitat.

It's a separate hub device that acts as a gateway for the shades.

But for the sake of completeness, I did check. The shade hub does not have the same data the Hubitat. And the Hubitat data is correct, both on location and timezone, as I expected.