Renamed Example 14 to EmulatePushButton
AND updated Example 13 to reflect new loop() framework in place of SpanEvents. ALSO found a bunch of inconsistencies with WindowCovering HAP documentation. PositonState and HoldPosition are NOT used by HomeKit. However, HomeKit has a full slider for controlling shades which makes a Hold Button no longer needed. See Example 13 for details. Open to do: add commentary to Example 13 and eliminate SpanEvents from library!
This commit is contained in:
Gregg
parent
a905ac4ef3
commit
258882fe6d
|
|
@ -14,53 +14,6 @@
|
|||
|
||||
void setup() {
|
||||
|
||||
// HomeKit is designed for two-way communication: HomeSpan devices not only receive and act on operational instructions from HomeKit Controllers, but
|
||||
// HomeSpan can also send HomeKit unsolicited messages regarding changes to the state of the device. Though it may not be apparent, this has already been
|
||||
// ocurring in the background in all prior examples. This is because when a HomeKit Controller sends an operational request to any HomeKit device, it expects
|
||||
// to receive a status message back indicating whether the request was successful or not. This is the purpose of returning StatusCode:OK in custom update()
|
||||
// methods. With this information returned, HomeKit can update its own status and properly reflect a change in the device, such as by showing a light is now
|
||||
// turned on instead of off. However, HomeKit unfortunately does NOT inform any other HomeKit Controllers of this new information. So if you have two iPhones
|
||||
// and use one to turn on a light, the other first iPhone does not relay a message to the second iPhone that a light has been turned on. This is the case even
|
||||
// if you are using an AppleTV or HomePod as a central hub for HomeKit.
|
||||
|
||||
// Normally this does not matter much, since the second iPhone will naturally update itself as to the status of all HomeKit devices as soon as the HomeKit
|
||||
// application is launched on that iPhone. It does this by sending every HomeKit device a message asking for a status update. In this fashion the second
|
||||
// iPhone quickly synchronizes itself as soon as the HomeKit app is opened, but ONLY when it is first opened (or re-opened if you first close it). But if you
|
||||
// have two iPhones BOTH opened to the HomeKit app (or one iPhone and one Mac opened to the HomeKit app) and you use one Controller app to turn on a light, the
|
||||
// resulting change in status of that light will NOT be reflected in the second Controller app, unless you close tha app and re-open (at which point it goes
|
||||
// through the request procedure discussed above). This is very annoying and counterintuitive.
|
||||
|
||||
// Fortunately, HomeKit provides a solution to this in the form of an Event Notification protcol. This protcol allows a device to send unsoliciated messages
|
||||
// to all Controllers that have previously registered themselves with the device indicating the Characteristics for which they would like to receive an event
|
||||
// message from the device whenever there is a change in the status of one or more of those Characteristics.
|
||||
|
||||
// The good news is that HomeSpan takes care of this automatically. To see this for yourself, use two iPhones (or an iPhone and Mac) with any of the previous examples
|
||||
// and open the HomeKit app on both. Any changes you make to the device using one of the Controllers, such as turning on an LED, is immediately reflected
|
||||
// in the other Controller. Not quite magic, but close.
|
||||
|
||||
// A different use of Event Notifications was also working behind in the scenes in Example 10 - Timed Resets. In this case, HomeSpan sent an unsolited Event message
|
||||
// to all registered Controllers letting them know that a device that was previously turned on, is now in fact turned off.
|
||||
|
||||
// In this Example 13 we explore the explicit use of Event Notifications to support Services that require constants updates from the device to all HomeKit Controllers.
|
||||
// The two Services we will use below are a Temperature Sensor and an Air Quality Sensor. Neither of these Services have any operational controls. They cannot be
|
||||
// turn on or off, or operated in any way. As such, they do not need to implement an update() method, since HomeKit Controllers will never ask them to change
|
||||
// any of their Characteristics.
|
||||
|
||||
// Rather, HomeKit is expecting to get periodic Event Notification messages from such Services so that the HomeKit Controllers can accurately reflect the status
|
||||
// and values of the Characteristics for those Services, such as the temperature, in the HomeKit Controller.
|
||||
|
||||
// There are two steps to accomplishing this. The first is to implement an event() method for each Service that uses a setVal() function to change the values
|
||||
// for one or more Characteristics for that Service. The second step is to instantiate a new SpanEvent() object for each Service that you want HomeSpan to invoke your
|
||||
// event() method. The SpanEvent object take only one argument - the number of milliseconds to wait between calls to a Service's event() method.
|
||||
|
||||
// As usual, all of the logic for this is encapsulated in new standalone derived Services. You'll find fully-commented definitions for the DEV_TempSensor() and
|
||||
// the DEV_AirQualitySensor() Services instantiated below, in the DEV_Sensors.h file. Note that this example is for instructional purposes only -- we do not actually
|
||||
// connect a Temperature Sensor or Air Quality Sensor to our ESP32 device. As such, we did not define the Services to take any arguments to specify pin numbers or any
|
||||
// other information needed to implement an actual sensor. Instead, in order to see how real a device would work, we will send Event messages by manufacturing simulated
|
||||
// updates. See DEV_Sensors.h for complete details.
|
||||
|
||||
// Once you understand these examples, you should be able to use Event Notifications for any combination of HomeKit Services with Characteristics that require your device to
|
||||
// send periodic update messages to HomeKit Controllers, ranging from Smoke Alarms to Door Sensors.
|
||||
|
||||
Serial.begin(115200);
|
||||
|
||||
|
|
@ -78,7 +31,7 @@ void setup() {
|
|||
|
||||
new SpanAccessory();
|
||||
new DEV_Identify("Window Shade","HomeSpan","123-ABC","Shade","0.9",0);
|
||||
new DEV_WindowShade(); // Create a motorized Window Shade (see DEV_DoorsWindows.h for definition)
|
||||
new DEV_WindowShade(); // Create a motorized Window Shade (see DEV_DoorsWindows.h for definition)
|
||||
|
||||
} // end of setup()
|
||||
|
||||
|
|
|
|||
|
|
@ -9,14 +9,10 @@ struct DEV_GarageDoor : Service::GarageDoorOpener { // A Garage Door Opener
|
|||
SpanCharacteristic *target;
|
||||
SpanCharacteristic *obstruction;
|
||||
|
||||
unsigned long alarmTime;
|
||||
|
||||
DEV_GarageDoor(ServiceType sType=ServiceType::Regular) : Service::GarageDoorOpener(sType){ // constructor() method
|
||||
|
||||
new SpanEvent(1000); // check for events on this Service every 1 second
|
||||
|
||||
current=new Characteristic::CurrentDoorState(0);
|
||||
target=new Characteristic::TargetDoorState(0);
|
||||
current=new Characteristic::CurrentDoorState(1);
|
||||
target=new Characteristic::TargetDoorState(1);
|
||||
obstruction=new Characteristic::ObstructionDetected(false);
|
||||
|
||||
Serial.print("Configuring Garage Door Opener"); // initialization message
|
||||
|
|
@ -36,18 +32,16 @@ struct DEV_GarageDoor : Service::GarageDoorOpener { // A Garage Door Opener
|
|||
obstruction->setVal(false);
|
||||
}
|
||||
|
||||
alarmTime=millis()+10000;
|
||||
|
||||
return(StatusCode::OK); // return OK status code
|
||||
|
||||
} // update
|
||||
|
||||
void event(){ // event() method
|
||||
void loop(){ // loop() method
|
||||
|
||||
if(current->getVal()==target->getVal())
|
||||
return;
|
||||
|
||||
if(random(30)==0){
|
||||
if(current->getVal()==3 && random(100000)==0){
|
||||
current->setVal(4);
|
||||
obstruction->setVal(true);
|
||||
LOG1("Garage Door Obstruction Detected!\n");
|
||||
|
|
@ -56,10 +50,10 @@ struct DEV_GarageDoor : Service::GarageDoorOpener { // A Garage Door Opener
|
|||
if(current->getVal()==4)
|
||||
return;
|
||||
|
||||
if(millis()>alarmTime)
|
||||
if(target->timeVal()>5000)
|
||||
current->setVal(target->getVal());
|
||||
|
||||
} // event
|
||||
} // loop
|
||||
|
||||
};
|
||||
|
||||
|
|
@ -69,19 +63,14 @@ struct DEV_WindowShade : Service::WindowCovering { // A motorized Window Sha
|
|||
|
||||
SpanCharacteristic *current;
|
||||
SpanCharacteristic *target;
|
||||
SpanCharacteristic *state;
|
||||
SpanCharacteristic *hold;
|
||||
|
||||
unsigned long alarmTime;
|
||||
int speed=5;
|
||||
|
||||
DEV_WindowShade(ServiceType sType=ServiceType::Regular) : Service::WindowCovering(sType){ // constructor() method
|
||||
|
||||
new SpanEvent(1000); // check for events on this Service every 1 second
|
||||
|
||||
current=new Characteristic::CurrentPosition(0);
|
||||
new SpanRange(0,100,10);
|
||||
|
||||
target=new Characteristic::TargetPosition(0);
|
||||
state=new Characteristic::PositionState(2);
|
||||
new SpanRange(0,100,10);
|
||||
|
||||
Serial.print("Configuring Motorized Window Shade"); // initialization message
|
||||
Serial.print("\n");
|
||||
|
|
@ -92,37 +81,26 @@ struct DEV_WindowShade : Service::WindowCovering { // A motorized Window Sha
|
|||
|
||||
if(target->getNewVal()>current->getVal()){
|
||||
LOG1("Raising Shade\n");
|
||||
state->setVal(1);
|
||||
alarmTime=millis()+speed;
|
||||
} else
|
||||
if(target->getNewVal()<current->getVal()){
|
||||
LOG1("Lowering Shade\n");
|
||||
state->setVal(0);
|
||||
alarmTime=millis()+speed;
|
||||
}
|
||||
|
||||
return(StatusCode::OK); // return OK status code
|
||||
|
||||
} // update
|
||||
|
||||
void event(){ // event() method
|
||||
void loop(){ // loop() method
|
||||
|
||||
if(current->getVal()==target->getVal())
|
||||
return;
|
||||
if(current->timeVal()>1000){
|
||||
if(target->getVal()>current->getVal()){
|
||||
current->setVal(current->getVal()+10);
|
||||
} else
|
||||
if(target->getVal()<current->getVal()){
|
||||
current->setVal(current->getVal()-10);
|
||||
}
|
||||
}
|
||||
|
||||
if(millis()<alarmTime)
|
||||
return;
|
||||
|
||||
if(state->getVal()==1)
|
||||
current->setVal(current->getVal()+1);
|
||||
else
|
||||
current->setVal(current->getVal()-1);
|
||||
|
||||
if(current->getVal()==target->getVal())
|
||||
state->setVal(2);
|
||||
else
|
||||
alarmTime=millis()+speed;
|
||||
|
||||
} // event
|
||||
} // loop
|
||||
|
||||
};
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
// HomeSpan: A HomeKit implementation for the ESP32 //
|
||||
// ------------------------------------------------ //
|
||||
// //
|
||||
// Example 14: Pushbuttons //
|
||||
// Example 14: Emulated PushButtons //
|
||||
// //
|
||||
////////////////////////////////////////////////////////////
|
||||
|
||||
|
|
@ -1232,7 +1232,7 @@ void HAPClient::checkTimedWrites(){
|
|||
for(auto tw=homeSpan.TimedWrites.begin(); tw!=homeSpan.TimedWrites.end(); tw++){ // loop over all Timed Writes using an iterator
|
||||
if(cTime>tw->second){ // timer has expired
|
||||
sprintf(c,"Removing PID=%llu ALARM=%lu\n",tw->first,tw->second);
|
||||
LOG1(c);
|
||||
LOG2(c);
|
||||
homeSpan.TimedWrites.erase(tw);
|
||||
}
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue