Novità

Cosa è cambiato

Farview per il desktop e il relay. Le versioni sono YYYY.M.N: la N-esima release di quel mese.

Download — le novità dell’app per Android sono nella sua pagina su Google Play.

L’app desktop

2026.10.11

Aree: raggruppa le telecamere di un sito per stanza o luogo («Ingresso», «Giardino»…). L’elenco mostra ogni area come una sezione che si può chiudere, con «Altre» in fondo per le telecamere senza area; il pulsante Aree le nomina, le ordina e le elimina (le telecamere di un’area eliminata restano nel sito), e la scheda della telecamera ha il campo Area. Le aree stanno nel sito: il telefono e chi condivide il sito vedono le stesse; chi ha l’accesso in sola lettura le vede ma non le cambia.

2026.10.10

La sincronizzazione non annulla e non cancella più i dati del sito scritti da un Farview più recente su un altro dispositivo: un campo che questa versione non conosce tiene la copia del server, invece di quella del lato che ha modificato per ultimo una telecamera. Prepara i siti alle aree delle telecamere, che arrivano in una prossima versione.

2026.10.9

Giorno e notte nella diretta: per una telecamera che permette a Farview di cambiare il filtro infrarossi, la scheda «Giorno e notte» offre Automatico, Giorno e Notte (solo quelli che la telecamera supporta), sulla rete di casa, tramite il relay o tramite il tunnel.
Un flusso che il decodificatore del computer rifiuta riparte una volta ricodificato, invece di lasciare l’immagine nera; se non va neanche così, la diretta lo dice.
Questa versione porta il relay 2026.10.8: il comando giorno e notte, e una riga nel log per ogni decisione sulle notifiche.

2026.10.8

L’indicatore di sincronizzazione non resta più su «Sincronizzo…» fino a cinque minuti dopo aver salvato una telecamera o avviato una sincronizzazione a mano, e nel frattempo il pulsante Sincronizza non resta più disabilitato.
Questa versione porta il relay 2026.10.7: il video di una telecamera con zone privacy ha la misura del bitrate della telecamera.

2026.10.7

Zone privacy (Pro): nelle impostazioni di una telecamera, fino a quattro aree dell’immagine che Farview non mostra e non conserva mai. Il relay che registra la telecamera le dipinge di nero prima che chiunque altro veda il video: nel dal vivo, nelle registrazioni e nelle immagini che questo computer conserva, e niente di ciò che si muove lì dentro genera un evento o una notifica. Toglierle si può sempre.
Una telecamera con zone privacy si guarda solo attraverso il suo relay, in casa o tramite il tunnel, mai direttamente dalla telecamera; se il relay non può mascherarla, la schermata del dal vivo dice perché e non mostra nulla. Le zone sono disegnate anche sopra l’immagine qui, così sono coperte anche le registrazioni fatte prima.
Le immagini di una telecamera conservate su questo computer vengono cancellate quando cambiano le sue zone privacy, su qualunque dispositivo siano state cambiate.
Questa versione contiene il relay 2026.10.6, che fa la mascheratura (pacchetto di rilevamento 4, con x264).

2026.10.6

Una notifica già mostrata tramite il tunnel non ricompare quando torni a casa, e non ne arrivano più dopo aver spento le notifiche o essere uscito dall’account. Un riepilogo («e altre N») più vecchio di due minuti va nell’elenco in silenzio, come ogni altra notifica, invece di comparire.
Salvare le impostazioni di una telecamera conserva le zone da ignorare disegnate su un altro dispositivo dopo che le hai aperte: viene scritto solo ciò che hai cambiato. «Applica alle altre telecamere» spegne le notifiche di una classe che il nuovo rilevamento non cerca più, come fa l’app Android.
Un tunnel rifiutato dal rendezvous viene richiesto una volta con un permesso nuovo, invece di fallire finché il vecchio non scade; uscire dall’account lo chiude del tutto.
Le notifiche chiedono al cloud una volta per controllo, non una per telecamera, e continuano a funzionare quando il cloud per un momento non risponde.
Questa versione contiene il relay 2026.10.5: notifiche push sui telefoni (2026.10.4), un telefono con una chiave a cui non si può cifrare non blocca più gli altri, e i limiti delle notifiche valgono anche dopo un riavvio.

2026.10.5

Il rilevamento dice cosa ha visto: persone, animali, veicoli o movimento, ognuno con il suo colore e la sua icona. Il Live disegna un riquadro con una didascalia intorno a ciò che vede, e dice quali classi sono accese e cosa c’è nell’immagine adesso.
Le Registrazioni elencano gli eventi del giorno con la loro durata, li filtrano per classe dalla legenda, e mostrano l’attività del giorno a quarti d’ora sopra la linea del tempo.
Notifiche (Pro, relay 2026.10.3): telecamera per telecamera, persone di default, oppure animali, veicoli e il solo movimento. Questo computer le mostra solo dopo che le accendi nel pannello Notifiche, e solo mentre l’app è aperta; un clic apre la registrazione qualche secondo prima dell’evento.
Si possono rilevare i veicoli, spenti se una telecamera non lo chiede, e ignorare fino a quattro aree dell’immagine di una telecamera: si disegnano sulla sua ultima immagine nelle impostazioni della telecamera.
Il Live attraverso il tunnel è più fluido: l’immagine arriva ogni mezzo secondo invece che a blocchi di due secondi.
Una telecamera che trasmette già a tutti gli spettatori che accetta (una Tapo ne accetta due, e il relay che la registra è uno di questi) è detta con queste parole, non come «Operation not permitted».
Questa versione contiene il relay 2026.10.3.

2026.10.4

Un aspetto nuovo, lo stesso dell’app Android. Una barra laterale prende il posto della fila di pulsanti in alto; le telecamere sono una griglia di immagini, ognuna con l’ultima immagine dal vivo della telecamera, tenuta solo su questo computer; Live e Registrazioni si aprono come pagine invece che come finestre sopra la lista. Chiaro o scuro segue il sistema.
Le telecamere si muovono anche lontano dalla loro rete, attraverso il tunnel: frecce, zoom, posizione iniziale e punti di vista salvati. Un clic breve su una freccia muove la telecamera. I punti di vista mostrano un’immagine della loro inquadratura, tenuta solo su questo computer. In un sito condiviso con te, ne muovi le telecamere se puoi modificarlo.
Ogni password si può mostrare prima di salvarla.
La password della telecamera non compare più nell’errore che si vede quando un flusso non si apre.
Corretto: l’app riscriveva il sito sul server a ogni sincronizzazione, anche quando non era cambiato niente.
Contiene ancora il relay 2026.10.2.

2026.10.3

Il rilevamento si imposta una volta sola per tutto il sito. Nella sezione Rilevamento di una telecamera, «Applica alle altre telecamere» dà alle altre telecamere del sito che registrano gli stessi movimento, persone e animali, la stessa sensibilità e la stessa scelta su cosa conservare, quando salvi. Le telecamere che non registrano restano come sono, e delle altre non cambia nient’altro della registrazione.
Contiene ancora il relay 2026.10.2.

2026.10.2

Contiene il relay 2026.10.2. Il rilevamento su una telecamera con un flusso a basso bitrate non si interrompe più ogni pochi secondi, e il relay non riscarica più il pacchetto di rilevamento a ogni avvio.

2026.10.1

Rilevamento, con Pro, su una telecamera registrata. Le impostazioni della telecamera hanno una sezione Rilevamento: tenere tutto o solo ciò che sta attorno agli eventi, cosa cercare tra movimento, persone e animali, e con quanta sensibilità. È attivo solo con Pro e con la registrazione accesa, e a cercare è il relay che registra la telecamera; niente di ciò che trova esce dalla tua rete, se non attraverso il tunnel, verso di te.
Riquadri sull’immagine. La vista live disegna ciò che trova il relay sopra il video stesso, anche quando la finestra non è 16:9, e li tiene un attimo perché non tremolino. Seguono l’immagine sullo schermo, che è qualche secondo indietro rispetto al relay, e non i dati man mano che arrivano, così un riquadro resta sulla persona a cui appartiene. Nelle registrazioni sono disegnati allo stesso modo.
La linea del tempo delle Registrazioni segna gli eventi: movimento, animali e persone, i più importanti sopra. Un clic su un segno riproduce da lì.
Il file di registrazione ancora in scrittura si può riprodurre. Gli ultimi minuti di una telecamera restavano irraggiungibili finché il file non si chiudeva; ora la vista Registrazioni riproduce fino all’ultimo frammento completo, chiede il seguito prima di arrivarci e propone il Live quando la riproduzione arriva in fondo.
Le telecamere che condividono un indirizzo (i canali di un registratore, due percorsi di un media server) hanno attraverso il tunnel il loro stato, le loro registrazioni e i loro riquadri, invece di quelli della prima telecamera.
Un righello sotto l’immagine live: trascinalo indietro per guardare le registrazioni da quel momento, anche gli ultimi due minuti ancora in scrittura; Diretta ti riporta al presente. La rotella o il pizzico ingrandiscono da dieci minuti a un giorno, le frecce spostano di dieci secondi e un clic su un segno degli eventi riproduce da lì, con i suoi riquadri.
L’immagine live poteva restare nera: l’inizio del flusso arrivava alla finestra prima che la finestra lo ascoltasse, e senza di esso non si riproduce niente di ciò che segue. Ora la finestra lo chiede quando è pronta.
Le registrazioni partono dal punto che chiedi. I file del relay portano l’ora del giorno nel video stesso, e questo spostava di ore la ricerca, l’orologio e i riquadri e fermava un file chiuso dopo un paio di secondi; ora sono letti su quella linea del tempo.
Contiene il relay 2026.10.1.

2026.9.8

Registrazione sul relay, con Pro. Le impostazioni di una telecamera hanno una sezione Registrazione: il flusso da tenere, per quanti giorni, l’audio, e il tuo consenso a dare nome utente e password della telecamera ai relay che la registrano — meglio un utente della telecamera che può solo guardare. La sezione dice quale relay la registra e quale è di riserva.
Una vista Registrazioni: scegli una telecamera e un giorno, vedi su una linea del tempo cosa c’è e riproduci da qualsiasi punto — dal relay in casa, o attraverso il tunnel da fuori.
Il pannello del relay mostra il disco delle registrazioni: usato, libero, lo spazio che tiene libero e lo stato di ogni telecamera.
Contiene il relay 2026.9.8.

2026.9.7

Un relay riceve le telecamere dei suoi siti e basta. Prima un sito mai aperto su questo computer — creato dal telefono, o con la password cambiata da un altro dispositivo — faceva sembrare il suo relay non assegnato, e l’app gli mandava le telecamere del sito principale.
Un sito può avere più relay. Le impostazioni di ogni sito elencano i relay dell’account con una casella, anche quelle del principale, così un relay si sposta da un sito all’altro.
Una telecamera può dire da quale relay passare e, solo se lo scegli, un relay di riserva per quando il suo non risponde. Mentre lo usa il player mostra «relay di riserva». Un limite del piano non lo fa mai cambiare: ogni relay rifiuterebbe allo stesso modo.
Include il relay 2026.9.5, che smette di servire una telecamera appena la sua lista non la nomina più.

2026.9.6

Uscendo dall’account, le modifiche non ancora salvate di un sito diverso dal principale — o di un sito condiviso con te in scrittura — venivano buttate via senza dire niente. Ora l’app le sincronizza e, se qualcosa non arriva al server, te lo chiede prima, come faceva già per il sito principale.
«Cambia password» di un sito ora passa dalla stessa fila di ogni altra scrittura: prima, con la sincronizzazione automatica nel momento sbagliato, poteva rimettere la password nuova su una versione vecchia del sito e far sparire una modifica appena fatta.
Togliendo a un sito la sua macchina del tunnel, quella macchina riceveva le telecamere del sito principale. Ora non riceve più niente: le telecamere di casa non finiscono su una macchina che sta altrove.
Il relay incluso è la 2026.9.4.

2026.9.5

I siti: un account può avere più di un vault — «Casa», «Ufficio» — e ognuno è un vault a sé, con la sua password, le sue telecamere, la sua macchina del tunnel e le persone con cui lo condividi. La password di un sito non apre gli altri. Più di un sito fa parte di Pro; il vault che hai oggi resta il sito principale e non cambia.
«Vault e condivisione» diventa «Siti e condivisione»: l’elenco dei tuoi siti, «Nuovo sito», e per ognuno il nome, l’apertura con la sua password, il cambio della password, le persone che vi accedono in sola visione o anche in modifica, da quale macchina esce il tunnel, «Ricomincia da zero» ed «Elimina sito». Il sito principale non si elimina: si può solo svuotare.
Le telecamere sono raggruppate per sito quando ne hai più di uno, o quando qualcuno ne condivide uno con te. Con un solo sito la schermata resta com’era.
Un sito condiviso con te in lettura e scrittura ora si modifica anche da qui, non solo dal telefono.
Ogni relay riceve le telecamere dei siti che lo indicano come macchina del tunnel.

2026.9.4

All’account si entra con Google o con un link via email, e basta: la passphrase non fa più entrare nessuno. Il vault ha una password sua, che apre solo il vault.
La prima volta crei il vault con la sua password, oppure apri quello creato dal telefono. Un vault creato da una versione precedente si apre con la passphrase di allora e viene convertito sul momento: da lì in poi quella password apre solo il vault.
Una volta aperto, questo computer ricorda l’accesso e la chiave del vault nel portachiavi di sistema, e a ogni avvio si apre direttamente sulle telecamere. Resta allineato con il telefono da solo, ogni pochi minuti e ogni volta che la finestra torna in primo piano, e passa le modifiche ai tuoi relay.
Vault e condivisione: che cos’è il vault, il cambio della password e — con Pro — le persone con cui lo condividi, ognuna solo in visione o anche in modifica. Anche i vault condivisi con te si aprono qui, per guardare; la loro password non viene salvata su questo computer.
Quando esci, l’accesso, la chiave e le telecamere lasciano questo computer e restano nel vault. Se una modifica non è ancora arrivata nel vault, prima te lo chiede.
Niente più Google con il PIN su Drive: una volta scritta la password del vault su un computer, lì non viene più chiesta.
Eliminare una telecamera, dimenticare il relay e smettere di fare da relay chiedono conferma, ed Esc chiude il player e il pannello del relay. Il menu nella barra di sistema è in italiano.

2026.9.3

La riga del tunnel nel pannello del relay segue il nuovo limite di mezz’ora al giorno per telecamera: i minuti a disposizione di ogni telecamera, le telecamere usate oggi su quelle che il piano consente, i flussi aperti, il traffico del mese e quando il conteggio riparte, nell’ora locale. La 2026.9.2 lì mostrava «0,1 GiB di 0,0 GiB».
Il relay dentro l’app è la 2026.9.3, che comunica al cloud Farview la sua versione.

2026.9.2

Il relay dentro l’app è la 2026.9.2: farview-relay version ne stampa la versione, e una parola che il relay non conosce ora è un errore che la nomina, invece di essere ignorata.

2026.9.1 — prima release pubblica

Cosa fa

Guarda le telecamere con bassa latenza e muovi quelle che si spostano: tieni le frecce o salta a una posizione salvata.
Mantieni lo stesso elenco di telecamere del telefono, cifrato su questo computer con una passphrase che conosci solo tu, e sincronizzato attraverso il tuo account Farview.
Apri l’app con la passphrase, o con Google e un PIN una volta che la chiave è su Google Drive.
Crea l’account dimostrando prima il tuo indirizzo, con Google o con un link inviato per email, e poi scegliendo la passphrase.
Ospita il relay su questo computer, così le telecamere possono essere raggiunte da fuori casa senza una seconda installazione.
Vedi in che modo le telecamere sono raggiungibili da fuori e se Plus funziona: il cloud Farview prova ora a connettersi da internet e, quando non ci riesce, dice perché.
Configura un telefono scansionando un codice QR e adotta altre macchine approvando il codice che mostrano.
Raggiungi le telecamere attraverso il tunnel quando la linea è dietro il carrier-grade NAT.
Resta in esecuzione nella barra di sistema con la finestra chiusa e si avvia con il computer, nascosta, quando ospita il relay.
Ti avvisa una volta per avvio se è uscita una versione più recente.
Esegui solo il relay, senza finestra, con farview --headless.

Dalle prime build

La registrazione dimostra l’indirizzo prima che una passphrase possa essere impostata: un indirizzo da solo non crea più un account.
L’accesso con Google funziona nell’app scaricata, non solo sul computer su cui è stata costruita.
L’app comunica con i relay e i servizi su /api/v1, e continua a funzionare con i relay più vecchi.
Il movimento PTZ si interrompe quando rilasci, chiudi la finestra o perdi la connessione.

Il relay

2026.10.8

Giorno e notte: POST /api/v1/cameras/{id}/daynight legge e cambia il filtro infrarossi di una telecamera via ONVIF Imaging (auto, day, night), con le credenziali della telecamera nella richiesta come per il PTZ; il relay non tiene niente. Una telecamera senza questo comando risponde 422 no_daynight. Le Tapo C200 e C320WS non lo offrono via ONVIF; altre telecamere sì.
Ogni decisione sulle notifiche finisce nel log su una riga notice: con decision= e reason=: emessa, oppure scartata per l’intervallo minimo, il tetto orario, le impostazioni della telecamera o il piano; inviata, oppure non inviata perché il cloud non ha dispositivi, ha risposto con un errore o non l’ha accettata nessuno. Gli scarti si scrivono una volta per telecamera, classe e motivo in ogni finestra. Nel log non finisce niente di segreto.

2026.10.7

Zone privacy: il video oscurato ora ha la misura della telecamera. Il tetto del codificatore segue il bitrate che la telecamera manda davvero, misurato sugli ultimi 30 secondi: 1,25 volte, almeno 500 kbit/s e mai sopra il tetto per l’altezza dell’immagine valido finora. Una Tapo C200 che manda circa 0,85 Mbit/s veniva registrata oscurata a circa 29 MB ogni 2 minuti, contro 13 MB senza zone. Finché non ci sono 10 secondi di misure vale il tetto di prima; un mascheratore partito con quello si riavvia una volta, su un keyframe, quando il tetto misurato è sotto i tre quarti.

2026.10.6

Fissa il pacchetto di rilevamento 4 (ffmpeg con x264, GPL; l’helper accetta fino a 8 zone).
Zone privacy: una telecamera può avere aree dell’immagine che Farview non mostra e non conserva mai. Il relay che registra la telecamera decodifica il video, dipinge le zone di nero pieno, lo codifica di nuovo (x264, nell’ffmpeg del pacchetto di rilevamento, pacchetto 4) e registra e trasmette solo quello. Se non può (pacchetto assente, codificatore fermo, relay che non è proprietario né riserva della telecamera) la telecamera non viene registrata e la sua immagine in diretta viene rifiutata: non si ripiega mai sull’immagine della telecamera. Il relay applica la maschera qualunque sia il piano; creare le zone è Pro, nelle app.
Il relay serve da sé l’immagine in diretta di una telecamera con zone privacy, da un server RTSP interno, all’indirizzo della telecamera attraverso il tunnel e sul suo ascoltatore in rete locale (stesse credenziali della telecamera, fino a 8 spettatori). Quelle connessioni non vengono più inoltrate alla telecamera. La maschera parte a richiesta e si ferma 30 s dopo l’ultimo spettatore.
Le zone che il relay conosce sono salvate in privacy.json e applicate all’avvio, prima del primo roster: un relay che riparte senza internet continua a mascherare. Il roster di un’app più vecchia che non nomina le zone non smaschera la telecamera; solo un elenco vuoto esplicito lo fa.
Il roster ha un secondo elenco, privacyCameras, che un relay precedente non legge mai. Una telecamera con la registrazione spenta può comunque essere mascherata e servita (record.mode: "off").
I rilevamenti dentro una zona privacy vengono scartati (all’assistente ora arrivano fino a 8 zone: prima quelle da ignorare, poi quelle privacy), quindi lì non nasce alcun evento né notifica.
GET /api/v1/recordings (e /status di meta+) hanno un privacy di primo livello e, per ogni telecamera, lo stato della sua maschera; GET /api/v1/cameras segna una telecamera privacy con "privacy": true. Il pacchetto viene scaricato per una telecamera privacy che questo relay maschera, qualunque cosa dica relay.json sul rilevamento.

2026.10.5

Push: un telefono con una chiave a cui non si può cifrare non blocca più la notifica per i telefoni che vengono dopo di lui nell’elenco; viene saltato, e tolto dall’elenco. Fermare il relay non aspetta più fino a mezzo minuto un cloud che non risponde.
Notifiche: la pausa di 5 minuti per telecamera e classe e il limite di 30 l’ora valgono anche dopo un riavvio, quindi una persona ancora davanti alla porta non viene annunciata di nuovo. Un crash a metà della scrittura di una notifica non fa più perdere anche quella dopo.

2026.10.4

Notifiche push (lato relay): una notifica che verrebbe mostrata viene anche cifrata sul relay per ogni telefono indicato dal cloud, in modo che solo quel telefono possa leggerla, e consegnata al cloud perché la recapiti. Il cloud e Google vedono che una notifica è partita, mai cosa dice. Un relay non adottato, o un cloud che non fa ancora push, non cambia comportamento.
Gli avvisi di una telecamera vanno solo ai telefoni delle persone del suo sito (e a quelli del proprietario del relay); il «e altri N» di tutto il relay va solo ai telefoni del proprietario.

2026.10.3

Notifiche, senza il cloud: il relay decide quando qualcosa che una telecamera ha visto merita un avviso — una persona di default, e animali, veicoli o il solo movimento se la telecamera lo chiede — e tiene gli avvisi degli ultimi sette giorni. Al massimo un avviso per telecamera e classe ogni 5 minuti (15 per il solo movimento), al massimo 30 all’ora, poi una riga che dice quanti altri. Le app li leggono sulla rete di casa (GET /api/v1/notices, e un flusso dal vivo) e fuori casa attraverso il tunnel, telecamera per telecamera; mai attraverso l’API pubblica del relay. Un roster scritto da un’app che non conosce le notifiche le lascia come erano.
Veicoli e zone da ignorare (pacchetto di rilevamento 3): una telecamera può cercare i veicoli, spenti se non lo chiede, e ignorare fino a quattro aree della sua immagine.
Un’auto parcheggiata non è un evento ogni volta che si muove qualcos’altro: un veicolo viene segnalato solo dopo che lo si è visto muoversi.
La fine di un evento di movimento dice se nello stesso momento c’era una persona, un animale o un veicolo, così le app distinguono il solo movimento da quello che qualcosa spiega.
Questa versione fissa il pacchetto di rilevamento 3 (vedi detect/CHANGELOG.md).

2026.10.2

L’ausiliario di rilevamento non obbliga più il relay a scaricare di nuovo il suo pacchetto a ogni riavvio. Ora gira in una cartella propria accanto ai pacchetti (detect/run), dove ciò che scrive ONNX Runtime non può far sembrare danneggiato un pacchetto; prima il relay registrava «installed detection pack is damaged» a ogni avvio e riscaricava 18 MB.
Questa versione fissa il pacchetto di rilevamento 2 (vedi detect/CHANGELOG.md): il decodificatore video dell’ausiliario non viene più riavviato ogni pochi secondi su una telecamera con un flusso a basso bitrate, e la telemetria di ONNX Runtime è spenta.

2026.10.1

Il relay può cercare movimento, persone e animali nelle telecamere che registra, e dire alle app dove. Fa parte di Pro, come la registrazione, e lavora su una telecamera solo finché è questo relay a scriverla. Al binario del relay, che resta un unico file statico, non si aggiunge nulla: a guardare è un processo ausiliario con il suo ffmpeg, ONNX Runtime e un modello piccolo, in un pacchetto che il relay scarica la prima volta che una telecamera ne ha bisogno (circa 15 MB; controllato contro valori sha256 compilati in questa versione, e di nuovo prima di ogni avvio). Il registratore dà all’ausiliario il video che già riceve, quindi una telecamera non costa un secondo flusso, salvo che sia registrata sul principale e ne abbia uno più piccolo. Accanto a ogni registrazione il relay scrive i riquadri trovati (<inizio>.det.jsonl) e, nella cartella di ogni giorno, gli eventi che ne risultano (events.jsonl); spariscono insieme alla registrazione. Questa versione fissa il pacchetto di rilevamento 1 (vedi detect/CHANGELOG.md); un pacchetto nuovo arriva sulle macchine con la versione successiva del relay.
Una telecamera può essere impostata per tenere solo ciò che sta attorno agli eventi: le registrazioni con più di 24 ore che non toccano alcun evento, e che il rilevamento ha guardato per intero, vengono cancellate prima della loro conservazione. Tutto ciò che non si sa tranquillo tiene la sua conservazione, e quando il piano smette di consentire il rilevamento non si accorcia più nulla.
Nuovi endpoint di sola lettura, dietro il solito token e nel tunnel come meta+: GET /api/v1/cameras/{id}/events, GET /api/v1/cameras/{id}/segments/<inizio>/detections e GET /api/v1/cameras/{id}/detections/live (Server-Sent Events, con i riquadri man mano che vengono trovati). GET /api/v1/recordings mostra il pacchetto, per ogni telecamera retain e lo stato di detect con il motivo quando non gira, e l’elenco dei segmenti segna le registrazioni che hanno rilevamenti ("det": true). Una sessione meta+ ora dura fino a dieci minuti, come rec+ (prima due), perché valga la pena aprire un flusso live. Il limite di sessioni meta+ cresce con il piano: 3 per spettatore più i flussi del piano, così i riquadri live di più telecamere non consumano quelle che servono a stato ed elenchi dei file.
relay.json guadagna detect (false è un veto: niente scaricato, niente eseguito), detectDevice, detectThreads, detectMaxFps, detectDir, detectPackURL e detectPackFile. L’unità Linux non cambia per la CPU, con ogni riga di protezione (l’ausiliario è stato provato sotto MemoryDenyWriteExecute); una detectDir fuori dalla cartella di stato viene aggiunta a ReadWritePaths= da relay service install, e su Windows l’installazione crea %ProgramData%\Farview\detect scrivibile solo da SYSTEM e Administrators. relay service gpu on|off (Linux, come root) aggiunge o toglie il drop-in systemd che servirà a una GPU.
Il livello di log dell’API di controllo non nasconde più la connessione agli handler che fanno flush, cosa che un flusso live richiede.
Il file di registrazione ancora in scrittura si può riprodurre. I file ora si chiudono al primo keyframe dopo due minuti (prima uno), e finora l’ultimo tratto di ogni telecamera, fino a quei due minuti, non era raggiungibile: un salto di poco indietro finiva nel live. Il relay ora elenca il file aperto ("open": true, con durata e dimensione dei suoi frammenti completi) e lo serve tagliato all’ultimo frammento completo, così un player non riceve mai mezzo frammento, mai dalla cache, e lo stesso indirizzo continua a funzionare quando il file si chiude. La playlist lo include come ultima voce.
La playlist delle registrazioni elenca ogni file in pezzi di circa 6 secondi, tagliati ai confini dei frammenti, ciascuno con il suo orario. Un player che salta dentro un file ora scarica dal pezzo in cui arriva, non dall’inizio del file. Un file di cui il relay non riesce a leggere i frammenti resta elencato intero.
Le telecamere che condividono host e porta (i canali di un registratore, due percorsi di un media server) si distinguono anche attraverso il tunnel: le richieste meta+ e rec+ accettano ?id=<camera id>, così ogni telecamera ha il suo stato, i suoi file e i suoi riquadri invece di quelli della prima.
Trovati con telecamere che si comportano come quelle vere: una telecamera che si riavvia o perde la rete per qualche secondo non lascia più il rilevamento sul flusso principale per dieci minuti quando torna, ma riconnette quello più piccolo; una telecamera che sul secondo flusso risponde 401 senza chiedere credenziali è trattata come un rifiuto, come ogni altro rifiuto; una riconnessione della sessione del registratore non fa più credere al rilevamento che l’immagine sia 0x0, cosa che riavviava il decoder e scriveva una dimensione vuota nell’intestazione del file; una telecamera che chiede il rilevamento a un relay con detect a false risulta disabled_on_relay, così l’app può dire perché non succede nulla; e una telecamera il cui ausiliario è morto risulta in avvio, non attiva, mentre aspetta di essere riavviata.

2026.9.8

Quali telecamere registrare, e quale relay le registra, lo decide l’account. Una telecamera che qualcuno ha scelto di registrare — accettando, nello stesso gesto, che il suo nome utente e la sua password vadano al relay — la registra un relay del suo sito, il titolare, con un secondo di riserva. I due si trovano sulla rete di casa (porta UDP 47086, multicast 239.255.70.86, ogni messaggio firmato con una chiave del sito, così un relay di un altro account viene ignorato): la riserva parte dopo trenta secondi senza notizie del titolare e si ferma al file successivo quando il titolare torna, quindi al peggio c’è una breve sovrapposizione e mai un buco. Le password arrivano solo a quei due relay e non finiscono mai nei log.
La registrazione fa parte di Pro. Il relay legge il piano dell’account a ogni lista di telecamere e tiene l’ultimo sì per sette giorni finché il cloud non risponde; se la risposta è no si ferma subito, e quello che ha registrato resta visibile in casa finché la conservazione non lo toglie. La risposta sta nella cartella di stato del servizio, perché quella della configurazione è di sola lettura.
Il relay può registrare le telecamere che gli vengono assegnate, sul proprio disco: una sessione RTSP per telecamera scritta in MP4 frammentato, H.264 e H.265 come arrivano, l’audio solo se richiesto, un frammento per GOP e un file al minuto, sotto recordingsDir (nuovo, solo in relay.json; /var/lib/farview/recordings con il servizio Linux, accanto alla configurazione negli altri casi). Tiene lo spazio libero del disco sopra minFreePercent (15 di default) cancellando i file più vecchi di qualsiasi telecamera, rispetta la conservazione di ogni telecamera e un eventuale maxRecordingGB, e si mette in pausa invece di riempire il disco. Un file rimasto aperto per un crash viene riparato all’avvio. Endpoint di sola lettura sull’API di controllo elencano ciò che esiste e lo servono come HLS con byte range, e il tunnel li raggiunge per una telecamera nota come meta+host:porta e rec+host:porta. L’unità systemd guadagna StateDirectory=farview e un ReadWritePaths= per la cartella delle registrazioni. Non registra nulla finché al relay non viene detto quali telecamere registrare.

2026.9.7

Il tunnel ora arriva anche al servizio ONVIF della telecamera, non solo al suo video, così un telefono fuori casa può chiederle quali flussi ha. Solo la porta che la scoperta della telecamera ha annunciato per il suo servizio, sull’indirizzo della telecamera stessa: mai un’altra porta della stessa macchina, mai un indirizzo che l’annuncio di una telecamera si limita a nominare, e niente per una telecamera aggiunta a mano, che quell’ indirizzo non ce l’ha. Un relay precedente a questa versione rifiuta quel bersaglio e il telefono ripiega sul percorso del flusso che già conosceva. Il telefono lo chiede come onvif+host:porta, un bersaglio a sé: il cloud non lo conta come telecamera del giorno, né come tempo di tunnel, né come uno dei flussi aperti, e il relay lo chiude dopo due minuti o trenta secondi di silenzio. Il semplice host:porta del servizio ONVIF non è più un bersaglio del tunnel.

2026.9.6

Un telefono fuori casa può chiedere a questa macchina quali telecamere ha trovato. L’elenco — e solo l’elenco — ora risponde anche attraverso il tunnel, oltre che all’indirizzo della macchina, così l’app può importare le telecamere da un relay che non raggiunge direttamente. Lì si può solo leggere: muovere una telecamera, leggerne i profili e cambiare la macchina vogliono ancora il suo indirizzo e il suo token. Chiederlo richiede il tunnel nel piano dell’account e non conta come una delle telecamere del giorno.

2026.9.5

Una telecamera che la lista dell’account non nomina più per questa macchina smette di essere servita alla lettura successiva della lista, non al riavvio: una eliminata, una spostata sul relay di un altro sito, o tutte quando la macchina viene tolta da ogni sito. Prima un relay spostato da un sito a un altro continuava a servire le telecamere del primo finché qualcuno non lo riavviava. Le telecamere del file di configurazione, e quelle trovate in rete che nessuna lista nominava, non vengono mai tolte così. Una macchina che legge anche il vault continua come prima.

2026.9.4

La scoperta delle telecamere accetta una risposta solo se l’indirizzo che dichiara è quello da cui è arrivata. Prima chiunque fosse sulla stessa rete poteva farsi registrare come telecamera un host qualsiasi — e quell’host si prendeva una porta pubblica del relay e diventava un bersaglio legittimo del tunnel.
Il relay non resta più senza una telecamera al primo errore di rete: riprova ad accettare connessioni con attese crescenti, invece di chiudere quella porta fino al riavvio. In più ogni telecamera accetta al massimo 32 connessioni insieme, e una connessione ferma da due minuti viene chiusa.
GET /api/v1/tls risponde una prova anche per il token pubblicato dall’account, non solo per quello del file di configurazione: un’app che ha adottato questa macchina con «Collega una macchina» ora riesce a fissare il certificato. Chi usa il token del file non cambia niente.
Il README diceva che il token protegge anche le porte del video: non è così, e ora lo dice. Quelle porte le difende solo la password della telecamera, che è il motivo per cui vanno dietro un firewall, una VPN o un tunnel, e per cui il TLS conta.

2026.9.3

Il relay dice al cloud Farview quale versione è, nell’intestazione User-Agent di ogni richiesta, come farview-relay/<version>. Prima la maggior parte delle richieste non ne mandava nessuno.

2026.9.2

farview-relay version stampa la versione. Una parola che il relay non conosce ora è un errore che la nomina, invece di essere ignorata mentre il relay parte.

2026.9.1 — prima release pubblica

Cosa fa

Scopre le telecamere ONVIF sulla rete locale usando WS-Discovery e mantiene l’elenco aggiornato.
Rilancia ogni telecamera aprendo un listener TCP esterno e instradando trasparentemente i byte all’endpoint RTSP interno della telecamera.
Espone un’API di controllo protetta da token e una pagina di stato, sulla porta 8088 sotto /api/v1, per elencare le telecamere, aggiungerle a mano e muovere quelle PTZ.
Opzionalmente avvolge i listener in TLS, supportando la fornitura del tuo certificato o lasciando che il relay ne generi uno autonomo.
Chiede al router di inoltrare le sue porte — innanzitutto UPnP, poi PCP e infine NAT-PMP — per rendere il relay raggiungibile da fuori della rete domestica.
Controlla la raggiungibilità con STUN (è la linea dietro il carrier-grade NAT?) e chiede al cloud Farview di connettersi da fuori, così può dire se Plus funzionerà e perché no.
Entra nel tuo account con relay pair, approvato dal telefono, senza che la passphrase dell’account passi mai sulla macchina.
Offre relay login per accedere direttamente sulla macchina con Google o email, quindi adottare se stesso e disconnettersi.
Si installa come servizio di sistema con relay service install così si avvia automaticamente su Linux, macOS e Windows.
Può raggiungere le telecamere attraverso il tunnel Farview quando la linea è dietro il carrier-grade NAT.
È disponibile come pacchetti Linux (.deb, .rpm, Arch) per macchine senza interfaccia grafica e come un unico binario per Windows e macOS.

Dalle prime build

L’API si è spostata sotto /api/v1; i vecchi percorsi continuano a rispondere, quindi le app più vecchie continuano a funzionare.
Il movimento PTZ ha un timeout, così una telecamera si ferma se la connessione cade.
Il relay genera il proprio certificato TLS quando richiesto e lo mantiene tra un riavvio e l’altro, così un telefono che l’ha fidato una volta lo continua a fidare.
L’elenco delle telecamere può arrivare dal tuo account come un elenco sigillato, aperto con una chiave che non lascia mai la macchina, invece che con una passphrase memorizzata su di essa.