It would be nice to have a REST API access so that we may combine it with other systems.
Some examples where an API can come into play:
Sprinklers may be automated to water a lawn when it is dry. This could happen at odd hours and maybe even when the home owner is away. A custom home automation system may tell Streamlabs to go into home mode right before turning the water on to the lawn and then go back to away mode when it has shut the water off.
Water level of a pool can be monitored with sensors. If enough water evaporates the pool can be set to fill. This again can be at an unexpected time, completely normal and would flag as a leak if it turned on while in away mode.
Being able to create our own reports and store our own data on water usage over time.
Using several different sensors to detect if someone is home or not and then maybe create our own alerts.
By having a open API we can create our own uses for this product and share the knowledge with all
We're excited to announce the launch of our API Beta program! Head on over to our new Streamlabs API forum to join the discussion and learn more about what the API entails.
Thank you all for your valuable feedback and ideas! The discussion in this thread was key in the development of our API program, and we are very excited to provide it for you!Comment actions
I have a feeling a public API going to be a pain for them to release since they are using the AWS Security Token Service and the request will cost them over a long period of time if the customer tries to poll this after 60 seconds. I guess it back to the drawing board unless there a local interface page I can scrap for details. Really love the product and it a great idea but the lack of an API sucks :(
-H ' Host: api.streamlabs.io'
-H 'accept: application/json'
-H 'content-type: application/json'
-H 'x-amz-security-token: '
-H 'accept-language: en-us'
-H 'x-amz-date: 20180407T041809Z'
-H 'utc-offset: -7'
-H 'user-agent: aws-sdk-iOS/2.6.1 iOS/11.2.6 en_US'
-H 'authorization: AWS4-HMAC-SHA256 Credential=, SignedHeaders=accept;content-type;host;user-agent;utc-offset;x-amz-date;x-amz-security-token, Signature=' --compressed 'https://api.streamlabs.io/v1/locations/$$$$$/trends'
Oy. Really, An API, or other ways to integrate this is so obviously needed. The fact that it wasn't part of their plan is troublesome.
How about start with something really simple... Send read-only stuff like consumption/flow rate every minute over udp to a local IP address. Requires no authentication. Expose more data, and maybe let us set home/away with websockets and a very simple auth like a key. Again. fine for local use. Then IFTTT and finally a real public REST API. But do something.
I'm really interested in an open REST API too !
I want to integrate it to :
- Home Assistant for better automation / alerting (MQTT integration would be great too in addition of the REST API)
- InfluxDB + Grafana for good graphing
If the API is local (ie. hosted on the device as we can find on many home bridges) it would be better for privacy, product life cycle, performances.
IoT is all about BIG Data and then combining, mashing that data to drive smart (even AI) automations... using your phone to control stuff is not smart... is is just another remote control....
Break down the "walled gardens" give users access to their data....
...give me an API and I will start selling these as part of the (Global) Telco I work for's IoT product offering for which I am the product owner...
+1 on the free API. I agree charging for services provided by Streamlabs that require the use of the API, such as downloading data is fair but if the end user has the wherewithal to access the API and manipulate the data without the services of StreamLabs that should remain free. A good example of allowing users to access the API for development is Samsung SmartThings. That practice has propelled that user base into the millions because of the huge amount of 3rd party development and support of that platform because of the free an open API.
In today's environment a closed ecosystem is doomed to fail. The Lowe's Iris platform is just one recent example.
Thank you for your feedback. We plan to adjust our subscription details based on customer feedback and I have passed your concerns along to our team. Please let me know if you have any additional questions or concerns and feel free to reach out to us at email@example.com.
I agree that a paid subscription for advanced API use is justifiable for 'commercial' users (like landlords with multiple monitors) but there is enormous potential for sales to Smartthings users if there could be direct integration to simply set Home/Away (both ways - ST->SL and SL->ST) and have the Monitor throw a wet alert to ST so ST could close a valve. ST users do not require usage data (advanced API) just read/set Monitor status Home/Away/Wet/Dry. SmartLabs would benefit from increased sales to Smartthings users which would easily offset the lack of subscription fee income (these types of subscription-based business models have mostly failed in the past).
Please sign in to leave a comment.