Update Frequency?


#1

The websocket connection will provide real-time data updates every 0.5 seconds, but I want them less frequently. In order to get semi-real-time updates, I was planning on having a component poll it every 30 seconds. That does mean it has to initialize the connections every 30 seconds, but it’s less traffic overall.

Is that an acceptable rate? Is lower ok? Should it be higher?


#2

Please don’t poll the websocket that frequently. We’re dealing with some headaches based on users hitting the websocket too hard. Let me converse with the SW engineering team and get back with a better guideline.


#3

I expect everyone with the Sense app running on a phone, desk top etc. is getting the .5s real time updates using the websocket protocol. AFAIK, that data can only be pushed from the server.

Is there a way to get the same data without using websocket? I haven’t seen a published API.

If we do just poll instead of using websocket, I expect we could use persistent connections rather than reconnecting for each sample.

I’ve published one of the utilities that retrieves the real time data. I expect it is just one of the many sessions doing that, but I could update it if it is better to poll at a lower rate. I do wonder if polling is actually more efficient though.

My utility currently accepts the .5s stream but averages the data over whatever collection interval is specified in order to reduce output volume.


#4

The other products have a similar feature. However, I can imagine the real time updates could be a burden on the back end. That has to be managed.

But the HS110 and Wemo give you data locally. Maybe Sense could provide a similar capability. If we could get the data from the device itself, the back end load (and headaches) of streaming all the data to us could be avoided.


#5

FWIW, my WebSocket traffic is around 1K every .5s plus protocol. It varies depending on the number of devices that are active.

 1070 2018-05-07 18:29:05.792172  192.168.1.7 ? 34.226.34.247 TCP 54 49463 ? 443 [ACK] Seq=1795 Ack=14124 Win=65700 Len=0
 1080 2018-05-07 18:29:06.121782 34.226.34.247 ? 192.168.1.7  WebSocket 962 WebSocket Text [FIN] 
 1081 2018-05-07 18:29:06.327198  192.168.1.7 ? 34.226.34.247 TCP 54 49463 ? 443 [ACK] Seq=1795 Ack=15032 Win=64792 Len=0
 1104 2018-05-07 18:29:06.520389 34.226.34.247 ? 192.168.1.7  WebSocket 972 WebSocket Text [FIN] 
 1111 2018-05-07 18:29:06.727122  192.168.1.7 ? 34.226.34.247 TCP 54 49463 ? 443 [ACK] Seq=1795 Ack=15950 Win=65700 Len=0
 1120 2018-05-07 18:29:07.024900 34.226.34.247 ? 192.168.1.7  WebSocket 971 WebSocket Text [FIN] 
 1123 2018-05-07 18:29:07.227296  192.168.1.7 ? 34.226.34.247 TCP 54 49463 ? 443 [ACK] Seq=1795 Ack=16867 Win=64780 Len=0

On the uplink from the Sense monitor to the server, I see roughly half that.

620 2018-11-05 07:14:36.645669    192.168.1.26          34.239.73.252         TLSv1.2  359    Application Data
621 2018-11-05 07:14:36.659715    34.239.73.252         192.168.1.26          TCP      66     443 ? 35295 [ACK] Seq=1 Ack=5324 Win=853 Len=0 TSval=1755932916 TSecr=76527567
630 2018-11-05 07:14:36.761099    192.168.1.26          255.255.255.255       UDP      105    9999 ? 9999 Len=63
631 2018-11-05 07:14:36.761102    192.168.1.26          255.255.255.255       UDP      105    9999 ? 9999 Len=63
642 2018-11-05 07:14:37.176401    192.168.1.26          34.239.73.252         TLSv1.2  359    Application Data
643 2018-11-05 07:14:37.189996    34.239.73.252         192.168.1.26          TCP      66     443 ? 35295 [ACK] Seq=1 Ack=5617 Win=853 Len=0 TSval=1755933048 TSecr=76527620
664 2018-11-05 07:14:37.639013    192.168.1.26          34.239.73.252         TLSv1.2  359    Application Data
667 2018-11-05 07:14:37.651914    34.239.73.252         192.168.1.26          TCP      66     443 ? 35295 [ACK] Seq=1 Ack=5910 Win=853 Len=0 TSval=1755933164 TSecr=76527666
700 2018-11-05 07:14:38.212046    192.168.1.26          34.239.73.252         TLSv1.2  408    Application Data
701 2018-11-05 07:14:38.225508    34.239.73.252         192.168.1.26          TCP      66     443 ? 35295 [ACK] Seq=1 Ack=6252 Win=853 Len=0 TSval=1755933307 TSecr=76527724
728 2018-11-05 07:14:38.665109    192.168.1.26          34.239.73.252         TLSv1.2  359    Application Data
729 2018-11-05 07:14:38.679403    34.239.73.252         192.168.1.26          TCP      66     443 ? 35295 [ACK] Seq=1 Ack=6545 Win=853 Len=0 TSval=1755933421 TSecr=76527769
741 2018-11-05 07:14:38.760714    192.168.1.26          255.255.255.255       UDP      105    9999 ? 9999 Len=63
742 2018-11-05 07:14:38.760718    192.168.1.26          255.255.255.255       UDP      105    9999 ? 9999 Len=63
780 2018-11-05 07:14:39.141136    192.168.1.26          34.239.73.252         TLSv1.2  359    Application Data
781 2018-11-05 07:14:39.154641    34.239.73.252         192.168.1.26          TCP      66     443 ? 35295 [ACK] Seq=1 Ack=6838 Win=853 Len=0 TSval=1755933539 TSecr=76527817
848 2018-11-05 07:14:39.760557    192.168.1.26          34.239.73.252         TLSv1.2  359    Application Data
849 2018-11-05 07:14:39.773874    34.239.73.252         192.168.1.26          TCP      66     443 ? 35295 [ACK] Seq=1 Ack=7131 Win=853 Len=0 TSval=1755933694 TSecr=76527878

Notice that we get 2 udp broadcasts to port 9999 every 2 seconds.
I don’t know what those are, but they seem identical. I wonder if both are needed.


#6

The websocket data is all json and includes all the devices and everything. The uplink is (I assume) just raw sensor readings that are processed by the server.

I’m guessing the useful device data is all calculated server side so a local connection would only be good for the instantaneous power usage

Is it better to leave the webpage open and continuously retrieve data or close it and load it up every time I want it?


#7

I’m jumping in here with little background on what you are doing with the websocket and json processing on your side. From a strict Performance Analyst point of view - it is better to run a Headless Web app that can go to sleep for an interval and then reuse the connections that you already spent resources to create.

Then you can re-poll for the updated information without needing to start and stop any new sessions. Unless of course your ‘sleep’ period is long. 1 per second or every 2 seconds - should still get you good data on the back in IMHO.

I’ll look over this thread and enbickar to see what I missed since i recently joined this discussion board.