Sitting on FeaturePage HTTP requests for realtime event notification?

[mrslother]

I have an HTML page that needs to monitor my plugin for events. What I want to do is have the web page connect to my plugin using AbstractFeaturePage.RegisterRequestCallback(). The idea is that the registered callback function receives the request and sits on it until some event occurs. I have this working really well if I create my own listening socket bound to some random port but to properly manage firewalls and such I would rather use HomeSeer as it binds to port 80.

Unfortunately a RegisterRequestCallback() registered callback can only sit on one HTTP connection request at a time. Is there any way to tell HomeSeer to async process such HTTP requests so that I can queue them up and return results when my code is ready to do so?

The only other options I have is to either:

1. Client constantly polls the plugin:
   My registered callback function simply returns immediately with some flag indicating whether a change as been detected (that the client responds to). This is what I am currently doing but a call every second puts an undue load on the HomeSeer and is not scalable.
2. Plugin binds to random TCP port:
   I did this and it works really well but makes it difficult to penetrate firewalls and such.

Is there a 3rd option someone can advise me on?

[alexbk66]

The usual approach is to use timer in js which calls your callback. In my FeaturePage I generate HTML and JS in C#:

[mrslother]

Right. That is my option #1, where a client is polling the plugin. Depending on the polling frequency required that puts a continuous load on the HS service routing the callback requests.

Ideally the client (JS code) would open a socket which is held open until it either timesout (which the client then retries) or the callback code in your HS plugin returns data and closes the socket. The client then has result data which it can action on.

My tests suggest that HomeSeer processes such callback requests synchronously so I cannot sit on the request until ready to respond.

Would love to learn that there is some setting or other option to mitigate this.

[alexbk66]

You are basically talking about server sending messages to the client, which is kind-of against server/client architecture.

Usually for that in js you would use EventSource, but it requires the server also to support this, I doubt HS can do that.

[mrslother]

You are right, EventSource is an excellent example of this. As you point out it requires server side support. Unfort HomeSeer on Windows does not leverage HTTP.sys so there is no ability to share port 80 across other sources like a plugin or other tools.

I may just deal with firewall port management and listen on my own socket. I was hoping for a more elegant port 80 solution on the HS platform.

Thanks, again, Alex. You have been a massive help across my posts.

[rmasonjr]

You know, under the hood, HSTouch mush have realtime 2-way communication with HS on port 10200 (I think).