Open source community created dashboard solution Open-Dash.com - Alpha Version in Testing

I’d definitely love to help!

1 Like

Wow, the response to this has been overwhelming. I’ve heard from a lot of community devs and designers and others who want to be a part of this open source project.

I’ll wait a few days to give everyone a chance to get a hold of me somehow and let me know if and how you want to be a part of this great project.

We will have our first “kick off” group session late next week and start working on all aspects of the project. Keep submitting your ideas, use cases, concepts, code references, etc.

I am really excited to help facilitate this great open project and am humbled by how many of you want to be a part of this.

Competition, transparency and openness are the driving principles that steer great projects. When the best ideas, concepts, designs are presented and the code is able to be publicly reviewed, improved and most importantly be trusted and secure, then we can have the best open source community created dashboard solution.

I’ve wanted to do this project since I got started with SmartThings years ago, but it is clear to me now is the time to make this project a reality. I look forward to what this great team will be able to produce.

2 Likes

Great stuff @pstuart! I love the focus on community involvement. Aside from the value of brainstorming in general, I think it’s also a great way to ensure you’re building something that real people actually want.

So anyway, I’m a Javascript/Node.js developer and I work in open source for a living. I’d be happy to contribute in any way that I can. However, I feel like I should mention that I’ve been using ST for a couple years now with a fairly long list of devices and I’ve always felt like building a dashboard that will support any possible ST device is a somewhat complicated endeavor since you have to write the SmartApp code that handles any external requests. I’m a strong front/back-end Javascript developer and I can write an app on top of an HTTP API in no time, but having to deal with the ST-specific Groovy/SmartApp stuff has always been a bit of a turnoff for me. I’ve always wished there could just be a REST API for this exact use case so anybody that knows how to write a web app in any language/framework could easily integrate with ST without all of that manual overhead. Having to write a custom SmartApp to handle requests has always felt fairly tedious to me. And not having websockets, etc. for the stream of events that happen means polling is the only option to have a “realtime” UI (which is surely assumed/expected in the context of an IoT dashboard).

On that note, I recently revisited Wink’s site and was looking at their API docs…

http://docs.winkapiv2.apiary.io/

Their HTTP API doesn’t appear to cover everything (looks like mostly GET requests), but that’s totally what I’m talking about. It’s a uniform way to query devices and listen for changes. I could build a dashboard on top of something like that in no time. I realize that offering an API like that is not a trivial amount of work for ST at this point, but HTTP is the language of the web and I think that’s an extremely important feature for a company that is trying to appeal to developers or any tech-forward customers. Having an HTTP interface would really open things up to a huge list of integrations that already use those standards.

So… maybe that’s what we could focus on to help push things forward? Aside from building a dashboard that we’d all love to use, maybe we could also create a SmartApp that implements a universal HTTP API that allows anyone to interface with ST without needing to know how things are implemented on the other end. I’m thinking endpoints that do things like…

# List all devices
GET /devices

# List all devices of type <device_type>
GET /devices/<device_type>/

# get the details/state of a device
GET /devices/<device_type>/<id>

# update the state of a device
POST /devices/<device_type>/<id>
# { "state": "on" } (or whatever)

Etc…

Or am I totally missing things that are already available? Am I overcomplicating this? Do solutions like this already exist? Other thoughts?

2 Likes

So you are correct, SmartThings lacks an API, so any interaction with a 3rd party (ie, our dashboard concepts) will need some sort of API created via a SmartApp. Thankfully there are quite a few examples out there that can do this already for us (and they are already open source).

Here’s one good example of how @jody.albritton tackled this for the community as a POC https://github.com/jodyalbritton/apismartapp/blob/master/endpoint.groovy

We can build off this, modify it or start from scratch.

Once we have a solid SmartApp API, we need to figure out how to connect the Installed SmartApp for the user to the dashboard solution.

This is where it can get difficult. Currently SmartThings allows the rendering of HTML to an API endpoint, essentially making the SmartApp its own webserver. This isn’t an ideal solution, due to the limiting factor being if/when SmartThings closes this hole.

So, other options are to feed the data out via a tokenized oauth workflow, to a 3rd party and allow the dashboards and other configuration, files, etc be served from there.

Then comes the video above that apparently “hosts” all the files somehow and serves up the html inside the dashboard solution concept. So if we build everything based on HTML we should be able to do mobile first dashboard solutions that are hosted externally getting data to/from ST via our API, and then potentially pivot towards the built in “dashboard” solution if/when its available.

So, we will need to polish up the API, create some sort of user layer interaction to link to a 3rd party server (self hosted, or shared hosted) and then create the front end and back end resources for managing dashboards and serving up the content, UI/UX, etc.

We will need to split focus on the following areas (not inclusive):
-UI/UX and Design elements
-Javascript objects to ingest our API and interact with our API
-API creation
-User management, both master user and guest user accounts
-Security and Audit team
-Database
-Platform

This isn’t a trivial task to do correctly, but I trust we have all the right resources here in this great community to pull something like this off.

This is exactly the problem I was trying to solve with the SmartApp that Patrick linked to in the above post.

I am working on a bootstrap node app and a short tutorial. There is a meteor example app in the github repo, but it’s out of date from the api smart app.

I’ve also dabbled in creating a generic REST API for my private projects. Personally, I’d prefer exposing all documented (and possibly even some undocumented) ST capabilities via the API. Since it’s an open-source project, any attempt to artificially restrict access to certain features would simply lead to proliferation of clones that circumvent those restrictions. It’s best in my opinion to do it in a managed way.

Specifically, the API should provide access to:

  • Devices: ID, name, type, state, capabilities, attributes, commands, etc.
  • Routines: list, invoke
  • Modes, list, set, get current
  • Location: name, latitude, longitude, etc.
  • SHM status
  • Events

The app can also expose added-value services via the API, such as push notifications and SMS notifications.

Yeah. We may need to have split APIs. One that we can get published and in the marketplace for our dashboard and another with “community / advanced” features to expose some of the more hidden features.

Something we can discuss further with ST as we move closer.

I’m in, but I’m useless for programming. I can beta test and troubleshoot all day long.

My only request, as I run my own servers/domains, would be to have the ability to run local regardless of the community driven infrastructure if possible.

I’m not sure how flexible the ST hub is in local execution other than the few things I run (Insteon/Influxdb logging) but based on that it seems pretty plausible the API you guys would make would easily support REST/json stuff to a local network server right?

I’d feel much more secure actually in knowing I could selectively allow ONLY my known devices into my firewall to the backend server, vs the entire cloud mess. Better yet, a simple https landing page with simple cert authentication, throw a cert on my devices, webpage validates it to my internal CA…done.

Would this use the fancy new HTML rendering ST was talking about? You mention it may go away is why I ask. I missed all the developer stuff on that lately I think. Too much to follow on this forum…

Running completely local is impossible on this platform. However there are some tricks we can do. Essentially if you run the dashboard on an internal box it will have to make external calls to the smart things api but no devices have to be exposed. Does that make sense?

3 Likes

The API would be provided by a SmartApp running in the cloud via HTTPS and standard OAuth authentication token mandated by SmartThings platform. The app should be highly configurable to allow user to grant access to devices and other features (e.g. Routines, modes, location, notification, etc.) explicitly. That’s a fairly easy part, imo.

2 Likes

That makes perfect sense and sounds like a good compromise with what’s available.

Should create a slack channel.

Can always resurrect hadashboard as as starting point.

3 Likes

Right off the bat I’d say you need multiple user support as well. Even though that can probably come in down the road after all the quirks are worked out, having the ability to have a “public dashboard” for say the living room and a “kids dashboard” so they can’t blast the Sonos or disarm the alarm by mistake is a must.

I like the idea of integration as well, although hopefully the learning curve to get things setup will be easier than something like OpenHAB or some of the other solutions out there.

1 Like

Multi user support AND unique multi device support. So I can have a shared tablet (device) allowed to certain dashboards with no explicit user attached. Then our individual devices that are allowed on a device and individual user restriction. If that makes sense.

This can be easily accomplished by installing multiple instances on the app or possibly using child apps. Just enable what you want in each instance.

1 Like

Excited to see what comes of this :slight_smile:

3 Likes

Lets get a dashboard up and running first.

I already see issues with mutli-user and multi device support. Unless we want this to run on a real webserver (raspberrypi) there will be limitations.

@pstuart do you envision this running purely on ST platform (minus pulling in libraries through javascript and css)

1 Like

Also, please let me know how I can help from my side :slight_smile:

3 Likes

Personally, I see this running on a hosted or self hosted web server, internal or external. Something lightweight, open and ideally secure first.

I don’t like the idea of hosting all files in ST, to much in one basket. I think the SmartApp side is just to provide the API and link up to the oauth2 workflow for getting / renewing a token. Think of how alexa or other 3rd party integrations work. You chose the devices you want to be a part of it, and then from the server side we do all the magic :slight_smile:

If we build this like how the video above is suggestion “solutions” might be implemented, whatever we “self host” could be modified easily to be run inside the ST dashboard area, if/when that is ever made public.

So its the best of both worlds, lightweight, HTML, CSS, image resources, JS objects for interaction, templates for UI/UX and a backend storage and authentication for linking users to auth tokens / smartapp configs.

The goal is to keep as much off ST as possible and shift the load to something that can scale with the individual user demands. Self hosted means sky is the limit (what you can afford) shared hosted means we could be limited, but in the end, I don’t see it being a huge burden if done right. And I know we have the resources here that can help build that out.

1 Like

Thanks @slagle we will keep you in the loop. Biggest hurdles are going to be making sure we are developing something that can be fast tracked to the marketplace and we maintain the standards ST is looking for in SmartApp development and 3rd party integrations.

Also, any idea when the video HTML stuff above from April’s SDC will be public? Or maybe we can get a jumpstart on it with this team that is coming together to build a “solution” from the community perspective?

1 Like