While creating more and more trigg’s extending my home automation ruling, the trigg’s become more critical. This raises the question/need for them to operate when my home is ‘off the grid’ (temporarily no internet connection). For example the trigg’s controlling stuff for the sun blinds(wind/rain), etc.
Any ideas or roadmap?
Maybe a separate hardware device and/or (offline)app for caching/syncing trigg’s…
Hi Floriszz
I am happy to hear you are using Triggi and for more and more things.
I understand your question, and the question is not new to us. We have had (internal) debates on how we could address the issue you are raising, and some of the debates have been intense 
We do have a few answers, but unfortunately we don’t have the solution right away.
First of all our “smart-ass” response: if Internet fails, what do you do at home? You can’t watch television, run spotify, watch YouTube, run Netflix, do mails or check Facebook. So likely, when this happens, you have more on your mind than just Triggi. If this happens occasionally, it’s no problem, and if it happens a lot, wouldn’t the solution be to get a better Internet connection?
But seriously …
We interface in many (most) cases through an API of a product manufacturer that is in the cloud. So if we would run Triggi locally on – say – a RaspberryPi, and your Internet is down, this wouldn’t help, we couldn’t access the cloud API’s, and the cloud API’s in turn couldn’t access your devices. And then, for some conditions to work, you would depend on connectivity as well (geofencing, weather). So it is likely that running Triggi locally in your house does not solve it all.
The direction in which most devices and services develop, is towards the cloud. Take Amazon Echo (“Alexa”), “she” lives in the cloud. Voice analysis is done in the cloud. And if Alexa decides you want to turn on Philips Hue after you have spoken to her, the command goes back to your home. So a solution like this, also depends on having a working Internet connection. And we sense that most developments head that way. Although Sonos is the counter-argument, we cannot reach it through a cloud-API.
So to really address the problem, we would need to build local APIs to your devices, so we can control them directly, without a cloud and without an API via Internet. This is a bit of a task to develop and, especially, to maintain, because there simply is not a single standard. It could be done, but it would double our work, to develop different API connections towards local API’s as well. And for some systems (like Eneco’s Toon), there is no local API, it’s just via the cloud. For a number of very good reasons that I understand, but that’s a different topic.
On the other side, cloud APIs tend to standardize towards OAuth2 and REST-type of interfaces.
Then we would need to run the rules locally, for instance by providing you with software that can run on a RapsberryPi or on a NAS (e.g. Synology). Or sell you a device that can do it. But then we are going to have rules that still depend on triggers / events or information about state from “the outside”. And what do we do if only half of the trigg can work? If a trigg includes conditions partially from your home and partially from the outside? And how would we recover, and re-sync state. We have been thinking about this, and concluded that it is awefully complex to have parts of the “context” of your account run in the cloud, and part somewhere else. The solution could then be to run everything locally in your home on a device. Which then brings us on: taking care of software updates, security and find secure ways to connect your phone(s) to the local (offline) Triggi instance.
And then, for the one account we would use a local rule execution engine, for the other (without hardware at home) we would do it centrally. For both, we would have different architectures, with centrally different pieces of technology than we would run on a Rpi. We would need to decide (per account) and then maybe “move” triggs from our cloud to a local device, meanwhile preserve accurate state.
So it is really really complex, far from trivial to address.
And these only are our technical considerations.
The other question to address would be: for how many people would we do this? Sure, we have had the question a few times, but a centralized solution scales way way better, allowing us to serve many users.
For people wanting to make an effort and with the skills to set things up and maintain them, there are a few open source initiatives around. For example: OpenHAB (www.openHAB.org). And if you would like to integrate a couple of things that Triggi can do that OpenHAB can’t do, you could setup integration yourself with Triggi Connect (www.triggi.com/connect).
So where does this take us? We are sympathetic to the question, but we can’t say: “Yes”. We are sometimes thinking about making a Rpi software package or so that can do things and easily integrate. Or maybe create an OpenHAB integration. But then other activities take priority over this. So maybe someday one day we’ll have a hobby project in our company to go and do this, but I really cannot make this promise. Sorry.
I know this is not the solution to your problem, but I hope you understand our reasoning.
Arjen
Founder