Updatd Example 10 to address HomeKit Notification Bug

Added check for newValue==true even though this should not be necessary.

examples/Advanced/10-TimedResets/DEV_Blinker.h

@@ -27,9 +27,10 @@ struct DEV_Blinker : Service::LightBulb {           // LED Blinker
     // Here we create a new Timed Reset of 2000 milliseconds. Similar to SpanRange(), SpanTimedReset() automatically
     // attaches to the last Characteristic instantiated, which in this case the the "power" Characteristic::On above.
     // SpanTimedReset() will notify HomeKit that the Characteristic has been turned off by HomeSpan 2000 milliseconds
-    // after HomeKit requests it be turned on.  This DOES NOT cause HomeKit to send an "off" request to HomeSpan.
+    // after HomeKit requests it be turned on.  This DOES NOT cause HomeKit to send an "off" request to HomeSpan (with
-    // Rather, HomeSpan is notifying HomeKit that HomeSpan itself has turned "off" the Characteristic, and that HomeKit
+    // one exception --- see * below). Rather, HomeSpan is notifying HomeKit that HomeSpan itself has turned "off" the
-    // should reflect this new "off" status in the Tile shown for this device in the HomeKit Controller.
+    // Characteristic, and that HomeKit should reflect this new "off" status in the Tile shown for this device in the
+    // HomeKit Controller.
     //
     // Note that in practice you'll want to set the reset time to 500ms or less to better emulate a pushbutton.
     // We've used a full 2 seconds in this example for illustrative purposes only.
@@ -50,10 +51,6 @@ struct DEV_Blinker : Service::LightBulb {           // LED Blinker
 
   StatusCode update(){                              // update() method
 
-    LOG1("Activating the LED Blinker on pin=");
-    LOG1(ledPin);
-    LOG1("\n");
-
     // Instead of turning on or off the LED according to newValue, we blink it for
     // the number of times specified, and leave it in the off position when finished.
     // This line is deleted...
@@ -62,6 +59,12 @@ struct DEV_Blinker : Service::LightBulb {           // LED Blinker
 
     // and is replaced by...
 
+    if(power->newValue.BOOL){                       // check to ensure HomeKit is requesting we "turn on" this device (else ignore)
+
+      LOG1("Activating the LED Blinker on pin=");
+      LOG1(ledPin);
+      LOG1("\n");
+
       for(int i=0;i<nBlinks;i++){                     // loop over number of blinks specified
         digitalWrite(ledPin,HIGH);                    // turn pin on
         delay(100);                                   // wait 100 ms
@@ -69,11 +72,9 @@ struct DEV_Blinker : Service::LightBulb {           // LED Blinker
         delay(250);                                   // wait 250 ms
       }
       
-    // Note that we do not need to read newValue since we are not making a decision to turn a device
+    } // if power->newValue==true
-    // either on or off.  We are emulating a pushbutton which means the same routime is supposed to
-    // occur when the button is pressed - there is no concept of on or off.
 
-    // Also note that the delays above of 100ms and 250ms are for illustrative purposes only
+    // Note that the delays above of 100ms and 250ms are for illustrative purposes only
     // (and so you can see the LED blink). In practice, if you were controlling an IR LED
     // or an RF transmitter, the whole signal would likely transmit in 10ms total.
     
@@ -83,3 +84,10 @@ struct DEV_Blinker : Service::LightBulb {           // LED Blinker
 };
       
 //////////////////////////////////
+
+// * EXCEPTION:  There is an apparent bug in HomeKit such that if you have an Accessory with three or more
+// Services, and the Accessory receives a notification message from the device, AND the HomeKit interface is
+// open to show the detailed control for Service in the Accessory, then for some reason HomeKit tries to
+// update the device with the same status it just received from the device, even though this is contrary to
+// the purpose of notification requests.  This is why it's a good idea to check that newValue.BOOL==true.  It
+// avoids triggering the device if for some reason HomeKit should send a reqeust to update newValue to false.