Openhab-addons: [hdpowerview] Support for Duette shades

[berland]

For Duette shades, the top position of the shade is also steerable, but this is not supported by the binding.

Supporting this is only a matter of a new channel and adding a parameter position2in the json body, like this:

{"shade": {"id": 63778, "positions": {"position1": 0, "posKind1": 1, "position2": 1000, "posKind2": 2}}}

and POSTing this json to http://powerviewhub/api/shades/63778

posKind2: 2 is important to get it to work.

(and interpreting this position2 while polling).

[yog18r]

Not sure if this is available elsewhere but I'm attaching the Powerview IP control guide which confirms posKind2 being for the secondary rail and also gives the range of values etc for open/closed. Hope this helps someone.

PowerView HUB Over IP.pdf

[mstroeve]

I just created a bounty for this issue https://www.bountysource.com/issues/67368673-hdpowerview-support-for-duette-shades.

[andrewfg]

I am doing some other work on this binding at the moment => @berland and @mstroeve are you still interested in having this enhancement? If so, are you willing to test it for me, since I do not have any Duette shades myself?

[berland]

Yes, I can test.

[mstroeve]

Same for me i can also test. It would be nice to get the positions of both rails. Currently use a scene to detect if some of my powerviews are all the way down to trigger closing zwave curtains. But when some manually close them i currently can detect it.

[andrewfg]

Many thanks @berland and @mstroeve to you both for your kind offer to help. As a starting point can you please answer for me the following questions about what happens in your systems with the existing binding when you use it with your Duette shades?

• Does the current "position" Rollershutter channel, display the position status of the _lower_ shade (or the upper one)?
• Does sending a command to the "position" Rollershutter channel cause that part of the shade to actually move?
• Does the direction of movement match what you would expect for a regular single top-down shade?

PS I can tell you already that we will have some fun getting the movement UP/DOWN directions, and 0..100% position indications to align properly with the behaviour of single top-down or bottom-up shades. So perhaps you could give some thought about what you would consider to be the "correct" directions & indications?

[andrewfg]

But when some manually close them i currently can detect it.

Yes, I noticed that too. This is in fact the original reason why I started to do work on this binding. The following is a quotation from the API document _"Hubs maintain transient shade state such as position and battery level. Any API call that returns the shade position and/or the battery level is delivering the last Hub saved value of these attributes. In general, shades are moved via API calls to Shades, Scenes, and Scene Collections. Since the Hub is always involved in these motion events, it tracks the final shade position and saves it; however, shades can be moved without the Hub’s knowledge. An individual can manually move a shade simply by pressing the motion button on the side of the shade. In addition, shades can be moved using a PowerView Motorization handheld remote control device. In both of these cases, the Hub is not told of the shade’s new position. Consequently, to ensure an accurate Hub view of shade position, an application may choose to call the GET /shades/{id} API with the refresh query string set to true."_ => So I am planning to do just that!

[andrewfg]

Hi @berland and @mstroeve, I already made significant progress on the code (its on my fork of the OpenHAB repo here). You can get an idea of the changes by looking at the ReadMe file (scroll down to see the additions). You should be able to build your own Jar from the repo (but if you want the Jar separately please let me know..)

[andrewfg]

PS the jar is here

[berland]

I have tested your jar (removing the Thing I had for the shade, and re-adding it through its id gave me a new Thing with the secondary channel).

Not able to control it or get the status; check this TRACE log:

09:43:20.916 [DEBUG] [nternal.handler.HDPowerViewHubHandler] - Polling for state
09:43:20.917 [TRACE] [erview.internal.HDPowerViewWebTargets] - API request = http://hdpowerview.r40/api/shades/
09:43:20.937 [TRACE] [erview.internal.HDPowerViewWebTargets] - JSON response = {"shadeIds":[63778],"shadeData":[{"id":63778,"type":8,"batteryStatus":0,"batteryStrength":0,"roomId":891,"firmware":{"revision":1,"subRevision":8,"build":1944},"motor":{"revision":0,"subRevision":0,"build":267},"name":"R2FyZGluIDE=","groupId":18108,"positions":{"posKind2":2,"position2":23194,"posKind1":1,"position1":26566},"signalStrength":4,"aid":2,"capabilities":7,"batteryKind":"unassigned"}]}
09:43:20.938 [DEBUG] [nternal.handler.HDPowerViewHubHandler] - Found 1 shades
09:43:20.938 [DEBUG] [nternal.handler.HDPowerViewHubHandler] - Skipping non-bound shade 63778
09:43:20.938 [TRACE] [erview.internal.HDPowerViewWebTargets] - API request = http://hdpowerview.r40/api/scenes/
09:43:20.997 [TRACE] [erview.internal.HDPowerViewWebTargets] - JSON response = {"sceneIds":[],"sceneData":[]}
09:43:20.997 [DEBUG] [nternal.handler.HDPowerViewHubHandler] - Received 0 scenes

where I guess the 'Skipping non-bound shade' is the thing to solve?

For reference I have uploaded my current "binding" using only mqtt and python to https://gist.github.com/berland/ec762e4c555a167953829aece46ec4a3 which I have used for the past 1-2 years for controlling my shade.

[andrewfg]

I guess the 'Skipping non-bound shade' is the thing to solve?

Not really. That is just a normal message from the binding, which says that the Shade is in the Hub but is not configured in the binding. Probably you need to go to PaperUI Inbox and add the Shade from there..

I copied the JSON payload from your trace log, and parsed it in my test environment, so I can at least confirm that the new version of the binding can correctly read your hub's JSON for your shade.

Note: I also made a new build of the binding here which includes a few refinements. Please note that if you just installed OH 2.5.6 (which "stupidly" I did today) then you will notice that the maintainers seem to have removed the dependent jcifs-netbios package from the main distribution, so for the time being I have added a copy of that file also in this download link.

[andrewfg]

http://hdpowerview.r40

@berland I noticed you have an fqdn so I suppose you have a DNS (??); the hub binding works with IP addresses, and I am not sure if fqdn are fully supported; perhaps try this ..

things file ..

Bridge hdpowerview:hub:me "PowerView Hub" [host="192.168.1.123"] {
    Thing shade s63778 "Garden Shade" [id="63778"]
}

items file ..

Rollershutter Garden_Shade_Position "Garden Shade Position [%.0f %%]" {channel="hdpowerview:shade:me:s63778:position"}

Rollershutter Garden_Shade_Secondary "Garden Shade Secondary Position [%.0f %%]" {channel="hdpowerview:shade:me:s63778:secondary"}

[berland]

I can confirm it works with my FQDN. I can confirm that moving both primary and secondary now works when configured using a things file and an items file (as pr. your example).

It does not work yet through Paper UI. Discovery of the hub does not work (as said in the code/docs, and also in #6910, so I add the hub manually using FQDN or IP. After hub is added in Paper UI as a thing, I cannot add any shades (even though my shade is apparently found through the json response in the trace log). If I add a shade manually (by providing the id in Paper UI), I can't control the shade (that is the log above).

openhab> things  list | grep shade                                                                                                                             
hdpowerview:shade:me:s63778 (Type=Thing, Status=ONLINE, Label=Garden Shade, Bridge=hdpowerview:hub:me)
hdpowerview:shade:22871743 (Type=Thing, Status=ONLINE, Label=PowerView Shade, Bridge=hdpowerview:hub:me)

The second thing listed here is added through Paper UI and does not work. I see it has one less colon-separated field, perhaps related?

[berland]

When adding shades manually in Paper UI to a hub, I can provide any "id", and they will come up as "Online" (even though it does not work).

[andrewfg]

Hmm. The auto discovery problems that you mention, are not a result of the changes I have just made; they pre-date my changes. However I will see if I can fix them too.

I also noticed that the NetBios discovery does not work; as you say, this is due to the v2 hub using a different Netbios name than the v1 hub. I was struggling to fix this because on my Window test environment Netbios is blocked by Windows or a/v software, and I could not figure out how to solve that yet. :(

It seems that the v2 hub uses mDNS discovery too. And OpenHAB has a an mDNS plug in in the core, but it is poorly documented, so I was not able to code for that yet either.

[andrewfg]

Ok @berland, I have made a few more fixes; my full change log so far, is as follows:

• Softer handling of hub Http 423 errors
• Support for shade secondary position => please test it on a physical top-down / bottom-up shade
• Support for Netbios lookup with v1 _and_ v2 hub names; my LAN wont support NetBios, so not tested => please test if you can
• Alternate support for mDNS zero-conf lookup; all tested and working
• In the shade auto- discovery process, the discovered things now include the bridge Id in their thing Uid
• Shades that are in the binding but not in the hub will now show OFFLINE
• Improvements in the clarity of logging messages
• Added a refresh Switch channel to the hub; to order the hub to refresh its state after remote control / manual commands
• A refresh can also be triggered by sending RefreshType.REFRESH from within OpenHAB e.g. from within the rules engine
• Comprehensively updated and extended the ReadMe file
• Internal code quality improvements, null checks, exception catching, spotless formatting, etc.

The new jar is here -- enjoy!

[berland]

Great progress from the latest jar!

• Autodiscovery of my v2 hub works!
• Discovery of my shade works!
• Control of the shade by items linked to the Paper UI-added shade works (I'll revert to text-based config afterwards)
• Adding shades manually in PaperUI does not work (though not necessary for me), the uid's generated do not include the hub's id, and they come up as online no matter how.
• Adding a shade with an erroneous id through the text-based config file gives correctly an offline shade.

[mstroeve]

Nice progress indeed!

I don't have much time this week but made a quick test.
I added the binding and the hub was discovered nicely when adding it the shades were also found in the inbox.

Controlling through PowerView app
Adding a item for a secondary position works and I get a changed event value in frontail when changing this secondary position.

Manually controlling secondary position through pebble remote
No event/changed value was logged so i added hub refresh switch and triggered it. But I stil can't seem to get a new value?

Using roller shutter down/up command in paper ui
I tried to click on the down button in paper ui of this secondary shutter but the top shutter was going down??
So I tried to click on the stop button and I noticed:
[WARN ] [rnal.handler.HDPowerViewShadeHandler] - PowerView shades do not support StopMove commands

[andrewfg]

Hi @berland

Adding shades manually in PaperUI does not work ... the uid's generated do not include the hub's id ..

_I think you found a bug in PaperUI or the OH core !!_

I do confirm your finding that the uid's do not contain the bridge id. However I tried it on some other bindings and the same thing happens, so I think this problem is outside the binding code.

=> Probably we need to open an Issue with the core developers?? But before doing that I would appreciate if you can do some tests on your side with other bindings, and re-confirm that you see the same issue on them?

PS

.. and they come up as online no matter how.

Notwithstanding the above, I should be able to fix this :) _UPDATE: fixed in next build._

[andrewfg]

Hi @mstroeve some answers to your points below; and some questions also..

---

Manually controlling secondary position through pebble remote
No event/changed value was logged

Yes, this is normal behavior. The remote talks to the shades directly, and not to the hub; so the hub is not aware of the change.

---

so i added hub refresh switch and triggered it. But I stil can't seem to get a new value?

Certainly this is what you should be doing. It tells the binding to initiate a full scan of all shades to force an update of all shade's states. Do you have a large quantity of shades? The update seems to take a few seconds per shade. It works for me, but if it really does not work for you, can you please supply a trace log?

Note: I was considering to do a regular manual refresh (automatically) within the binding, but I think there may be problems with timing if the binding tries to do it every minute (especially if there are many (say 10..20) shades in the hub). Also I suppose the batteries in the shades might expire sooner. The ideal solution would be to only do the refresh when the user is actually looking at the data (this is how the PowerView App does it). However in OpenHAB there is no way really to determine if the user is actually looking at the data.

---

Using roller shutter down/up command in paper ui
I tried to click on the down button in paper ui of this secondary shutter but the top shutter was going down??

I'm not sure I understand your comment. I think that we are trying to achieve the functionality shown in the attached picture, but
I don't have a physical Duette shade, so it is hard to visualise => can you please confirm that is what you would expect?

Our problem is that, (if I understand the HD API description correctly), the internal raw co-ordinate system (the position1, position2 variables in the JSON payload) of the shades is as follows. I think this means the functionality of the RollerShutter actors in OpenHAB will be logically reversed between single rail and dual rail shades -- but I cannot check this. If it is indeed reversed, then I will need to add some logic to the code (either a manual setting or an automatic one based on the shade type) so that the RollerShutter logic appears to a human being as -- well -- logical.. => I really really need your feedback on this!

• Single rail shade: (primary rail) Y-axis raw co-ordinate 0 => shade closed (window dark) // Y-axis raw co-ordinate 65535 => shade open (window clear)
• Dual rail shade (bottom rail = primary): Y-axis raw co-ordinate 0 => shade open (clear) // Y-axis raw co-ordinate 65535 => shade closed (dark)
• Dual rail shade (top rail = secondary): Y-axis raw co-ordinate 0 => shade open (clear) // Y-axis raw co-ordinate 65535 => shade closed (dark)

---

So I tried to click on the stop button and I noticed:
[WARN ] [rnal.handler.HDPowerViewShadeHandler] - PowerView shades do not support StopMove commands

This is indeed true. The PowerView hub does not have any support for Stop/Move commands. Sadly I cannot change that.

[andrewfg]

PS I _think_ that we are trying to achieve the following (it is _not_ what we have in the current build) => so can you both @mstroeve and @berland please kindly advise on this table before I change anything?

_NOTE: IMAGE CORRECTED !!_

[andrewfg]

The PowerView hub does not have any support for Stop/Move commands

PS thinking more about this, perhaps I could hack StopMoveType.STOP as follows (although StopMoveType.MOVE would still have to fail) => what do you think?

setHubPosition( getHubPosition() );

[berland]

Hi @berland

Adding shades manually in PaperUI does not work ... the uid's generated do not include the hub's id ..
_I think you found a bug in PaperUI or the OH core !!_
=> Probably we need to open an Issue with the core developers?? But before doing that I would appreciate if you can do some tests on your side with other bindings, and re-confirm that you see the same issue on them?

Tried on the Hue binding, I could add a Thing manually with a bogus (hue) id and it comes up online. The thing uid does not contain the hub's uid, as the other working Hue things do, so yes it seems the same problem is there.

[andrewfg]

@berland between us we have observed the same problem in Hue, PowerView, Velux, and also my own NeoHub binding; so it is definitely an issue in the core => since you were the first to observe it, do you want to report the issue yourself? or shall I do it?

[berland]

@berland between us we have observed the same problem in Hue, PowerView, Velux, and also my own NeoHub binding; so it is definitely an issue in the core => since you were the first to observe it, do you want to report the issue yourself? or shall I do it?

I'd be happy if you report it, I would not know how to formulate the problem precisely.

[andrewfg]

PS this is what I have written in the ReadMe..

[andrewfg]

I'd be happy if you report it, I would not know how to formulate the problem precisely.

Done here

[andrewfg]

I did a few "final" tweaks; you can download the latest version of the Jar here ..

[andrewfg]

PS @berland and @mstroeve please let me know when you are happy with the new functionality, so I can open the respective PR for it.

https://github.com/andrewfg/openhab-addons/tree/hdpowerview-experimental/bundles/org.openhab.binding.hdpowerview

[andrewfg]

The PowerView hub does not have any support for Stop/Move commands

I think I have discovered an undocumented hack for this!

In the HD API specification, there is a documented JSON command to “jog” the shades {"shade": {"id": 63778, "motion": "jog"}} and on a whim I tried the same command with “motion”: “stop” and, at least on my shades, this does work.

[berland]

Testing the 202005271221 jar with RollerShutter items in Basic UI: Bottom rail works fine. Up/down buttons in Basic UI makes sense.

Bottom (primary) rail responds reliably in less than 1 sec.

Secondary rails is slower to respond (2-8 secs), and sometimes does not respond at all, not sure if that is the hub or the binding. When clicking in Basic UI, the log immediately gives this:

13:56:41.633 [TRACE] [erview.internal.HDPowerViewWebTargets] - API request = http://192.168.1.67/api/shades/63778?refresh=true
Then 6 secs later I get this

13:56:47.609 [DEBUG] [nternal.handler.HDPowerViewHubHandler] - Polling for state
13:56:47.610 [TRACE] [erview.internal.HDPowerViewWebTargets] - API request = http://192.168.1.67/api/shades/
13:56:47.797 [TRACE] [erview.internal.HDPowerViewWebTargets] - JSON response = {"shade":{"id":63778,"type":8,"batteryStatus":3,"batteryStrength":186,"roomId":891,"firmware":{"revision":1,"subRevision":8,"build":1944},"motor":{"revision":0,"subRevision":0,"build":267},"name":"R2FyZGluIDE=","groupId":18108,"positions":{"posKind1":1,"position1":0},"signalStrength":4,"aid":2,"capabilities":7,"batteryKind":"unassigned","timedOut":true}}

and in this case nothing happened (probably related to timedOut=true)

[andrewfg]

Hi @berland many thanks for taking the time to do these tests.

Hmm... Interesting...

Before we interpret your log traces, we need to know that there are two unrelated processes in the binding:

• The hub maintains an internal cache of the last known state of its shades. And the binding runs a regular timed polling process that reads those values. The polling is fast and reliable since it depends only on the Ethernet connection between binding and hub. The following is a trace from the polling process..

13:56:47.610 [TRACE] [erview.internal.HDPowerViewWebTargets] - API request = http://192.168.1.67/api/shades/

• If the user has manually operated the shades (via a push button or a remote control) the hub's internal cache might not reflect the actual status of the shades. So there is a second refresh process, which forces the hub to query the shades a via its 868MHz radio link, and physically force the shade to provide its new state values, and update the cache accordingly. Since this refresh relies on an RF connection it is a) less reliable, b) might suffer from dropouts, and c) takes a longer time round-trip. The refresh process is triggered by the OpenHAB core sending a RefreshType.Refresh command on binding start up, and perhaps some other times thereafter, and refresh may also be triggered by a user manually turning on a switch item connected to the hub's refresh channel. The following is a trace from the refresh process (notice the ?refresh=true query parameter on the end)..

13:56:41.633 [TRACE] [erview.internal.HDPowerViewWebTargets] - API request = http://192.168.1.67/api/shades/63778?refresh=true

Therefore the 6 seconds "delay" that you observe between your two traces is not an issue, since the first trace comes from the refresh process and the second one from the polling process. This is not a problem.

However there is, as you say, a problem (actually two) in the JSON response having the "timedOut":true element in it, which comes from the refresh process. The fact that the JSON response exists at all tells us that the Ethernet communication between binding and hub is working, however its content says something is indeed wrong inside. Apart from the positive timedOut value, compared to the polling trace you sent a few days ago from the same shade, there are also missing position2 / posKind2 elements, and furthermore position1 is explicitly zero.

Extract of JSON from the refresh trace you sent today..

"positions": {
    "posKind1": 1,
    "position1": 0
}

Extract of JSON from the polling trace you sent a few days ago..

"positions": {
    "posKind2": 2,
    "position2": 23194,
    "posKind1": 1,
    "position1": 26566
}

The differences do support the hypothesis that there may be something wrong in the communication. But it would be something in the RF communication between the hub and the shade itself, so I think it this is not something I can fix. _=> How close is your hub physically located to your shade?_

Another possibility is that in today's trace "position1": 0 so perhaps it may be a special case where it does not bother to send a position2 value if position1 is zero ?? _=> What is the actual physical position of your two rails? => And could you try some other position(s)?_

[andrewfg]

PS another possibility may be that on polling it returns a full / valid set of position1 and position2 values, whereas on refresh it only returns a truncated / invalid position1 ?? _=> I would need more trace logs to find out._

[andrewfg]

To be specific on the co-ordinate system for shade positions, I will need a trace JSON log (with the position1 and position2 values) for the following five test cases..

1. Bottom-rail fully up; Top-rail fully up
2. Bottom-rail 30% down from top; Top-rail fully up
3. Bottom-rail fully down; Top-rail fully up
4. Bottom-rail fully down; Top-rail 30% down from top
5. Bottom-rail fully down; Top-rail fully down

[berland]

Some observations:

• It could be my timeouts are related to RF between hub and shade, even though they are only 4 meters apart (and a plaster wall). They are not very consistent and it has happened on bottom shade as well. So not something the binding could fix, but perhaps when timedOut returns True, the binding could log it, or even try again some seconds later?

• timedOut is included in the JSON response when ?refresh=true is added to the API request.

• Moving top/secondary rail includes ?refresh=true in the API request, moving the bottom/primary does not. Is that intentional? It might explain some of the differences in response I see between the two (more time lag from command in OpenHAB until physical movement).

• TRACE logging might also include the JSON body of the request sent to the hub?

• The hub or the shade might ignore my request if I move it by increments of 1 (in the 0-100 scale), but not always.

• When moving the bottom (primary) rail, position2 is not included in the JSON response. When moving top rail (secondary), both position1 and position2 is included. When polling for state, both positions are reported.

[berland]

Here are some positions after commands, from JSON response from the hub:

| case | bottom | top | position1 | position2 |
| ---- | ------ | --- | --------- | --------- |
| 1, all up | 0 | 0 | 65160 | 0 |
| 2, top up, bottom 30% down | 30 | 0 | 45874 | 0 |
| 3, top up, bottom down | 100 | 0 | 0 | 0 |
| 4, top 30% down, bottom down | 100 | 30 | 215 | 19661 |
| 5, all down | 100 | 100 | 215 | 65535 |

Note that from 3 to 4, pos0 increases from 0 to 215 without movement. The number in the 0-65535 scale moves up and down within some accuracy at the hub's own will (I don't think this is a problem, and you have most likely seen it, the shade cannot move with 16 bit accuracy :) )

[andrewfg]

Here are some positions after commands, from JSON response from the hub:

Many thanks @berland this is very helpful. I can do a last check in my code to confirm the direction and scaling.

.. pos0 increases from 0 to 215 without movement ..
.. shade cannot move with 16 bit accuracy ..

Indeed. It is a PercentType channel so 655 is the minimum delta to have an observable impact.

[andrewfg]

It could be my timeouts are related to RF between hub and shade, even though they are only 4 meters apart (and a plaster wall). They are not very consistent and it has happened on bottom shade as well. So not something the binding could fix, but perhaps when timedOut returns True, the binding could log it, or even try again some seconds later?

That is a good suggestion about logging and retrying. I will see what I can do.

For info: in my case there were two possible places to locate my hub: a) 4 metres RF distance from the shades and plugged into an Ethernet socket, or b) 1 metre RF distance from the shades and connected to WiFi. Personally I find b) to be better.

timedOut is included in the JSON response when ?refresh=true is added to the API request.

Many thanks for the info.

Moving top/secondary rail includes ?refresh=true in the API request, moving the bottom/primary does not. Is that intentional?

My intention was to not include ?refresh=true in move commands, since the hub does an implicit refresh itself, in any case when such a command is sent. So I will check over my code once more.

TRACE logging might also include the JSON body of the request sent to the hub?

Yes, I will do that. There are two categories of request -- namely GET (without JSON request) and PUT (with JSON)

The hub or the shade might ignore my request if I move it by increments of 1 (in the 0-100 scale), but not always.

Hmm. The binding uses the formulae below, so maybe there are values of x where the sequence x=Read(); Move(x+1); x=Read(); could result in the same value of x due to the three integer rounding steps (??) _EDIT actually more than three integer rounding steps, because as we have seen, the motors are "rounding" by 215 between write and read steps.._

Move command:
    position1 = 65535 - (int) Math.round(channelPercent / 100d * 65535);
Read position:
    channelPercent = new PercentType(100 - (int) Math.round((double) position1 / 65535 * 100));

When moving the bottom (primary) rail, position2 is not included in the JSON response. When moving top rail (secondary), both position1 and position2 is included. When polling for state, both positions are reported.

Ah-Ha! Very useful information. Thank you.

[andrewfg]

Hi @berland I implemented all of your suggestions. _Except_ the one about retrying the refresh if it encounters a time out; reason for not doing that is because it is not clear a) how long to wait for the retry, and b) after how many retries to give up. I did however add a logger warning if a time out is encountered. I hope that the rest is to your satisfaction. The new build is here..

[mstroeve]

I had some time to test again with the latest jar file.
I deleted all things and added them again.

Refreshing after using a remote control seems to work with this build.
But I still have a issue/question regarding position of the top/secondary rail:

Having this dual rail PowerView item fort the top/secondary rail:
Rollershutter LF_KEUKEN_EETTAFEL_SHADE_SHUTTER_BOVENZIJDE "Luxaflex eettafel shutter bovenzijde" {channel="hdpowerview:shade:192_168_1_54:60902:secondary"}
When lowering it in two steps I see:
2020-06-30 20:09:54.123 [vent.ItemStateChangedEvent] - LF_KEUKEN_EETTAFEL_SHADE_SHUTTER_BOVENZIJDE changed from 100 to 96 2020-06-30 20:11:54.487 [vent.ItemStateChangedEvent] - LF_KEUKEN_EETTAFEL_SHADE_SHUTTER_BOVENZIJDE changed from 96 to 90

But when reading the readme I read as if 100 means: DOWN | OPEN | 100% ?

[andrewfg]

Hi @mstroeve many thanks for the testing. I fear that @berland and you have two different varieties of shades (??)

I made the latest build to support the coordinate system described by @berland for his shade in the table in his post here but I think your shades are using a different coordinate system ??

=> @mstroeve can you please turn on log tracing and try to make the same table as @berland did, but for your shade? And could you please post the part of the log file that contains the shades JSON status info?

I understood from @berland that on his shade, he cannot move the top rail, until the bottom rail has been fully lowered; but perhaps I misunderstood that => @berland is my understanding correct? => could you please also post a photo of your shade?

Whereas for @mstroeve ‘s shade it seems from the photo that the two rails can move independently?

[berland]

My shade looks exactly identical to @mstroeve , even in colour! I can move the top rail independently of the bottom, but if I try to move it past the bottom rail, it stops, naturally enough.

The mapping between 0 and 100 to OPEN and CLOSED is a design choice, and I support the current way it is implemented in the binding for the bottom and the top rail.

[andrewfg]

Thanks to you both for your feedback. I am trying to emulate the operation of all the varieties of shades described on the Hunter Douglas help page, with their pebble remote. But even with all their videos, it is hard to visualize what is going on without having the physical shades (and to make it more difficult, my own shades are of a banded roller type which is not mentioned on that page).

It is also complicated because on the pebble remote the Up Arrow at the top has the text label "Open" and the Down Arrow at the bottom has the text label "Closed" so even Hunter Douglas own operation can bring confusion between Up/Down and Open/Close on some types of shades :)

Note: that today I made a build which probably contains an error in that any movement of the upper rail would force the lower rail to go fully down. I will revert that change tomorrow, and make yet another build.

[andrewfg]

The latest build jar is here

I have been thinking more about the direction of operation of the top-down shade.. and I concluded that there is no perfect solution -- whichever direction of operation is chosen, it _cannot_ be any more confusing than the following table from the HD help instructions, where to paraphrase one example: _"Press ▼ (close) to fully raise the middle rail"_

[mstroeve]

I agree and I don't mind if 100 means the value for the top (secondary rail) to be at the top but the binding readme states otherwise. So shouldn't that be changed/reversed in the readme?
Dual action (upper rail) | secondary | UP | CLOSED | 0%
-- | -- | -- | -- | --
  |   | DOWN | OPEN | 100%

I really appreciate all the effort and I think there's nothing more to be tuned/added to the binding except the small readme issue maybe.

Time to get it in review?

[andrewfg]

Hi @mstroeve thanks for the feedback. I think the ReadMe does already say what you are suggesting. Or??

PS I think the binding currently has 0% being the top for both rails; or are you saying that this is not the case? We just need to make the ReadMe match the reality. Could you please send me a trace showing the polling result JSON when the shade is physically at the top? It should show “position2”: 0 and “position1”: 65535 ..

[andrewfg]

Perhaps a picture makes it clearer. What I intended is

• Press the two RED buttons => room is dark
• Press the two BLUE buttons => room is light

[mstroeve]

If you press the two blue buttons both rails will be in the middle with a duette shade. You want the both at the top to be fully open

[berland]

Latest jar looks good here. The STOP command works!

The only downside is that the hub or shade does not like getting too many commands it seems, so when testing, a lot of messages simply do not go through. Maybe RF communication HUB-shade, maybe not. It seems I can provoke this packet loss while playing with the official Android app as well (sometimes it seems that the hub queues up each request as well, and the shades go up/down/up/down many seconds after I stopped clicking around).

I did notice that when sending JSON for the lower rail, position2 is not included, but when sending top rail, position1 is always included (a note in my "python"-binding says that this is at least necessary for the top rail). My "python"-binding always sends position 2 while updating the lower rail, but I cannot claim it will make a difference.

[andrewfg]

@berland yes I agree that the hub is not fast, and not multi tasking; so it is..

Concerning position1 and position2, according to the Api specification, the former is mandatory, and the latter optional. So I only send the latter when it is really needed.

Concerning the direction of operation of the secondary shade, I have the feeling that you are observing something different than @mstroeve . Unfortunately I cannot resolve this. Can you please align with him?

[andrewfg]

If you press the two blue buttons both rails will be in the middle with a duette shade.

• @mstroeve and @berland can you please confirm that this is what actually happens for _both_ of you?
• And can you both please confirm that you are using the latest jar build?

You want the both at the top to be fully open

• Can you please infirm me what sequence of two buttons must be pressed (with the latest build) to achieve this?

[andrewfg]

Revised ReadMe

[andrewfg]

@berland and @mstroeve I think the latest build is stable and good to go, and the ReadMe matches the reality, so I would like to open a Pull Request for it. Is that OK with you?

[berland]

Perhaps a picture makes it clearer. What I intended is

• Press the two RED buttons => room is dark
• Press the two BLUE buttons => room is light

Pressing the two RED -> dark - this is correct.
Pressing the two BLUE does not make sense, because the secondary rail cannot be below the primary (bottom) rail.

There are two possibilities for "room is light", both rails at the bottom or both rails at the top, clicking UP on both, or DOWN on both yields this. So the binding works correct as far as I can see.

When both are to be sent down, the primary/bottom rail must get the DOWN command first if it is not already at the bottom.

When both are to be sent up, the secondary rail must get UP first, otherwise the bottom rail stops at the secondary rails current position.

[berland]

@berland and @mstroeve I think the latest build is stable and good to go, and the ReadMe matches the reality, so I would like to open a Pull Request for it. Is that OK with you?

Ok with me! I can't find any further issues. Thanks again for the good work!