Announcement

Collapse
No announcement yet.

Future HS4 Development "Fixes"

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

  • Future HS4 Development "Fixes"

    spud
    I'm not sure if there is a better place to raise this, but I assume you are working on coding for a HS4 version of Easy Trigger and wanted to raise a few issues with the current version that I'm hoping you might be able to address in the HS4 version.

    The purpose here is not to call for new features, but rather to address a few issues I've run into with current operation where there are a number of non-obvious "errata" that seem like they would be hard for new users to identify / diagnose.

    They relate to the following subjects (which are detailed below):

    1. Startup Initialization Delays
    2. Handling of Global Variables (etDeviceName, etDeviceStatus, etDeviceLocation1, etDeviceLocation2, etDeviceRef, etDeviceValue)
    3. Better recognition of Devices in Easy Trigger Groups when using the Events page "Referencing Device(s)" Events Drop-Down.


    I'm assuming that a number of the issues may exist due to limitations in the HS3 plugin API, but as HS4 is still unreleased, maybe there's an opportunity to influence it and the plugin API to improve the operations.

    Here are my thoughts:

    1. Startup Initialization Delays.

    In HS3, I have the startup script set to automatically runs an event on startup. That startup event includes actions that make use of Easy Trigger dynamic groups. I've found that the Easy Trigger groups will occasionally result in a Warning that the group is missing. I believe this is due to the fact that Easy Trigger is still initializing. While this can be handled by inserting a large delay at the start of the startup event, it would be better if the end-user didn't have to experiment and figure out the root cause in order to address this.

    With this in mind, it seems useful to have HomeSeer wait until plugins finish initializing before running events.

    I was thinking of something along the following lines might be a way to address the issue of events running before plugins are ready:

    (i). Adding Plugin SDK calls where the plugin (a) informs HS that it should wait until the plugin finishes initialization before HS runs events, and also specifies a maximum wait time - say 3 minutes; (b) and another call where the plugin can report that it has completed initialization.

    (ii). HS should delay running events until all plugins that have requested that HS wait for initialization have reported initialization is complete. HS should have a "safety" timeout just in case a plugin fails to report completion - i.e., it should have a maximum initialization wait time of, e.g., 5 minutes, after which HS4 will no longer wait but will, instead, log an excessive initialization time error.

    2. Handling of Global Variables
    Currently, as I understand the way that Easy Trigger global variables work, if you have an Event that triggers based on an Easy Trigger trigger, and that event takes a while to execute (for example, it has "wait" actions or slow actions), it is possible for the etGlobal variables to be overwritten by another triggering event before your first event is done processing them. What I suggest is that when an Easy Trigger event triggers, the event makes a local copy of the variables which live for the scope of the event and which are used for subsequent processing of statements within the event. That way, multiple events could trigger at about the same time and the global variables won't be overwritten. I assume there may be other / better /easier to program ways to address this concern - e.g., maybe HS4 has some better local scoping mechanism or something could be added at this stage; so if there is another solution on the way, that would be just as welcome.

    3. Groups and the Events "Referencing Device" drop down.
    Currently, if you select a particular device in the "Referencing Devices" drop-down on the Events page, you will only see the associated event if the device is explicitly identified in an trigger / condition / action, but you won't see the event if the device is part of an Easy Trigger group. This can make it hard to trace which events are influencing which devices. The "preferred" solution for this would be if HS4 had its own "group" defining mechanism so that all plugins could see / access / share groups. However, if that isn't happening, consider if there is a way of "influencing" the plugin SDK development such that, when devices in the "Referencing Devices" drop down are selected, there is a way of identifying the relevant Events that may have the device as part of an Easy Trigger Group so that the proper list of Events could be displayed in the Events list.

  • #2
    As I've increased the number of ET groups in my setup, I've found the problem you describe in #3 to be particularly inconvenient. I think all 3 are very good points.
    -Wade

    Comment


    • #3
      jvm great points

      spud #2 please ... this problem makes it impossible for me to use ET's Global variables

      Comment


      • #4
        thanks for the ideas

        #3 is easy, I fixed it in version 3.0.0.71 available in the beta section of the updater

        I will think about the 2 other points.

        Comment


        • #5
          Originally posted by spud View Post
          thanks for the ideas

          #3 is easy, I fixed it in version 3.0.0.71 available in the beta section of the updater

          I will think about the 2 other points.
          Glad to hear that one of them was easy! I realize the others may not be - hopefully, at the least, if adjustment to HS4 API's is needed to achieve this, you may be able to get them thinking along these lines and a fix could be done in the longer-term. After you've had some time to think about this, it would be great to get your feedback, even if just to know to know "too hard for now" or whether some of these are likely to get implemented.

          Comment


          • #6
            #1 was easy fro me to fix. I run a 1 minute delayed cleanup event to give HomeSeer time to settle down.

            hs.DelayTrigger (60, "StartupCleanupDelayed")

            That being said, it does make sense for HomeSeer to hold most Event processing until all plug-ins have been initialized. The exception would be something you want to do like write a log entry or set a timer or counter as soon as the startup script runs.

            Maybe there could be a special scripting call for an Event in startup.ini or even better a trigger "HomeSeer Started" that would be true once all plug-ins have initialized.
            Randy Prade
            Aurora, CO
            Prades.net

            PHLocation - Pushover - EasyTrigger - UltraECM3 - Ultra1Wire3 - Arduino

            Comment


            • #7
              Originally posted by rprade View Post
              #1 was easy fro me to fix. I run a 1 minute delayed cleanup event to give HomeSeer time to settle down.

              hs.DelayTrigger (60, "StartupCleanupDelayed")

              That being said, it does make sense for HomeSeer to hold most Event processing until all plug-ins have been initialized. The exception would be something you want to do like write a log entry or set a timer or counter as soon as the startup script runs.

              Maybe there could be a special scripting call for an Event in startup.ini or even better a trigger "HomeSeer Started" that would be true once all plug-ins have initialized.
              I make sure that important plugins start first by manually editing the sequence in settings.ini. I wish there was a way to specify startup order so I wouldn’t have to keep doing that. However, I would not want to hold up event processing while waiting for all plugins. I have some multi-instance ones that take quite a while to start but are non-critical . Maybe a checkbox for each plugin to indicate whether event processing should be waiting for it or not.
              HS 3.0.0.548: 1976 Devices 1156 Events
              Z-Wave 3.0.1.262: 123 Nodes on one Z-Net

              Comment


              • #8
                I like the idea of being able to specify a persistent startup order for plug-ins. I don’t have any Events where it is critical they run as soon as possible after restarting, so a fixed delay is just fine in my case.
                Randy Prade
                Aurora, CO
                Prades.net

                PHLocation - Pushover - EasyTrigger - UltraECM3 - Ultra1Wire3 - Arduino

                Comment


                • #9
                  Originally posted by rprade View Post
                  I like the idea of being able to specify a persistent startup order for plug-ins. I don’t have any Events where it is critical they run as soon as possible after restarting, so a fixed delay is just fine in my case.
                  +1

                  I load 79 plugins on startup. I have a specific order for them to load in. I end up copying the "config.ini" line over each time I restart HS to get them to load in the correct order. Having a static load order would be super helpful.
                  My home is smarter than your honor roll student.

                  Comment


                  • #10
                    Originally posted by rprade View Post
                    #1 was easy fro me to fix. I run a 1 minute delayed cleanup event to give HomeSeer time to settle down.

                    hs.DelayTrigger (60, "StartupCleanupDelayed")

                    That being said, it does make sense for HomeSeer to hold most Event processing until all plug-ins have been initialized. The exception would be something you want to do like write a log entry or set a timer or counter as soon as the startup script runs.

                    Maybe there could be a special scripting call for an Event in startup.ini or even better a trigger "HomeSeer Started" that would be true once all plug-ins have initialized.

                    The real key to what I'm after is to move in a direction where, whenever reasonably possible, the end user has does not have to search the forums or otherwise figure out why something hasn't functioned as expected and then figure out and evaluate solutions. This particular example of startup delay seems like pretty low-hanging fruit where a plugin should have a way to tell HS to "wait until I'm ready" and "I'm ready." In any case, spud got a quick start on this and he already was able to release the .71 beta which solved one of the problems I indicated, so I'm glad for that.

                    Comment


                    • #11
                      Originally posted by jvm View Post


                      The real key to what I'm after is to move in a direction where, whenever reasonably possible, the end user has does not have to search the forums or otherwise figure out why something hasn't functioned as expected and then figure out and evaluate solutions. This particular example of startup delay seems like pretty low-hanging fruit where a plugin should have a way to tell HS to "wait until I'm ready" and "I'm ready." In any case, spud got a quick start on this and he already was able to release the .71 beta which solved one of the problems I indicated, so I'm glad for that.
                      There is one setting in the HS Setup section under the Labs tab that may be relevant called “Load plug-ins in the background on startup”. Do you have it checked? If so, does un-checking it eliminate or improve this issue?
                      HS 3.0.0.548: 1976 Devices 1156 Events
                      Z-Wave 3.0.1.262: 123 Nodes on one Z-Net

                      Comment


                      • #12
                        Originally posted by sparkman View Post

                        There is one setting in the HS Setup section under the Labs tab that may be relevant called “Load plug-ins in the background on startup”. Do you have it checked? If so, does un-checking it eliminate or improve this issue?
                        I have not experimented with it, but my assumption is that background loading would result in HomeSeer beginning event processing sooner and worsen the problem of processing events before the underlying devices are ready.

                        Comment


                        • #13
                          Originally posted by jvm View Post

                          I have not experimented with it, but my assumption is that background loading would result in HomeSeer beginning event processing sooner and worsen the problem of processing events before the underlying devices are ready.
                          Yes, that’s my understanding as well which is why I asked if you currently have it checked. Seems like the answer is that you don’t...
                          HS 3.0.0.548: 1976 Devices 1156 Events
                          Z-Wave 3.0.1.262: 123 Nodes on one Z-Net

                          Comment

                          Working...
                          X