Quando l’APRS in Puglia sembrava ormai una specialità radioamatoriale dimenticata, sono stato tentato di spegnere il digideater che ho gestito dai primi anni 2000 ( link ) per mancanza di traffico locale.
Ma prima che questa mia intenzione si concretizzasse, ho assistito a una inaspettata rinascita dell’attività, grazie all’entusiasmo dell’amico Luigi IZ0YAY che, tornato a lavorare in Puglia (mi auguro definitivamente), riesce a diventare punto di riferimento per tutti gli appassionati APRS di zona 7 e zona8 che erano momentaneamente in stand-by.
Proprio grazie a questo nuovo gruppo, gli OM interessati hanno iniziato a scambiarsi idee ed entusiasmo, e diversi digipeaters e I-Gate sono sorti nuovamente sul territorio Pugliese, principalmente nelle province di Bari, Brindisi e Taranto.
Durante la fase di test dei digipeater, ma anche dopo la loro stabilizzazione, è capitato spesso di aver comunicato agli altri Sysop del gruppo gli eventuali problemi tecnici che hanno portato il nodo stesso ad essere irraggiungibile. Questo tipo di comunicazione si svolgeva prevalentemente via Wahtsapp, se il Sysop lo riteneva opportuno e aveva il tempo di farlo.
Proprio per mancanza di tempo (risorsa rara!) , talvolta è capitato di perdersi questo tipo di informazioni e anche che fossero gli altri ad avvisare il sysop ignaro di un problema alla sua stazione,.
Dopo uno scambio con Luigi, è nata l’idea di provare ad automatizzare questo processo e cercare di implementare un sistema con questi due principali requisiti:
1) Collezionare informazioni circa lo stato di tutti i digipeaters e I-gate del gruppo e mostrarle in forma intuitiva su una pagina web.
2) Inviare allerte via whatsapp o telegram nel caso in cui una qualsiasi di queste stazioni diventi irraggiungibile o, viceversa, ritorni operativa dopo un’anomalia.
Ho iniziato a cimentarmi e a pensare a come poter soddisfare questi requisiti, ma la prima domanda che mi son fatto è stata: come facco a determinare lo stato di vitalità di un Digi/I-Gate? Bè, la prima risposta è stata quella di utilizzare il database APRS più grande e potente al mondo, ovvero aprs.fi.
In tale database, son presenti le informazioni che servono a determinare lo stato di vitalità:
- Tempo passato dall’ultimo ascolto della stazione (last heard)
- Fonte dell’ultimo ascolto (via RF o TCP-IP)
Questo tipo di informazioni è estraibile dal database grazie alle API messe a disposizione da aprs.fi , che consentono di interfacciaare applicazioni sviluppate dagli utenti al database stesso.
La seconda domanda è stata: basandosi sul “last heard” qual’è il criterio col quale definire una stazione operativa o no?
Questo parametro (timeout) deve essere per forza determinato sperimentalmente, partendo innanzitutto dalla conoscenza degli intervalli medi tra un beacon e l’altro.
Nei ritagli di tempo, mi son messo quindi al lavoro per sviluppare questa interfaccia web. Non sono un programmatore professionista, ma ho delle basi di PHP, quindi la mia scelta è andata su tale tipo di linguaggio.
Sono riuscito in meno tempo del previsto a provare le query con le API e a mostrare i dati di ogni stazione in maniera tabellare.
Ho quindi aggiunto, sotto la tabella, un’immagine che mostri la dislocazione dei digipeater attivi su una mappa. La scelta, in questo caso, è ricaduta su aprsdirect perchè aprs.fi a quanto pare non supporta più la possibilità di integrare le sue viste all’interno di una pagina web.
Qui sotto, riporto il risultato finale della dashboard.
La regolazione del timeout, dopo diverse prove, si è fermata su 3 ore .
La dashboard è raggiungibile questo indirizzo .
A questo punto, il primo requisito è stato soddisfatto e un front-end di facile lettura è stato messo a disposizione.
Rimaneva da implementare il sistema che monitori lo stato delle stazioni e invii le allerte. Tale sistema deve avere una logica diversa da quella della dashboard, in quanto deve essere un processo che, eseguito in background, invii con una cadenza periodica le query al database di aprs.fi, determini lo stato di vitalità di ogni stazione e invii le allerte.
Prima di determinare il linguaggio da utilizzare per questo script, ho dovuto scegliere innanzitutto su quale canale inviare i messaggi.
In questo caso ho preferito telegram, che nascendo open-source, offre molte pià flessibilità di interfacciamento.
Effettuando una ricerca di qualcosa di pronto per l’interfacciamento a telegram, ho trovato l’ottima libreria python telegram-send, quindi mi son messo all’opera per sviluppare lo script proprio in linguaggio python.
Questa volta ho dovuto pensare un po’ di più alla logica da utilizzare per tracciare i cambiamenti di stato delle stazioni.
Confrontandomi con Luigi, infatti, abbiamo deciso che i messaggi debbano partire solo in caso di cambio di stato di una stazione, ovvero in caso di passaggio da stato “non operativa” a “operativa” e viceversa.
Per mantenere traccia dello stato di ogni stazione, ho creato un array di digit binari in cui ogni “0” o “1” rappresenta lo stato di ogni stazione.
Il codice è strutturato con un ciclo “while” principale che viene eseguito ad un intervallo scelto dall’utente (Nota: non diminuire troppo questo intervallo sia perchè è inutile, sia perchè aprs.fi ha un numero limitato di chiamate alle sue API!). Ad ogni ciclo, viene interrogato il database e determinato lo stato della stazione. Ad ogni ciclo, lo script procede a comprare lo stato attuale di ogni stazione con quello precedentemente memorizzato nel array. Solo in caso di cambio di stato, si entra nella parte di codice dedicata all’invio della notifica su telegram.
Sotto, viene riportato un esempio di schermata telegram con i messaggi di notifica:
Il sistema è in funzione initerrottamente da circa 8 mesi e non ha mostrato nessuna instabilità. Sia la dashboard che lo script girano su un raspberry Pi3 sul quale girano già altre applicazioni, e non si sono mai bloccati.
Sperando che l’articolo vi sia piaciuto e che possa essere di ispirazione per eventuali espansioni e/o nuove applicazioni, condivido con voi anche il sorgente su GitHub:
L’articolo originale, con qualche dettaglio tecnico in più, è disponibile a questo link.
73′ e buon divertimento con APRS
Alfredo IZ7BOJ
