Personal home automation, when well done, it facilitates our daily life with its features and its efficiency especially when we are at home, but it is even more useful when you are away from home.
La possibilityin fact, to act on more domestic features what climate, security, thelumination and other while not physically finding ourselves in the environment rappit is a great value: let's imagine the possibility of automatically turning on the heating or the heatingnamewhen tenants approach geographicallyappelement, or to check the status of the anti-intrusion system (including video images taken in real time), etc. This possibility is called "remote control"
To do this, some technical aspects must be unmarked a priori.
The domotic components on the market are typically linked ad appspecific licenses provided by producers, which (for example the IHC for Broadlink, or eWeLink for Sonoff) are used first of all for the first configuration of the devices, then for their ordinary control.
In the vast majority these app they also offer a cloud service which basically acts as a "bridge" between it final management tool in which theapp and the component to be controlled: when you are away from home, our smartphone "dialogues" via the Internet with the cloud which, in turn, automatically communicates with the component placed at home (connected with the home modem / router), and vice versa .
This allows even inexperienced users to remotely control devices without excessive technical expertise.
Obviously - otherwise we would not write - this approccio has three specific disadvantages:
- security and availability of the service are delegated (also) to third parties;
- each component needs aapp specific;
- it is not possible to control functions that involve multiple components of different proproducers.
When and if the cloud doesn't work, then the service does not work accordingly. If the personal account associated with the cloud service comes compromesso (internamente or esternameto the supplier company), malicious people could have access to the components associated with the service. We are not talking about the inconvenience of having more applicenses for several different services, or the inability to use features that involve components of prodifferent drivers.
If the choice was made (blessed) to base the profirst home automation on HUB personal, mostly it is possible to abandon the approoverwritten to connect no longer to individual members but to the profirst home automation agreement as a single control platform, an bridge from which to manage all. This allows you to bypass one or more third-party clouds and connect directly with home proman through theapp dedicated toHUB in use and / or browser.
To succeed in this, however, it is necessary to carry out some operational steps.
Basic steps (in principle)
1) INTERNET NAME
Every modem connected to the Internet owns un profirst IP address, which uniquely identifies it on WAN network which is the Internet. Mostly (except for some specific cases, typically regulated by specific requests from the user) this IP tends to change over time, therefore it is not sufficient to know this IP for point la proman app dell 'HUB at home automation proere.
To overcome this first "inconvenience" it is necessary to use a free service from Dynamic DNS, which allows you to associate an internet name (eg. "casamia.duckdns.org") to the propri IP WAN which, as it varies, is updated dynamically. This allows us to point al internet name instead ofIP, name that is then (automatically) "converted" into IP (the updated one that rappresenta casa), which finally allows us to point to the correct address.
One of the best known Dynamic DNS services is DuckDNS.
At this point we have arrived at the doors of the home modem and we would like to enter.
To do this, however, we must know the "port”On which to enter. And how a street address, which is composed of one road it's a House number. For now we know the way (the internet name above) but we do not yet have the civic, so to speak, to go to.
La port is related to the service that we want to consult. If in a hypothetical "Via delle Vigne" of our city we had at the 3 number the Fire Brigade, the 5 the Police, at the 10 a pub and we wanted to go to it, the complete address would obviously be "Via delle Vigne 10" .
Bene: the port, as mentioned, is related to the service, and therefore to the configuration of ours HUB personal.
The doors vary based onHUB in use (default configurations):
- Home Assistant: 8123;
- openHAB: 8080 or 8443;
- Domoticz: 8080 or 443.
So, if the propria domotica was hypothetically based on Home Assistant heappresent from the internet name "casamia.duckdns.org", The complete address to point to (via app or browser) would be: "casamia.duckdns.org:8123”
3) PORT FORWARDING
If we have already implemented a HUB personal, we will certainly have attributed to the computer (host) that hosts it an IP (LAN) fixed. At this point it is necessary to configure the modem / router for any request procoming from outside (from the WAN Internet) addressed to the door of our interest be "turned" towards the IP (LAN) of thehost which houses thepersonale HUB, obviously on the same door.
Remaining in the wake of the previous example, let us assume that the external address of the house is "casamia.duckdns.org:8123"While the internal LAN is"192.168.1.50:8123"
We will therefore go to the configuration page of our modem / router and we will search for the item “port forwarding", Creating a rule that indicates as an external door"8123"And how it leads e host iterni "8123" and "192.168.1.50". This activity varies from modem to modem, therefore we recommend reading of this guide to understand, in broad terms, how to adapt this action to proprio. Nb This is a mandatory configuration.
Still remaining in the example, it will now be possible to remotely connect to the profirst personal home automation (via app and / or browser) by connecting to the URL:
The potential, last proremaining problem is rappresented by the prefix "http", Which identifies a connection unsafe. This connection could allow frappbears between you and home automation - with various techniques - and therefore abuse the service you and you alone should be able to use.
To remedy this proproblem is necessary to ensure that the proprio HUB uses, for connections, un prosafe tocol that uses encryption techniques to make traffic to and from it understandable alone to yours application / browser.
For Home Assistant we have drafted an ad hoc guide which explains how to implement this prosecurity protocol. Also for openHAB and Domoticz there are (online) similar guides.
Once the security activity is completed, the URL will change, replacing “http"With"https". In some cases, even the port destination may change (eg openHAB pass by 8080 a 8443).
A small addendum dedicated to users Apple it is rightful.
Where these users do not use a personale HUB (As Home Assistant, openHAB or Domoticz) but use theapp "Home" offered by Appthe iOS and compatible HomeKit components (and / or Homebridge), to connect remotely:
- they must not define any internet name;
- they do not need to define any port forwarding rule;
- they do not need to configure any prosafe tocol;
- must own (and maintain sedentary at home) at least one iPad, one AppTVs or a HomePod.
This is because personal home automation based on HomeKit, by design, necessarily includes to use the cloud Apple as a bridge and a device (among those mentioned above) in the domestic environment as an "actuator".
There are no alternatives - if not to adopt un personale HUB.
|ATTENZIONE: remember the existence of our community FORUM for any doubt, question, information on the specific merit of the contents of this page and much more.|