Announcement

Collapse
No announcement yet.

Plug-In Startup best practices

Collapse
This is a sticky topic.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Plug-In Startup best practices

    There a few properties of the HSPI class that are queried when HS3 starts up. It appears that some plugins are actually doing some work in these properties.

    When HS3 starts it loads your plugin in a seperate AppDomain, loads the HSPI class, then queries the following properties:

    Name
    AccessLevel
    Capabilities
    comport
    supportsMultipleInstances
    supportsMultipleInstancesSingleEXE

    The plugin is then unloaded. These properties should simply return values and not do any work such as launching threads.

    Note that the New sub in the HSPI class will also be called and that sub should not contain any code. Do all initialization in InitIO.

    Launching threads from any of the properties above, or from New, could caused HS to exit and not start up. Build 3.0.0.330 and later has some added checks to not allow HS to exit.
    website | buy now | support | youtube

  • #2
    Good info - thanks...

    I have found through much trial and error that the InitIO should initialize quickly or you will get the warning "...not found in the list of active interfaces..." message in the Manage Plugins page. Basically you want to get in and out of InitIO as quickly as possible so that HS doesnt think the plugin is hung up or down.
    HS3Pro Running on a Raspberry Pi3
    64 Z-Wave Nodes, 168 Events, 280 Devices
    UPB modules via OMNI plugin/panel
    Plugins: Z-Wave, BLRF, OMNI, HSTouch, weatherXML, EasyTrigger
    HSTouch Clients: 3 Android, 1 Joggler

    Comment


    • #3
      You are correct, doing a lot lot of workin in InitIO will slow down startup and will error if it takes too long. Ideally, start a thread and return. You can log any errors later.

      Originally posted by rmasonjr View Post
      Good info - thanks...

      I have found through much trial and error that the InitIO should initialize quickly or you will get the warning "...not found in the list of active interfaces..." message in the Manage Plugins page. Basically you want to get in and out of InitIO as quickly as possible so that HS doesnt think the plugin is hung up or down.
      website | buy now | support | youtube

      Comment


      • #4
        Originally posted by rjh View Post
        There a few properties of the HSPI class that are queried when HS3 starts up. It appears that some plugins are actually doing some work in these properties.

        When HS3 starts it loads your plugin in a seperate AppDomain, loads the HSPI class, then queries the following properties:

        Name
        AccessLevel
        Capabilities
        comport
        supportsMultipleInstances
        supportsMultipleInstancesSingleEXE

        The plugin is then unloaded. These properties should simply return values and not do any work such as launching threads.

        Note that the New sub in the HSPI class will also be called and that sub should not contain any code. Do all initialization in InitIO.

        Launching threads from any of the properties above, or from New, could caused HS to exit and not start up. Build 3.0.0.330 and later has some added checks to not allow HS to exit.
        Rich, is it safe to invoke Callback functions in AccessLevel specifically CheckRegistrationStatus? I have coded some plugins that are free if one of my others are purchased, otherwise there is a cost. I use CheckRegistrationStatus to make the determination.

        Comment


        • #5
          AccessLevel is called when HS instantiates your HSPI class in a seperate app domain on startup. Calling back could cause some issues, and might not even work, so I would not do that.

          Make your call in InitIO and simply cripple your plugin, or exit, if licensing is not correct.

          Originally posted by bsobel View Post
          Rich, is it safe to invoke Callback functions in AccessLevel specifically CheckRegistrationStatus? I have coded some plugins that are free if one of my others are purchased, otherwise there is a cost. I use CheckRegistrationStatus to make the determination.
          website | buy now | support | youtube

          Comment


          • #6
            Originally posted by rjh View Post
            AccessLevel is called when HS instantiates your HSPI class in a seperate app domain on startup. Calling back could cause some issues, and might not even work, so I would not do that.

            Make your call in InitIO and simply cripple your plugin, or exit, if licensing is not correct.
            Better yet, as Rich mentioned "somewhere", launch a new thread in initIO that checks for licensing and then use that to set a flag in your program that can disable it and put up a message somewhere, like on the config web page that describes the issue. "must purchase one of these programs to get this one free"

            Just a thought.
            If it ain't broke, don't fix it!

            Comment


            • #7
              That would work if the only way to license the program is to buy another, but to have the option of this for X or free with Y I don't (yet) see away around the check in AccessLevel.... (but appreciate the comment!)

              Comment


              • #8
                Originally posted by rjh View Post
                You are correct, doing a lot lot of workin in InitIO will slow down startup and will error if it takes too long. Ideally, start a thread and return. You can log any errors later.
                Just documenting something Rich said in email. I had an issue where RegisterPage was returning properly, but my plugin was not being called to render the page. Rich stated that RegisterPage must be done on a thread that doesn't exit, so if you use a worker (thread pool) thread from InitIO RegisterPage may not work. I think either a long running thread, or doing the call from InitIO itself is safe.

                Comment

                Working...
                X