Send an even notification for given characteristic and changed value to all connected clients.
If originator
is specified, the given HAPConnection will be excluded from the broadcast.
The accessory id of the updated characteristic.
The instance id of the updated characteristic.
The newly set value of the characteristic.
Optional
originator: HAPConnectionIf specified, the connection will not get an event message.
Optional
immediateDelivery: booleanThe HAP spec requires some characteristics to be delivery immediately. Namely, for the Characteristic.ButtonEvent and the Characteristic.ProgrammableSwitchEvent characteristics.
The actual HAP server that iOS devices talk to.
Notes
It turns out that the IP-based version of HomeKit's HAP protocol operates over a sort of pseudo-HTTP. Accessories are meant to host a TCP socket server that initially behaves exactly as an HTTP/1.1 server. So iOS devices will open up a long-lived connection to this server and begin issuing HTTP requests. So far, this conforms with HTTP/1.1 Keepalive. However, after the "pairing" process is complete, the connection is expected to be "upgraded" to support full-packet encryption of both HTTP headers and data. This encryption is NOT SSL. It is a customized ChaCha20+Poly1305 encryption layer.
Additionally, this "HTTP Server" supports sending "event" responses at any time without warning. The iOS device simply keeps the connection open after it's finished with HTTP request/response traffic, and while the connection is open, the server can elect to issue "EVENT/1.0 200 OK" HTTP-style responses. These are typically sent to inform the iOS device of a characteristic change for the accessory (like "Door was Unlocked").
See EventedHTTPServer for more detail on the implementation of this protocol.