Could this be only affecting some clients? I have a tablet that keeps popping up: “There was a problem talking to the Sense service” but the app on my phone and the web app seems to be working correctly.
Are there any viable alternatives to Sense that have a published/supported API? I started off with a CurrentCost back in the day, then moved to Sense. looking for new alternatives…
-jason
Now that IFTTT is moving to a paid subscription model for more than 3 applets, I feel like this needs to be a higher priority.
1 Like
I would also like to see an officially supported API. However, there is one alternative path for Sense. It is true that a user can only have 3 custom made applets unless they are going to pay for IFTTT Pro. However, a user can utilize as many applets as they want that have been published by a manufacturer. So, Sense would need to write and publish a wide range of IFTTT applets to meet the needs of the Sense community.
I am not a fan of IFTTT’s transition to a subscription service and have tried to push several manufacturers of products I own to publish APIs so there is an alternative to IFTTT. Unfortunately, I haven’t met with much success.
I believe Sense, and other smart home product manufacturers, need to step up one way or another to meet users’ needs. Either publish an API or greatly expand their IFTTT applets so users aren’t forced to pay a fee to leverage the data and functionality of the products they own. My $.01
1 Like
I would honestly be happy with a local hub web socket that I could connect to via something like NodeRed to listen for updates and then act upon them. I could then update my home automation system. I realize there is the web based web socket integration out there but again something local that doesn’t constrain my ability to connect my mobile app to Sense.
3 Likes
i agree with some local access, as this future proof’s sense and the ability to get basic data out of the device incase the company goes under at least we could still get basic numbers out of it and it wouldn’t be trash
2 Likes
Would love an official API so I could use Sense easilt with Hubitat
4 Likes
Also throwing my hat into the ring for an official API. Some way to programmatically fetch usage data would be wonderful!
4 Likes
I’m surprised that an API would be much effort. Assuming Sense followed any semblance of modern software development, there is an API for the mobile/web apps to talk to the cloud, and for the meter to push data to the cloud.
1 Like
From my experience doing product management for an industrial API as part of my job, people tend to greatly underestimate the amount of effort that goes into an “existing” API to make it “Official”. Specifically, they seem to neglect or downplay the long term costs related to productization (full docs, testing of a broader set of use models), support (questions, bugs, etc.), plus compatibility (what happens when the underlying products require the API). The last one gets especially dicey when people build stuff on top and never expect to have to go back and tweak their code. And that’s for a nice clean existing modern API.
ps: I also notice that some people here are asking for a very different “local” API
pss: I have used the informal Sense API and find it quite useful fro certain tasks, though it doesn’t give access to the time history of devices, just the current readings. So my usage is limited. But I have seen a fair number of people on this forum that have successfully used it for home automation integration.
Official APIs are expensive. You’re going to lose at least one developer, full-time, to get current internal APIs in a shape where you can unleash a random person on it.
Then you have to maintain it. You can’t iterate as quickly without that same random person having problems if you want to change the API. You have to maintain backwards compatibility, even if the internal architecture doesn’t match that API anymore.
I think Sense is too early in their business to obtain true value from an official public API. Sure, I would love it, but I would rather have that developer working on better detection, or a better trigger system, or anything that is a feature they currently market. “Our solution isn’t great, but we have an API so you can do it yourself!” isn’t a great tagline.
I work on software professionally and we use modern techniques. Our internal APIs are good, but deadlines inflict paper-cuts in every feature. Maybe one endpoint doesn’t have full authorization. Maybe another expects very specific input and explodes on anything out of the ordinary. These add up. They’re fixable, but it’s going to cost serious effort to go back, identify these issues, fix these issues, and then provide suitable documentation and a versioning agreement for public users.
1 Like
An API is required for any 3P (third party) to integrate into Sense. The current IFTTT integration has outbound signals when something happens – but I want Sense to be smarter on what devices are on. I’m now on fridge 6, unnamed heat 5, unnamed motor 16, Microwave 3.
I have a power consuming home theater that I have no idea how much it consumes since there is no way for me to identify the different components and group them.
SmartHome customer solutions are going to include integration with a wide variety of equipment. A smart fridge can easily push out on/off signals to a metering device. Having the smart fridge monitoring its own power to be integrated is much more expensive and challenging.
If Sense were to have APIs to signal when a device/scene goes on and off, then it would do much better at recognizing those devices/scenes. As I know from my own experience with ML, ground truthing is hard – an API so others could share ground truth signals could accelerate building device profiles.
Ideally, the API would be somewhat standardized – as a smart dishwasher is unlikely going to write code specific for Sense.
FWIW: I have pretty extensive experience in startups, product management, and engineering. I was the founder of ActiveState, was on the board of Flickr when it took off because of the APIs, editor of OAuth 2.0, and was a Principal Engineer at AWS and Alexa. I have a pretty good sense on what it takes to support APIs at scale, and do ML.
Appreciate your experiences ! A couple thoughts:
- I would love to hear more specifics on the cost side of the equation for the APIs you related. The one I managed cost about 2 person-years to move from internal only to productization, plus 1/2 person-year thereafter for support and maintenance (changes in the underlying API to maintain compatibility, consistent functionality).
- There are already several forms of ground truth integration into Sense, the smartplug / DCM interfaces and the Ecobee Historic integration. Plus some industrious folks have already leveraged the Kasa “interface” to link to home automation. Probably worth exploring since you seem really interested in that type of integration.
You might check out some of the REST endpoints like /timeline if you really want to see that info 
1 Like
The unofficial API works pretty well. If you’re looking to do something at home, you could just use that. There are a couple libraries that interact with it
2 Likes
+1 for an official API. Even if it was just a subset of the simpler API endpoints, it would still be useful.
While you’re at it - it’d be swell to have a RESTful endpoint to get snapshots of realtime data w/o having to hook into websockets.
Have you tried the informal API ?
Or the Postman collection that leverages the API ?
1 Like
Yes - and big props to the developer(s)/maintainer(s) of that informal API. I’m using it and it’s well done. But it’d be more ideal if Sense hosted an official API and allowed users to provision API keys to simplify authentication.
3 Likes
I was thinking about making a small display that would stream my current consumption to an LED display. Will the informal API do that? I ran a quick test of it but only seemed to be able to get 1 update per authentication.
It’s been a little while since I’ve poked around here, but I thought I’d revisit my old project of building out Grafana dashboards with my Sense data collector. I rebuilt everything from scratch to make it completely dynamic and shareable. My poor Sense monitor hasn’t found anything else in the last few years, but I did start playing with some new Kasa smart plugs that had me curious again on how my Sense was doing. I’d love any feedback or any potential testers if anyone is interested.
Also - pertaining to this thread - yeah - sooooo many questions about the structure of and details of the JSON files. If you have a smart plug, there’s a measurement in the ".payload.devices[].sd.e" message that I have no idea what it’s for.
6 Likes