search

openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.86k stars 3.58k forks source link

[hdpowerview] Support for Duette shades #4351

Closed berland closed 4 years ago

berland commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

andrewfg commented 4 years ago

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 commented 4 years ago

Yes, I can test.

mstroeve commented 4 years ago

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 commented 4 years ago

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?

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

PS the jar is here

berland commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

The new jar is here -- enjoy!

berland commented 4 years ago

Great progress from the latest jar!

mstroeve commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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?

20200624_123356 (002)

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!

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 commented 4 years ago

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 !!

image

andrewfg commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

image

andrewfg commented 4 years ago

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

Done here

andrewfg commented 4 years ago

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

andrewfg commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

13:56:47.610 [TRACE] [erview.internal.HDPowerViewWebTargets] - API request = http://192.168.1.67/api/shades/
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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Some observations:

berland commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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% ? IMG_7214

20200630_181156960_iOS

andrewfg commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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"

image

mstroeve commented 4 years ago
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 commented 4 years ago

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 commented 4 years ago

Perhaps a picture makes it clearer. What I intended is

image

mstroeve commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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?