Am I thinking about this correctly? First time DTH dev


(James) #1

Hi all,

I’ve got some Hunter Douglas blinds, and a DTH skeleton.

What I need to do is find out the current position of the shades (a GET) before moving them to a new position (a POST).

Both of these two operations work fine independently, but because the GET appears to be asynchronous, I’m thinking of options to either block, or set state on the DTH and pick it up on the callback method.

Is this the right way to think about these type of problem, or am I way off??

Thanks for the help!


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #2

You are definitely not “way off” :slight_smile:.

  1. Ideally, a DTH should never have to “ask” (poll) a Thing for its current Status: If possible, the Blinds should call an endpoint in your DTH (or companion web service SmartApp) each and every time they have been moved to a new position, so that the Device Instance always and already knows the current position. It can then display that on a Control Slider Tile and/or Value Tile and the user will know exactly how opened or closed the blinds are.

Are you connecting to the blinds via a LAN WiFi or a Cloud API?

The Hue DTH is a sophisticated example of the LAN case. The Hue Bridge does not call SmartThings when lights have been updated, but I think SmartThings frequently checks its log to look for state changes…


(James) #3

Thanks for the response.

I managed to get it working using state and a callback method but it’s ugly! It’s all LAN based.

Sadly the Hunter Douglas hub doesn’t have a publish mechanism, so if the state is changed from outside ST it’s difficult to know. I think it’s a design flaw in the blinds; as an example, I have a hardware remote which BYPASSES the hub and communicates directly with the blinds so the hub/blind are not guaranteed to be in-sync.

I’ve sniffed the traffic in the Hunter Douglas app and it does a “refresh” every time it launches as the only reliable source of state is from the blind itself (using an unknown radio protocol).

Anyway, long story short, it works but it’s far from ideal!


(David) #4

Interesting timing. I am a few weeks away from exploring connecting to Hunter Douglas Blinds. Would you share your devicehandler? I have a little experience now (over the last few months creating the yeelight integration)


(Chris) #5

I’m pretty far along on my own Hunter Douglas blinds SmartApp and DTH. Maybe we could collaborate rather than working separately on our own implementations. I haven’t posted it publicly here because I’m still not happy about a few rough edges. But what I do have working:

  • Shade/scene/room discovery
  • Creating individual Shade Things for specific shades OR auto-creating for all shades
  • Rudimentary control/tiles for Shades (set top/bottom position, job, calibrate)
  • Creating individual Scene Things for specific scenes OR auto-creating for all scenes
  • Scenes act as momentary buttons and also support ‘presetPosition’
  • Creating Room Things that have a user-specified Open Scene and Close Scene (this was specifically done for EchoSistant integration, so I could have a single Thing that EchoSistant opens/closes for a given Profile, rather than having it try to open/close close eight individual blinds)

Things that are rough:

  • Device discovery UX is bad/unreliable
  • Haven’t implemented blind-type-specific position handling (e.g., right now it thinks my Top-Down blinds have a bottom position)
  • Querying for blind status is very hit-or-miss – this may just be a limitation of the PowerView hub, as the quality of the data it returns for status updates seems very random, even with ‘refresh=true’ or ‘updateBatteryStatus=true’ are specified

Things that aren’t implemented:

  • Multi-room scenes (I’d like these to act like regular Scenes, but it’s a separate PowerView API and I haven’t gotten around to hooking it up yet)

If you are interested in seeing what I’ve done, I can work on getting it up onto GitHub tonight or tomorrow. (Again, as I say, I’m not in a position yet to really support others using my own code, since I have work still to do, but we could compare notes.)


(David) #6

Sounds like you are very close to a full solution…please don’t rush the GitHub…I am still wrapping up my own project.

Would very much prefer to collaborate rather than work on my own.

My Hunter Davis project is for my son’s flat, Just have the blinds a month. Have to say that the powerview app itself seems a bit ‘hit or miss’ on blind status, so I suspect your symptoms are not down to your implementation


(Chris) #7

Yes, the inconsistency seems there whether using the PowerView app or hitting the hub directly via HTTP, so it seems to either be a fundamental problem with their implementation, or else a side-effect of communication problems in the house. Blind control seems to (more or less) work, though, so I’m skeptical of the latter.

For what it’s worth, I put what I have up on GitHub. If you have any feedback, would be happy to hear it.


(David) #8

Nice and simple…when I get to looking at this will save me time for sure. Thanks for posting!