Best practices: indirizzi IP ed entità con Home Assistant

HassioHelp

Best practices: indirizzi IP ed entità con Home Assistant

best practice

 

Argomento: Configurazioni
Livello: Esperto (Novizio,Esperto, Pro)
Difficoltà: Bassa (Bassa, Media, Alta)

Introduzione

L’articolo presenta quelle che sono definite in gergo IT (Information Technology), ma non solo, delle “best practices” ovvero delle regole testate sul campo che permettono di ottenere ottimi risultati in un determinato ambito; di seguito andremo a vedere due best practice: la prima relativa a come assegnare in maniera ordinata e coerente gl indirizzi IP dei dispositivi presenti nella propia LAN domestica e la seconda per dare alle entità configurate in Home Assistant quella che si chiama una “naming convention” ovvero una regola semplice da seguire quando si assegnano i nomi alle entità di Home Assistant.

Il prerequisito fondamentale per la lettura dell’articolo è una conoscenza di base dei concetti di LAN/VLAN, indirizzo IP e degli apparati più comuni come router, switch, Access Point (AP), non fatevi spaventare da termini tecnici che appaiono nelle regole più complesse, la maggior parte degli utenti non ha bisogno di tali configurazioni ma sono inserite per completezza dell’articolo.

IP Addressing

Questo è un argomento che non è certo una novità ma vediamo di dare qualche informazione utile per permettere a tutti di assegnare in maniera ragionata gli indirizzi IP ai dispositivi presenti nella propria rete.

Indirizzamento IP privato

La classica RFC 1918 pubblicata nel lontano 1996 dall’ Internet Assigned Numbers Authority (IANA) ha riservato tre reti di indirizzi  IPv4 come privati. Questi indirizzi IP sono riservati alle organizzazioni (siintendono anche i privati) per costruire un’infrastruttura di rete interna basata su TCP / IP, non sono indirizzi “pubblici e conosciuti” su Internet e quindi questo significa che ogni organizzazione può utilizzare per la propria rete IP interna queste classi di indirizzamento, senza timore di conflitti con altre.

Nel caso che un’organizazzione abbia la necessità di collegare ad Internet la propria rete locale che utilizza le reti definite in RFC 1918 si deve ricorrere al Network Address Translation (NAT) che mappa indirizzi IP privati con indirizzi IP pubblici, visibile ed instradabili su Internet.

Aggiungo una piccola nota che riguarda l’impossibilità, per utenti che usano a casa collegamenti di tipo mobile o di alcuni provider, dell’accesso diretto al proprio server Home Assistant tipicamente tramite Duckdns o altri servizi di Dynamic DNS: in questo caso si parla di Carrier-grade NAT (CGN o CGNAT), ovvero di un ulteriore lilvello di NAT configurato dal provider del servizio Internet  (RFC 6598). I modi per superare questa modalità si basano tutti sullo sfruttare un servizio esterno che faccia da “ponte”.

Le reti private, incluse nell’RFC 1918, sono le seguenti, ho inserito solo per completezza alcuni dettagli tecnici relative alle classi di indirizzamento:

  • 10.0.0.0 – 10.255.255.255 (10.0.0.0/8), una singola classe A
  • 172.16.0.0 – 172.31.255.255 (172.16.0.0/12) con a disposizione 16 classi B
  • 192.168.0.0 – 192.168.255.255 (192.168.0.0/16), con a disposizione 256 classi C

Anche in ambito domestico valgono le considerazioni generali sopra esposte, ci limiteremo a considerare per gli esempi la rete 192.168.1.0/24 che  mette a dispozione 254 indirizzi IP da 192.168.1.1 a 192.168.1.254 (192.168.1.0 è l’indirizzo che caratterizza la rete e 192.168.1.255 è il cosiddetto indirizzo di broadcast).

Assegnazione degli indirizzi

Di seguito proponiamo tre possibili regole in ordine crescente di complessità da seguire per dare ordine alle decine di dispositivi che popolano la propria rete di casa:

  • Livello BASE, adatto alla grande maggioranza degli utenti;
  • Livello INTERMEDIO, per chi ha esigenze un po’ più avanzate;
  • Livello AVANZATO: parliamo di installazioni più complesse, per esempio per ville, appartamenti sviluppati su più piani, con depandances o magari con un ufficio o studio annesso, con decine e decine di dispositivi e/o con esigenze di una separazione netta tra le varie subnet/VLAN.

Singola Subnet, singola VLAN – Livello BASE

Vediamo quindi come assegnare gli indirizzi IP in maniera organica e coerente utilizzando una logica a “insiemi”, usando come rete di esempio 192.168.1.0/24; la regola classica utilizzata nella progettazione è che i server e dispositivi assimilabili abbiano un indirizzo IP “fisso” (statico) inserito nelle “impostazioni di rete” del server stesso, mentre per il mondo PC, tablet, smartphone, l’indirizzo IP sia assegnato tramite DHCP eventualmente effettuando una “DHCP reservation” cioè andando a specificare nelle impostazioni del router l’associazione tra “MAC address e IP address” in modo che il router assegni sempre lo stesso indirizzo IP al dispositivo identificato da quel mac address (il mac address è indirizzo della scheda di rete Ethernet o del modulo WiFi).

  • 192.168.1.1: è l’indirzzo del default gateway della rete, tipicamente il router
  • da 192.168.1.2 a 192.168.1.9: destinati a ad apparati di rete come switch, AP, etc
  • da 192.168.1.10 a 192.168.1.99: riservati per dispositivi su cui configurare un indirizzo IP statico (server, NAS, stampanti etc)
  • da 192.168.1.100 a 192.168.1.254: liberamente assegnati dal DHCP per PC, smartphone, tablet etc

Per i dispositivi domotici (IoT: Internet of Things) la scelta è tra effettuare una configurazione dell’indirizzo IP statico, se il dispositivo lo permette, oppure effettuare la DHCP “reservation” configurando in maniera opportuna il router o la macchina che effettua la funzione di “DHCP server”.

Singola Subnet, singola VLAN – Livello INTERMEDIO

Andiamo a rendere più completa la configurazione BASE inserendo delle specifiche più dettagliate relative ai vari sottoinsiemi di inidirizzi IP.

  • 192.168.1.1: è l’indirizzo del default gateway della rete, tipicamente il router
  • da 192.168.1.2 a 192.168.1.19: destinati a ad apparati di rete come switch, AP, etc
  • da 192.168.1.20 a 192.168.1.49: riservati per videosorveglienza (cam,  NVR, etc),centrale allarme ed altri apparecchi di sicurezza fisica
  • da 192.168.1.50 a 192.168.1.59: riservati per server domestici, NAS e stampanti di rete

Per questa prima parte di configurazione della rete fino all’indirizzo .59 che conviene utilizzare indirizzi IP statici: il motivo è che normalmente sono configurazioni di rete effettuate una volta e difficilmente occorre variarle nel tempo.

Per la parte successiva riservata ai dispositivi IoT, occorre valutare se assegnare ai dispositivi potenzialmente più soggetti a variazioni, mutamenti di vario genere o inseriti in luoghi difficilmente accessibili, l’indirzzo IP attraverso “DHCP reservation”: nell’esempio ipotizziamo di dare indirizzi IP statici per gli attuatori Shelly e Sonoff e per la sensoristica DIY (Do it youself) basata su esp8266/esp32.

Il pool di indirizzi gestiti dal DHCP parte quindi dall’indirizzo IP 192.168.1.150, come descritto di seguito:

  • da 192.168.1.60 a 192.168.1.119: riservati per attuatori IoT come Shelly o Sonoff – IP Statici
  • da 192.168.1.120 a 192.168.1.149: per sensori IoT basati su esp8266 / esp32 o altro – IP Statici
  • da 192.168.1.150 a 192.168.1.254: liberamente assegnati dal DHCP per PC, smartphone, tablet – IP dinamici

Subnet e VLAN multiple – Livello AVANZATO

Vi diamo solo qualche spunto senza entrare nei dettagli di configurazioni complesse da ritagliare sulle esigenze di ognuno, intanto partiamo dicendo subito che anche in installazioni domestiche è possibile avere più reti (subnet IP e VLAN, Virtual Local Area Network) dedicate a scopi diversi, diamo di seguito un esempio che non vuole essere completo (volutamente si tralasciano tutti gli aspetti di ottimizzazione dell’inidirzzamento IP con il “subnetting”):

  • 192.168.1.0/24 di management per apparati di rete come router, switch, AP
  • 192.168.2.0/24 per client, PC, smartphone, tablet etc
  • 192.168.3.0/24 per videosorveglianza e sicurezza
  • 192.168.4.0/24 per dispositivi IoT, sensori, attuatori etc

Una rete così disegnata richiede anche un apparato router in grado di gestire queste configurazioni, quindi configurazioni di VLAN, “router-on-a-stick”, etc; inoltre ricordo che ogni VLAN rappresenta un dominio di broadcast isolato da altre VLAN, questo ha effetto anche su protocolli basati sul multicast il cui traffico non può “uscire” da una VLAN, per fare ciò occorrono specifici protocolli di routing.

Per concludere la parte di IP Addressing invito i più interessati a leggere la documentazione presente sui siti web dei vari costruttori in particolare Cisco che nelle sue best practice e design guide citate anche nella bibliografia è la fonte principale e la base di ispirazione per questo articolo.

Naming Convention

Proviamo a vedere come assegnare in maniera uniforme e coerente i nomi alle entità di Home Assistant così da raggiungere due risutati importanti:

  • configurazioni più agevoli
  • salvataggio dei dati semplificato

Per il primo punto avere le entità costruite con dei nomi che rispettano una regola vuol dire poterle manipolare in maniera facilitata (ad esempio tramite Jinjia), poterle raggruppare ed identificare velocemente, poterle visualizzare in Lovelace minimizzando il codice necessario (ad esempio con la custom card auto-entities).

Per il secondo punto i vantaggi sono ancora superiori: il salvataggio sul DB di HA impostato tramite il componente recorder o su DB esterni come InfluxDB è immediato con poche righe di configurazione YAML che non necessiteranno di molta manutenzione anche aggiungendo ulteriori componenti alla nostra installazione di HA poichè gestibili tramite wildcard (il classico asterisco *).

Altro fattore da considerare nella composizione delle regole è di non esagerare con una lunghezza eccessiva dei nomi delle entità e di non inserire informazioni superflue, in pratica l’applicazione del classico principio KISS (Keep it simple, stupid).

Sensor e binary_sensor

La regola per i nomi che proponiamo è la seguente basata su una tripletta di stringhe separate dal carattere underscore (“_”)

  • sensor.identificativo_area_tipologia
  • binary_sensor.identificativo_area_tipologia

Identificativo: è per l’appunto un identificativo che ci fa immediatamente capire a che entità ci stiamo riferendo, potrebbe essere presa, applique, piantana, hue, porta, finestra, tenda, pir etc, etc

Area: è l’ambiente della casa dove si trova il sensore, potrebbe essere bedroom, salotto, cucina, ingresso, bagno1, bagno2, giardino etc etc

Tipologia: identificano immediatamente che tipo di dato restituisce il sensore, le più comuni tipologie da considerare sono le seguenti, ma nulla vieta di aggiungerne altre.

  • occupancy / contact per indicare l’attivazione di un sensore di movimento o apertura/chiusura di una porta
  • status per identificare le entià che rappresentano uno stato particolare
  • temperature / humidity / pressure per i dati ambientali/atmosferici
  • power /energy per i dati relativi a potenza ed energia consumati
  • voltage / current per tensione e corrente rilevati
  • runtime ad indicare un tempo di attivazione
  • illuminance per i dati di luminosità
  • battery per i sensori che rappresentano la carica di una batteria
  • cost per entità che rappresentano una spesa o un costo
  • linkquality per il Link Quality Indicator (LQI) dei dispositivi Zigbee
  • use per indicare un dato che è una percentuale di utilizzo

Alcuni esempi sono: sensor.thb_sala_temperature (dove THB sta per Temperature, Humidity, Barometer), sensor.lavatrice_rimessa_power, sensor.huelight_bagno1_power etc

Light e switch

Per luci e interruttori di vario genere la regola sopra esposta può diventare più semplice visto che lo scopo di una lampadina è quello di fornire illuminazione, alcuni esempi sono: light.applique_cucina, light.luce_balcone, light.piantana-hue_salotto, switch.presa_ripostiglio. Nulla vieta di continuare ad usare le triplette inserendo informazioni che si reputano interessanti: switch.presa_xiaomi_garage

  • light.identificativo_area
  • switch.identificativo_area
  • light.identificativo_marca_area
  • switch.identificativo_marca_area

Automation e Input

Per questo tipologia di entità è più dififcile trovare una regola base e semplice adatta a tutti, alcuni preferiranno avere dei nomi che descrivano al meglio cosa fa l’automazione, anche se è possibile utilizzare il tag “description” allo scopo, altri preferiranno notazioni più compatte, quello che si può consigliare in generale è di inserire la tipologia di componenti (ad esempio light o alarm), l’area o zona a cui si fa riferimento, se è un paramentro significativo, ed utilizzare alcune parole chiave come “rilevamento”, “controllo”, “apertura”, “chiusura”, che descrivono al meglio lo scopo dell’entità.

Vediamo quindi degli esempi: automation.attivazione_allarme_sala, automation.rilevamento_persone_motion, automation.spegnimento_presa-lavatrice_rimessa, input_select.ac_sala_mode.

Esempo di uso con i template Jinjia

Home Assistant mette a disposizione un potente strumento, i template, che consente di controllare le informazioni in entrata e in uscita dal sistema. I principali usi sono:

  • Formattazione dei messaggi in uscita, ad esempio, nelle piattaforme di notifica e nei componente Alexa e Google.
  • Elaborazione dei dati in entrata da sorgenti che forniscono dati grezzi, come MQTT,  REST o sensori di tipo command_line.
  • Creazione di automazioni complesse.

Per l’ultimo caso avere una “naming convention” standard ci permette di effettuare delle operazioni in maniera standard e ripetibile usando il inguaggio Jinjia2, definito per l’appunto come un “templating language”; vediamo quindi un sempice esempio:

Il codice sopra indicato da usare nella parte  “condition” o “action” di un’automazione ci permette di verificare immediatamente con un template la tipologia di sensore che ha triggerato l’automazione stessa, è importante sottolineare che questo codice è usabile senza modifiche in una qualsiasi automazione con entità che rispettano la regola sui nomi che ci siamo dati.

Vediamo nel dettaglio cosa fa il codice con il sensore binary_sensor.pir_bedroom_occupancy:

  1. Prende l’entity_id che ha triggerato l’automazione, quindi binary_sensor.pir_bedroom_occupancy
  2. identifica solo la parte a destra del punto, quindi pir_bedroom_occupancy grazie all’azione di “split”
  3. identifica solo il terzo elemento della tripletta occupancy sempre con “split”
  4. effettua il confronto e restituisce il valore boolen True

Esempo di configurazione del recorder e integrazione InfluxDB

Vediamo come configurare velocemente il componente recorder (vedi anche l’articolo sul Repack) segeundo una naming convention come quella proposta, tenendo sempre a mente di salvare quello che veramente serve, ricordo infatti che lo stato attuale delle entità è salvato periodicamente dentro la cartea nascosta .storage (feature introdotta in HA 0.84 e migliorata nel tempo).

Per quanto riguarda un estratto di configurazione del componente InfluxDB (vedi anche l’articolo sulla progettazione della conservazione dei dati ):

Esempo di visualizzazione con auto-entities

Con la custom-card auto-entities,facilmente scaricabile da HACS, è possibile visualizzare nell’interfaccia Lovelace molte entità con poche righe di codice:

La configurazione della card è piuttosto semplice: dentro la sezione filter sono incluse le entità che finiscono con “linkquality“(selezionate tramite wildcard, “*_linkquality“), come options è inserita l’informazione secondaria “last-updated” e come ordinamento (sort) delle varie entità nella card si è scelto l’ordinamento alfabetico del friendly_name.

Conclusioni

Come avete visto l’articolo tocca due argomenti poco considerati ma importanti per permettere una gestione migliore e più semplice della propria domotica, ovviamente quanto scritto va personalizzato e modificato in base alle proprie esigenze e gusti: a qualcuno non piacerà il suffiso occupancy, ma preferirà motion, la tripletta potrà diventare una quadrupletta, si potrà mettere in prima posizione l’area invece che l’identificativo, etc, l’importante resta sempre l’obiettivo di sempilficazione e gestibilità.

Ricordo infatti che gli articoli devono essere fonte di sviluppo e riflessione per poter creare le proprie configurazioni e personalizzazioni: quello che va bene per me nella mia infrastruttura non è detto che sia repicabile integralmente per voi nella vostra.

Se avete qualcosa da suggerire ci vediamo nei gruppi Telegram e Facebook.

Alcuni link utili:


Sostienici, dona un caffè al nostro sito

 

Una risposta.

  1. Avatar Antonio ha detto:

    ottimo articolo con spunti interessanti ed utili

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *