Announcement

Collapse
No announcement yet.

API Request: Split Timers from Devices for HS_EVENT registration

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

    API Request: Split Timers from Devices for HS_EVENT registration

    Can we create a new set of HSEvent.* enums for timers? If you register for VALUE_CHANGE today you get called once per second for every timer running on the system, since most plugins do not need to track the per second state of the timers, this creates a large overhead which contributes to the HSEvent queue full errors (2 timers runnings means all HSEvent handlers in all plugins TOTAL must complete in 500ms including the remoting costs or the queue will eventually overflow which leads to unpredictable experience for users)

    If so, I'd suggest then documenting in the porting guide that you need to register for the new event type and handle it in your HSEvent callback. Plugin authors can check the HS version to know if they need to handle that case separately or (if they need it for some reason) handle it in the their 3.0 handler.

    #2
    Even more, I would love to be able to decide that calls from HSEvent will be filtered in advance to only those HSEvents that should be handled by the plugin. For my plugin I do have NO interest in any HSEvent calls not belonging to my plugin. It would save time as the plugin does not have to check the device if it is a useful call?

    Wim
    -- Wim

    Plugins:RFXCOM, HSTouch Server, Squeezebox, BLGData, Restart, Jon00's Perfmon and Network monitor, WeatherXML, BLBackup, TenScripting, BC4, Pushover, PHLocation, JowiHue, Zwave, Sonos
    650 devices ---- 336 events ----- 40 scripts

    Comment


      #3
      Originally posted by w.vuyk View Post
      Even more, I would love to be able to decide that calls from HSEvent will be filtered in advance to only those HSEvents that should be handled by the plugin. For my plugin I do have NO interest in any HSEvent calls not belonging to my plugin. It would save time as the plugin does not have to check the device if it is a useful call?

      Wim
      Yes, so you want a flag basically saying filter by interface. That would greatly reduce overhead for most plugins.

      Comment


        #4
        I actually think this should be the default. I bet most plugins don't need to hear about devices they don't own, unless they are some kind of system logging/monitoring/UI type plugin. The flag would need to be set to get events from devices the don't own.

        Originally posted by bsobel View Post

        Yes, so you want a flag basically saying filter by interface. That would greatly reduce overhead for most plugins.
        website | buy now | support | youtube

        Comment


          #5
          Originally posted by rjh View Post
          I actually think this should be the default. I bet most plugins don't need to hear about devices they don't own, unless they are some kind of system logging/monitoring/UI type plugin. The flag would need to be set to get events from devices the don't own.
          In that case you can use the same API since you already pass in an interface and instance. If you add a flag of say HS_EVENT_ALLINTERFACES OR'd with the value you want, then you could know to send all for folks like me (which I fully agree is the minority)

          Comment


            #6
            Originally posted by rjh View Post
            I actually think this should be the default. I bet most plugins don't need to hear about devices they don't own, unless they are some kind of system logging/monitoring/UI type plugin. The flag would need to be set to get events from devices the don't own.


            actually, due to the time it takes to generate a list of devices in a plugin (at least in HS3), my base library built and maintained a local copy of the devices using HSEvent. This would take my system from 5-10 seconds to generate the list, to < 1 second. yes, there is overhead involved, but for the plugins that I wanted/needed to generate a full list of HS devices, this was preferred.

            Now, I really only needed to know when a device was added/removed, not when the value changed, but I just ignore the noise.
            MeiAutomtion Home

            Comment


              #7
              Originally posted by sirmeili View Post

              actually, due to the time it takes to generate a list of devices in a plugin (at least in HS3), my base library built and maintained a local copy of the devices using HSEvent. This would take my system from 5-10 seconds to generate the list, to < 1 second. yes, there is overhead involved, but for the plugins that I wanted/needed to generate a full list of HS devices, this was preferred.

              Now, I really only needed to know when a device was added/removed, not when the value changed, but I just ignore the noise.
              Sounds VERY familiar; I do the same thing and my plugins actually share that dictionary between themselves via PluginFunction so I can avoid calling GetDeviceEnumerator (since it would often timeout and fail on me, albeit we recently figured out why and there is a fix in flight)

              Do you register only for config_change (add/removes/edits) and not register for set/value changes? If you don't need them, its much cheaper to not register for them since the quanta of time for processing is today effectively split over the sum of time of all plugins who get that event.

              Comment


                #8
                Originally posted by rjh View Post
                I actually think this should be the default. I bet most plugins don't need to hear about devices they don't own, unless they are some kind of system logging/monitoring/UI type plugin. The flag would need to be set to get events from devices the don't own.
                rjh I have been thinking about this more, I would like to also in addition propose a new API where a caller can pass in an HashSet<int> of device or event refs they care about and only get HS change notifications if the changed item is in the set. The first change handles the normal case where a plugin manages its own devices and wants to see changes to them, this change handles utilities that may manage other devices but only need to see changes to some devices (CpsTags, CpsLinks, BLRadar and others are examples of such plugins).

                Something like
                HSSetFiler(HS_VALUE_CHANGE, mySet1);
                HSSetFilter(HS_VALUE_SET, mySet2);

                If a filter is setup HS would simply to a filter.contains() call and if not in the set the HS callback and related removing can be completely avoided. I think this would substantially lower the CPU load for any plugin that needs access to devices that don't have their interface set to the plugins interface.

                Comment


                  #9
                  Originally posted by rjh View Post
                  I actually think this should be the default. I bet most plugins don't need to hear about devices they don't own, unless they are some kind of system logging/monitoring/UI type plugin. The flag would need to be set to get events from devices the don't own.
                  BTW rjh in HS3 I found that HSEvent is not called when a device is renamed, even though HSEvent does have parameter 4 "DAC device/event was 0 = not known, 1 = Added, 2 = Deleted, 3 = Changed"

                  Hopefully it will be fixed in HS4. Do I need to create a separate thread for this?

                  Comment


                    #10
                    I have logged the rename issue and the HSEvent requests to our bug tracker so they get addressed.
                    website | buy now | support | youtube

                    Comment


                      #11
                      Originally posted by alexbk66 View Post

                      BTW rjh in HS3 I found that HSEvent is not called when a device is renamed, even though HSEvent does have parameter 4 "DAC device/event was 0 = not known, 1 = Added, 2 = Deleted, 3 = Changed"

                      Hopefully it will be fixed in HS4. Do I need to create a separate thread for this?
                      Thats odd, I certainly did receive renames (at one point) but I have not validated that on the latest version (so perhaps it got broken). What HS_* do you register for?

                      Comment


                        #12
                        Originally posted by bsobel View Post
                        Thats odd, I certainly did receive renames (at one point) but I have not validated that on the latest version (so perhaps it got broken). What HS_* do you register for?
                        Thanks Bill, I did have commented out
                        Code:
                        Callback.RegisterEventCB(Enums.HSEvent.CONFIG_CHANGE)
                        no wonder it didn't work. rjh

                        Comment

                        Working...
                        X