From 70c62367cd52d057dae9a18ebe1cb569b19ad8f8 Mon Sep 17 00:00:00 2001
From: Gregg <gregg.berman@me.com>
Date: Sat, 1 Aug 2020 17:23:53 -0500
Subject: [PATCH] Updatd Example 10 to address HomeKit Notification Bug

Added check for newValue==true even though this should not be necessary.
---
 .../Advanced/10-TimedResets/DEV_Blinker.h     | 42 +++++++++++--------
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/examples/Advanced/10-TimedResets/DEV_Blinker.h b/examples/Advanced/10-TimedResets/DEV_Blinker.h
index 3a3de8b..7bba1ec 100644
--- a/examples/Advanced/10-TimedResets/DEV_Blinker.h
+++ b/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.
-    // Rather, HomeSpan is notifying HomeKit that HomeSpan itself has turned "off" the Characteristic, and that HomeKit
-    // should reflect this new "off" status in the Tile shown for this device in the HomeKit Controller.
+    // after HomeKit requests it be turned on.  This DOES NOT cause HomeKit to send an "off" request to HomeSpan (with
+    // one exception --- see * below). Rather, HomeSpan is notifying HomeKit that HomeSpan itself has turned "off" the
+    // 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,18 +59,22 @@ struct DEV_Blinker : Service::LightBulb {           // LED Blinker
 
     // and is replaced by...
 
-    for(int i=0;i<nBlinks;i++){                     // loop over number of blinks specified
-      digitalWrite(ledPin,HIGH);                    // turn pin on
-      delay(100);                                   // wait 100 ms
-      digitalWrite(ledPin,LOW);                     // turn pin off
-      delay(250);                                   // wait 250 ms
-    }
+    if(power->newValue.BOOL){                       // check to ensure HomeKit is requesting we "turn on" this device (else ignore)
 
-    // Note that we do not need to read newValue since we are not making a decision to turn a device
-    // 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.
+      LOG1("Activating the LED Blinker on pin=");
+      LOG1(ledPin);
+      LOG1("\n");
 
-    // Also note that the delays above of 100ms and 250ms are for illustrative purposes only
+      for(int i=0;i<nBlinks;i++){                     // loop over number of blinks specified
+        digitalWrite(ledPin,HIGH);                    // turn pin on
+        delay(100);                                   // wait 100 ms
+        digitalWrite(ledPin,LOW);                     // turn pin off
+        delay(250);                                   // wait 250 ms
+      }
+      
+    } // if power->newValue==true
+
+    // 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.