{"id":84024,"date":"2020-06-04T19:42:32","date_gmt":"2020-06-04T17:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty"},"modified":"2020-06-04T19:42:32","modified_gmt":"2020-06-04T17:42:32","slug":"ble-pod-mikroskopom-atty-gatty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","title":{"rendered":"BLE sotto il microscopio (ATT e GATT\u2026)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"BLE<\/p>\n

BLE sotto il microscopio (ATT e GATT\u2026)<\/h2>\n

Parte 1, panoramica<\/b><\/p>\n

\u00c8 passato un bel po' di tempo da quando \u00e8 stata pubblicata la prima specifica di Bluetooth 4.0. E, sebbene il tema BLE sia molto interessante, continua a scoraggiare molti sviluppatori a causa della sua complessit\u00e0. Nei miei articoli precedenti ho principalmente affrontato i livelli pi\u00f9 bassi: Link Layer e Physical Layer. Questo ha permesso di non dover affrontare concetti complessi e confusi come il protocollo degli attributi (ATT) e il profilo generale degli attributi (GATT). Tuttavia, non si pu\u00f2 fare a meno di comprenderli, poich\u00e9 senza di essi \u00e8 impossibile sviluppare dispositivi compatibili. Oggi vorrei condividere con voi queste conoscenze. Nel mio articolo mi baser\u00f2 su un tutorial<\/a><\/noindex> per principianti dal sito Nordic. Quindi, iniziamo.
\n<\/a><\/noindex><\/p>\n

Perch\u00e9 \u00e8 tutto cos\u00ec complicato?<\/h3>\n

\nDal mio punto di vista, era subito chiaro che il controllo dei dispositivi tramite smartphone \u00e8 un tema molto promettente e di lungo termine. Pertanto, \u00e8 stato deciso di strutturarlo subito e al massimo. In modo che i produttori di vari gadget non inventassero i propri protocolli, che poi non sarebbero stati compatibili. Da qui derivano le complessit\u00e0. Gi\u00e0 nella prima fase, nel protocollo BLE si \u00e8 cercato di includere tutto ci\u00f2 che era possibile. E non importa se sar\u00e0 utile in seguito o meno. Inoltre, \u00e8 stata prevista la possibilit\u00e0 di ampliare l'elenco dei dispositivi in futuro.<\/p>\n

Diamo un'occhiata all'immagine dove \u00e8 rappresentato lo schema del protocollo BLE. Esso \u00e8 composto da diversi livelli. Il livello pi\u00f9 basso, il livello fisico (PHY), \u00e8 responsabile del canale radio del dispositivo. Il Link Layer (LL) contiene tutta la sequenza di byte nel messaggio trasmesso. Nei miei articoli precedenti abbiamo studiato proprio questo. L'Host Controller Interface (HCI) \u00e8 il protocollo di scambio tra i livelli o i chip BLE, se il Controller e l'Host sono implementati su chip diversi. La creazione dei pacchetti, la suddivisione in frame, il controllo degli errori e la raccolta dei pacchetti \u00e8 responsabilit\u00e0 del Logical Link Control and Adaptation Protocol (L2CAP). La crittografia dei pacchetti \u00e8 gestita dal Security Manager Protocol (SMP). Il profilo di accesso generale (GAP) \u00e8 responsabile dello scambio iniziale di dati tra i dispositivi, per determinare \u00abChi \u00e8 chi\u00bb. Esso comprende anche scanning e advertising. In questo articolo mi concentrer\u00f2 sulle due parti rimanenti del protocollo: GATT e ATT. GATT \u00e8 un'estensione di ATT, quindi sono fortemente intrecciati.<\/p>\n

\"BLE
\n
\nPer semplificare la narrazione, vorrei ricorrere a un'analogia. L'ho sentita da qualche parte e vorrei sostenerla. Immaginate un dispositivo BLE come una libreria con diversi ripiani. Ogni ripiano rappresenta un tema separato. Ad esempio, abbiamo ripiani di fantascienza, matematica, enciclopedie. Su ogni ripiano ci sono libri riguardanti il tema specifico. E in alcuni libri ci sono anche segnalibri con annotazioni. Inoltre, abbiamo un piccolo catalogo cartaceo di tutti i libri. Se vi ricordate delle biblioteche scolastiche, questo \u00e8 un cassetto stretto con schede cartacee. In questa analogia, la libreria rappresenta il profilo del nostro dispositivo. I ripiani sono i servizi, i libri sono le caratteristiche e il catalogo \u00e8 la tabella degli attributi. I segnalibri nei libri sono i descrittori, di cui parler\u00f2 pi\u00f9 dettagliatamente in seguito.<\/p>\n

Tutti coloro che hanno sviluppato dispositivi sanno che molti progetti contengono pezzi di codice simili. Il fatto \u00e8 che molti dispositivi hanno funzionalit\u00e0 simili. Ad esempio, se i dispositivi funzionano con batterie, il problema della ricarica e del controllo del loro livello sar\u00e0 lo stesso. Lo stesso vale per i sensori. Infatti, l'approccio orientato agli oggetti nella programmazione \u201coffre la possibilit\u00e0 di creare oggetti che collegano propriet\u00e0 e comportamenti in un'alleanza autonoma, che pu\u00f2 poi essere riutilizzata pi\u00f9 volte\u201d<\/i>. A mio parere, nel BLE \u00e8 stato fatto un tentativo simile. Il gruppo Bluetooth Special Interest Group (SIG) ha sviluppato profili. Dispositivi di diversi produttori, che presentano profili identici, devono funzionare senza difficolt\u00e0 tra loro. I profili, a loro volta, consistono di servizi, e i servizi di caratteristiche, completate da descrittori. In generale, questo pu\u00f2 apparire cos\u00ec:<\/p>\n

\"BLE
\n
\nPer esempio, consideriamo lo schema del profilo heart rate monitor (braccialetto fitness). Esso \u00e8 composto da due servizi e diverse caratteristiche. Da esso risulta immediatamente chiara la gerarchia del profilo. La caratteristica del punto di controllo azzera il conteggio totale delle calorie bruciate. <\/p>\n

1. Il servizio di frequenza cardiaca include tre caratteristiche (0x180D):
\n    a) Caratteristica obbligatoria della frequenza cardiaca (0x2A37)
\n    b) Caratteristica opzionale della posizione del sensore corporeo (0x2A38)
\n    c) Caratteristica condizionale del punto di controllo della frequenza cardiaca (0x2A39)
\n2. Servizio di gestione della batteria (0x180F):
\n    a) Caratteristica obbligatoria del livello di carica della batteria (0x2A19)<\/p>\n

UUID<\/h3>\n

\nAffinch\u00e9 possiamo riferirci in modo univoco agli elementi del profilo (servizi, caratteristiche e descrittori), \u00e8 necessario numerarli in qualche modo. A questo scopo viene introdotto il concetto di Universally Unique ID (UUID) o Identificatore Unico Universale. Nelle parentesi di ciascuna riga \u00e8 indicato l'UUID. E c'\u00e8 una particolarit\u00e0. Per l'UUID si \u00e8 deciso di utilizzare un codice lungo 16 e 128 bit. Perch\u00e9, vi chiederete? Nel protocollo BLE tutto \u00e8 subordinato al risparmio energetico. Pertanto, una dimensione di 16 bit \u00e8 piuttosto ragionevole. \u00c8 improbabile che nel prossimo futuro vengano creati pi\u00f9 di 65.000 servizi e caratteristiche unici. Attualmente, ci\u00f2 che potevamo, gi\u00e0 lo abbiamo conteggiato (ricordate da dove viene \u2014 \u00ablui ha contato anche voi\u00bb :-)) Elementi numerati profili<\/a><\/noindex>, servizi<\/a><\/noindex>, caratteristiche<\/a><\/noindex> e descrittori<\/a><\/noindex> potete visualizzarli nei link.<\/p>\n

Tuttavia, penso che tutti ricordino la storia dei 4 byte degli indirizzi IP su Internet. Inizialmente si pensava che fosse sufficiente, e ora non riusciamo a passare a un indirizzo a 6 byte. Per non ripetere questo errore e dare spazio a mani disordinate di artigiani, SIG ha deciso fin da subito di introdurre anche gli UUID a 128 bit. Questo, per me, ricorda la banda non autorizzata da 433 MHz, che \u00e8 stata lasciata agli artigiani del canale radio. Nel nostro caso, \u00e8 stato lasciato un identificatore di servizi e caratteristiche a 128 bit. Ci\u00f2 significa che possiamo utilizzare praticamente qualsiasi valore a 128 bit per i nostri servizi e dispositivi. La probabilit\u00e0 di inventare un UUID identico \u00e8 comunque prossima allo zero.<\/p>\n

In realt\u00e0, gli UUID brevi a 16 bit hanno una loro estensione fino a un valore a 128 bit. Nella specifica, questa estensione \u00e8 chiamata Bluetooth Base UUID e ha valore 00000000-0000-1000-8000-00805F9B34FB. Ad esempio, se l'UUID a 16 bit dell'attributo ha valore 0x1234, allora l'equivalente a 128 bit avr\u00e0 valore 00001234-0000-1000-8000-00805F9B34FB. Viene anche fornita la formula corrispondente:<\/p>\n

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID<\/p>\n

Da dove provenga questo numero magico, non lo so. Se qualcuno dei lettori lo sa \u2014 lo scriva nei commenti (l'utente con il nickname Sinopteek lo ha gi\u00e0 fatto. Vedi i commenti). Per quanto riguarda l'invenzione di UUID a 128 bit, in linea di principio, \u00e8 possibile utilizzare un apposito generatore<\/a><\/noindex>, che lo far\u00e0 per voi.<\/p>\n

ATT\u044b GATT\u044b\u2026<\/h3>\n

\n Dunque, ora inizia la parte pi\u00f9 interessante. Ricordo che ATT si basa su una relazione client-server. Ora stiamo esaminando il dispositivo del server. Contiene informazioni come valori dei sensori, stato dell'interruttore della luce, dati sulla posizione, ecc. Adesso che tutti i \"partecipanti al nostro corteo\" sono numerati, dobbiamo in qualche modo allocarli nella memoria del dispositivo. Per farlo, li inseriamo in una tabella chiamata tabella degli attributi. Ricordate bene questo. \u00c8 il cuore del BLE. \u00c8 ci\u00f2 che esamineremo in seguito. Ora chiameremo ogni riga un attributo. Questa tabella si trova in profondit\u00e0 nello stack e, di solito, non abbiamo accesso diretto ad essa. La inizializziamo e vi accediamo, ma ci\u00f2 che accade all'interno \u00e8 nascosto a noi dietro sette sigilli. <\/p>\n

Consideriamo l'immagine dalla specifica, tuttavia prima di ci\u00f2, voglio richiamare l'attenzione su una comune confusione nei termini, in particolare nei descrittori. Il ruolo del descrittore \u00e8 quello di completare la descrizione di una caratteristica. Quando \u00e8 necessario ampliarne le funzionalit\u00e0, si utilizzano i descrittori. Anch'essi sono attributi e, come i servizi e le caratteristiche, si trovano nella tabella degli attributi. Li esamineremo dettagliatamente nella seconda parte dell'articolo. Tuttavia, a volte i descrittori vengono chiamati numero di riga nella tabella degli attributi. \u00c8 da tenere presente. Per non confonderci, utilizzeremo il termine \"puntatore dell'attributo\" per questi scopi.
\n\"BLE
\n
\nQuindi, un attributo \u00e8 un valore discreto che ha le seguenti propriet\u00e0 associate:
\n1. Puntatore dell'attributo (Attribute Handle) \u2014 \u00e8 l'indice della tabella corrispondente all'attributo
\n2. Tipo di attributo (Attribute Type) \u2014 \u00e8 il UUID che descrive il suo tipo
\n3. Valore dell'attributo (Attribute Value) \u2014 sono i dati indicizzati dal puntatore dell'attributo
\n4. Permessi degli attributi (Attribute Permissions) \u2014 sono parte dell'attributo, permessi che non possono essere letti o scritti utilizzando il protocollo degli attributi<\/p>\n

Come si interpreta tutto questo? Il puntatore dell'attributo \u00e8, in termini algebrici, il suo numero nella nostra tabella.
\nConsente al cliente di fare riferimento a un attributo nelle richieste di lettura o scrittura. Possiamo numerare le nostre righe (attributi) da 0x0001 a 0xFFFF. Nella nostra associazione con la libreria, questo corrisponde al numero della scheda nel catalogo cartaceo. Allo stesso modo, nel catalogo della biblioteca, le schede sono disposte in ordine crescente di numero. Il numero di ogni riga successiva deve essere maggiore di quello precedente. Come in una biblioteca, a volte si perdono alcune schede, quindi anche nella numerazione delle righe possono esserci intervalli. Questo \u00e8 consentito. \u00c8 importante che siano in ordine crescente.<\/p>\n

Il tipo di attributo determina cosa rappresenta un dato attributo. Analogamente al linguaggio C,
\ndove ci sono variabili booleane, numeriche e stringhe, anche qui. Dal tipo di attributo capiamo
\ncon cosa abbiamo a che fare e come dobbiamo lavorare ulteriormente con questo attributo. Di seguito esamineremo alcuni tipi specifici di attributi. Ad esempio, \"dichiarazione di servizio\" (0x2800), \"dichiarazione di caratteristica\" (0x2803), \"dichiarazione di descrittore\" (0x2902).<\/p>\n

Il valore dell'attributo \u00e8 proprio il suo valore, scusate per la tautologia. Se il tipo di attributo \u00e8 una stringa, allora il valore dell'attributo pu\u00f2 essere, ad esempio, uno slogan \"Hello World !!!\". Se il tipo di attributo \u00e8 \"dichiarazione di servizio\", il suo valore \u00e8 il servizio stesso. A volte, \u00e8 anche un'informazione su dove trovare altri attributi e le loro propriet\u00e0.<\/p>\n

I permessi degli attributi consentono al server di capire se l'accesso per la lettura o la scrittura \u00e8 consentito.
\nSi noti che questi permessi si applicano solo al valore dell'attributo, e non al puntatore, al tipo e al campo stesso dei permessi. Cio\u00e8, se la scrittura dell'attributo \u00e8 consentita, possiamo cambiare, ad esempio, la stringa \"Hello World !!!\" in \"Good morning\". Ma non possiamo vietare la scrittura di una nuova riga o cambiare il tipo di attributo e designare la riga come \"dichiarazione di servizio\". Quando un client si rivolge al server, richiede i suoi attributi. Questo consente al cliente di scoprire cosa pu\u00f2 fornire il server. Anche se non \u00e8 obbligatorio leggere e scrivere valori.<\/p>\n

Come appare<\/h3>\n

\nIl concetto di GATT consiste nel raggruppare gli attributi in una tabella degli attributi insieme in un ordine molto specifico e logico. Esaminiamo pi\u00f9 da vicino il profilo della frequenza cardiaca riportato di seguito. La colonna pi\u00f9 a sinistra di questa tabella \u00e8 facoltativa. Essa descrive semplicemente cosa rappresenta questa riga (attributo). Tutte le altre colonne ci sono gi\u00e0 familiari.<\/p>\n

\"BLE
\n
\nNella parte superiore di ogni gruppo abbiamo sempre l'attributo di dichiarazione del servizio. Il suo tipo \u00e8 sempre 0x2800, e il puntatore dipende da quanti attributi sono gi\u00e0 presenti nella tabella. Le sue autorizzazioni sono sempre disponibili solo in lettura, senza alcuna autenticazione o autorizzazione. Di questi concetti parleremo pi\u00f9 avanti. Il valore \u00e8 un altro UUID che determina di che tipo di servizio si tratta. Nella tabella il valore \u00e8 0x180D, che viene definito dal Bluetooth SIG come servizio di frequenza cardiaca. <\/p>\n

Dopo la dichiarazione del servizio, segue la dichiarazione della caratteristica. Ha una forma simile a quella della dichiarazione del servizio. Il suo UUID \u00e8 sempre 0x2803, e le autorizzazioni sono sempre disponibili solo in lettura senza alcuna autenticazione o autorizzazione. Esaminiamo il campo Valore dell'Attributo, che include alcuni dati. Contiene sempre un puntatore, un UUID e un insieme di propriet\u00e0. Questi tre elementi descrivono la successiva dichiarazione del valore della caratteristica. Il puntatore indica naturalmente la posizione della dichiarazione del valore della caratteristica nella tabella degli attributi. L'UUID descrive che tipo di informazione o valore ci possiamo aspettare. Ad esempio, un valore di temperatura, lo stato di un interruttore della luce o un altro valore arbitrario. E infine, le propriet\u00e0, che descrivono come si pu\u00f2 interagire con il valore della caratteristica. <\/p>\n

Qui ci aspetta un altro tranello. \u00c8 legato alle autorizzazioni degli attributi e alle propriet\u00e0 delle caratteristiche. Diamo un'occhiata all'immagine delle propriet\u00e0 del campo bitario della specifica.<\/p>\n

\"BLE
\n
\nCome potete vedere, qui ci sono anche campi che offrono possibilit\u00e0 di lettura e scrittura. Potreste chiedervi perch\u00e9 abbiamo autorizzazioni di lettura\/scrittura per l'attributo e la propriet\u00e0.
\nLetture\/scritture per il valore della caratteristica? Non dovrebbero essere sempre uguali? Il fatto \u00e8 che le propriet\u00e0 per il valore della caratteristica sono, in effetti, solo raccomandazioni per il cliente, utilizzate in GATT e nei livelli applicativi. Sono semplici suggerimenti su cosa il cliente pu\u00f2 aspettarsi dall'attributo della dichiarazione della caratteristica. Esaminiamo questo pi\u00f9 nel dettaglio. Quali tipi di autorizzazioni esistono per l'attributo? <\/p>\n

1. Autorizzazioni di accesso:
\n     \u2014 lettura
\n     \u2014 scrittura
\n     \u2014 lettura e scrittura
\n2. Autorizzazione all'autenticazione:
\n     \u2014 autenticazione richiesta
\n     \u2014 autenticazione non richiesta
\n3. Autorizzazione all'autorizzazione:
\n     \u2014 autorizzazione richiesta
\n     \u2014 autorizzazione non richiesta<\/p>\n

La principale differenza tra le autorizzazioni degli attributi e le propriet\u00e0 delle caratteristiche risiede nel fatto che le prime si riferiscono ai server, mentre le seconde ai clienti. Un server pu\u00f2 avere l'autorizzazione a leggere il valore della caratteristica, ma pu\u00f2 esserci una richiesta di autenticazione o autorizzazione. Pertanto, quando il cliente richiede le propriet\u00e0 della caratteristica, otteniamo che la lettura \u00e8 consentita. Ma nel tentativo di leggere si ricever\u00e0 un errore. Quindi si pu\u00f2 tranquillamente affermare che le autorizzazioni hanno la precedenza sulle propriet\u00e0. La conoscenza delle autorizzazioni disponibili per l'attributo non pu\u00f2 essere ricevuta dal lato del cliente.<\/p>\n

Descrittore<\/h3>\n

\nTornando alla nostra tabella. Dopo la dichiarazione del valore della caratteristica, sono possibili le seguenti dichiarazioni degli attributi:
\n1. Nuova dichiarazione della caratteristica (nel servizio possono esserci molte caratteristiche)
\n2. Nuova dichiarazione del servizio (nella tabella possono essercene molte)
\n3. Dichiarazione del descrittore <\/p>\n

Nel caso della caratteristica di misurazione della frequenza cardiaca, nella nostra tabella, l'annuncio del valore della caratteristica \u00e8 accompagnato dall'annuncio del descrittore. Il descrittore \u00e8 un attributo con informazioni aggiuntive sulla caratteristica. Esistono diversi tipi di descrittori. Di questi parleremo nel dettaglio nella seconda parte di questo articolo. Ora ci occuperemo solo del descrittore di configurazione delle caratteristiche del client (Client Characteristic Configuration Descriptor - CCCD). Ha un UUID pari a 0x2902. Con questo descrittore, il client ha la possibilit\u00e0 di attivare sul server l'indicazione o la notifica. La differenza tra di essi \u00e8 piccola, ma comunque esiste. La notifica non richiede conferma di ricezione da parte del client. L'indicazione, invece, richiede questa conferma, anche se avviene a livello GATT, senza arrivare a livello applicativo. Perch\u00e9 \u00e8 cos\u00ec, vi chiederete? Purtroppo, non lo so. Posso solo dire che gli specialisti della Nordic consigliano di utilizzare la notifica. Soprattutto perch\u00e9 il controllo dell'integrit\u00e0 del pacchetto (tramite CRC) avviene in entrambi i casi.<\/p>\n

Conclusione<\/h3>\n

\nAlla fine dell'articolo vorrei dire questo. L'ultima tabella \u00e8 piuttosto confusa. Tuttavia, mi sono fermato su di essa perch\u00e9 \u00e8 fornita in abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer.<\/a><\/noindex>, su cui mi baso. Nella seconda parte del mio articolo intendo approfondire la specifica BlueTooth 4.0. L\u00ec ci aspettano schemi e disegni pi\u00f9 corretti. Nella terza parte, vorrei analizzare il log ottenuto tramite il programma Wireshark da uno dei gadget e vedere 'dal vivo' tutta quella teoria che stiamo studiando.<\/p>\n

Dipendente del Gruppo Aziendale \u00abCesare Satellit\u00bb<\/a><\/noindex>
\nPechersky Vladimir
\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b…) \u0427\u0430\u0441\u0442\u044c 1, \u043e\u0431\u0437\u043e\u0440\u043d\u0430\u044f \u0423\u0436\u0435 \u043f\u0440\u043e\u0448\u043b\u043e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u0441 \u0442\u0435\u0445 \u043f\u043e\u0440, \u043a\u043e\u0433\u0434\u0430 \u0432\u044b\u0448\u043b\u0430 \u043f\u0435\u0440\u0432\u0430\u044f \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u043d\u0430 Bluetooth 4.0. \u0418, \u0445\u043e\u0442\u044f \u0442\u0435\u043c\u0430 BLE \u043e\u0447\u0435\u043d\u044c \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0430, \u043e\u043d\u0430 \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043e\u0442\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0433\u0438\u0445 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432, \u0438\u0437-\u0437\u0430 \u0441\u0432\u043e\u0435\u0439 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u043b \u0432 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u043c \u0441\u0430\u043c\u044b\u0439 \u043d\u0438\u0436\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c Link Layer \u0438 Physical Layer. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84025,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84024","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47BLE al microscopio (ATT e GATT\u2026) | ProHoster","description":"BLE al microscopio (ATT e GATT...) Parte 1.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b\u2026) | ProHoster","og:description":"BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b...) \u0427\u0430\u0441\u0442\u044c 1.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-04T17:42:32+00:00","article:modified_time":"2020-06-04T17:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84024","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:06:38","updated":"2022-09-28 11:11:59","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84024","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=84024"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84024\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/84025"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=84024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=84024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=84024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}