I am a windows programmer (c# .net) so I have tech abilities but I am brand new to home automation and have a very high level understanding of Rasbery PI and no knowledge of Pine. Very little unix.
Before I invest a lot of time in figuring how to set up a system I would like to ask if what I want to do is possible and if it is the best way to go. My main reason for getting into this is to monitor a empty house that will be 3000 miles away from me for 6 months this winter in New England so heating will be necessary. I will have someone I can call in an emergency but beyond that I want to be able to monitor temperatures and sump pumps, I would also like to have some internal cameras for keeping a eye inside.
I believe I can buy a bunch of devices to do this individually (thermostat, temperature sensors, water sensors and web cams all cloud based. But if I could tie them together using home control software that would be a big bonus. I am also thinking of adding battery backup for the server to keep it up when the power fails although it is likely if the power fails the internet (cable based) will also be down even though the router will be powered.
Now as you can imagine there’s a gazillion potential solutions how to tackle that, the main problem is to select that one to match your abilities best.
These I don’t know but I’ll try, so in a nutshell:
Install a Raspi with one or better two additional USB sticks and a USB card writer and put it and the router on a small UPS.
Use openHABian for a quick and just-very-little-knowhow-to-use-UNIX-required setup.
Take care to make it a fully remote-capable server install, setup backup and take precaution of disaster recovery ! With 3k miles away, you will be having a very hard time to recover your server when in need.
Keep spare HW ready on location. Pis are infamous for corruption of their SD card, this you need to protect against. Check out this post to change your server setup to NOT write data to SD but to the external USB stick so in case that fails your server won’t. And don’t use “move root to USB” in openHABian.
openHABian has a backup tool called Amanda. The USB stick is also meant to provide storage for backups. Use Amanda to generate a clone of your SD card once you’re done installing, and repeat after significant changes. That’s what the card writer is for so you can clone your server from remote. Should your Pi fail, you can have your remote helping hands person replace the SD card with the clone one (or even the Pi with the spare one if that’s broken). That’s best practice for homes to run your automation on Pis, but even more so if that home is as far away as is yours.
To access your openHAB instance to run there, see here.
You could start using myopenHAB, but that will only give you GUI-level access to openHAB which is ok for monitoring, but it will be insufficient when you need to start diagnosing problems with your house.
I’d setup your router to use a DynDNS like service so it’ll dynamically map a fixed DNS name to its (ever-changing) IP address. You need to make your router forward a couple of ports to your Pi as then you will be able to access the openHAB GUI via browser and the Pi on UNIX shell level using SSH on these ports.
Install NGINX to protect access via GUI (use openHABian there’s an option to auto-setup NGINX).
You should make use of monitoring capabilities built into the bindings you will use for your devices, plus use the generic network binding to ping devices on IP level.
Mid-term you should implement rules using the openHAB rules engine to constantly monitor your devices on application level, auto-diagnose output to the extent possible, and to send alarms if something’s weird or broken. I’m using the telegram binding for that purpose, but there’s many more options.
In addition, as I don’t want to open any ports of my LAN to Internet other than absolutely needed:
The Pi does run an ssh server (per default), so it’s sufficient to open one port to ssh to the Pi.
Setup a Public/Private key to login to the Pi and change settings for the openssh server to prohibit password logins for all users.
Use Putty to login via the dynamic FQDN. It’s possible to save the key to use and the login name, so after unlocking the key (this is done via pageant, part of Putty install) the only thing to do is opening the session, and you are at your Pi 3000 Miles away.
And there is another option in Putty, you can forward local Ports to the remote side. This way it’s possible to forward Port 18080 to openhabianpi:8080 and so on, and as long as the Putty session is open, you can use http://localhost:18080/ to reach the openHAB UIs.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
4
Just to throw in my two pennies
I would advise a more powerful SBC than a Pi.
Especially due to the SD card issue.
I’m told that the Openhasbian solution can be deployed on most Linux OS flavours.
My AVM router allows for a VPN connection and selecting a machine to run OpenHab2 on that has a LAN port that supports Wake-on-lan will mean you can bring the machine back to life if it accidentally gets powered down. (Yes I have forgotten the -r after a poweroff command, or instead of using reboot)
Being a big supporter of Velbus, I’d also recommend installing a completely wired solution, rather than wireless (battery powered sensors etc) especially if sending someone in to change a battery would be an issue.
First, you don’t need any more power than a Pi does provide - period.
Second, SD card behavior clearly does NOT have anything to do with processing power, so don’t mix that into one statement.
And it actually is a big misbelief that any of the other SBCs is any better with respect to corruption.
It’s flash memory to be the reason for that, and SBCs they all use flash memory, be it that they use SDXC or eMMC or USB as the interface.
While of course you could pimp most SBCs to not use any flash, given the OP’s self-assessment and a number of known problems, I’d clearly refrain from trying to take that route.
And of course you can deploy any other server as well, but Pis are the mainstream, i.e. the by far best known and best supported servers. For sure the more you get off-mainstream, the less people will be able to help you with, so in a nutshell: don’t.
Let alone that essentially anything larger than a Pi is just a waste of money, better put that into spare HW.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
6
As Markus said, there are lots of ways to solve this.
This is how I deployed a remove instance of OH to keep an eye on my aging father.
Hardware:
Raspberry Pi 3. In high sight I probably could have gotten away with using a Pi Zero W given it only has one sensor and no Rules.
I did a manual install of openHABian on a stock Raspbian Lite largely because I had some problem with the automated install of openHABian and not the time to figure out if it was something I was doing wrong or a bug.
After that I have a set of Ansible playbooks I run on all my RPis to move /tmp, /var/log, and /var/tmp to a tmpfs file system. I’ll lose all the data in these folders when the RPi reboots but when my system is running along as normal these are the only folders being written to. This mitigates the file system corruption problem on power loss as well as greatly limiting writes to the SD card in general extending its life.
I installed OpenVPN on the RPi and configured it to connect to my OpenVPN server. I’ve also configured my OpenVPN server to assign a static IP address so for all intents and purposes the RPi is on my LAN and I can monitor and administer it as necessary.
I have no Persistence or Rules running on the remote RPi. Instead I have the Zwave binding (connected to the sensor) and MQTT binding configured with the event bus. Since the remote RPi is on my LAN it connects to my internal MQTT broker. In my main OH I configured Items to receive the sensor readings.
Stuff I wish I had done:
Created an image of the working system on a spare SD card that my dad could swap out for in the event that the remote RPi file system does become corrupt for some reason.
Were I to deploy this to a remote and unoccupied building I would add a lot more instrumentation to the device to detect and report failures of individual devices and watchdogs to try to reset the RPi itself when it detects certain problems.
I would plan on not making any modifications to the RPi system unless you are physically present. Maybe updates to Rules and the like would be OK. Definitely don’t make any changes to networking, upgrades, edit sudoers, or anything else that might cause the device to lose power or networking or break your ability to access or operate the device remotely. Especially if the network is not super reliable because if you lose your ssh connection in the middle of editing the sudoers file or an apt-get upgrade you can be left with a non-functional RPi and have to rebuild the SD card.
One thing that I’ve found really helpful at home is to have a way to reset the RPi remotely. But that means having another RPi or something else you can control remotely like a power outlet or the like. But there will be rare circumstances where the risk of killing the power to the RPi, particularly with the mitigations in places described above, is less then the risk of having your RPi down and inaccessible and a restart of the RPi might bring it back.
Really useful thread as it covers a lot of common ground for me. Re the VPN access - I was under the impression that the openHAB cloud was going to give access to the information about the local pi - guess I was wrong about that.
To access the openHAB REST API and web based UIs remotely. This lets you access your sitemaps/HABPanel, PaperUI, and other OH UIs remotely without poking a hole in your firewall. It also will send out OH is Online/Offline alerts to the phone apps should your OH instance fall off the network and let you send your own alerts to the phone apps.
I want to make openHAB setup very simple and plug n play.
Just connect openHABian based RPi with LAN cable (openHAB cloud connector enabled and signed up) and Install Android App.
Ready to go (no need to set the local URL manually, fix static IP of RPi and no need to worry local IP change)
Before implementing, please check whether it is possible or not.
When I connect RPi with LAN, Router (DHCP) will allocate dynamic local IP for RPi.
When RPi connects to Internet then send its local assigned IP to myopenhab.org web server
or call REST API to find local server IP via myopenhab.org
In Android App, I want to fetch local server IP from API call (https://home.myopenhab.org/…)
and fix the IP from parsing JSON instead of set manual local URL.
Now, I didn’t find any API call or method that can provide the server’s local IP.
Please assist here.
After this, if somehow I fetch local server IP then can I do implement what I want?
Is it good approach?
This should be a separate topic. It has nothing to do with Remote Access.
There are already ways to do this using Bonjour/Avahi or GDM or a myriad of other protocols that will allow the Android app to send out a packet to a broadcast address and OH will respond with it’s IP address. If I’m not mistake, this is already implemented in OH and the Android app, though I could be wrong.
Don’t try to implement a solution that requires myopenhab.org to work. That will greatly and needlessly limit who can use it.
You didn’t find any API call because there isn’t one.
Next time, I would post such kind of things in separate topic.
For iOS devices, there is no problem to implement because Apple’s platforms has in-built support for mDNS but for Android devices, when I enter local server address like raspberrypi.local/ then it doesn’t work because chromium/android doesn’t support.
As you said that it is already implemented in OH then could you please guide me more about it?
I would use our own hosted cloud instead of myopenhab.org
I don’t do development on any part of OH so can’t point you anywhere in specific. And if you don’t intend to submit your changes back to the project you can do what ever you want.
But if you want to make this available to the community, I highly recommend implementing an approach that does not require an instance of openHAB Cloud and most especially not a personally hosted openHAB Cloud. Having that as a requirement would bring the user base down to single digit percentages.
mDNS is not the only way to implement network discovery of a service.
