Announcement

Collapse
No announcement yet.

Hunter Douglas Powerview Integration/PlugIn

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #46
    Originally posted by prsmith777 View Post
    I have the Gen2 Hubs.
    I made Homseer virtual devices for all my shades grouping them by room. I have buttons for controlling individual shades, battery, refresh. I have room control for refreshing all shades in the room and checking battery level for all shades in the room. I also have room scenes on the page.
    You must have a huge house, never mind the investment in window treatments. 46 powered shades?! Is this HA system installed in the Palace of Versailles?

    Comment


      #47
      Originally posted by prsmith777 View Post

      Did you try using "" where there are " ?

      I had it working in BIG5 a while ago. I took a bit of fiddling to get it right. It is doable, but I didn't save the exact commands when I moved on to using a script. You might ask for help in Big6 sub forum.
      Thanks. Alas, "" in stead of " didn't work. I will try Big6 sub forum.

      Comment


        #48
        Originally posted by alexbk66 View Post
        I have two plugins for controlling blinds

        https://forums.homeseer.com/forum/hs...ig-screenshots

        https://forums.homeseer.com/forum/hs...-configuration

        I can create a plugin for hunter douglas / luxaflex if there's sufficient interest
        I would be interested too +1

        Comment


          #49
          I've been working on a HD Plugin and quickly ran into some questions about how to represent shades and scenes in the HS device list. If you have these blinds and the phone app, you know you can control by scene or individual shade, and the shades can be filtered by rooms.

          How would you represent all this as HS devices?

          1) Hub - The hub would surely be the root device. I already have it in the list with the HD logo, firmware version, MAC address on the device.

          2) Scenes - Scenes are all global items that include shades in one or more rooms. Should there be a device for each scene, or a SCENE device with all the scenes on a list and shades simply obey whatever the last scene selected is? The downside is this would just show the last one selected. Maybe it returns to a neutral value of "--SELECT SCENE--" after activation?

          If each scene is a separate device, I think it would be better for creating events but what is the device status before and after the "Activate" button is pushed at some arbitrary time later? It can't be on/off. If another scene is chosen that involves some of the same shades, then the previously selected scene isn't really on anymore because the shades common to both may have moved to a new position. Again, open to suggestions.

          Should I even do scenes or just run all the shades directly? Scenes could be ignored and users can just write events in HS to set the individual shades to the desired positions. Personally, I need it this way because I'm going to condition the closing of shades on whether the window they cover is open or closed.

          3) Shades - The shades seemed at first to be a no-brainer: Each shade is a device. But there are two different controls for some shades, and possibly more for shade types I don't have like top-down bottom-up shades. Mine are all open/close and vane rotation, so two devices per shade?
          If you're familiar with the API there is this indicator of posKind which indicates if a shade command is open/close (posKind 1) or vane rotation (posKind 3). They also seem to respond to API calls with negative numbers controlling vanes while positive numbers control open/close. I'm still figuring this out. My plan is to update shade devices to reflect the positions of individual shades.

          There is also two different battery level indicators: a 0-255 value and a hi/med/low. I will only use one, but this is a third device per shade? Is each shade now a root device?

          4) Rooms - I can read the room name from the API and populate the room field with it in HS. This would allow filtering by room at the device level and just show shades for that room along with lights and other devices, if desired. Doing this could potentially create new rooms the user does not want. For example, if your HS has a room called "Master Bedroom" but you've named that room "MBR" in the HD PowerView app, I would be creating another room. Of course this may be a minor inconvenience since once devices are created the first time, I would not alter a user-overwritten room value for an already recognized shade.

          5) Responsiveness - How fast should this API poll the Hub API to update device status? Probably can't be more often than once every 4-5 seconds because the Gen 2 Hub API can't respond faster than that on a local LAN call.

          6) Changes - what about when new shades, new scenes, or a new controller are added? The plug-in template I've been using for C# appears to create all devices once. If you add shades, it would not recognize them and create additional shades nor additional scenes. I can't imagine anyone being happy with a plugin that has to have all devices deleted and recreated just because you added a scene or new shade, so I have to work that out. As for new controller, my thought is I'm not going to get into replacement since I can't program the hub anyway and the shade and scene IDs may all change. If a new hub is put in, all devices will have to be deleted, remade, and wherever referenced in events and scripts, the old devices will have to be replaced with the new.

          Bottom line: I'm not stuck because of the programming and have the API fully reporting everything. I'm just stuck on how to represent it in HS.

          Comment


            #50
            [mention]dzee [/mention] Nice to read you started with a HD plugin.

            I think you should follow the structure of HD and represent it in terms of HS.

            So, a shade is a root-device in HS with separate devices for battery-status, up/down-postion (position) and vane (PosKind), etc.

            Scènes are more difficult, conform HD each scène should be a root-device in HS. But since they have no other sub-devices you can maybe bundle all scenes to one root-device 'Scenes'.

            Rooms are not the same in HD en HS, mixing them is indeed not a good idea. Room is a kind of status, I think. Maybe they can be a sub device of root-shades.

            Hope this will help you in your doubts about this.

            If I can help by testing or something else, please ask.

            Regards, Luuc.

            Comment


              #51
              How would you represent all this as HS devices?

              1) Hub - The hub would surely be the root device. I already have it in the list with the HD logo, firmware version, MAC address on the device.

              --Seems reasonable.

              2) Scenes - Scenes are all global items that include shades in one or more rooms. Should there be a device for each scene, or a SCENE device with all the scenes on a list and shades simply obey whatever the last scene selected is? The downside is this would just show the last one selected. Maybe it returns to a neutral value of "--SELECT SCENE--" after activation?

              --How I did it was to have one scene device for each room and have buttons for each scene. See my screen caps above. When a button is pushed my script will fire off the scene then update the shade positions accordingly

              If each scene is a separate device, I think it would be better for creating events but what is the device status before and after the "Activate" button is pushed at some arbitrary time later? It can't be on/off. If another scene is chosen that involves some of the same shades, then the previously selected scene isn't really on anymore because the shades common to both may have moved to a new position. Again, open to suggestions.

              --I'm not sure keeping track if a scene is on or off is going to work. Shades can be controlled individually and when they are, they scene is not really valid anymore. As long as you update the individual shade position when a scene is deployed that should be ok. That is how I do it. The problem comes with the hand held remote. The remote will change shade position but the hub is not updated as to the shade position so it gets out of sync. The way do deal with this is to do a shade refresh command.

              Should I even do scenes or just run all the shades directly? Scenes could be ignored and users can just write events in HS to set the individual shades to the desired positions. Personally, I need it this way because I'm going to condition the closing of shades on whether the window they cover is open or closed.

              --I use the scene control a lot in my house. I would definitely include them

              3) Shades - The shades seemed at first to be a no-brainer: Each shade is a device. But there are two different controls for some shades, and possibly more for shade types I don't have like top-down bottom-up shades. Mine are all open/close and vane rotation, so two devices per shade?
              If you're familiar with the API there is this indicator of posKind which indicates if a shade command is open/close (posKind 1) or vane rotation (posKind 3). They also seem to respond to API calls with negative numbers controlling vanes while positive numbers control open/close. I'm still figuring this out. My plan is to update shade devices to reflect the positions of individual shades.

              --Figuring out shade positioning for top down bottom up is complicated. I dont have the info off hand but I know I found it online somewhere. If you get stuck I can research it more for you

              There is also two different battery level indicators: a 0-255 value and a hi/med/low. I will only use one, but this is a third device per shade? Is each shade now a root device?

              -- The battery values are used to calculate the ok, low, critical. I didnt want to clutter up my devices with a battery device for each shade, so I ended up using the shade device icon to show battery status. I added an extra line underneath the icon that showed if battery level was low or critical. If battery was ok, then there was no extra line.

              4) Rooms - I can read the room name from the API and populate the room field with it in HS. This would allow filtering by room at the device level and just show shades for that room along with lights and other devices, if desired. Doing this could potentially create new rooms the user does not want. For example, if your HS has a room called "Master Bedroom" but you've named that room "MBR" in the HD PowerView app, I would be creating another room. Of course this may be a minor inconvenience since once devices are created the first time, I would not alter a user-overwritten room value for an already recognized shade.

              --not sure of a workaround for this issue.

              5) Responsiveness - How fast should this API poll the Hub API to update device status? Probably can't be more often than once every 4-5 seconds because the Gen 2 Hub API can't respond faster than that on a local LAN call.

              --reading through that thread I linked, there was a discussion about how often the hub can be polled. 4-5 seconds was way too often. If I remember right, it was in the minutes range. Honestly though, the only time to poll the hub for shade position is if you use a remote and the shades get out of sync, or if a scene is deployed but the shade doesnt respond and it gets out of sync. Minutes should be ok. I don't use polling at all in my script and there is rarely a time shade are out of sync.

              6) Changes - what about when new shades, new scenes, or a new controller are added? The plug-in template I've been using for C# appears to create all devices once. If you add shades, it would not recognize them and create additional shades nor additional scenes. I can't imagine anyone being happy with a plugin that has to have all devices deleted and recreated just because you added a scene or new shade, so I have to work that out. As for new controller, my thought is I'm not going to get into replacement since I can't program the hub anyway and the shade and scene IDs may all change. If a new hub is put in, all devices will have to be deleted, remade, and wherever referenced in events and scripts, the old devices will have to be replaced with the new.

              --You will definitely need to rework your script. Perhaps you should have a script for creating devices the first time, and a second script for updating devices as needed. People will be constantly changing things. For a new hub, I agree the user needs to start over.

              Bottom line: I'm not stuck because of the programming and have the API fully reporting everything. I'm just stuck on how to represent it in HS.

              Comment


                #52
                Click image for larger version

Name:	battery status.jpg
Views:	131
Size:	88.6 KB
ID:	1568170

                Here is a pic of how I do the battery status. This is on HS3 of course. I use a smaller font to squeeze it in.

                Notice I also have buttons for refresh, calibrate and battery for each shade. Also, I have a device that controls all shades in the room for refresh and battery updates.

                Comment


                  #53
                  Click image for larger version  Name:	refresh.jpg Views:	0 Size:	80.4 KB ID:	1568173

                  Here is a pic of after I hit refresh button. Sometimes the refresh command doesnt go through. I have the script try it twice and if it returns and error I mark it as "refresh timed out" , other wise I use "refresh ok". If the shade position was changed, then I add "shade repostitioned" or else if not then "shade unchanged"

                  Comment


                    #54
                    Thank you for input, luucelzinga.

                    Since the hub cannot really do anything by itself, I can see how making the shades individual root devices with their controls and battery level may be a better approach. I have been looking more carefully at the HD app and notice that if you want to interact with a shade, you must first select rooms. I will dismiss that HD convention because it makes no sense to have rooms as root devices in HS when rooms is an attribute of devices already.

                    I have a single-story house, so I've used the floor attribute to specify device categories like Insteon, Z-Wave, Shades, Security, etc. I would not assume others do that, so it will be up to the user to determine how to see all the shades together in the device view.

                    I was sitting in a dentist's chair this morning for a few hours, so I was thinking about scenes, more. Maybe those are child devices under the hub since they are not affiliated with particular rooms. Still trying to figure out how to make a device with an on that reverts to off so you can turn it on again later

                    Comment


                      #55
                      prsmith777, thanks for your feedback. Good thinking here.

                      [QUOTE=prsmith777;n1568167]

                      --I'm not sure keeping track if a scene is on or off is going to work. Shades can be controlled individually and when they are, they scene is not really valid anymore. As long as you update the individual shade position when a scene is deployed that should be ok. That is how I do it. The problem comes with the hand held remote. The remote will change shade position but the hub is not updated as to the shade position so it gets out of sync. The way do deal with this is to do a shade refresh command.

                      Dzee> Totally agree re: scenes going invalid.

                      Hadn't thought of the hand held remote issue yet. While not entirely a showstopper, I kind of get disenchanted when the home automation system isn't / can't really be up to date on status of things.


                      I knew the hand held remotes don't go through the hub, but now that you mention it, it explains why the app has to refresh the shade position before you can control the shade.Too bad that's not an automatic poll by the hub or an ack signal to the hub from the shade so it doesn't have to be part of the plugin. The API is only going to report what the hub knows, and asking the hub to poll the shades on a regular basis is just going to chew through batteries on the shades.

                      --Figuring out shade positioning for top down bottom up is complicated. I dont have the info off hand but I know I found it online somewhere. If you get stuck I can research it more for you

                      DZee> Agree. On my roller shades, I'm trying to figure out if it's just 16-bit signed int roll-over happening or it's really doing something different when I supply negative numbers. I've written a Windows thick app that just lets me play with the values directly and observe the shades, so more research required.

                      -- The battery values are used to calculate the ok, low, critical. I didnt want to clutter up my devices with a battery device for each shade, so I ended up using the shade device icon to show battery status. I added an extra line underneath the icon that showed if battery level was low or critical. If battery was ok, then there was no extra line.

                      DZee> That's a great idea since there are only a few values. My take was, who cares if the battery is at 255 vs 240 or even maybe 150? In the end, you want to use up the batteries yet get up there and swap batteries before you have to crawl behind a shade stuck in the lowered position because they're dead. Quite possibly the only statuses needed are OK and Replace Batteries. Since this is a monitor-only value it could be part of the parent device as you did, which could still be used to trigger an email or other signal to change batteries.

                      --reading through that thread I linked, there was a discussion about how often the hub can be polled. 4-5 seconds was way too often. If I remember right, it was in the minutes range. Honestly though, the only time to poll the hub for shade position is if you use a remote and the shades get out of sync, or if a scene is deployed but the shade doesnt respond and it gets out of sync. Minutes should be ok. I don't use polling at all in my script and there is rarely a time shade are out of sync.

                      DZee> The reason I was thinking in terms of a faster poll was to allow for triggers when shades go up/down relatively quickly after it happens. I have a Rachio Irrigation system and I hate that it's sometimes more than 5 minutes later before the HA system knows a zone started. If I left a car window open next to the lawn sprinklers, it won't exactly prevent it from getting wet if there is an announcement instantly, but I'll need fewer towels than if it tells me 5 minutes later.

                      For shades, the only scenario I'd probably want to know about right away is a shade closing in front of an open window, especially if it's windy. There are preventative steps for that (except when using handheld remotes, and then it's human stupidity which is an intractable issue HA will never solve).

                      Comment


                        #56
                        Originally posted by prsmith777 View Post
                        Click image for larger version  Name:	battery status.jpg Views:	0 Size:	88.6 KB ID:	1568170

                        Here is a pic of how I do the battery status. This is on HS3 of course. I use a smaller font to squeeze it in.

                        Notice I also have buttons for refresh, calibrate and battery for each shade. Also, I have a device that controls all shades in the room for refresh and battery updates.
                        DZee> Hadn't thought about putting calibrate in the plugin. I think that will be a nice to have, but easily done in the HD app. What does Update Batteries do? Does the hub have to do a demand pull of that data from the shades? If so, it seems that maybe that should be done on a schedule like heartbeat maybe once a day or every 48 hours or so.

                        I'm running HS3 as well. Not sure how that presents itself on HS4 but have the upgrade and want the plugin to work with either. I upgraded to HS4 a few weekends ago but immediately reverted to HS3 after running into issues with CADDX alarm plugin on HS4 that weren't an issue on HS3.

                        The idea of having a plug in for HD shades is rapidly becoming less interesting.

                        We can already run scenes and shades with scripts or curl commands, but the whole reason I wanted to do the plugin was to get more real-time info back about shade positions and send me battery low warnings.

                        If all that has to be polled and the device list is constantly behind the times, I'm beginning to understand why a plugin doesn't already exist. Your interface looks like it does everything possible already.

                        Comment


                          #57
                          I have my HD hubs and repeaters on an IOT network so its kind of a pain to switch networks on my phone to access the HD app. (Creating a firewall rule to allow my Iphone to the HD hubs doesnt seem to work for me.) I use HomeSeer instead for all my shade needs including calibrate.

                          I believe HD updates battery level about once per week. I added the battery button in case I wanted to update a shade sooner. You are right it has to query the shade which would draw down on the battery.

                          I think I am going to add a routine in my script to poll the Hub every 5 minutes to update shade position. I don't have it now and shades definitely get out of sync with the hand remote.

                          Only reason I did a script is because I have no clue how to do a plugin. I am self taught programmer and this script is my most complicated one so far.

                          Comment


                            #58
                            Following

                            Comment


                              #59
                              Originally posted by dzee View Post

                              DZee> Hadn't thought about putting calibrate in the plugin. I think that will be a nice to have, but easily done in the HD app. What does Update Batteries do? Does the hub have to do a demand pull of that data from the shades? If so, it seems that maybe that should be done on a schedule like heartbeat maybe once a day or every 48 hours or so.

                              I'm running HS3 as well. Not sure how that presents itself on HS4 but have the upgrade and want the plugin to work with either. I upgraded to HS4 a few weekends ago but immediately reverted to HS3 after running into issues with CADDX alarm plugin on HS4 that weren't an issue on HS3.

                              The idea of having a plug in for HD shades is rapidly becoming less interesting.

                              We can already run scenes and shades with scripts or curl commands, but the whole reason I wanted to do the plugin was to get more real-time info back about shade positions and send me battery low warnings.

                              If all that has to be polled and the device list is constantly behind the times, I'm beginning to understand why a plugin doesn't already exist. Your interface looks like it does everything possible already.
                              Yes, thats true, but scripting en curl commando’s aren’t easy for much users. For me both are time consuming and error prone.

                              I hope you still want to develop a PI for HD.

                              regards, Luuc.

                              Comment

                              Working...
                              X