Delay testing

[randy]

I have mentioned in a few posts that I run some events that test the function and delay of Arduino boards. I have received a request to show how I run these tests. I use a series of events to test Arduino and Z-Wave devices for delays. I also test a Virtual Device to identify if there are any systemic delays in HS Event processing. The event structure is the same for Arduino and Virtual devices. An output pin is wired directly to an input pin.

The first Event makes sure the Arduino Output is off, starts a timer, then turns the output On.



A second event toggles the output Off when the Input goes high. I do this because I prefer to measure the time for a round trip of the input going On then Off. This is actually two steps, where I could trigger the "Pass" event as soon as the Input goes high, but this round trip actually combines two delays for the final time and has been better at catching delays introduced by the plug-in or boards.



The third is a Pass event.



This event is triggered by the input changing to low. It stops the timer, writes the timer's value to the log, resets the timer and turns the output Off.

There is a 4th event that is a Fail event.



If the input has not returned to low after a minute, the timer is stopped, its value written to the log, the timer is reset and the output is turned off. Then it does a soft reset of the board. In addition to the testing, I have a Freetronics watchdog timer board on each of my Arduinos. The testing output/input pin pair is connected to the watchdog and resets the watchdog timer. If it is not reset within its 4 minute window, it will force a hard reset of the Arduino. This will fix even the most stubbornly locked up board. It is not a problem I have seen often, but it is a good scheme to have in place. The testing Failure event increments two counters, one for the particular board and another for the cumulative failures of all boards. I only use the individual board counter for reference. The cumulative counter is reset every 20 minutes. If its value exceeds 6 the HomeSeer server is restarted. If the counter gets to this level, there is a serious problem. This will clear any major problems on the HomeSeer side.

I run this test and a virtual device test back to back,so I have a reference as to if HS is encountering any delays. It is rare that HS has delays, but it is good to see if more than one device type is affected. The log entries filtered on"Delay" tell the story.



There are virtual devices that will enable the delay testing for any of the three devices. If the delay testing is off, the board testing continues, but there is no tme logging or round trip, an output pin on each of my boards is turned on once every 3 minutes to reset the watchdog timers.

[Pierre]

Wow Randy, that means a lot of events and timers to setup, and some more delays I guess...

What I have done is simply to tie-up physically an input to an output pin, add them in the Plugin board setup.

Then, setup an event:
If test output changes any value
then
execute this script: test_arduino.vb.

Then, toggle your output and check your log.


Here is the test_arduino.vb script:

Public Sub Main(ByVal Parms As Object)
   
  'change these values with your device ref
   Dim test_output as integer=1552
   Dim test_input as integer=1551
   '******************************************
   dim diff as long
   dim totalDuration  as long 
   dim output_last_change,input_last_change as date
   
   hs.waitsecs(2)' to be sure the input was triggered

   output_last_change = hs.DeviceLastChangeRef(test_output)
   input_last_change = hs.DeviceLastChangeRef(test_input)
   
  ' hs.writelog ("TEST ARDUINO","output=" & output_last_change &" Input "& input_last_change)
   
  diff = input_last_change.Ticks- output_last_change.Ticks   
  totalDuration  = (diff / 10000)'convert to milliseconds

  hs.writelog ("TEST ARDUINO","diff=" & totalDuration)
End sub 

I guess the result is the addition of the delays to :
turn the output pin on/off
advise HS
trigger the event
turn the input pin on/off

I always get delays over 500 msecs, wich is not good enough for pushbuttons

[randy]

Yes, it is a lot of events. I have never quite understood the aversion to events that some folks express. HomeSeer was designed to be able to do most anything with events and it is rare that scripting needs to be used. I don't have a problem building and using events, they are extremely easy and fast to build. I don't have a problem using scripting when an event cant do what I need. When I first started using HomeSeer I wanted to use events to the greatest extent possible, Not for any particular aversion to scripting, just to test how powerful events can be. As far as creating timers, creating a timer within an event takes just a few seconds. Scripting and events can usually be used interchangeably, it is just up to personal preference. I do contend that an event adds little (if any) significant overhead as compared to a script.

Like your test I connect an input to an output. Yours requires an event and a script for each board, a simple test such as yours could be done with 2 events. My delay testing was an add on to testing my Arduino boards for proper communication, it was not the initial goal. In addition to the delay measurement I also evaluate whether or not the test was successful and take remedial actions if there is a failure. There is a hardware watchdog that is reset with each test pass.

It is interesting to see your delay of over 500ms for a single action and mine at 650-1300ms with 2. It is reasonable to assume that a single pass tested with events would be about half the time that two passes take. With mine employing 3 events and changing states of both pins twice, it would seem that the HS event engine is very efficient and fast showing essentially the same measurement as your script. This sort of bears out my belief that there is virtually no difference in speed between a script and an event.

As far as 500ms being too slow for a button press, since the inputs are polled, I don't think you could get it much faster than that. I suppose if the inputs could be interrupt driven, you could get that a bit faster, but that would probably affect Greigs approach to making this plug-in as simple and flexible as it is. It also might impact the sketch size, which is tight on the Uno. We use 3 buttons tied to Arduino inputs to control a device and a couple of modes of operation. Other household members have never complained about delays with Arduino buttons, they are still faster than our DirecTV remote

[Pierre]

I like events and use them in priority but I am still used to scripting as it was mandatory for HS2 (and HS).
I am very pleased of Greig's plugin, I have replaced about all the wired I/O of the house, that were tied long time ago to my JDS Stargate, then to various hardware, to a simple $30 Arduino .
The only problem is for using push buttons, we are used to double-tap and long presses to control light scenes...I might have to go another way for that.