La nostra posizione \u00e8 semplice: \u00e8 fattibile in alcuni casi, ma solo alle giuste condizioni. Per i normali telefoni di consumo e le app utilizzate occasionalmente, questo approccio di solito non \u00e8 sufficientemente affidabile da poter essere considerato un sostituto completo di un gateway dedicato.<\/p>\n\n\n\n
Il caso d'uso di destinazione<\/h2>\n\n\n\n
Sulla carta, l'architettura richiesta \u00e8 semplice. B002<\/a> O B005<\/a> Il beacon trasmette dati BLE a intervalli configurabili. Un telefono su cui \u00e8 installata l'app del cliente cerca questi dati, legge l'ID del beacon e l'intensit\u00e0 del segnale e carica l'evento di rilevamento sul server.<\/p>\n\n\n\n Ci\u00f2 si adatta alle capacit\u00e0 di Lansitec fari<\/a>. IL B002<\/a> \u00e8 un'etichetta BLE ultrasottile basata su iBeacon, con intervalli di pubblicit\u00e0 configurabili da 100 ms a 10 s e una distanza di trasmissione in linea d'aria indicata come 150 m. B005<\/a> \u00e8 un faro IP68 pi\u00f9 robusto con intervalli configurabili, opzionale Supporto AoA<\/a>, e la stessa portata di 150 m in linea d'aria.<\/p>\n\n\n\n Il problema, quindi, non risiede nel dispositivo beacon, bens\u00ec nel telefono.<\/p>\n\n\n\n In Lansitec B-Mobile<\/a> soluzione, Gateway Bluetooth<\/a> vengono dispiegati in postazioni fisse. Fari<\/a> pubblicizzare periodicamente, portali<\/a> ricevono i dati e il server calcola o interpreta la posizione in base alle posizioni note di quelli portali<\/a>. Gli stessi documenti notano anche che porta d'accesso<\/a> La ricezione \u00e8 effettivamente sempre attiva nel modello di implementazione previsto, e questo RSSI<\/a> pu\u00f2 variare a causa di muri, interferenze ed effetti di multipath.<\/p>\n\n\n\n Avere l'app in questo punto cambia completamente la progettazione della soluzione.<\/p>\n\n\n\n Un fisso porta d'accesso<\/a> Ti offre tre cose che un telefono normale non ha:<\/p>\n\n\n\n Questa \u00e8 la prima avvertenza che porremmo a qualsiasi cliente. Anche se l'app rileva il segnale del beacon, un telefono in movimento non \u00e8 funzionalmente equivalente a un dispositivo montato. porta d'accesso.<\/a><\/p>\n\n\n\n Su iOS, il funzionamento del Bluetooth in background \u00e8 possibile, ma limitato. Apple afferma che le app che funzionano solo in primo piano non possono eseguire la scansione e rilevare periferiche pubblicitarie mentre sono in background o in sospensione. Le app che dichiarano la modalit\u00e0 di background "Bluetooth-central" possono comunque rilevare e connettersi alle periferiche in background, ma la scansione in background si comporta in modo diverso: i rilevamenti duplicati vengono uniti e gli intervalli di scansione potrebbero aumentare, il che significa che il rilevamento potrebbe richiedere pi\u00f9 tempo. Apple afferma inoltre che le app riattivate da eventi Bluetooth dovrebbero terminare rapidamente e indica circa 10 secondi di funzionamento in background prima che la pressione della sospensione diventi un problema. (1)<\/a><\/sup><\/p>\n\n\n\n Esiste una soluzione alternativa utile per iOS: il monitoraggio delle aree beacon. Il framework Core Location di Apple pu\u00f2 monitorare le aree iBeacon e riattivare l'app in caso di ingresso o uscita. Tuttavia, ci sono dei compromessi. Apple limita il monitoraggio delle aree a 20 aree per app e raccomanda esplicitamente di utilizzare il rilevamento della distanza tramite beacon solo quando l'app \u00e8 in primo piano. (2)<\/a><\/sup><\/p>\n\n\n\n Cosa significa questo in pratica?<\/p>\n\n\n\n Su iOS, un'app pu\u00f2 supportare comportamenti in background correlati ai beacon, in particolare flussi di lavoro generici come "ingresso in una determinata area \/ uscita da un'altra". Tuttavia, non \u00e8 una piattaforma adatta per la scansione passiva continua, simile a quella di un gateway, su larga scala. Se il cliente desidera un telefono sempre in ascolto che agisca silenziosamente come un'infrastruttura, iOS rappresenta la soluzione meno indicata.<\/p>\n\n\n\n Android \u00e8 pi\u00f9 flessibile, ma non fa miracoli. Le attuali linee guida per gli sviluppatori di Google affermano che la comunicazione BLE in background \u00e8 possibile, ma il processo dell'app deve rimanere attivo. Se il processo viene terminato, le connessioni vengono chiuse. Google precisa inoltre che le scansioni non filtrate vengono interrotte quando lo schermo si spegne e riprendono quando si riaccende, a meno che non venga utilizzata la scansione filtrata.<\/p>\n\n\n\n Per l'utilizzo in background, Android documenta diverse soluzioni: eseguire la scansione con un PendingIntent, utilizzare CompanionDeviceService, utilizzare WorkManager o eseguire un servizio in primo piano con il tipo connectedDevice. Google sconsiglia inoltre le scansioni periodiche come soluzione generale perch\u00e9 sono inefficienti e potrebbero comunque essere interrotte. A partire da Android 14, i servizi in primo piano devono dichiarare esplicitamente il tipo di servizio appropriato. (3)<\/a><\/sup><\/p>\n\n\n\n Ecco il punto cruciale: Android pu\u00f2 farlo meglio di iOS, ma l'affidabilit\u00e0 dipende in larga misura dalla disciplina di implementazione.<\/p>\n\n\n\n Un normale telefono Android per utenti consumer potrebbe comunque interrompere l'app a causa dell'ottimizzazione della batteria da parte del produttore, delle impostazioni utente, delle restrizioni in background o della pressione sulla memoria. Potrebbe essere necessario un dispositivo Android personalizzato di livello industriale per garantire che il processo non venga terminato in background. Un dispositivo gestito con whitelisting, gestione delle app ad alta priorit\u00e0, impostazioni di alimentazione controllate e un flusso di lavoro specifico per ruolo ha molte pi\u00f9 probabilit\u00e0 di successo.<\/p>\n\n\n\n Abbiamo individuato tre situazioni in cui l'idea di un'app \u00e8 ragionevole.<\/p>\n\n\n\n Questo potrebbe funzionare nei casi in cui l'utente tiene l'app aperta durante un turno, o il telefono \u00e8 montato e utilizzato come parte di un processo lavorativo; in questi casi la ricezione del beacon diventa molto pi\u00f9 realistica. Un esempio potrebbe essere il caso in cui il telefono sia montato su un veicolo o su una macchina da costruzione, come nel caso di un'app per autisti di Uber.<\/p>\n\n\n\n Uno smartphone Android robusto o personalizzato, soprattutto se gestito dall'azienda, \u00e8 di gran lunga preferibile a un qualsiasi telefono personale. In questo caso, il telefono non \u00e8 una semplice piattaforma per app mobili, ma un terminale semi-dedicato. Pertanto, \u00e8 prevedibile un maggiore grado di personalizzazione ed \u00e8 ragionevole che il software venga adattato in modo da rendere il processo fattibile.<\/p>\n\n\n\n Se al cliente basta una semplice notifica come "beacon rilevato", "beacon vicino al telefono" o "operatore entrato in una zona con un dispositivo gestito", l'app potrebbe essere sufficiente. Se hanno bisogno di un monitoraggio stabile a livello di stanza o di sito indipendente dal comportamento dell'utente, allora no, cio\u00e8 porta d'accesso<\/a> territorio.<\/strong><\/p>\n\n\n\n L'approccio basato sulle app presenta le seguenti limitazioni principali:<\/p>\n\n\n\n Per un cliente che insiste sull'utilizzo dell'app, consigliamo quanto segue.<\/p>\n\n\n\n Utilizzo Android, non iOS<\/strong>, Per la prima dimostrazione di fattibilit\u00e0, basare l'applicazione su scansioni BLE filtrate, comportamento del servizio in primo piano laddove consentito e gestione dei dispositivi aziendali. Utilizzare dispositivi robusti\/personalizzati, se possibile. Mantenere l'app integrata in un flusso di lavoro operativo, non utilizzarla solo occasionalmente. Trattare l'app come un terminale gestito, non come una semplice installazione da un app store.<\/p>\n\n\n\n Per iOS, la soluzione va posizionata in modo pi\u00f9 specifico. Pu\u00f2 supportare avvisi, suggerimenti di presenza o flussi di lavoro controllati in aree beacon, ma non la sostituzione completa del gateway in implementazioni complesse.<\/p>\n\n\n\n E per i clienti che necessitano di una copertura del sito costante, una dipendenza minima dal comportamento dell'utente e un punto di riferimento stabile per il monitoraggio, manteniamo il dedicato Gateway Bluetooth<\/a> architettura. Questa rimane la soluzione migliore dal punto di vista ingegneristico e della stabilit\u00e0 funzionale.<\/strong><\/p>\n\n\n\n S\u00ec, un'app mobile pu\u00f2 ricevere trasmissioni beacon in background. Ma questo non la rende automaticamente un buon sostituto di un Gateway Bluetooth<\/a>.<\/p>\n\n\n\n Su iOS, l'approccio \u00e8 limitato e dovrebbe essere considerato, nella migliore delle ipotesi, condizionato. Su Android standard \u00e8 possibile, ma fragile. Su dispositivi Android personalizzati o industriali, soprattutto in un ambiente operativo gestito, diventa molto pi\u00f9 realistico.<\/p>\n\n\n\n La conclusione finale \u00e8 quindi questa:<\/p>\n\n\n\n Una soluzione di monitoraggio in background basata esclusivamente su app \u00e8 fattibile per implementazioni Android selezionate con dispositivi controllati e utilizzo continuo dell'app. Non \u00e8 un sostituto generale affidabile per il monitoraggio fisso. Gateway Bluetooth<\/a>, soprattutto su iOS o su telefoni consumer non gestiti.<\/strong><\/p>\n\n\n\n <\/p>\n\n\n\n Riferimenti e ulteriori letture:<\/p>\n\n\n\n <\/p>","protected":false},"excerpt":{"rendered":" Scopo Alcuni clienti desiderano utilizzare un'app mobile su iOS o Android per ricevere trasmissioni di beacon Bluetooth in background, anzich\u00e9 implementare un gateway Bluetooth dedicato. In questo documento, valutiamo se tale approccio sia tecnicamente fattibile per il monitoraggio basato su beacon di Lansitec, in particolare per dispositivi come l'etichetta Bluetooth B002 e il Bluetooth B005\u2026 Leggi tutto \u00bbFattibilit\u00e0 dell'utilizzo di un'app mobile per il monitoraggio dei beacon in background al posto di un gateway Bluetooth.<\/span><\/a><\/p>","protected":false},"author":12,"featured_media":18710,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[19],"tags":[],"class_list":["post-18704","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-iot-education"],"_links":{"self":[{"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/posts\/18704","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/users\/12"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/comments?post=18704"}],"version-history":[{"count":4,"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/posts\/18704\/revisions"}],"predecessor-version":[{"id":18712,"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/posts\/18704\/revisions\/18712"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/media\/18710"}],"wp:attachment":[{"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/media?parent=18704"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/categories?post=18704"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.lansitec.com\/it\/wp-json\/wp\/v2\/tags?post=18704"}],"curies":[{"name":"parola chiave","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Perch\u00e9 questo \u00e8 diverso dal normale modello Lansitec?<\/h2>\n\n\n\n
\n
fattibilit\u00e0 iOS<\/h2>\n\n\n\n
fattibilit\u00e0 Android<\/h2>\n\n\n\n
Quando l'approccio basato sulle app pu\u00f2 funzionare<\/h2>\n\n\n\n
Innanzitutto, quando l'app \u00e8 effettivamente in uso operativo continuo<\/h3>\n\n\n\n
In secondo luogo, quando l'hardware \u00e8 controllato<\/h3>\n\n\n\n
![\"telefono](\"https:\/\/www.lansitec.com\/wp-content\/uploads\/2026\/04\/Android-Phone.jpg\" "\\"\\"")
In terzo luogo, quando il requisito \u00e8 il rilevamento di eventi, non la localizzazione a livello di infrastruttura.<\/h3>\n\n\n\n
Principali limitazioni che devono essere indicate chiaramente<\/h2>\n\n\n\n
\n
Consigli pratici<\/h2>\n\n\n\n
Conclusione<\/h2>\n\n\n\n
\n