Announcement

Collapse
No announcement yet.

registerEventCB and missing events

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

  • registerEventCB and missing events

    Hi,

    I have been using the MQTT plugin (not mcsMQTT) and sometimes it just stops working and publishing topics. Not being able to figure out why I wrote my own plugin using registerEventCB and then in HSEvent looking for my devices and then on change opening a connection to the broker and publishing the topic.

    Whilst that all seems very simple, and I do get a stream of device value changes, because that's what I asked for, Virtual device changes seem to sometimes generate a HSEvent and sometimes nothing at all. I guess this is the same behaviour I'm seeing with the original MQTT plug-in.

    So, first question; is this a known issue, and if so what's the work-around?

  • #2
    Just thinking this late at night but one thing to check might be the option not to change the device updated time if the value is not changing. You might find that devices are regularly sending the same device value to a device but if this option is not set then certainly HSTouch does not know about it so your plugin may not either as this setting may inhibit the raising of the event.
    My Plugins:

    Pushover 3P | DoorBird 3P | Current Cost 3P | Velleman K8055 3P | LAMetric 3P | Garadget 3P | Hive 3P |
    Yeelight 3P | Nanoleaf 3P

    Comment


    • #3
      Originally posted by mrhappy View Post
      Just thinking this late at night but one thing to check might be the option not to change the device updated time if the value is not changing. You might find that devices are regularly sending the same device value to a device but if this option is not set then certainly HSTouch does not know about it so your plugin may not either as this setting may inhibit the raising of the event.
      Changed that, but no change.

      Playing with it some more, and just using my thrown together plugin to dump out HSEvent callbacks I notice something strange here. There is a stream of value changes from other plug-ins like the current cost plug-in so we know where in the right place, but device changes (virtual device on/off 0/1) can be immediateish, delayed (sometimes for several minutes) or never at all. This morning I turned a virtual device ON, OFF then changes some setting and ON, OFF again, nothing in HSevent, then about a minute later I get my ON, OFF, ON, OFF together as if there is some queueing at work.

      Question; If you have a bunch of plug-ins all using registerEventCB, does homeseer provide events to their respective HSEvent functions simultaneously or in order? And does it wait for each plug-in to process the HSEvent callback before moving on?

      I'm calling callback.RegisterEventCB(Enums.HSEvent.VALUE_CHANGE, Plugin_Name, "") in my InitIO

      and my HSEvent is
      Public Sub HSEvent(ByVal EventType As Enums.HSEvent, ByVal parms() As Object) Implements HomeSeerAPI.IPlugInAPI.HSEvent

      In which I'm looking for the array parms() to get things like device Ref etc.

      Any idea's appreciated?

      Comment


      • #4
        What version of HS3 are you testing on?

        I'm pretty sure they changed callback processing recently because previously if a plug-in were not complete a call to HSEvent it would cause problems throughout the system.
        If I need callbacks, what I do in my plug-ins is push the callback events into a queue and process them on another thread so that HSEvent always completes in a timely manner.

        I've always had doubts about the reliability of HS3 callbacks but I've not done any testing recently in that area. Once over, I tried to implement CONFIG_CHANGE callbacks in one of my plug-ins to detect if the user deleted or changed one of my devices but at the time of testing it was sporadic to say the least so I abandoned that plan.

        Unless something changed, callbacks are queued in HS3. I don't know if they are dequeued on a FIFO basis, nor how they are handled amongst multiple plug-ins.

        In the early days of HS3 I identified (and reported to Rich) an issue with callback events getting stuck in the queue which exhibited similar symptoms to what you describe with events being triggered some time after the actual event or just going missing. Perhaps this issue has returned.
        If I get time over the next couple days, I'll do some testing here.

        The problem I reported was found to be that HS3 was not handling the queueing / dequeuing of the callback events in a thread safe manner which was causing events to get stuck in the queue. The issue was allegedly fixed pretty soon after.

        Paul..

        Comment


        • #5
          The problem I have been having since the initial days of HS3 is that there is no way of disconnecting from RegisterEventCB.

          I have tried every way I can think of to terminate my plugin, but HS3 never seems to clean up the RegisterEventCB so that when I restart the plugin, I usually do not get any new events (although, sometimes I do). If I wait some long time before restarting the plugin, I may get events again.

          I have documented this via bug report, to no avail. Are you saying that this processing has been changed with a recent HS3 upgrade? Any info would help.

          Another inconsistency, is that in HS2 your logically ORed the event record type bits that you wanted to register for when you wanted to receive multiple event types (log, device change, etc.). I never could get this to work under HS3, but if I called RegisterEventCB multiple times, each with a different bit set, then I would get multiple record types in my HSevents. This does not match the documentation (unless that has changed also).

          So, I would like to hear from any of you folks that are using RegisterEventCB in your plugins. Are you seeing these same issues? How do you terminate your plugin if you have registered for an event?

          tenholde
          tenholde

          Comment


          • #6
            Originally posted by tenholde View Post
            The problem I have been having since the initial days of HS3 is that there is no way of disconnecting from RegisterEventCB.
            I have also searched for ways to disconnect from RegisterEventCB, without terminating my plug-in, to no avail. It would be useful in some instances where I don't need to be registered continuously.

            Originally posted by tenholde View Post
            I have tried every way I can think of to terminate my plugin, but HS3 never seems to clean up the RegisterEventCB so that when I restart the plugin, I usually do not get any new events (although, sometimes I do). If I wait some long time before restarting the plugin, I may get events again.
            However, I haven't noticed any problems with it being cleaned up when I terminate a plug-in. Whilst developing I am quite often stopping and restarting the plug-in I'm working on and I haven't notices any issues with RegisterEventCB being closed and reestablished. I'd just like to be able to do it without closing the plug-in.

            Originally posted by tenholde View Post
            I have documented this via bug report, to no avail. Are you saying that this processing has been changed with a recent HS3 upgrade? Any info would help.

            Another inconsistency, is that in HS2 your logically ORed the event record type bits that you wanted to register for when you wanted to receive multiple event types (log, device change, etc.). I never could get this to work under HS3, but if I called RegisterEventCB multiple times, each with a different bit set, then I would get multiple record types in my HSevents. This does not match the documentation (unless that has changed also).

            So, I would like to hear from any of you folks that are using RegisterEventCB in your plugins. Are you seeing these same issues? How do you terminate your plugin if you have registered for an event?

            tenholde
            I can also confirm that I have to call RegisterEventCB multiple times to be able to successfully register more than one event type.

            Sorry, not much help just similar observations.

            Steve

            Comment


            • #7
              Following my previous post I ran some tests here.

              Testing was done on my live system which is running HS3 beta 3.0.0.418 on Win 7 (x86) with approx 1000 devices and 300 events.

              I modified one of my existing plug-ins that registers for VALUE_CHANGE callbacks only to count the actual number of callbacks processed and log each one to file.

              HS3 had been up for 25 hours prior to testing and was not shut down during the testing. I just stopped the running plug-in instance, copied over the modified exe and re-enabled it.

              I allowed the plug-in to run for 2 hours during which it logged just under 5000 value change callbacks.
              Obviously I can't be 100% sure that all actual value changes were caught by HSEvent within the plug-in but I periodically checked my log against manual device changes that I initiated from the device management page and it showed that in all cases they were processed by the plug-in almost immediately.

              I then stopped and re-started the plug-in at least 10 times (without shutting down HS3) and in all cases it resumed processing of the value change callbacks without issue.

              From those tests I can conclude that on my particular setup there does not appear to be an issue with VALUE_CHANGE callbacks.

              As Steve said, I've never seen an issue with callbacks not resuming after a plug-in re-start.

              This post is where Rich comments on changes to callback handling.

              Paul..

              Comment


              • #8
                One clarification. When I talk about stopping the plugin and then restarting, I am talking about terminating the plugin from the plugin code, not from HS. My plugin disconnects from HS and then terminates execution. When I restart my plugin and connect to HS and then register for events, all works except the events.

                If anyone is able to do this successfully, I would love to see the code you use to terminate your plugin.

                tenholde
                tenholde

                Comment


                • #9
                  It could be this, could be that, could be anything

                  I've done some more testing today, pulled some of the other plug-ins and loaded mine up. I'm using VS2015 enterprise on a VMware Windows 10 PC and I'm connecting remotely to HS which is on another Win10 box.

                  I can reproduce this regularly, but not reliably. When I've been doing something else and HS is generally idle for a while and then I toggle a virtual device, no event. Toggle it a few more times and other devices and then I get CHANGE events for those devices, and after that its fine until I leave it alone a while after which I'm back to sometimes or not at all. During all this I'm still getting change events for CurrentCost devices just fine.

                  So I'm at a loss right now. It should be noted at the HS log shows the devices change almost immediately regardless of whether the plug-in gets the change or not, suggesting that HS itself is ok, but the code that queues/feeds events to plug-ins is where the problem may be.

                  Do plug-ins get events in order or simultaneously ? and if in order, what dictates the order?

                  Comment


                  • #10
                    Workaround

                    So, here's a workaround for the missing events scenario. I created a virtual device, 0/1 and then created an event every 1 minute to turn it on, 30s later turn it off. This creates a steady stream of events every 30s which seems to fix the issues above.

                    Its not good, and its not a fix but until I can figure out a way to diagnose the problem further it makes things work.

                    Comment


                    • #11
                      I Think I know what's going on...

                      Having still not given up with this, I stripped my plug-in back to the bare bones and just had one line in HSEvent which dumps out the parms() and then grabs a GetDeviceByRef and dumps out some of the device data.

                      Running this plugin remotely I can see that the CurrentCost 3P plugin is updating 'values' at a rate of about 10 per second. The plug-in reads the XML data from the device, and then updates a bunch of device values. Since I have 9 sensors, this is a LOT of changes.

                      Looking at the stream of events from HSEvent in my plug-in and then toggling a few devices I can see that (a) HS does queue events to some degree as events arriving at the plug-in are delayed behind a mass of current cost value change events, and (b) HS does perhaps have a max queue length because in some cases my device change isn't even getting to the plug-in.

                      Now, firstly can someone confirm what I'm seeing? Is there a queue and does it throw events away if it gets behind?

                      and of course secondly, what's the fix?

                      As a side note, the whole RegisterCBEvents system is not what I need. As a plug-in I'm rarely going to want to see all value changes on the system instead just my devices or devices by Ref. With 10 plug-ins, my current cost change events are going to ALL 10 plug-ins and all 10 of then are not interested.

                      There must be a way to setup a callback for specific devices (by ref maybe) but I can't find this in the documentation, can anyone point me to this?

                      Comment

                      Working...
                      X