did you enable OAUTH for the new SmartApp ?
did you enable OAUTH for the new SmartApp ?
No, i forgot.
i had the same issue, till i enabled OAUTH… now all my devices showed up…
Is curb and SmartThings integration available for use? I tried following the github readme but i’m new and cannot figure out how to integrate. I look in the ST smarapp section but do not know where to find curb connect.
in curb there is a link to enter ST credentials, but that’s a bit confusing as well as i can’t tap authorize.
This integration is alive and well. You should be able to install from the instructions at the github page. I highly recommend you take the “Curb Connect” route to integration. The instructions on github are targeted at users who have experience installing 3rd party software into SmartThings. Sounds like this would be your first adventure in that direction, so have a look here for the required background reading.
On your Curb webapp, there is an option to connect to SmartThings, but this “official” integration is completely different from my project. The official integration allows you to control SmartThings devices from the curb website. My integration gets the power usage data from Curb and makes in available in SmartThings.
Does your project allow routines to be created where they turn things off or on?
Nope. This integration just pulls in the data. Doing something smart with the data is up to the other SmartApps you use.
For example, this SmartApp allows you to see how much power your kitchen stove is using. You could then use that data in webCoRE to send you a notification if you leave home and the stove is still on.
ok thanks. Your newbie post helped a lot. I’m halfway there and will get to configure the rest when i’m home.
The integration works well. However, I get the following message since yesterday:
Usage Response Error: Failed with status code 408
It seems that the Curb servers are not handling the http requests the way they should.
Thanks for bringing this to my attention. I’m also getting various error codes (404, 408, 503, 504) back from the Curb API, so I’d guess something changed on their end. I’ll be sure to update here when I figure out what’s going on.
Well I haven’t heard back from the Curb folks and it appears that their cloud services are still (partially) down. I’ve pushed a bandaid to the app which will fall back to a different api endpoint if the primary one is down. It fixes the problem for me. Give it a shot and let me know if you have trouble.
So I’m beginning to think these guys went out of business or just don’t care about their customers. I’ve tried emails/tickets (10/22, 11/9, 11/20), phone support (11/13, 11/20 - call center confirmed my ticket existed in the system), Twitter (11/13) and Facebook (11/13, 11/20). I have had zero response from the company directly since starting to contact them on Oct 22. Their last tweet was 10/20 and their last Facebook message was 10/21. @jh0 also says he hasn’t heard back.
I finally got a call back. Sounds like they have someone new (in the last month or so) trying to catch up with customer care to solve the problem I highlighted. That would seem to indicate they know they had a problem and care to address it. Hopefully that means the API will be fixed soon too. @jh0 she said to try and contact them again to explain whats going on.
I just installed this and determined the net (aka Main) meter isn’t working correctly, because consumption isn’t reporting correctly. Perhaps this is due to the solar setup. However, the result form GetUpdate is below and you can see consumption is only -21, it should actually be about 800W at this very moment, as seen in the Curb web app. I also noticed that docs.energycurb.com isn’t working, and I can’t find API documentation for the web API. Is there perhaps a different API call that will work properly?
Got Latest: [timestamp:1520810033, consumption:-21, locationId:e1309351-2613-48c2-b5a6-a002a07b8d50, net:-2737, production:-2716, circuits:[[id:dec1aeda-a55f-48d8-8989-33c76945c1f4, w:-1360, label:Solar, production:Breaker-side, main:false], [id:14840643-5fa1-4201-9c95-6bc6c87c0a70, w:-8, label:AC, production:false, main:false], [id:2db4ef90-2de2-4bf4-807b-0ccde749cb0e, w:0, label:Car, production:false, main:false], [id:74447d23-4cbc-4f89-9cfb-f1325470ce5f, w:-13, label:Furnace, production:false, main:false], [id:855a6bc9-c276-47b8-b8c8-d75c912a6549, w:-1356, label:Solar, production:Breaker-side, main:false], [id:4ab9ecc2-a0fb-48a4-a64c-c5bf40f7210e, w:0, label:AC, production:false, main:false], [id:f7fc089a-10f5-4b8f-a515-e63da0a5d67a, w:0, label:Car, production:false, main:false]]]
Update: I managed to solve my issue to get the results I wanted by using getUsageFromHistorical rather than the getUsage, and I modfied that function a little bit. I changed the request from 5m/m to 5s/s, and I added a catch for production=true so that I could subtract production from main to get current usage. It seems to work, but will need to double check once solar is producing. I am pretty sure this breaks historical capability in the device handler, but I just turnned off the polling for historical since that’s not really needed. The main purpose here is to get useful info in ActionTiles.
Glad you could figure this out. I’m sure this is related to the fact you have a solar setup. I don’t have solar so haven’t been able to test any of that functionality.
A bit of history that may help you understand the code:
The online docs existed at one point, but the API was changed drastically and those docs were no longer valid (so they were taken down). I worked directly with the folks a Curb to get the preliminary documentation for the new API.
The “official” API includes the /user, /locations, /historical and /aggregate HTTP endpoints, but requires the use of socket.io to access live readings. Since SmartThings doesn’t have socket.io capability, I originally faked the live readings by asking for a short historical window (parsed in processUsageFromHistorical) and taking the latest reading. Later, they added an undocumented /latest HTTP endpoint just for this project (parsed in processUsage). It is a better way to get the live usage, but has some subtle differences in the way it reports the mains (and I’m assuming production as well). I have kept the usage-from-historical functionality around as a fallback, because there have been times where the /latest endpoint fails to respond to requests, but /historical is still up.
It sounds like you’ve figured out the production stuff enough for your own purposes, but I’m definitely open to pull requests for any changes you’ve made that you believe will improve the project, especially for users of the solar functionality.
Justin, thanks for the history. That helps fill in a lot of blanks. Hopefully they get the docs back up online. I sent back my Sense for the Curb because I knew they had an API and I expected it to be more mature than it is.
I will request a fork of your code soon, and add my changes. Right now, only change is to change to process from historical instead of /latest and also changed request to 5s/s instead of 5m/m (I poll every 10 seconds). I’d also like to add a second poll for 2d/d history (if possible, haven’t tried it yet) and show production today and yesterday. This is all for my kitchen mounted ActionTiles setup.
Ok - just did a couple little tests. Looks like Historical reports an average for the timeframe, not a sum. So, 2d/d isn’t useful. However, the aggregate looks like it does sum. However, the aggregate doesn’t report timestamps, so it’s not clear if the 2d/h on the aggregate reports last 48 hours, or since midnight yesterday. I’ll have to experiment a little to see. Looks like if I want total today and total yesterday, I’ll have to subtract the aggregate sum from today from the 2d/h sum.
It looks like the Curb (connect) SmartApp has been down for a couple of days. Something has changed on Curb’s end… I’m looking into it and will post here with any updates. Just wanted to make a note here so people know you aren’t alone!