Anyone have a JSON based smartapp then can share?

I want to write a smart app to interface with my PV Solar Array

They have a nice json based api. But I have no idea how to write a json smart app.

I don’t see any examples in the ide Template code.

Can anyone share full code for a simple json smart app ?

1 Like

For full disclosure: I haven’t done any serious Cloud/LAN/JSON device or app development, but I’m very interested in giving it a try, and I have some idea of what’s going on … especially for the Philips Hue Bridge, on my LAN for example – that may be a good example Device and SmartApp.

The best choice of examples depends on your use case. – Are you treating the Solar Array as a new Device Type (which you then can attach various SmartApps to)?

The starting point, I think, is the Documentation on Cloud & Lan Connected Development
http://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/index.html

Then, the example that I think might get you somewhere is “Life 360 User”, though … I’m not sure – maybe Hue is better, or Alfred, or … ?

  • The local LAN stuff needs a discovery process (but an internet cloud service does not).
  • To use a cloud service, though, you might need to handle the authorization OAuth key exchange or save the key as a preference. Seems easier than LAN discovery, actually.

Hope that’s a start…
…CP / Terry.

I agree with this, specifically the parts about Cloud-Connected devices.

For SmartApps, another example you could look at would be the Dropcam (Connect) app. Specifically the places that do an httpGet call. You can see there how to make calls with query parameters, and how to handle the response coming back (look for resp.data). For the most part, you can treat JSON as just another Map object. If the response is JSON, like it looks it will be in your case, you can just treat the values as a big Map and do things like resp.data.current_power.

I hope that helps

2 Likes

OK thanks Guys. I will give these suggestions a try.

1 Like

Ron,

I have had a look through the [e]enphase documentation for their API and have some experience in writing all pieces of what is needed to bring this to “life” What I have not determined is whether or not each user will have to register with enphase to gain access uniquely to the API…

For this to be “useful” in ST (other than for informational purposes) we will need to create a service-handler App that will collect the user information, communicate with their API, and create the child devices needed as “things” to do something with data. From a first glance it seems to me like there are about 3 different child device-types that should be created to mirror their API data available. First, One that provides data about all the systems - seems like this is a useful set of information that would be collected from all systems and populated into a device-type with a series of useful data points… Second (and probably the most useful) the individual “system” based on id from enphase, and 3rd (and maybe the least integrated from a ST standpoint) the Envoy, based on envoy_id… Each of these child-devices will communicate with the API via the service-manger SmartApp to the enphase API…

I can see how the “systems” could have energy metering and an on/off switch capability and the envoys could have the on/off capability… What other capabilities are you thinking about for the device type?

I am not sure what ON/OFF would do. You can’t shut off/turn on the PV system via envoy. You have to do so physically using a breaker

I am not really sure how useful this would be as a smart device. One thought I had was that you could use it to turn devices on when solar energy production is high. Depending on your local power companies strategy for charging for power from the grid relative to put on the grid by your system this could be very useful. In Hawaii it will not be so useful at this time because the power company currently gives you equal value fro what to deliver to the grid and what you use. This may be changing. They want to change the model to one where you get paid 50% of the cost of a kilowatt hour for what to give to the grid vs what you take off the grid being charge at full cost.

This means it is better to run devices during the energy generation hours and if energy production is low due to clouds etc you may want to reduce the devices you are running.

So I see this as a sensor. Reporting energy production levels. Then I can have a smart app that says when energy production is low shut off water heater, AC Unit, etc. When energy production is high turn these devices on.

Mostly I wanted to see if I could write the device interface and learn from it :smile:

My understanding of the API is I can have 10 hits/min 10,000 hits per month as a customer.
So I think every user would have to create their own account.
If this was a profitable device type you could purchase the higher usage plans and let everyone use the same account. So providing a third party service interface could use this model.
Here are the detail of the plans.

2 Likes

Ron- Wanted to see if you ever got anywhere with your Enphase Smart App - My system goes live today, and I’d love to be able to monitor it’s output from SmartThings!
EDIT - Never mind, found your SmartApp. Thanks for contributing!~!!

@bryanphaas
Actually you want this one if you want enphase.

Ron-

Trying to install this smartApp, but getting the following errors:
No signature of method: script14388879633801335942706.metadata() is applicable for argument types: (script14388879633801335942706$_run_closure2) values: [script14388879633801335942706$_run_closure2@208c35c8] Possible solutions: getMetadata(), getState(), setState(java.lang.Object), metaClass(groovy.lang.Closure)

Any ideas?

@bryanphaas That looks like it is a device type not a smartApp try adding it that way instead.

1 Like

Andy - Thanks - That was it!

If you want to send JSON to a cloud service, I am using GroveStreams.com cloud which is free. If you want some idea how it works, contact me. You then can pull data from the cloud service.