Announcement

Collapse
No announcement yet.

How open is HST to ideas to improve the SDK?

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

    How open is HST to ideas to improve the SDK?

    Looking at the sample plugin and the SDK I am still seeing plenty of areas that are going to lead to some really messy plugin code.

    How Open is HST on improving their "SDK" so that we can improve our plugin's code without having to depend on, in my case, an external DLL to do most of the heavy lifting?


    For instance, the idea that I can't just register a "web page class" and have the SDK auto delegate to those classes for methods like PostBackProc is insane to me. I'm not trying to be mean, but no one should be putting a switch/case to handle all their pages.

    I have a library that does a bunch of auto-wiring for my plugins (devices, web pages, actions/triggers, etc). I was hoping I could move away from this, but it appears I'm not.

    I was going to release my library anyways, so I need to know how interested is HST in absorbing some of these changes directly into the SDK?

    #2
    I would hope very, but if not perhaps you can coordinate with Alex who's also been working on a foundational lib, maybe join forces?

    Comment


      #3
      AS I'm looking deeper into the SDK code, it's very similar to how I handled a lot on my side. Actions seem to be similar (which is nice), and triggers seems similar. The only thing I've noticed at first glance (and maybe I'm wrong) is that the sub triggers seem to be all contained in the main trigger. I handled this different and maybe there are pros/cons to both.

      In my HS3 code I treat triggers and subtriggers the same. the only difference is that a trigger might contain multiple sub triggers in it (both inherit the same base class). I think this is a bit cleaner an it means I no longer have to use case statements in my code, which I dislike. It allows my sub triggers to each be their own independent class. I would strongly suggest HST consider this approach. Just make AbstrictTriggerType contain a SubTriggerTypeCollection in it for subtriggers. this could be a collection of "AbstractSubTriggerType". If I were to do it, I would make AbstructSubTriggerType my base and have AbstractTriggerType extend it with the methods/properties to support subtriggers. (<!---- n

      This offers many benefits...when looking if a trigger has sub triggers you can just look for a count (which I think it is doing anyways on the list). Only difference is instead of a list of names, you get the objects you can then access.

      Thoughts?

      While I'm here, the SDK is in GitHub. What is the expectation here? Is HST saying they are open to forks and allowing people to do Pull requests back into the main branch for inclusion?

      Comment


        #4
        Yeah, I have similar lib (opensource) - mapping config pages and mapping class variables to controls - so no additional handling is required in PostBack functions
        https://forums.homeseer.com/forum/de...plugin-library

        Comment


          #5
          You guys have written far more plugins than we have so of course we value your feedback. The goal of the new SDK is to make it easier to create plugins. If we miss that mark in some areas let us know how it can be improved. But note that I want to make changes that multiple developers can agree upon and use, not just a change that one developer thinks is good. I will get with JL and see the best way to submit changes and approve them.
          💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

          Comment


            #6
            Originally posted by rjh View Post
            But note that I want to make changes that multiple developers can agree upon and use, not just a change that one developer thinks is good.
            Hi Rich, my library was based on every publicly available code I could find in Google, I did a bit of clean-up and many additions.

            I think especially valuable is mapping class variables to controls in config pages (for both Config pages and Trigger/Action UI)

            Originally posted by alexbk66 View Post
            Class VariableMap - mapping controls to variable names for ProcessPostUI - for config pages and Triggers/Actions. This mapping links UI controls to corresponding variables to automatically update the variable when control value changes. This mostly eliminates the need for ProcessPostUI functions. See post #35, #36 and #60, #61
            Originally posted by alexbk66 View Post
            More on VariableMap class. It makes consistent creating UI for both Config pages and Trigger/Action UI
            https://forums.homeseer.com/forum/de...-library/page3


            Comment


              #7
              If you want to contribute to the SDK, just create a fork, add your changes, test and submit it. We will solicit feedback from developers on any changes to make sure they are acceptable. The SDK is here:

              https://github.com/HomeSeer/Plugin-SDK
              💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

              Comment


                #8
                Originally posted by rjh View Post
                If you want to contribute to the SDK, just create a fork, add your changes, test and submit it. We will solicit feedback from developers on any changes to make sure they are acceptable
                Sure. Main problem is - converting existing plugins to HS4. And especially - supporting both HS3 and HS4.
                I know, you point is - lets all move to HS4 - which is good in theory, I always prefer the latest and greatest.
                But:
                1. You charge for the upgrade and not everybody is happy to suddenly pay again (for both HS and plugins)
                2. Not everybody have time to go through the upgrade pain because I'm sure it won't be seamless process.

                So really I feel very discouraged now to do anything...

                Comment


                  #9
                  Originally posted by alexbk66 View Post

                  Sure. Main problem is - converting existing plugins to HS4. And especially - supporting both HS3 and HS4.
                  I know, you point is - lets all move to HS4 - which is good in theory, I always prefer the latest and greatest.
                  But:
                  1. You charge for the upgrade and not everybody is happy to suddenly pay again (for both HS and plugins)
                  2. Not everybody have time to go through the upgrade pain because I'm sure it won't be seamless process.

                  So really I feel very discouraged now to do anything...
                  Not to be negative, but I don't think you're alone.

                  I honestly think the best approach would be for us to find a way to have a plugin flagged as HS3, HS3+ or just HS4. In the HS3+ version have methods for building the UIs for 3 and 4. Yes, we would have to maintain multiple sets of code for the UI, but not multiple copies of a plugin.

                  HS3 plugins would still work in HS4 without the new UI.

                  HS3+ would work in HS3 with old UI, and work in HS4 with new UI

                  HS4 plugins woud only work in HS4

                  At least then the only code I'm really duplicating is the UI logic and when I decide to move to only HS4 (if I ever do), I can just remove that portion of my plugin code.

                  This would be a true upgrade path that benefits not only existing HS3 users, but those that upgrade to HS4 and new HS4 customers.

                  Comment


                    #10
                    Originally posted by sirmeili View Post

                    Not to be negative, but I don't think you're alone.

                    I honestly think the best approach would be for us to find a way to have a plugin flagged as HS3, HS3+ or just HS4. In the HS3+ version have methods for building the UIs for 3 and 4. Yes, we would have to maintain multiple sets of code for the UI, but not multiple copies of a plugin.

                    HS3 plugins would still work in HS4 without the new UI.

                    HS3+ would work in HS3 with old UI, and work in HS4 with new UI

                    HS4 plugins woud only work in HS4

                    At least then the only code I'm really duplicating is the UI logic and when I decide to move to only HS4 (if I ever do), I can just remove that portion of my plugin code.

                    This would be a true upgrade path that benefits not only existing HS3 users, but those that upgrade to HS4 and new HS4 customers.
                    I like this idea, a lot...

                    Comment


                      #11
                      Originally posted by bsobel View Post

                      I like this idea, a lot...
                      By the sounds of how "devices" and grouping now work, I don't think this is possible anymore. There are too many changes to really have a hybrid plugin. For most of us, it looks like a complete rewrite of the actual code that talks to HS. Hopefully most knew enough to encapsulate their business logic so changes like this don't affect the business logic and only the actual code that talks to HS.

                      Comment

                      Working...
                      X