I’m thinking that, too. My websocket connection rarely reconnects once the connection is going and has kept itself running just fine for weeks at a time. It’s only recently I’ve started seeing an impact on the real-time meter if my agent is also running.
1 Like
Really want an API here too! Would be great to use the solar production to know if it’s a cloudy day and adjust internal lighting accordingly
1 Like
wow, what a neat idea. like playing minecraft with your house 
The informal API details helped me head down a decent path to grab some data and hack things together. I’m by no means a developer/coder - but I do like my metrics! I pull the API and segment out details around my overall consumption as well as individual devices. I pull the web-socket for a few seconds and then kill the connection. I really just need a snapshot - wish there was a way to get a single polling of that data than a kill -9 on the script! 
But it does make for some fun graphs:
4 Likes
Any chance you guys could look into what @brbeaird reported above?
The integration with SmartThings he developed goes a long way towards making the data generated by Sense useful and actionable beyond just looking at bubbles. I think it’s a big opportunity for Sense to gain some traction in the established ST HA market without much resource cost if you don’t intend to offer an official API to access our data. Accessing the data using his integration is limiting the functionality of both the Sense mobile app and home.sense.com - which in either case should probably be looked at since it’s something that could potentially affect support in other instances as well. Thanks in advance! 
2 Likes
We have rate limits in place, which might be causing his issues. Otherwise, it could be related to the real-time services issues mentioned in Data Gaps in Timeline/Meter, which we’re still working on. He’s certainly welcome to write into Support and they can advise if it might be related to the RTS data gap issue.
It’s not data gaps (at least in my case) - the data, when it loads, is continuous and complete in the app. It’s just the real-time monitoring from the app that’s slow. The odd part is that it’s the Sense mobile app that’s impacted, I would think it would be the other way around.
Were rate limits changed or added recently, say in the last 1-2 months or so? That’s when the issue cropped up - it hadn’t been a problem before then.
When I’ve dealt with rate limits, those typically come up when working with excessive polling using HTTP requests. In this case, it’s a live websocket connection, so I don’t think it’s polling in the same way.
What seems most likely to me is there was a “concurrent websocket” type limit added a couple months ago that makes it impossible to listen on the websocket in more than 1 instance at a time.
Pardon the delay. Had to reach out to the Eng team. Yes, rate limits were implemented recently as websocket misuse was negatively affecting the app experience of other Sense users. There was some egregious over-polling happening. This rate limit happens in situations that you’re describing @brbeaird, where more than two concurrent clients are connected, as those are the scenarios that hit our systems the hardest.
Note that these are not officially supported means to access Sense data. Ultimately, we need to protect the core experience of the majority of our users. We’re certainly interested in providing deeper access to Sense data in the future — whether through the WS or a full, documented API — but dev resources must be located elsewhere for now.
@RyanAtSense can you share what the rate limit rules are so that those of us polling don’t exceed them?
No doubt - and no complaints from me here. If multiple websocket connections cause strain, that’s definitely understandable.
For future reference, the main things I’m looking for via API are:
- Event hook that a device turned on/off
- Relatively fresh numbers on each device’s current usage
I realize IFTTT was intended to help with the first one, but it’s limited in that you have to manually set up an applet for every single device, which I found to be too tedious. If there were an option to just send ALL events to an IFTTT trigger that I can then sort out myself later, that would work. On a related note, the current websocket connection refreshes far more frequently than necessary to satisfy both of those requirements. One idea might be to put out an additional websocket endpoint that only pushes data once a minute or so.
If you get some developers freed up sometime in the future and need some people to bounce ideas off or test things, feel free to hit me up.
Thanks for looking into it and getting back to us.
2 Likes
I’ve been able to successfully retrieve historical data using the API published here, but I get an error when attempting to stream active data using web sockets.
Invoking update_realtime returns this error: ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1045)
Anyone else having better luck? Is this something with the server API or is it user-error? I’m still hoping to use the active value to control lighting in my home.
Websocket is still working for me over nodeJS, although I’m modifying it to only hold the stream open for one tick of data to lessen the load.
Any tips about what I might be doing wrong would be greatly appreciated! Do I need to have an SSL certificate?
Are you trying to run this behind a firewall? I regularly get SSL verification errors at work because we have a firewall that basically sits in the middle of Internet SSL and client machines. As a workaround, I usually have to disable SSL verification on whatever app I’m using that verifies by default.
Have you guy thought about providing local APIs , at least use some kind of UDP broadcast with consumption and solar production on some port so I can listen to it locally ?
1 Like
First, welcome to the community!
I’ll say that we have lots of ideas of things we’d like to implement, including API related. The perpetual challenge, as it goes with any software/hardware dev project, is resources to devote to it. Building out and continually supporting an API is a significant amount of labor and would benefit (this is purely my impression from working closely with our user community both here and across all of our other social channels) a minority of the userbase. Personally, I’d love it too, but we always need to balance product dev resources. You can read a little bit about how we do that here: Using the Product Wishlist forum
Ryan
I disagree with one thing you said. It is true that a minority of the user base might make use of an API. However, what you are not taking into account is that if Sense created a repository where people who wrote software against the API could post their code, then a large number of people could benefit from it. Just look at the benefit and the volume of users that take advantage of the Apple and Google app stores.
Creating the API enables people to take feature requests off the plate of the developers at Sense. For example, many of the requests for additional graphing of data could be handled by someone using an API. Now the development team is suddenly relieved of the burden of working on those requests and can focus on other things. It becomes a win for everyone.
My $.02
1 Like
You’re certainly correct in that and it’s a strong argument in favor. Still, it requires resources now, regardless of future benefit, and that now plate is very full with some other exciting stuff. I expect we’ll get there in time. In the interim, there’s some unofficial options (check out the Data Analysis subforum) that can get you pretty close.
Thanks Ryan. Reporting was just an example of how people could leverage an API. Another example, would be that people could leverage the API to combine data from multiple Sense monitors and probably take care of 90% of the requests of the people with 400 amp service and multiple sense monitors. They are certainly a very vocal group on the forum.
I understand there are always conflicting priorities; especially in a small company. But if you give people the tools to do things they want themselves, it can reduce the backlog of requests, and allow more to get done.
3 Likes