No announcement yet.

Delay with triggering events from ocelot

This topic is closed.
  • Filter
  • Time
  • Show
Clear All
new posts

    Delay with triggering events from ocelot

    I have motion sensors on my secu16 and experience a few seconds delays before the motion sensor triggers the events.

    I have troubleshooted and found the following.
    the ocelot communications seem to be right but HS responds a few seconds slow. The ocelot log shows the input changed at 8:47:25 but HS doesn't record the change until 8:47:29.
    I don't believe it is the hs machine, there is nothing else running on it. CPU useage is always very low. And if I trigger the same event from a palmpad through the w800 it is instant everytime. Any ideas ?
    I am running hs 1.6.200 and the ocelot plugin 1.0.32

    5/4/2004 8:47:25 PM MSCOMM
    5/4/2004 8:47:25 PM IO point change mod= 2 point= 13 newval= 1
    5/4/2004 8:47:25 PM Setting HS device: ]14 to OFF
    5/4/2004 8:47:26 PM MSCOMM

    5/4/2004 8:47:29 PM~!~MOTION~!~>>>>>>>> Motion Detected with Sensors Downstairs - Playroom - No Motion (00:04)
    5/4/2004 8:47:29 PM~!~Event Trigger~!~Status change condition (Playroom ON):Sensors Downstairs - Playroom ]14 On q21 On (Playroom Light Left)
    Why oh why didn't I just leave things alone, they had been working.

    About 4 seconds is my experience with the time from GUI action to SECU16 relay action. I know I measured from switch input to HS update in the past. When I was logging both the ocelot log and the hsTrace log then it seems to me that inputs were recognized rather quickly by HS. I do not know the latency between recognition and update of device status, however.

    I was going to use the ocelot to illuminate an LED when the VR attention phrase was recongized, but I have since elected to go with 1-wire because of the latency associated with I/O on the ocelot. The ocelot is good when the logic is self-contained, but when it is part of a serial logic chain then latencies become excessive for real-time control.

    The same results are obtained with ocelot and ADIOcelot plugins.



      I have read many times about other people having latency problems. But I myself have never experienced them until lately.
      I can't find any reason for the delay, I even updated to the latest HS and Ocelot plugin to see if that would help. I was several revisions behind before on both.

      I find it very dissapointing. And the slowdown seems to me to be between the plugin and the HS interface.
      Why oh why didn't I just leave things alone, they had been working.


        I'm not certain if the standard ocelot plugin contains I/O trace code, but it should. You will see a line in the ocelot log when debug is enabled that shows when the ocelot notifies the plugin that an IO change has happened. You can corrrelate this with the hs trace log for detail or the standard log if you do not have device logging disabled.

        I looked at the ocelot vs ADIOcelot on the handling of Inputs. I know I had to change much to accomodate spawning of CMAX and managment of individual devices. I do not see much correlation anymore between the two in this area and I do not remember very much of actually doing it. A quick look shows that the standard Ocelot plugin looks for FF indication of an IO change and then polls all the IO and updates all the values. ADIOcelot looks for F0 and updates the single IO point that changed. Both of these are processed out of a timer that is kicked off by the start of a byte stream over the serial port from the ocelot.


          As much as I love the ocelot I seem to encounter too many downsides lately in my installation regarding motion sensors and lighting.

          I seem to have few options. Wait until ADI comes out with the "future-ware" z-wave module and have cmax completely control my lighting setup. ( this would be excellent but i am not sure I am that patient. )

          Or Attempt to use one of the parallel,usb,1wire or network input options to connect my motion sensors to HS.

          The usb inputs sounded interesting but I don't know what the speed of the inputs are.

          Why oh why didn't I just leave things alone, they had been working.


            The ocelot really should not be slow on the input side between the controller and homeseer. There are timing results posted in this forum showing the traces in the ocelot log, hsTrace log and homeseer log and I think they showed quick reaction through the plugin and processing by HS. It really will be no different for any plugin or script interface to an external signal. It is the same mechanism used for the RF to be received via a serial port and homeseer status updated.

            If memory serves me the ocelot status code of FF indicates that something has changed and the F0 status indicates a specific change. The change is included with the F0 notification. By using F0 then the ADIOcelot plugin can immediately inform homeseer of a new status. When the FF is used then homeseer needs to conduct a polling cycle of all IO from the ocelot. This means delays in communciations, the cpuxa querey of the SECU16, and the same on the return trip.

            If you do go another route it would be nice to have something on the outside that will generate an interrupt to the PC when something of interest exists. I do not like to use high speed polling solutions on the PC looking for a change in an input level. If your are using discrete inputs, the 1-wire at least has an alarm mode so only one request needs to go out to see if any connected switch has changed.