Closed jemella closed 4 years ago
The thing is that the notification-server isn't intended to trigger the actual operation (setting the switch to on). Rather it was intended that the accessory which is called can inform the switch plugin about its current state (which then informs HomeKit about the state change). Under that premise it wouldn't make sense to call the onUrl/offUrl. The http endpoint would send a http notification to the plugin informing it that it got switched on. It would be useless when the plugin than again sends a http call to the http endpoint to switch it on. Then we also would need to trust the http endpoint that it would not send a http notification if it is already turned on (though it would be a good idea to send notifications regardless of which state the http endpoint is in, to ensure the latest data is pushed to HomeKit). Otherwise we would end in an endless loop.
So what you are asking is simply not a use case I was trying to solve with the notification-server. What exactly is your use case? Can't you solve this with regular HomeKit automations. Or, if you can call the http endpoint of the notification server, why not just call the onUrl directly?
Try to just create a new comment and not edit your message so I can get notified 😅 I don't think I would implement web hooks 🤔 The plugin is essentially calling a Webserver, why not just setup a Webhook which points directly to you http device?
Seems to be stale, closing for now.
Currently the notificationID is only registered into the notification server for stateful switches.
But a notification hook url makes also sense to switch on a stateless switch as a rising edge. After the timeout it will be return to its original state.
Update: I understood something wrong. If the status is set via notification server the onUrl isn't called. I thought the notification could be used as a web hook for the switch. But that's not working. Is such a feature planed?
Thank you for this useful project!