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.
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.
Comment