Hi,
I am trying to subscribe SSE events from openhab-cloud with my android app. It works fine for a locally running openHAB instance, but does not seem to connect when using openhab-cloud, regardless if it is installed locally or if I use myopenhab.
I can see that there is a difference in the response if I try to connect with curl. Local server replies with
GET /rest/events?topics=smarthome/items/VBatteryLevel/statechanged,smarthome/items/VCommand/command HTTP/1.1
Host: openhabianpi:8080
User-Agent: curl/7.58.0
Accept: /
HTTP/1.1 200 OK
X-Accel-Buffering: no
Content-Type: text/event-stream
Transfer-Encoding: chunked
Server: Jetty(9.4.12.v20180830)
openhab-cloud does not respond at all. It just leaves the connection open:
which does not look like a valid response to me. Does anybody know why the cloud instance answers differently than the server install? Is this for a reason or might this be a bug?
Not sure why this does not work for you, this works for me at least. Also the Paper UI uses SSE, which also works using myopenHAB (control section), i have not heard of it not working to date. This is what i get when i use curl
I see a few differences here, but I am not sure if they are the cause of this:
I subscribe only two states, which do not change, so I do not get data back
the response from openhab-cloud that I posted above was from my local install, which does not have nginx in front of it. The docs suggested that this is not needed. But I suppose the cloud install has nginx in front of it and it did not work there, either.
@digitaldan, the difference is whether there are any item updates or not. If I just call curl on rest/events, I also get an immediate response that looks good:
curl --verbose --user ********* http://localhost:3000/rest/events
Enter host password for user '***********':
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
* Server auth using Basic with user '***********'
> GET /rest/events HTTP/1.1
> Host: localhost:3000
> Authorization: Basic ***************************
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Set-Cookie: CloudServer=undefined%3Aundefined; Max-Age=900; Path=/; Expires=Tue, 14 May 2019 15:09:23 GMT; HttpOnly
< Set-Cookie: connect.sid=**********; Path=/; HttpOnly
< Transfer-Encoding: chunked
< Server: Jetty(9.4.12.v20180830)
< X-Accel-Buffering: no
< Content-Type: text/event-stream
< Date: Tue, 14 May 2019 14:54:23 GMT
< Connection: keep-alive
<
event: message
data: {"topic":"smarthome/things/jeelink:lacrosse:11/status","payload":"{\"status\":\"ONLINE\",\"statusDetail\":\"NONE\"}","type":"ThingStatusInfoEvent"}
Correct me if I am wrong, but I would assume that subscribing to a topic that has no immediate updates should answer in the same way. At least it would then work with oksse, which is the library I use (this probably applies to others as well).
The best thing would be if current values of subscribed topics would be send as a reply to the subscription. Then I could also get rid of the calls to the rest api to get initial values.
Edit: I just checked the SSE specification and that states that the server has to respond with status 200 and a Content-Type header specifying the type text/event-stream, so openhab-cloud definitely does not comply with the SSE spec.
Do you want me to write an issue in the openhab-cloud github project?
Even though ok-sse shows the connection as not open, it actually is connected and will notify the connection listener as soon as the first data message is received.
@digitaldan, how do we proceed with this? Is there any way I can help?
Hi Sorry for the late reply, I’m not 100% where the issue lies, its either in the cloud binding code, hosted cloud code or the nginx configuration we use to front it. I think opening an issue with openhab-cloud is probably a good start (it’s the most likely culprit).
I agree this would be a useful feature to have in the SSE rest endpoints
