Riferimento per integrazioni di terze partiTigerTagFirebase Integration
Collega Home Assistant, una bilancia ESP32 o uno script Python a un account TigerTag.
Questo repository documenta come qualsiasi client accede con le credenziali TigerTag dell'utente stesso, legge le sue bobine di filamento e i suoi scaffali in Firestore e riscrive il peso delle bobine. Ciò che è documentato qui è ciò che è in produzione, e ogni modifica è registrata nel changelog.
Il tuo clientHome Assistant · ESP32 · Python · Spoolman
email + password
Firebase AuthenticationL'account dell'utente stesso, un idToken da 1 ora
Authorization: Bearer {idToken}
Firestore Security RulesI proprietari leggono e scrivono, gli amici leggono
Firestoreusers/{uid}/inventory
0.1.3Ultima versione rilasciata del contratto (CHANGELOG, 2 maggio 2026)
1 hDurata di un idToken: rinnovalo prima che scada
5 minIntervallo minimo di polling consigliato
3 mesiPreavviso minimo di deprecazione prima che un campo venga rinominato o rimosso
Come un client si collega a TigerTag
Ogni client segue gli stessi quattro passaggi: recuperare la configurazione pubblica di Firebase, accedere come l'utente, chiamare l'API REST di Firestore con il token dell'utente e mantenere valido quel token.
1
Recupera la configurazione pubblica
Una sola GET restituisce la configurazione del progetto Firebase. L'apiKey è pubblica per scelta progettuale: identifica il progetto, non chi effettua la chiamata. Mettila in cache; basta aggiornarla una volta alla settimana.
L'email e la password dell'utente stesso restituiscono un UID, un idToken da 1 ora e un refreshToken. Google Sign-In richiede un browser, quindi i client senza interfaccia usano una password.
Invia l'idToken come token Bearer. Le bobine si trovano in users/{uid}/inventory, gli scaffali in users/{uid}/racks; i pesi sono grammi netti, le date millisecondi Unix.
Rinnova l'idToken prima che scada l'ora e sostituisci entrambi i token salvati. In caso di permission-denied, rinnova una volta e riprova la lettura una volta.
GET https://tigertag-cdn.web.app/__/firebase/init.json
POST https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key={apiKey}
{ "email": "user@example.com", "password": "…", "returnSecureToken": true }
GET https://firestore.googleapis.com/v1/projects/{projectId}/databases/(default)/documents/users/{uid}/inventory
Authorization: Bearer {idToken}
I valori tra parentesi graffe provengono dalla chiamata precedente: apiKey e projectId dalla configurazione, uid e idToken dall'accesso.
Integrazioni documentate in questo repository
Ogni guida in docs/clients copre l'autenticazione, i dati che legge o scrive, la mappatura dei campi e il codice. I frammenti qui sotto sono copiati dalle guide.
Bozza di componente
Home Assistant
Un componente personalizzato di Home Assistant che espone un sensore per bobina, con il peso residuo in grammi come stato. La guida copre anche gli inventari degli amici, la paginazione e la memorizzazione dei token; il config flow e il sensore sono scheletri, e un componente completamente funzionante è ancora da scrivere.
Per una bilancia o un dispositivo NFC: cerca una bobina tramite l'UID RFID scansionato (uid, poi twin_uid), calcola il peso netto e scrivi weight_available e last_update con una maschera di aggiornamento. La guida si conclude con uno sketch completo per ESP32 (WiFi, ArduinoJson).
Un client Python minimale basato su Pyrebase4: accede, elenca le tue bobine e mostra quante bobine ha ciascun amico. La guida contiene lo script completo e un esempio di esecuzione.
Un ponte unidirezionale da TigerTag a un'istanza di Spoolman: i marchi diventano vendor, ogni combinazione di marchio, materiale e colore diventa un filament, e ogni documento dell'inventario diventa uno spool, creato o aggiornato tramite l'API REST di Spoolman. Si esegue da cron, systemd o Docker.
Il contratto che una TigerScale o una bilancia compatibile segue per apparire online in Tiger Studio Manager e nell'app mobile TigerTag: un documento di heartbeat ogni 30 secondi, un aggiornamento del peso a ogni lettura stabile e i tag gemelli scritti in un unico batch atomico.
users/{uid}/scales/{mac} ← heartbeat, every 30 s
users/{uid}/inventory/{spoolId} ← weight_available + last_update
Sviluppi per un'altra piattaforma? Una nuova guida va in docs/clients, un esempio eseguibile facoltativo in examples/. CONTRIBUTING.md
L'account dell'utente, le regole dell'utente
Non c'è nessuna chiave condivisa da proteggere né alcun token master che possa trapelare: un client può fare esattamente ciò che può fare il suo utente, e Firestore lo impone sul server.
Nessun account di servizio
Ogni client accede con le credenziali dell'utente finale stesso. Non includere mai l'SDK firebase-admin né alcuna chiave di amministrazione in un client di terze parti.
Decidono le Security Rules
Le Firestore Security Rules verificano ogni richiesta rispetto a request.auth.uid: i proprietari leggono e scrivono i propri documenti, gli amici possono leggere l'inventario e gli scaffali, e tutto ciò che non è consentito viene negato. La copia pubblica delle regole si trova in rules/firestore.rules.
Un legame per ogni amicizia
Accettare una richiesta di amicizia scrive un documento su ciascun lato. Finché esiste users/{friend}/friends/{you} puoi leggere l'inventario e gli scaffali di quell'amico, in sola lettura; eliminarlo interrompe subito l'accesso.
Interroga al massimo ogni 5 minuti, mai sotto i 30 secondi, scrivi solo quando un valore cambia e passa un limite nelle letture di elenchi (200 bobine, 50 scaffali). Firebase App Check non è imposto.
Il repository è trattato come un contratto pubblico: le modifiche che riguardano i client arrivano in questo repository nella stessa release, e il changelog registra ciascuna come Added, Changed, Deprecated, Removed, Fixed o Security.
Non cambierà senza preavviso
I percorsi dei documenti come users/{uid}/inventory/{spoolId}, users/{uid}/racks/{rackId} e users/{uid}/friends/{friendUid}.
Il nome e il significato di ogni campo documentato: weight_available è in grammi netti, last_update in millisecondi Unix, deleted: true indica un'eliminazione logica.
Il modello di accesso degli amici e gli endpoint di Firebase Auth con cui un client accede.
L'apiKey e il projectId, a meno che l'intero progetto non venga trasferito, cosa annunciata con almeno 6 mesi di anticipo.
Può cambiare: programma in modo difensivo
Le tabelle di riferimento si arricchiscono di nuovi marchi e materiali; gli id numerici vengono solo aggiunti e mai riutilizzati.
Gli endpoint HTTPS di comodo su cdn.tigertag.io possono evolvere la forma delle richieste e delle risposte.
Le nuove collezioni e i nuovi campi sono sempre aggiuntivi: ignora i campi che non conosci e rimarrai compatibile.
Mi serve un account di servizio o una chiave di amministrazione?
No. Ogni client accede con l'email e la password TigerTag dell'utente finale stesso, e le Firestore Security Rules decidono cosa quell'utente può leggere o scrivere. Non esiste alcuna chiave di amministrazione condivisa, e l'SDK firebase-admin non deve mai essere usato in un client di terze parti.
Perché l'apiKey di Firebase è pubblica?
L'apiKey identifica il progetto Firebase di TigerTag, non chi effettua la chiamata. Senza un idToken valido, ottenuto accedendo come un utente reale, non dà accesso a nulla; il controllo degli accessi è affidato all'autenticazione e alle Security Rules.
Home Assistant o un ESP32 possono accedere con Google?
Non direttamente: Google Sign-In richiede un reindirizzamento nel browser. Un utente che ha sempre usato solo Google imposta prima una password sull'account, tramite la procedura di password dimenticata dell'app desktop o mobile, e poi accede con email e password.
Con quale frequenza può interrogare la mia integrazione?
Al massimo ogni 5 minuti per un sensore, ogni 15 minuti per una panoramica degli scaffali, e mai sotto i 30 secondi. Una bilancia scrive solo quando un peso cambia. Le letture di elenchi devono passare un limite: 200 per l'inventario, 50 per gli scaffali.
La mia integrazione può leggere le bobine di un amico?
Sì, in sola lettura. Quando due utenti sono amici, ciascuno ha un documento per l'altro in users/{uid}/friends, e le regole consentono a un amico di leggere l'inventario e gli scaffali. Ciascuno dei due può rimuovere l'amicizia in qualsiasi momento, interrompendo subito l'accesso.
E se la produzione non corrisponde a questa documentazione?
Vale la documentazione: una differenza significa che è stata rilasciata una regressione. Apri una issue sul repository con la pagina, il percorso che hai letto o scritto e la risposta, rimuovendo token e chiavi private.
Con quale licenza posso riutilizzare il codice?
Le Security Rules e ogni frammento di codice della documentazione sono sotto Apache-2.0, e l'attribuzione non è richiesta per i frammenti incollati nel tuo progetto. La documentazione stessa è sotto CC-BY-4.0. Il nome, il logo e il servizio TigerTag non sono coperti da queste licenze.
Inizia la tua integrazione
Scegli la guida per la tua piattaforma nei link rapidi del README e seguila dall'accesso alla tua prima lettura.