LoRa è potente proprio perché è limitata. Quando forzi quei limiti, diventa la scelta sbagliata.

NON usare LoRa quando serve tempo reale

• Audio
• Voce
• Streaming
• Chat “tipo WhatsApp”

Motivo tecnico: latenza + duty cycle.
LoRa è pensata per eventi, non per conversazioni.

NON usare LoRa quando servono molti dati

• Log continui
• Telemetria ad alta frequenza
• Immagini
• Video
• File

Motivo tecnico: payload minimo + airtime lungo.
Più parli → più rompi la rete.

NON usare LoRa se i nodi sono in movimento continuo

• Veicoli in città
• Tracking in tempo reale
• Oggetti che cambiano spesso gateway

Motivo tecnico: handover assente o rudimentale.
LoRa non è nata per la mobilità rapida.

NON usare LoRa se vuoi affidabilità garantita al 100%

• Sistemi safety-critical
• Comandi che devono arrivare
• Attuatori immediati

Motivo tecnico: best effort.
LoRa privilegia l’autonomia, non la certezza.

NON usare LoRa se sei dipendente da Internet/IP

• API continue
• Backend cloud obbligatorio
• Architetture microservizi

Motivo tecnico: LoRa non è IP nativa.
Ogni bridge aggiunge fragilità.

NON usare LoRa se puoi usare radio classica

• Squadre sul campo
• Emergenze operative
• Coordinamento umano

Motivo tecnico:
per le persone → voce
per le macchine → LoRa

Confondere i due è un errore concettuale.

NON usare LoRa se stai inseguendo la moda

• “È IoT quindi va bene”
• “Così è più moderno”
• “Lo usano tutti”

Motivo reale:
LoRa non perdona i progetti mal pensati.

La regola d’oro

Usa LoRa solo se:

• il messaggio è breve
• l’evento è raro
• il nodo deve durare anni
• la rete deve esistere anche senza Internet
• puoi accettare che qualche pacchetto vada perso

Se anche una sola di queste condizioni non è vera → guarda altrove.

Sintesi brutale

LoRa non è:

• una rete dati
• una rete voce
• una rete veloce
• una rete “always on”

LoRa è:

una rete che resta in piedi quando tutto il resto cade

Ed è per questo che va usata solo quando serve davvero.