Dev Journal: November 6th 2018
This will be less exciting than my language journals, and that is impressive :)
Well, whether or not it is exciting isn't really the point, and probably depends more on your interests. But, how exciting it is, isn't the point.
I'm planning on starting a new application (or potentially a suite of applications) centered around Smart Home devices.
My problems are many. None of them are insurmountable at present. But, likewise, none of them actually need to exist.
The first step is to solidify what I want to accomplish into some sort of a plan. As you can see above, I'm not even sure whether I'm looking at one app, or at a series of applications. It will definitely start as one app. And, I want it to be something that I could at least monetize in part down the road. I'd like to spend more time on this sort of thing.
Anyway, the current problems in smart homes (for me at least) stem from a few widespread problems. There is a lack of consolidation and a lack of continued investment from the companies owning these products. Most of them support some level of integration or developer APIs though. And that means, with a bit of work, it is possible to make solutions even smarter than what is already out there.
For my first application, I want a local server application to consolidate as many devices as possible. I also want that application to have a web front end which can display and control either from a house view, or an individual room view. I want the service to store data (locally only) and use that data for analytics. It should be able to provide some rudimentary graphs from this data. Everything should be modular and event driven, leveraging an MQ technology of some sort.
Basically, what I'm looking to make is something similar to MagicMirror or openHab. And, I could probably make what I want work within the confines of either of those. But, I feel like there are key aspects of my plans that go against their fundamental designs and I don't want to keep running up against walls I need to code my way around.
Firstly, MagicMirror has a lot of smart home modules, but isn't even really meant to do any of this. It is simply such a well done project that it can enable these kinds of interactions. openHab on the other hand, kind of IS meant to be this SORT of thing. But, it falls flat in a few areas. The biggest short comings are that the UI doesn't break things up between rooms or spaces in a house, the modules aren't meant to talk to each other, and the nature of much of the project is such that many of the integrations require the user to setup developer accounts and fictitious products to make the APIs work. In this respect, the open source nature of the project kind of works against them. Though, it kind of doesn't as well, I guess.
As such, there WILL be some sort of closed source aspect to my project. I'd like to get my Nest integration published. This would enable a regular user to just authenticate with those services rather than forcing users to sign up dev accounts and jump through hoops. A simple OAuth screen to link the app to an account is what really should happen.
So, that kind of irons out requirement #1 for me. I want the application to not require anything beyond basic authentication with external services.
The next thing is, most smart home apps act simply as proxies for the functionality in the APIs. They do the same sorts of things as the 1st party apps, and usually do even less than that. Many smart devices can be a lot more powerful even using just the supplied APIs. Usually, this brings some benefit like rolling multiple solutions into a single hub app. But, that isn't really all that exciting.
What really got the ball rolling for me was my Nest Temperature Sensor. The Nest APIs allow me to build an application which can read humidity, outdoor temperature, indoor temperature and also set the temperature (among other things). If they expand the API to allow me to query the temp sensors as well, I could add in support for min/max logic and write an app which can choose based on household conditions which sensor to follow, rather than sticking to hardcoded schedules.
But, why stop there? Since I can read this data, I can write it off to disk. And I can graph that data. And that can give me a better idea of how my house, and individual rooms are cooling and heating relative to outdoor and indoor temperatures.
Another point of contention is IFTTT. Or rather, that no one integrates anything like this locally. Every module in the system should itself be comprised of modular components and UI should be separate from calls that retrieve data. This would allow any other module to opt into listening for changes in another part of the smart home. And, even better, everything one of those components does should exposed as a building block to make user driven flows. Basically, every action should be intercept-able and triggerable.
When the heat turns on, if I have an integration with smart vents or smart curtains... shouldn't a truly smart solution be able to say, "oh look, the heat turned on because the spare room is 2 degrees cooler than the rest of the house, but the house itself is fine, so, let's close the vents in the other rooms, and because it is a sunny day, let's open the curtains in the guest room".
The next major point of contention is privacy and granularity of control. I only want one server. But, I want multiple rooms to be able to interact with that server. Most rooms only need access to smart devices in those rooms. Not the whole house, probably not all the smart cameras either, and maybe not even the thermostat.
And, maybe if guests are in there it should show the WiFi password or household instructions.
To avoid screen burn-in it should probably be able to switch into some sort of digital picture frame, or move elements around on occasion.
Basically, these last couple of points are things neither openHab nor MagicMirror can do without substantial modification/work. Nor, as I suggested before, were they really meant to do those.
From this, I can draw up a list of basic requirements:
- Server side application, serves up web pages.
- Some sort of admin UI (doesn't need to be a web page)
- Individual URLs for different views/groupings (rooms, etc...)
- Standardized interfaces for UI components, actions
- Pub/Sub model using an MQ for work.
- On demand, and scheduled events.
Since talk of things like Nest integration means things like API keys and secret keys and the likes, a compiled application is preferred since it will need to contain non-open source elements to obfuscate those values.
I'm thinking .Net Core perhaps as the technology stack. A bit of a shame because I had also kind of liked the idea of NodeJS. But, with .Net Core I containerize the whole thing, which would be cool.
For things like Nest and Weather API's I'll probably also add configurations to allow users to point at their own if they already have those.
But, if I want to charge for the app, or even part of the app, then I probably want to go with Windows Store or Android apps. But then, I don't know if those would allow me to serve up web pages to other devices on the network.
There may be architectural compromises required. Basically, as far as apps go, what I'd like to deliver is a free product the option to buy modules for more advanced functionality.
The free stuff would basically be combining the stuff that most solutions do today into a single app with control for some limited number of rooms/groups.
Paid access would enable things like unlimited rooms and the extra smarts like improving upon the base offerings and inter-module communications.
Oh well, I guess round 1 is just build "something" which does the things I want. And then plan review licenses and platforms to see what I can pull off later.
Well, whether or not it is exciting isn't really the point, and probably depends more on your interests. But, how exciting it is, isn't the point.
I'm planning on starting a new application (or potentially a suite of applications) centered around Smart Home devices.
My problems are many. None of them are insurmountable at present. But, likewise, none of them actually need to exist.
The first step is to solidify what I want to accomplish into some sort of a plan. As you can see above, I'm not even sure whether I'm looking at one app, or at a series of applications. It will definitely start as one app. And, I want it to be something that I could at least monetize in part down the road. I'd like to spend more time on this sort of thing.
Anyway, the current problems in smart homes (for me at least) stem from a few widespread problems. There is a lack of consolidation and a lack of continued investment from the companies owning these products. Most of them support some level of integration or developer APIs though. And that means, with a bit of work, it is possible to make solutions even smarter than what is already out there.
For my first application, I want a local server application to consolidate as many devices as possible. I also want that application to have a web front end which can display and control either from a house view, or an individual room view. I want the service to store data (locally only) and use that data for analytics. It should be able to provide some rudimentary graphs from this data. Everything should be modular and event driven, leveraging an MQ technology of some sort.
Basically, what I'm looking to make is something similar to MagicMirror or openHab. And, I could probably make what I want work within the confines of either of those. But, I feel like there are key aspects of my plans that go against their fundamental designs and I don't want to keep running up against walls I need to code my way around.
Firstly, MagicMirror has a lot of smart home modules, but isn't even really meant to do any of this. It is simply such a well done project that it can enable these kinds of interactions. openHab on the other hand, kind of IS meant to be this SORT of thing. But, it falls flat in a few areas. The biggest short comings are that the UI doesn't break things up between rooms or spaces in a house, the modules aren't meant to talk to each other, and the nature of much of the project is such that many of the integrations require the user to setup developer accounts and fictitious products to make the APIs work. In this respect, the open source nature of the project kind of works against them. Though, it kind of doesn't as well, I guess.
As such, there WILL be some sort of closed source aspect to my project. I'd like to get my Nest integration published. This would enable a regular user to just authenticate with those services rather than forcing users to sign up dev accounts and jump through hoops. A simple OAuth screen to link the app to an account is what really should happen.
So, that kind of irons out requirement #1 for me. I want the application to not require anything beyond basic authentication with external services.
The next thing is, most smart home apps act simply as proxies for the functionality in the APIs. They do the same sorts of things as the 1st party apps, and usually do even less than that. Many smart devices can be a lot more powerful even using just the supplied APIs. Usually, this brings some benefit like rolling multiple solutions into a single hub app. But, that isn't really all that exciting.
What really got the ball rolling for me was my Nest Temperature Sensor. The Nest APIs allow me to build an application which can read humidity, outdoor temperature, indoor temperature and also set the temperature (among other things). If they expand the API to allow me to query the temp sensors as well, I could add in support for min/max logic and write an app which can choose based on household conditions which sensor to follow, rather than sticking to hardcoded schedules.
But, why stop there? Since I can read this data, I can write it off to disk. And I can graph that data. And that can give me a better idea of how my house, and individual rooms are cooling and heating relative to outdoor and indoor temperatures.
Another point of contention is IFTTT. Or rather, that no one integrates anything like this locally. Every module in the system should itself be comprised of modular components and UI should be separate from calls that retrieve data. This would allow any other module to opt into listening for changes in another part of the smart home. And, even better, everything one of those components does should exposed as a building block to make user driven flows. Basically, every action should be intercept-able and triggerable.
When the heat turns on, if I have an integration with smart vents or smart curtains... shouldn't a truly smart solution be able to say, "oh look, the heat turned on because the spare room is 2 degrees cooler than the rest of the house, but the house itself is fine, so, let's close the vents in the other rooms, and because it is a sunny day, let's open the curtains in the guest room".
The next major point of contention is privacy and granularity of control. I only want one server. But, I want multiple rooms to be able to interact with that server. Most rooms only need access to smart devices in those rooms. Not the whole house, probably not all the smart cameras either, and maybe not even the thermostat.
And, maybe if guests are in there it should show the WiFi password or household instructions.
To avoid screen burn-in it should probably be able to switch into some sort of digital picture frame, or move elements around on occasion.
Basically, these last couple of points are things neither openHab nor MagicMirror can do without substantial modification/work. Nor, as I suggested before, were they really meant to do those.
From this, I can draw up a list of basic requirements:
- Server side application, serves up web pages.
- Some sort of admin UI (doesn't need to be a web page)
- Individual URLs for different views/groupings (rooms, etc...)
- Standardized interfaces for UI components, actions
- Pub/Sub model using an MQ for work.
- On demand, and scheduled events.
Since talk of things like Nest integration means things like API keys and secret keys and the likes, a compiled application is preferred since it will need to contain non-open source elements to obfuscate those values.
I'm thinking .Net Core perhaps as the technology stack. A bit of a shame because I had also kind of liked the idea of NodeJS. But, with .Net Core I containerize the whole thing, which would be cool.
For things like Nest and Weather API's I'll probably also add configurations to allow users to point at their own if they already have those.
But, if I want to charge for the app, or even part of the app, then I probably want to go with Windows Store or Android apps. But then, I don't know if those would allow me to serve up web pages to other devices on the network.
There may be architectural compromises required. Basically, as far as apps go, what I'd like to deliver is a free product the option to buy modules for more advanced functionality.
The free stuff would basically be combining the stuff that most solutions do today into a single app with control for some limited number of rooms/groups.
Paid access would enable things like unlimited rooms and the extra smarts like improving upon the base offerings and inter-module communications.
Oh well, I guess round 1 is just build "something" which does the things I want. And then plan review licenses and platforms to see what I can pull off later.
Comments
Post a Comment