Inside the manual of my switch the channel notify is described by this:
"This web service is very special because it will not return immediately! It gives a device (a HTTP server) a chance to notify the requesting client as soon as something has happened in the device. The device will keep this request open until one of the channels has changed its state. Then the device will send the response. The response looks similar to that of a /zrap/chscan service. To be nice to naive clients each /zrap/chnotify request will also get a response after 30 seconds, even if no channel has changed its state! After each response the client must restart a new /zrap/chnotify to keep track of every state change."
I don't know if the way your switch handles those notify request is applicable to this plugin/homebridge.
As far as I understand it, the idea behind the /zrap/chnotify route is to provide real time notifications to the requesting client. If you have a look at the section urlObjects in the README of my plugin you can find the property requestTimeout which is set to 20s by default (that's also what causes the timeout error). You could possibly increase that to the expected 30s. However the statusUrl is called every time some HomeKit device requests the current state of the switch and thus, this would lead to very long waiting time inside the Home App (also I don't know what timeout HomeKit itself expects).
Maybe you could check the documentation of your switch if there is any route where the current switch state is instantly returned.
The notify route is more applicable when you want the state of the switch in HomeKit to be updated in real time. However this would need some programming work on your side to implement this a bit unconventional notification procedure.
I had the same thoughts than you. The vendor of the switch does not very well implement the notify mechanism. I had a conversion by eMail and phone with a developer. He said, it works like described in the manual, and they do not plan to change the code. Also that the device send out messages by XML is not adequate — not even this request they put on the dev backlog.
I'm an IT System Engineer and do have limited coding skills. Bash and Python are those scripting languages that can write. Java Script - I do not have a clue about it. So to code a new function would for me very time consuming because I start from zero. May I have to accept this challenge in someday :)
Regarding your suggestion about the "requestTimeout
" parameter. I'd tried this, but it does not work for my use-case. In my humble option, the only way would be to change the behavior of how the switch notifies the state.
Greeting form Zürich
Chris
I don't know if the way your switch handles those notify request is applicable to this plugin/homebridge.
As far as I understand it, the idea behind the /zrap/chnotify route is to provide real time notifications to the requesting client. If you have a look at the section urlObjects in the README of my plugin you can find the property requestTimeout which is set to 20s by default (that's also what causes the timeout error). You could possibly increase that to the expected 30s. However the statusUrl is called every time some HomeKit device requests the current state of the switch and thus, this would lead to very long waiting time inside the Home App (also I don't know what timeout HomeKit itself expects).
Maybe you could check the documentation of your switch if there is any route where the current switch state is instantly returned.
The notify route is more applicable when you want the state of the switch in HomeKit to be updated in real time. However this would need some programming work on your side to implement this a bit unconventional notification procedure.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Some ideas to get you started. From a software design decision standpoint, the 'prettiest' way to solve this is probably to directly alter the code of the http-switch plugin.
However when you are more experienced in for example python you could also write a custom http proxy, which implements the /zrap/chnotify route and always saves the current state of the switch. The python server then also exposes a http server which is accessed by the http-switch plugin and does directly return the saved switch state. I don't know if that's easier for you to achieve, but this could definitely work.
Hello
This is not an issue.
Inside the manual of my switch the channel notify is described by this:
"This web service is very special because it will not return immediately! It gives a device (a HTTP server) a chance to notify the requesting client as soon as something has happened in the device. The device will keep this request open until one of the channels has changed its state. Then the device will send the response. The response looks similar to that of a /zrap/chscan service. To be nice to naive clients each /zrap/chnotify request will also get a response after 30 seconds, even if no channel has changed its state! After each response the client must restart a new /zrap/chnotify to keep track of every state change."
When I query the state with Postman (http://zapp-17170017.hal.abc.ch/zrap/chnotify/?ch1) I get the following XML response:
I don't know if the way your switch handles those notify request is applicable to this plugin/homebridge. As far as I understand it, the idea behind the
/zrap/chnotifyroute is to provide real time notifications to the requesting client. If you have a look at the section urlObjects in the README of my plugin you can find the propertyrequestTimeoutwhich is set to 20s by default (that's also what causes the timeout error). You could possibly increase that to the expected 30s. However the statusUrl is called every time some HomeKit device requests the current state of the switch and thus, this would lead to very long waiting time inside the Home App (also I don't know what timeout HomeKit itself expects).Maybe you could check the documentation of your switch if there is any route where the current switch state is instantly returned. The notify route is more applicable when you want the state of the switch in HomeKit to be updated in real time. However this would need some programming work on your side to implement this a bit unconventional notification procedure.
Hi Andi
Thank you for getting back to me!
I had the same thoughts than you. The vendor of the switch does not very well implement the notify mechanism. I had a conversion by eMail and phone with a developer. He said, it works like described in the manual, and they do not plan to change the code. Also that the device send out messages by XML is not adequate — not even this request they put on the dev backlog. I'm an IT System Engineer and do have limited coding skills. Bash and Python are those scripting languages that can write. Java Script - I do not have a clue about it. So to code a new function would for me very time consuming because I start from zero. May I have to accept this challenge in someday :)
Regarding your suggestion about the "requestTimeout " parameter. I'd tried this, but it does not work for my use-case. In my humble option, the only way would be to change the behavior of how the switch notifies the state. Greeting form Zürich Chris
On September 1, 2019 at 5:02 PM, Andi notifications@github.com wrote:
I don't know if the way your switch handles those notify request is applicable to this plugin/homebridge. As far as I understand it, the idea behind the /zrap/chnotify route is to provide real time notifications to the requesting client. If you have a look at the section urlObjects in the README of my plugin you can find the property requestTimeout which is set to 20s by default (that's also what causes the timeout error). You could possibly increase that to the expected 30s. However the statusUrl is called every time some HomeKit device requests the current state of the switch and thus, this would lead to very long waiting time inside the Home App (also I don't know what timeout HomeKit itself expects).
Maybe you could check the documentation of your switch if there is any route where the current switch state is instantly returned. The notify route is more applicable when you want the state of the switch in HomeKit to be updated in real time. However this would need some programming work on your side to implement this a bit unconventional notification procedure.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Some ideas to get you started. From a software design decision standpoint, the 'prettiest' way to solve this is probably to directly alter the code of the http-switch plugin. However when you are more experienced in for example python you could also write a custom http proxy, which implements the /zrap/chnotify route and always saves the current state of the switch. The python server then also exposes a http server which is accessed by the http-switch plugin and does directly return the saved switch state. I don't know if that's easier for you to achieve, but this could definitely work.