that's awesome @bujvary! Can you elaborate on what you mean by the first item?
I'll definitely update here as well if/when I can figure out what's causing the PowerView hub problems I'm seeing.
Not polling the devices individually
Hunter Douglas Powerview v2.3.0 is available via HPM
- Changed to group polling of devices instead of individual device polling
- Added option to control polling of repeaters
- Added option to control forced refresh polling
1 Like
This is awesome ..
what does this package do with repeaters? Im trying to understand the use case.
@rvrolyk if you havent tried the update yet .. wondering if you see improvement
My original intent for the repeater was to be able to dynamically set the color so I could use it as an indicator of some sort of issue like a door being left open, I never got back to making the code changes to expose setting color as a method.
I'll put that on my To Do list and get it done.
1 Like
oooh .. this is an interesting concept ...
I haven't installed the new version yet but have been testing (since ~1pm yesterday) with a modified app that omits both battery and refresh polling for shades (but still polls the hub for status every 5m). So far, no hangs at all! Prior it was hanging about once a day so while I'm reasonably sure it's resolved, I'm going to give it one more day before declaring success. The next thing to try after that is enabling the hourly battery poll and see if it remains stable (at which point I'll be satisfied thinking the instability was caused by the refresh). After that I'll update to the new version (want to keep variables low at this point).
1 Like
@bujvary Im seeing what looks like a bug with the new version. When controlling the shades via the remote, hubitat does not appear to see any changes. This did not appear the case prior to the update ..
Additionally, when using the Hubitat controls, close does not also change the tilt to 0. It still records the windowShade as closed, but does not zero out the tilt. I can test this for you if you unconver a change you wanted tested.
The driver not seeing the outside Hubitat changes is more problematic IMO
Polling settings:
I'll look into why the updated shade position is not showing up in Hubitat.
In the shade driver open/close changes the position of the shade while tilt open/tilt close changes the position of the vanes. Since the base capability of the Hunter Douglas shade device is WindowShade the state of windowShade is based on shade position and not vane the position.
Thanks for looking into why its not updating.
Open/Close via the HD app/remote also closes the tilt. Although, Im wondering if that discrepency just goes away once the proper status is updated in Hubitat
I understand that the app does that but Hubitat has two different capabilities for shades/blinds: WindowShade and WindowBlind. WindowShade does not have tilt control, while WindowBlind is tilt control only. I added tiltOpen/tiltClose commands to the shade driver for tilt control so all the different shade types were handled by a single shade driver. I'm thinking I may need to create different shade drivers based on the capabilities table.
Note that the current windowShade state will only be updated based on the position of the shade. It does not take into consideration the tilt position of the vanes.
Looking at the code briefly, I think this is because /api/shades?refresh=true doesn't actually cause the hub to actually poll each blind to refresh it. Unfortunately, as far as I can tell, the only way to get updates directly from the blinds is to actually call for each blind individually (which may trigger the problem I have).
I think the original polling mechanism was probably fine as long as having it use refresh=true can be disabled (in which case the 5 minute period would simply pull the cached hub values which will be correct some of the time) and instead forced via the device itself (e.g, the refresh button/method on the blind actually triggers refresh=true).
@rvrolyk I want to know why the hub doesnt know what is going on 
at all times ..hrm now that I type this, I guess when controlling the shades out-of-band (ie remote) they dont phone back home -- so without the hub polling each shade, it never really knows
That’s correct, the remotes speak to the blinds directly vs going through the hub so operation that way leads to the hub having the wrong (cached) values. The API doc is unclear and I haven’t tested but I think the hub has no periodic sync and it only gets new values when a user interacts with a specific shade via the app. I sniffed the request made in that case and it does send a request with refresh=true.
I know Ive opened the app and it thinks the shades in all sorts of wrong states ...
Hunter Douglas Powerview v2.4.0 is available via HPM
- Reverted back to individual device polling
- Removed option to control forced refresh polling
After reading through the Hunter Douglas Powerview API documentation today it's clear that the "refresh=true" query can only be used on individual shade calls (/api/shades/[id]) and not the "get all" shades call [/api/shades]. This means that we have to go back to individual shade polling using the refresh query string. This will ensure an accurate Hub view of shade position since shades can be moved without the Powerview hub's knowledge i.e., by pressing the motion button on the side of the shade or by using a PowerView Motorization handheld remote control device. This information is contained in the Background section of the Hunter Douglas Powerview API documentation.
Thanks @bujvary, that's my understanding as well. Unfortunately due to the instability I'm facing with forcing the refresh every 5 minutes, I would need to disable polling entirely. What I'd like to do is have a knob that controls whether or not refresh=true is provided in the API call. Ideally what it would do is:
- if polling is enabled and forced refresh is disabled, every 5 minutes call
/api/shadesto update Hubitat on the cached state of the blinds. In cases where a user only uses the app (and not any remotes) this will be 100% correct and in other cases it'll offer a reasonable state of things. This should be roughly what you had in v2.3.0) - if polling is enabled and forced refresh is enabled, things behave as they do today
- blind devices, when refreshed, will add
refresh=trueto the API call (e.g, how they behave today)
Until I have another day or so running, I can't say if the battery refresh causes any instability or needs a bit of tweaking as well. So far, my hub is stable with hourly battery refreshes but if it's somehow something that builds up over time, I feel a day may be too short of an interval given it's hourly vs. 12 times an hour.
Given I seem to be the only one having issues right now, I'm happy to get something that does all that and make a pull request if you'd like. The only benefit I gain over the existing solution is that I get a cached state of the world which will be accurate for a lot of rooms as we only actively use remotes in a few and the rest rely on automation. What do you think?
(side note: I'm trying to encourage our installer to file a bug with Hunter Douglas as their hub really shouldn't become unstable due to heavy RF usage; this seems like a deadlock on the radio or something else odd which shouldn't be happening imo)
I can reimplement the forced refresh option as you suggested so that if polling is enabled and forced refresh is disabled the poll every 5 minutes will call /api/shades i.e., the hub's cached state
For battery update, I can add an interval option (in hours) in the app that will allow you to control how often the battery status update is requested.
1 Like
that sounds perfect, thank you!
