I really like the freq history and the individual channel logging of watts and volts.
Agree for this simple use case. It’s quite powerful and I use it for many things like downloading backups of my HA hub, logging data and querying data in my local MySQL database. Eventually it will integrate my Sense devices with my HA system once I find time to set this up.
Looking at the monitor overview data, there’s a field called local_api_enabled which is set to false. Is there a way to enable that so we can grab power data when the internet goes out?
2 Likes
Personally I would love an API for home automation uses, which is one of the things Sense sorta advertises as a benefit of the product. I currently use IFTTT, but it’s so unreliable. I have a Hubitat, which I also linked to IFTTT and for automations, I create a virtual switch matching the device in Sense.
So for example, I have a virtual switch for my washer. Using IFTTT, if the washer turns on, it turns the virtual switch on. When the washer turns off, it turns the virtual switch off. Inside Hubitat, I setup a simple rule so that if the switch has been off for 10 minutes, it sends both me and my wife a notification on our phones. I do this for the dishwasher and the dryer as well.
But… we started a load of laundry 30 minutes ago. I got the notification from Sense that the washer has turned on. I checked in Hubitat, and the virtual switch was still off. I waited 15 minutes and checked again. Still off. I checked the rule in IFTTT and it says it last ran yesterday.
It would be so amazing to directly integrate Sense into my Hubitat.
1 Like
I have been using IFTTT for years and found it to be very reliable. The problem you may be having is that Hubitat will not propagate the status of a device when a command sets it to the state it is already in. In other words if you have IFTTT turning on a virtual switch you won’t get any notification if the switch is already on. So the first time your applet runs it turns on the virtual switch and it will never work after that.
There is a preference on a virtual switch called “Enable auto off” Setting this to 1 second will automatically turn the switch back off 1 second after it is turned on. In this way subsequent triggers to your IFTTT applet will always result in you getting notified when your virtual switch turns on.
Hope this helps
Well, I was ready to leave sense because I just out grew the data it was providing to me… I needed/wanted more detail, and to view it in different views, I wanted to share some info publicly, i wanted to use multiple Sense devices within one single pane of glass management/reporting/dashboard, i wanted more exact to the penny readings, I wanted an actual usable value for “powered by solar” based on the window i select (hour, day, week, month, bill etc), or at least a documented API so I can get this advanced info on my own!? and sense doesn’t do any of this! I found a few other meters out there that did more but not all, but I DO like sense hardware, wish they had more developers actively interacting on the forums, but i like sense as a company right now.
I’m a splunk enterprise user so being able to get this stuff in splunk and do all of the things i mentioned above on my own would be easy and a WIN for sense, if only they shared their API (sense there is nothing top secret in your data, its your processing that holds your secret sauce) but they do not have a public API. So after reading through multiple very helpful forum posts particularly this one:
I was able to use the undocumented sense API (which they don’t support, or approve of us using evidently) to pull 5 second data into my own splunk server. Now all of my previous “feature requests” can be done on my own!:
Just doing some testing and starting to build dashboards in splunk… I’m excited to be able to stay with sense… Please sense peeps, quit hording your api… lol.
2 Likes
@pir8radio, congrat on discovering then informal API. I wouldn’t say Sense is “hoading” since variants of it are published on Github, plus they have invested in improvements together with some of the individuals who have open-sourced. Wondering what here in the community would have pointed you to the API sooner ?
api documentation on the website would have, or a sense ran sticky thread with the documentation for the API would have lead me to it quicker… vs the reverse engineered api that people figured out on their own. I assumed none of these informal API’s are supported by sense meaning it can change, or go away all together at any time. Thats not a public API which is what i was looking for, still am.
2 Likes
Thanks for the guidance on how to better steer people to the API. As a former software marketing guy, I would take issue with your notion of “public API”. Any API that is public and available for usage is a public API. You are steering for “commercially supported API”, which typically implies company supplied documentation, steady enhancement as the underlying primary product is improved, formal licensing that allows derivative works and your ownership of derivative works, plus ongoing support.
But even a “commercially supported API” typically has no guarantees, beyond what’s in the software and support license agreement, on continuity and limited changes. A good example is Nest’s disappearing API, and switch to Google integration. And there is continued deprecation of old API elements even in the most successful and expensive APIs. Pretty much the only thing that guaranties an API will have continuity and consistently managed backward compatibility is a separate revenue stream for the API.
No, I think im looking for a normal “public api” 
it appears this api sense has was just discovered and exposed by sense users by reverse engineering… I’m just looking for a public API that sense tells you what values you can pull, and what they mean. I would be happy with that… This “public API” seems limited to what users have discovered and documented on their own. I mean sense uses this “api” for all of their apps, surly all of the API variables are not just in some guys head. A new hire working on a sense project would have to read/search through documentation so they know the capabilities, we are looking for the same info/documentation. Nothing that costs sense, no extra work, no licensing.
If they post it, they will be expected to support it. Support means costs. Sure it may be written down, but being written down for internal use and for public use are very different beasts.
They have already had to make adjustments to the API and ask people to modify their usage because people discovered it and have been polling their system in ways they didn’t expect which had unintended and negative consequences. Some of this was more the web socket connections, but the point stands. You can search the forums. It has been discussed ad nauseum, including I think some official response from Sense.
When the product was first released, it did not support calculating usage costs. In August of 2017 they started testing a basic cost function. They released that feature to production in September of 2017. Since then, they are probably 1 or 2 posts a week about how everyone thinks the cost calculations should be modified. How it should work. How it shouldn’t work. That feature which maybe was 20-40 hours of development time has probably cost them hundreds of hours in support having to explain it. Support it. Fix it etc… One little idea of a “simple” feature has spawned into hundreds of angry or frustrated posts on these forums. What is going to happen if they release a supported API? Anyone who suggests “all they have to do is document it and we’ll take the rest” is kidding themselves. Like anything else, it will just be a tech version of “If you give a mouse a cookie”
The # 1 priority of any company is to support the product that they have gone out to build. Sense developed a piece of hardware and supporting software. It functions in the way that they want it to. When they see fit, they add features. Based on this forum, they certainly ask for feedback from their customers and have implemented a lot of them when they feel they can support it. This is what makes them a great company in that they are interacting with their community. But we also need to remember that this community is only 4100 people strong and I would imagine a small sample of their overall customers. Out of that 4100, only 343 have been active in the last month. Not exactly a huge sample of the actual needs of their customer. They have to think about all the customers. Adding a “Public” API will absolutely incur costs. Software Dev time to fix bugs that they didn’t know about because they don’t use the API in the ways that new users will try. Customer Service time for the CS reps to field tickets regarding the API. Data ingress/egress costs for the added calls on their systems. Probably not substantial to begin with, but its money. A basic AWS API host is $3.50 per million requests.
I guess this is my really long way of saying, there are always costs. It is always easy for someone to say “this is how simple this would be” or “all you need to do is X” but saying it is different from doing it. Sense may release a Public or Commercially supported API some day. They may not. Thats up to them when they weigh the benefits and costs of such a tool or feature.
4 Likes
“They have already had to make adjustments to the API and ask people to modify their usage because people discovered it and have been polling their system in ways they didn’t expect which had unintended and negative consequences.”
- My point exactly, documentation would have prevented this. We are just grasping at whatever we can all willy-nilly with no guidance.
“That feature which maybe was 20-40 hours of development time has probably cost them hundreds of hours in support having to explain it. Support it. Fix it etc… One little idea of a “simple” feature has spawned into hundreds of angry or frustrated posts on these forums. What is going to happen if they release a supported API? Anyone who suggests “all they have to do is document it and we’ll take the rest” is kidding themselves”
-
Another good point, providing an API with documentation (thus not having to explain) and stating that you don’t “support” it from a technical support perspective, use the forums, offloads sense developers from having to deal with these odd feature requests, and complaints, because we can take on the simple features ourselves since we are using the API data, it moves the responsibility to us.
“The # 1 priority of any company is to support the product that they have gone out to build. Sense developed a piece of hardware” -
Exactly my point, great job on the hardware, let us deal with the data and massage it in our software.
“When they see fit, they add features.”
- Will bury a company that thinks customers want to be dictated what they can and can not do with what they paid for. That’s just now how things work these days, 10-20 years ago yea… now people expect more, and expect to get what they want… Its kind of like the jobs these days, we used to do whatever the boss says, “its my job I have to do it”, now the mentality is “what can you do for me boss?” and good people move on if they are not treated well.
I appreciate the feedback, I’m not trying to be a a$$. 
but there are a hundered other home energy monitor companies out there, and most of them are quite honestly as good/better than sense. All sense has going for it is nice hardware, and the device identification (which sucks right now) sense needs LOTS of users to make that better. How do you get more customers pulled over from these other energy monitors? Hang a carrot in front of them, and an API can do that… With API data that removes any “feature” limitations that may be keeping them away. Now that I can use the API (in a limited manor) I’m going to buy another unit just for my two solar arrays and combine that info in splunk… I was going to switch over to https://iotawatt.com/ to do this. If you work for sense, I strongly suggest you don’t get into that mindset of “we know best what the customer needs/wants” you will bury yourself. This type of hardware/service isn’t like a fashion tech device (iPhone) where its “cool” to have and they can then run with that “we know best” attitude.
I don’t mean to upset you guys, again I DO like the sense hardware great engineering there. I appreciate the feedback and banter. Not trolling or anything like that, just speaking to the group, in hopes that sense absorbs something from it.
I’m going to tone it down a bit… lol I know how these conversations can go off rail, and turn bad… So I will not replay to any further posts unless you have specific questions for me. I don’t want to stir up emotions, and derail the original post…
2 Likes
You aren’t upsetting me and I don’t work for Sense. Your point is well taken that this is really a reverse engineered API that is tacitly and indirectly supported by Sense (they have done a couple things to support the users who put it up on GitHub). I put this in the same category as the TP-Link API which is a proprietary supported API for a limited set of developers (like Sense), but has also been reverse engineered and is published on GitHub. One example here:
On the flip side, I have been on the software marketing and project management side, and many of the things you suggest are no cost, are really quite expensive (docs, support, R&D time to support that intern, backward compatibility), and you also miss one of the biggest costs, opportunity cost. Every investment in time in something other than the core product, is time taken away from the next important thing to be added to the core product. For your usage model, maybe the API is a core feature, but not likely for the mass market.
Bottom line - As a Sense enthusiast, I’m glad you have found enough capability in the informal API to keep you going. And as a guy who wants everyone in this community to succeed, I support your request, and have also “liked” the original wishlist entry. The only heartburn I have comes from my previous life on the SW side, where customers treated what they believe to be their “simple” requests as “nearly free”. It’s never “nearly free” and whatever it is, it always requires more support than that customer can imagine.
3 Likes
Some progress on my personal dashboard using the sense API, allows me to combine multiple sense sensors and what not. I’m not done with this dashboard, i need to throw the second solar array values on here and add my own version of “% powered by solar” But this dashboard took me less than a day to whip up… SENSE Employees, I would suggest if you do support an API that you change your device firmware to allow us direct access to its data, so we do not need to eat up your server bandwidth… Right now this stream of data is going from my home to your servers, then from your servers back to my database… I’m all for still having a stream go to your servers to help improve the AI, but the ability for us to poll the device directly saving you half of your bandwidth would be cool.
8 Likes
I like the local data access concept…
1 Like
Very cool dashboard! Nicely done.
1 Like
couldn’t have done it without you 
My method for pulling data through the Websocket seems to have stopped working this morning at 5:45am (central). Now I just get an error:
websocat: WebSocketError: TLS failure
Tried a newer version of websocat - no dice. Certainly know this was of fetching data is unsupported - just curious if anybody else had run into something similar?
edit: using a -k to turn off checking of SSL certificate worked. Seems like maybe there’s an issue with the cert?
Thanks!
_DS
I saw an issue authenticating with Postman (certificate error) this morning as well. Worked last night.
Yeah, it might be the Sectigo/Comodo root cert that expired. You’ll have to disable SSL checking until they update it.