Announcement

Collapse
No announcement yet.

Migrate HS3 documentation

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

    #16
    Originally posted by rjh View Post
    If the functionality of the device is not changing, you really don't need to migrate it. Is there a reason you want to do this?


    Confused .....

    I thought devices couldn’t have controls and we had to create features, no?

    Comment


      #17
      Originally posted by dcorsus View Post

      Confused .....

      I thought devices couldn’t have controls and we had to create features, no?
      The way I understand it is that in HS3 we had root devices with children. In HS4 the device root is now the parent or container for all the child devices which are now called features. That is exactly how HS3 devices import to HS4. A standalone device like a virtual or older Z-Wave switch is just represented as a device with a control, no "features".

      Here is one of your Sonos players imported from HS3

      Click image for larger version

Name:	capture.png
Views:	86
Size:	40.2 KB
ID:	1362959

      Note that none of the Features are shown. This something Rich is going to need to help figure out, because all the features are there

      Click image for larger version

Name:	capture1.png
Views:	70
Size:	290.3 KB
ID:	1362960

      A single device with no child devices just shows its control and has no Features

      Click image for larger version

Name:	capture2.png
Views:	69
Size:	10.4 KB
ID:	1362961



      Comment


        #18
        Rich,

        its not clear how hs4 devices and features map back to existing hs3 devices. I read somewhere that we can't have 'controls' on a device; now that they must be on features.

        i am taking the approach of rewriting my vista alarm plugin in native hs4 code; I don't know what a new hs4 device is going to look like; hence my concern about hs3 to hs4 device migration. will an hs3 migrated device behave/look the same as an hs4 created device.

        i don't need an answer to any of this here.

        Basically, we need more sample code and write ups in the *SDK* (https://docs.homeseer.com/display/HSPI/Overview). You have been working with your new hs4 architecture and object model for months if not years; the rest of us (who are not full time programmers) need good quality documentation to get up to speed); spending our time on trial and error, wading through this forum, and waiting for answers is painful, frustrating, and time consuming. I hope you will make this a priority.

        the entire devicefactory, and all its related objects needs a lot of documentation

        for example, why were multiple instances dropped; do you have a recommendation or alternative solution? this would be valuable info in the SDK. just saying its depreciated doesn't help. a lot of us spent a lot of time in hs3 on this feature.


        Mark

        HS3 Pro 3.0.0.534
        Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway
        Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 (by Kirby) | Ultra1Wire3 | RFXCOM | NetCAM | MyQ | BLRadar | BLDenon | Jon00 Charting
        Platform: HP h8-1360t, Windows Server 2012 R2, i7-3.4GHz, 16GB memory

        Comment


          #19
          Originally posted by rjh View Post
          If the functionality of the device is not changing, you really don't need to migrate it. Is there a reason you want to do this?


          Why mark the plugin than as a legacy plugin?

          Verstuurd vanaf mijn SM-G965F met Tapatalk

          Comment


            #20
            I was referring to migrating HS3 devices to your HS4 plugin. These are devices that the user already has created.

            Originally posted by kriz83 View Post
            Why mark the plugin than as a legacy plugin?

            Verstuurd vanaf mijn SM-G965F met Tapatalk
            website | buy now | support | youtube

            Comment


              #21
              HS4 allows HS3 devices to work as they did before, so no issue there. But in HS4 the root device cannot have controls on it. So add features (child) devices to your root and put your controls on those devices. If you don't have any controls on your root devices then your child devices can look the same in HS4 as they did in HS3. If you have a specific question on how to create your devices I can get an answer for you and post some sample code. The sample plugin has code that creates devices with features. Remember that a "device" is a root device and a "feature" is just a child device.

              Originally posted by mnsandler View Post
              Rich,

              its not clear how hs4 devices and features map back to existing hs3 devices. I read somewhere that we can't have 'controls' on a device; now that they must be on features.

              i am taking the approach of rewriting my vista alarm plugin in native hs4 code; I don't know what a new hs4 device is going to look like; hence my concern about hs3 to hs4 device migration. will an hs3 migrated device behave/look the same as an hs4 created device.

              i don't need an answer to any of this here.

              Basically, we need more sample code and write ups in the *SDK* (https://docs.homeseer.com/display/HSPI/Overview). You have been working with your new hs4 architecture and object model for months if not years; the rest of us (who are not full time programmers) need good quality documentation to get up to speed); spending our time on trial and error, wading through this forum, and waiting for answers is painful, frustrating, and time consuming. I hope you will make this a priority.

              the entire devicefactory, and all its related objects needs a lot of documentation

              for example, why were multiple instances dropped; do you have a recommendation or alternative solution? this would be valuable info in the SDK. just saying its depreciated doesn't help. a lot of us spent a lot of time in hs3 on this feature.

              website | buy now | support | youtube

              Comment


                #22
                IIn regards to multi-instance plugins, there really isn't a need for it as you can implement this easily in your plugin. Just put all your logic in one class and then initialize that for each instance you need. We felt it was far less confusing to the user to do it this way.

                There is one issue we are aware of. Some plugins need to run remotely on different computers. So in this case we do need a way to support the same plugin running multiple times. We are working on supporting that.

                Originally posted by mnsandler View Post
                Rich,

                its not clear how hs4 devices and features map back to existing hs3 devices. I read somewhere that we can't have 'controls' on a device; now that they must be on features.

                i am taking the approach of rewriting my vista alarm plugin in native hs4 code; I don't know what a new hs4 device is going to look like; hence my concern about hs3 to hs4 device migration. will an hs3 migrated device behave/look the same as an hs4 created device.

                i don't need an answer to any of this here.

                Basically, we need more sample code and write ups in the *SDK* (https://docs.homeseer.com/display/HSPI/Overview). You have been working with your new hs4 architecture and object model for months if not years; the rest of us (who are not full time programmers) need good quality documentation to get up to speed); spending our time on trial and error, wading through this forum, and waiting for answers is painful, frustrating, and time consuming. I hope you will make this a priority.

                the entire devicefactory, and all its related objects needs a lot of documentation

                for example, why were multiple instances dropped; do you have a recommendation or alternative solution? this would be valuable info in the SDK. just saying its depreciated doesn't help. a lot of us spent a lot of time in hs3 on this feature.

                website | buy now | support | youtube

                Comment


                  #23
                  Originally posted by rjh View Post
                  HS4 allows HS3 devices to work as they did before, so no issue there. But in HS4 the root device cannot have controls on it. So add features (child) devices to your root and put your controls on those devices. If you don't have any controls on your root devices then your child devices can look the same in HS4 as they did in HS3. If you have a specific question on how to create your devices I can get an answer for you and post some sample code. The sample plugin has code that creates devices with features. Remember that a "device" is a root device and a "feature" is just a child device.


                  Rich,
                  in my HS3 insteon plugin, i used parent/child relationships (both parents & child devices could have both controls, and status), and i kept track of the number of hs devices. for example, a KPL is 8 devices (1 parent, 7 child)

                  Now in HS4, if i create a KPL device, the device architecture is different. For example, a new KPL is 1 root, and 8 features (i guess) for a total of 9 devices.

                  so there is no consistency between hs devices (ie what they represent), and how i would manage them in my code

                  when the plugin receives a message from a device, it knows which button sent the message (1..8)

                  it would seem i would need code to manage hs3 legacy device differently than hs4 native devices.
                  Mark

                  HS3 Pro 3.0.0.534
                  Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway
                  Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 (by Kirby) | Ultra1Wire3 | RFXCOM | NetCAM | MyQ | BLRadar | BLDenon | Jon00 Charting
                  Platform: HP h8-1360t, Windows Server 2012 R2, i7-3.4GHz, 16GB memory

                  Comment


                    #24
                    Originally posted by mnsandler View Post

                    Rich,
                    in my HS3 insteon plugin, i used parent/child relationships (both parents & child devices could have both controls, and status), and i kept track of the number of hs devices. for example, a KPL is 8 devices (1 parent, 7 child)

                    Now in HS4, if i create a KPL device, the device architecture is different. For example, a new KPL is 1 root, and 8 features (i guess) for a total of 9 devices.

                    so there is no consistency between hs devices (ie what they represent), and how i would manage them in my code

                    when the plugin receives a message from a device, it knows which button sent the message (1..8)

                    it would seem i would need code to manage hs3 legacy device differently than hs4 native devices.
                    This is an excellent example Mark, I ended up pretty much in the same way. I have written my HS4 version, so I made all that work, the key problem for me is how to support people who came from HS3, who spent a lot of effort setting up HStouch screens, events, automation, scripts etc. and elect to use my HS4 plugin so they can make proper use of all the new functions enabled in HS4 (example there is a player optimized tile view).

                    In HS3 one Sonos player was a root device with controls and about 19 children, so 20 devices in total. In HS4, that code turned into one root device and 20 feature devices. I know I could write some conversion tool BUT the major issues is that I end up with different HS references after conversion which subsequently will break events. So I'm also eager to get guidance how we could address this, also curious how the HS3 to HS4 DB conversion tool works. Maybe it doesn't do any of this assuming all devices that were created in HS3 will remain exactly the same.

                    Last but not least, even though features are just like devices, I seem to recall that there are attributes associated which define them as devices over features and you cannot use say an HS function like getdevicebyreference on a feature and visa-versa. So Rich your statement that they are all "devices" even though called features, not sure that is 100% correct.

                    Thanks for giving guidance,

                    Dirk


                    Comment


                      #25
                      Originally posted by rjh View Post
                      But in HS4 the root device cannot have controls on it.
                      Just wondering why? What's the reason? I always tried to minimise number of HS devices by putting controls into root.

                      For me it's just redicoulus to have an extra device which just sits there saying "No status"

                      And the main reason I try to minimise number of HS devices - is because HS doesn't provide a user friendly way of selecting a device in events / HSTouch designer, etc.

                      So the users have to scroll the list of 1000 devices

                      If you force developers to multiply the number of devices - please also implement descent device selection!

                      Comment


                        #26
                        Originally posted by alexbk66 View Post

                        Just wondering why? What's the reason? I always tried to minimise number of HS devices by putting controls into root.

                        For me it's just redicoulus to have an extra device which just sits there saying "No status"

                        And the main reason I try to minimise number of HS devices - is because HS doesn't provide a user friendly way of selecting a device in events / HSTouch designer, etc.

                        So the users have to scroll the list of 1000 devices

                        If you force developers to multiply the number of devices - please also implement descent device selection!
                        I do know the bogus root device has something to do with the UI, this all started with the homeseer app in HS3. HST didn't want to support controls/status on the root device but too many of us already had that in place. so HST supported it in the app.

                        I guess in HS4 they are putting their foot down. still doesn't make sense; it must just be for ease/consistency.

                        but i'm with you; its worthless.
                        Mark

                        HS3 Pro 3.0.0.534
                        Hardware: Insteon Serial PLM | AD2USB for Vista Alarm | HAI Omnistat2 | 1-Wire HA7E | RFXrec433 | Dahua Cameras | LiftMaster Internet Gateway
                        Plugins: Insteon (mine) | Vista Alarm (mine) | Omnistat 3 (by Kirby) | Ultra1Wire3 | RFXCOM | NetCAM | MyQ | BLRadar | BLDenon | Jon00 Charting
                        Platform: HP h8-1360t, Windows Server 2012 R2, i7-3.4GHz, 16GB memory

                        Comment


                          #27
                          Originally posted by mnsandler View Post

                          I do know the bogus root device has something to do with the UI, this all started with the homeseer app in HS3. HST didn't want to support controls/status on the root device but too many of us already had that in place. so HST supported it in the app.

                          I guess in HS4 they are putting their foot down. still doesn't make sense; it must just be for ease/consistency.

                          but i'm with you; its worthless.
                          I don't mind if, but if HST could handle large number of devices, i.e. have efficient and fast enumeration (BSobel reported up to 60 seconds!) and user friendly device selection, instead of scrolling the list of 1000 devices - like I do in my AKSmartDevice - you can select Room or Group or Both or None - completely user friendly:

                          Click image for larger version  Name:	2020-02-18.png Views:	0 Size:	17.2 KB ID:	1363682

                          Click image for larger version

Name:	2020-02-18 (1).png
Views:	50
Size:	338.0 KB
ID:	1363683

                          Comment

                          Working...
                          X