Updatd Example 10 to address HomeKit Notification Bug

Added check for newValue==true even though this should not be necessary.
This commit is contained in:
Gregg 2020-08-01 17:23:53 -05:00
parent 6646aae799
commit 70c62367cd
1 changed files with 25 additions and 17 deletions

View File

@ -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,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
// 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.
} // if power->newValue==true
// 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.