M2M

AMQP message accepted : encoding on the wire

We saw the AMQP builtin type system, we sent a message to the broker …. now, how is encoded the receive confirmation from the broker itself ?

In this case, the so called performative is the disposition (format code 0x15, page 71 on official specification) that has some fields all filled in a lot of cases.

amqp_disposition

Of course it has the descriptor 0x00 0x53 and 0x15 as format code and it’s a list 0xC0 with 0x09 bytes distributed on 0x05 fields.

The first field is role that defines the role of the peer that could be sender or receiver. In this case the value is 0x41 that is the “true” value for the boolean type (page 26 of official specification). Why ? What’s the relationship between role and boolean ? The role type is defined as a restricted type that has boolean has source. You can see it like an inheritance because role derives from the existing boolean type restricting and/or changing the mean of the related values using choice (page 73 of official specification). In this case we have that sender is “false” and receiver is “true”. In our case we have 0x41 (true) so the role is the receiver and it’s true because we send a message to the broker (to a queue) and it means that on the other side of the link, the peer is the receiver.

After role, we have first & last fields. Each message sent by the sender has a “delivery-id”. When the receiver sends the disposition to the sender to confirm received message, it needs to set the “delivery-id” of the message itself. It’s possible to define a “delivery-ids” interval so that the receiver can confirm more received messages with a single disposition. The two limits are defined by first and last fields that are of type delivery-number (page 74 of official specification) that is a restricted type with sequence-no as base (it’s a serial number as defined in RFC-1982). In our example the receiver has to confirm only one message so first is 0 and last is null. As you can see, the 0 value is expressed with the byte 0x43 that is a specific and well defined byte used to describe a 0 value (uint0, page 26 of official specification).

Next field is settled that defines the delivery status of the message on the endpoint/peer. This value is also related to the QoS (Quality of Service) and it acts as an aknowledge on messages exchanged. For example, the settled field is in the transfer disposition too; a sender can set it to true and it means to apply a “fire and forget” QoS (the sender sends the message and it isn’t interested to have an acknowledge by the receiver). If the sender set it to false, it expects to receive a disposition with settled to true from receiver (it’s a “at least once” QoS because if the disposition message is lost, the sender re-send the message). Of course, AMQP supports “exactly once” QoS (it isn’t supported by Azure).

In this case its value is 0x41 (true) because it’s defined as a boolean type;

The last field is state that defines the delivery outcome with following possible values :

  • accepted : the message was processed by the receiver;
  • rejected :  indicates an invalid and unprocessable message;
  • released : the message was not (and will not be) processed;
  • modified : message was modified, but not processed;

Due to the above outcomes, a message can go through following state transitions :

amqp_message_states

In our example the message was accepted and the field has the descriptor 0x00 0x53 0x24 where the 0x24 format code defines the accepted outcome (page 89 of official specification) that is a list. In this case the list is empty and it’s defined by the byte 0x45 used to describe an “empty list”.

AMQP on the wire : messages content framing

After the previous post on the AMQP builtin type system, I’d like to show you a different sample frame strictly related to the sending messages. For starting, I used the SASL mechanisms frame as example to understand the encoding/decoding system just because it’s one of the first exchanged frames in the protocol but every day we use AMQP to send messages so understand their encoding is much more important.

An AMQP message on the wire

Consider the following source code that uses AMQP .Net Lite library to send a simple message :

Connection connection = new Connection(address);
Session session = new Session(connection);
SenderLink sender = new SenderLink(session, "sender-" + testName, "q1");

Message message = new Message("Hello");
message.Properties = new Properties();
message.Properties.MessageId = Guid.NewGuid().ToString();
message.ApplicationProperties = new ApplicationProperties();
message.ApplicationProperties["prop1"] = 1; 
message.ApplicationProperties["prop2"] = "value";

sender.Send(message, 60000);

In the above code, we are interested in the encoding and framing used in the AMQP protocol to send the Message object on the wire. As reported on the official specification (page 38), each frame has a format as showed in the following picture (we already saw this format for the SASL frames with some “little” changes).

amqp_frame

As we can see, the real body starts with the so called performative; you can think about it as an “operation” executed against the AMQP broker (opening the connection or the session, attaching the link, transfering a message and so on).

amqp_message_01

In this case, we have the transfer performative for sending messages and the encoded frame is much more complex than the first one (SASL mechanisms).

The objective of this article is to understand how the builtin type system is used to encode the three main parts of an AMQP message.

amqp_message_format

From the above picture we’ll consider :

  • Message properties : system properties well defined by the AMQP specification and used by the broker for manipulation, routing and so on;
  • Application properties : user defined properties to carry data without using the following payload;
  • Application data : user defined payload of the message;

The content of all these parts is encoded using the builtin type system. Starting from the “Message-Properties” section we have the descriptor (0x00 0x53 0x73) where the 0x73 code defines the “AMQP properties list” (page 84 of official specification) that is a list (format code 0xC0) of 39 bytes (0x27) with only one element (0x01). This element is an UTF8 encoded string (0xA1) with size of 36 characters expressed with only one byte (0x24). This string is the “Message-Id” we set in our source code (it’s the autogenerated GUID value). You can see that there is no information to describe that this field is the “Message-Id” field but we know that because it’s the first field of the composite type “AMQP properties list”. If the “Message-Id” field weren’t explicitly set by code, it would be null but encoded inside the properties list itself. This means that all missing fields between two defined fields are encoded as null but inserted inside the list (to guarantee the fields sequence); if all subsequent fields (until the end of the list) aren’t set, they aren’t encoded inside the frame (to avoid a waste of space).

amqp_msg_properties

The “Application-Properties” section starts with its related descriptor (0x00 0x53 0x74) where the 0x74 code defines the “Application properties map” (page 86 of official specification) that is a map (format code 0xC1) of 24 bytes (0x18) with four elements (0x04). A map is a compound type in the AMQP builtin type system we didn’t see yet; it’s a collection with key-value pairs each encoded as defined in the specification.

amqp_map

In our example, we have two pairs (“prop1” = 1 and “prop2” = “value”) so four elements in the map. The name of the first key “prop1” is encoded as a UTF8 string (code 0xA1) with 0x05 a size (five characters for “prop1”) and the related value that is the string “value” is encoded in the same way. Then there is the name of the second key “prop2” and the related value 0x01 that is an integral type expressed with only one byte (format code 0x54, page 27 on official specification).

amqp_app_properties

The last part of the message is the data section (the “Hello” string) that has the descriptor (0x00 0x53 0x77) where the code 0x77 defines an “AMQP value” (page 86 of official specification) that in this case is an UTF8 string (0xA1) with 0x05 characters.

amqp_value

Changing the data as raw binary

The interesting thing is that the data part of an AMQP message could be encoded as an “AMQP value” (as previous), as an “AMQP sequence” (of values) or as pure “Binary” data.

Consider the previous example but with following changes related to the creation of Message instance.

Message message = new Message()
{
    BodySection = new Data() { Binary = Encoding.UTF8.GetBytes("Hello") }
};

Using the BodySection as Data object and the related Binary field the encoding of “Hello” string on the wire is defined as binary (0xA0) with 0x05 following bytes.

amqp_binary_data

Encoding the data in the following way is an advantage for the consumer of the message that needs to understand pure binary data and not “AMQP value” encoding.

Conclusion

The AMQP message format seems to be more complex than any other protocol but deeping into it …. it’s seems to be simpler.

Of course, there is another part in the message we didn’t consider named the “Message Annotations” that are used a lot for customization inside brokers like for Event Hubs inside Microsoft Azure Service Bus.

However, we can’t see them on the wire because we know that Service Bus traffic is encrypted (using SSL/TLS protocol) and the local AMQP broker for testing doesn’t support event hubs for clear reasons 🙂

AMQP protocol : the builtin type system by examples

One of the most interesting features of AMQP protocol is the built in type system that provides a way to represent the AMQP values inside a frame starting from primitive types to custom types (based on our application domain) and composite types (containing fields).

During this article I’ll try to explain in a simple way the main features of the type system but for better understanding you can refer the official AMQP specification available at following link.

AMQP type system : a brief introduction

First of all, any AMQP data is encoded in the following way :

amqp_type

As you can see, it has a constructor followed by untyped bytes. The constructor could be a code to represent a primitive type (named primitive format-code) or a code to represent a described type that is useful to describe custom/complex types in our application domain; a described type consists of a descriptor followed by a primitive format-code.

For example, the encoding for the “Hello world” string is the following :

0xA1 0x0B “Hello World”

where :

  • 0xA1 : it’s the simple constructor with a single byte that represents the primitive format-code for UTF8 encoded strings. This format-code has the higher nibble “A” (named subcategory) that represents a data with variable width defined by a single byte so with size between 0-255 (page 19 on official specification). The lower nibble “1” is named subtype and the entire byte represents the type UTF8 encoded string with a max length of 255 characters (page 29 of official specification);
  • 0x0B : it’s the length of the string (11 bytes). As you can see, the length is represented with a single byte as described by the previous constructor 0xA1;
  • “Hello world” : the UTF8 encoded string represented as AMQP value;

Representing a primitive type like a string is very simple because the constructor is simple itself but describing a custom type is more complex. Using the same example from the official specification, imagine you want to define a custom type “URL” (of course, it’s a string but not all strings are URLs) and to encode an URL as AMQP value. In this case, the constructor doesn’t consist of a single byte (a simple primitive format-code) but it has a descriptor followed by a primitive format-code. The very interesting thing is that the descriptor itself is a valid AMQP value so it’s encoded in the same way ! It means that we need a constructor followed untyped bytes to define a descriptor !

Referring the URL example we have :

0x00 0xA1 0x03 “URL” 0xA1 0x1E “http://example.org/hello-world” 

where :

  • 0x00 : it’s the format-code that defines a descriptor (page 18 of official specification);
  • 0xA1 : it’s the primitive format-code used to define the custom type within the descriptor. Our custom type is defined as the UTF8 encoded string “URL” so a string with max length above 255 characters;
  • 0x03 : it’s the length of the string (3 bytes);
  • “URL” : the UTF8 encoded string used to define the type with the whole descriptor;
  • 0xA1 : it’s the primitive format-code that is part of the constructor for a described type and follows the above descriptor. In this case it represents an UTF8 encoded string with max length of 255 characters;
  • 0x1E : it’s the length of the string (30 bytes);
  • http://example.org/hello-world ” : the UTF8 encoded string represented as AMQP value;

In this way we don’t represent a simple string but a more specific string because we have defined the custom type “URL” followed by the URL value.

Of course, the AMQP type system is more complex and provides a lot of simple and complex type from scalar (integral numbers, booleans, strings and so on) to collections (arrays, lists and maps). To deep into them you can refer to the official AMQP specification.

Inside a sample frame : SASL mechanisms list

After a quick introduction to the AMQP type system, we can try to analyze a real frame sniffing the AMQP traffic with Wireshark who provides a specific AMQP protocol analyzer. Of course, we can’t collect this traffic if our client connects to Azure Service Bus (queues, topics/subscriptions or event hubs) because this traffic is encrypted with an SSL/TLS connection. For this reason, to have plain (not encrypted) traffic, I used the AMQP broker built in the AMQP .Net Lite library and my Azure SB Lite as client.

01_wireshark_amqp

After TCP handshaking between client and server and after the protocol header exchange, there is the SASL traffic that is used to define the security and authentication layer that will be used for data exchange. The first is the sasl-mechanisms list frame sent from the server to the client to announce the supported authentication mechanisms (for more information, starting from page 113 of official specification).

Following a screenshot of such a frame :

02_sasl_mechanisms_frame

The first 8 bytes are part of the AMQP frame header (page 37 of official specification) as it’s defined by the specification so we have :

  • first 4 bytes (0x00 0x00 0x00 0x1B) represent the entire frame length (which is 27 bytes) as decoded by Wireshark plugin;
  • the 5th byte is the DOFF byte (data offset) which represents where the frame data starts (the starting offeset is 4 * DOFF);
  • the 6th byte is the frame type so what’s the content inside the payload. In this case it’s 0x01 that represents a SASL frame;
  • the last 2 bytes of the header are ignored in the case of a SASL frame. In a more generic AMQP frame they represents the channel and it’s the reason why Wireshark plugin decodes them as channel 0 even if it’s a non sense.

After the AMQP frame header we have the frame body that is encoded using the “awesome” builtin type system.

sasl_frame

The first byte is 0x00 (descriptor format-code), so it means that we have a not simple constructor that has a descriptor inside it for defining a custom type. What’s this custom type we are describing ? It’s the SASL mechanisms list that contains all the authentication mechanisms supported by the server. This descriptor has 0x53 as primitive format-code that indicates a fixed-one value so an integral value (ulong type on page 26 of official specification) with a size expressed by a single byte (0 – 255). The following value 0x40 represents the custom SASL mechanisms list type as defined in the official specification on page 115. As we can see on this page, it’s a composite type which is a list as we can expected and it’s represented by the following 0xC0 byte (page 29 of official specification).

In the AMQP type system, a list is a polymorphic collection (as compound type) that could contain values with different types (ex. an integral, a boolean, an array …) so it’s encoded as follow :

amqp_compound_type

There is the total size of the list in byte (SIZE) and the number of items (COUNT). Each item consists of a constructor and the related data (this is the way for the list to be polymorphic, because each item doesn’t have only the value but the constructor to specify the type too). Returning to our frame we have 0x0E that is the size of the list (14 bytes) followed by 0x01 (the number of items, only one).

But … what’s the single item inside this list ? Of course it starts with the constructor that is represented with 0xE0 and it meas the format-code for an array. In the AMQP type system, an array is a monomorphic collection so that all the items are of the same type. For this reason, it’s encoded in the following way :

amqp_array_type

The encoding is like the list type (SIZE and COUNT) but it has only one constructor to define the single type for all the items inside the collection followed by all the item values themself.

In our frame, we have 0x0B (total size of array in bytes, 11 bytes) and 0x01 (only one element inside the array). After that we have the item constructor represented by 0xB3 format-code that is a “symbol” type (page 29 of the official specification). Symbols are values from a constrained domain; you can think them as enums with a limited number of possible values. The 0xB3 code represents a symbol with a size expressed with 4 bytes, so the following 4 bytes in the frame (0x00 0x00 0x00 0x05) represent a size of 5 bytes for the symbol value.

The symbol value is “PLAIN” and it means that the broker supports only PLAIN authentication method. We can notice that the frame value isn’t encoded as a simple string (primitive format-code 0xA1 we saw previously); a symbol is used because it wants to define an “enum” due to the limited possible values for SASL authentication mechanisms (PLAIN, EXTERNAL, ANONYMOUS and so on).

amqp_sasl_mechanisms_notes

Conclusion

Finally we have decoded the frame and it means we have a list with only one element that is an array of only one element that is the PLAIN symbol !

We could ask why there is a list with an array inside it and not a simple array without external list ! From the official specification (page 22) we can see that a composite type is sent on the wire as a list and it must be always a list. The SASL mechanisms frame is described as a composite type (page 115) so it must be a list.

Inside it we have an array because the broker may support more than one authentication methods and not only one as in this example.

I hope you found this article useful to understand the AMQP type system but you have to consider this blog post as a starting point to deep into the official specification.

Mobile Camp 2015 : telemetria da Windows 10 IoT Core all’Azure Event Hubs

mobile_camp_2015

Anche quest’anno ho avuto il piacere di essere speaker al Mobile Camp organizzato da Microsoft a Napoli; quest’anno l’evento era incentrato su Windows 10 e tutte le novità di Build 2015.

Da buon Microsoft MVP su Windows Embedded ed IoT, la mia sessione era ovviamente dedicata all’embedded ed all’Internet of Things ed in particolare alla Raspberry Pi 2 con Windows 10 IoT Core.

Ovviamente, in una soluzione IoT non può mancare il Cloud con i suoi servizi e nel mio caso non poteva mancare l’Azure Event Hubs come destinazione dei dati (temperatura) trasmessi dalla Raspberry Pi 2 (utilizzando la mia libreria Azure SB Lite).

Per chi fosse interessato, il materiale è disponibile su SlideShare (slide) e su GitHub (il codice sorgente della demo).

Internet of Things “wrap up” : eventi, slides, librerie e … demo con tanto codice !!

Nell’ultimo mese ho sviluppato molto ed ho avuto il piacere di essere speaker a tre eventi nazionali ed uno internazionale in California (ma da remoto).

Sono stato notevolmente impegnato nello scrivere codice e contenuti che ho deciso di riassumere qualora possano tornarvi utili.

DSC_0389 iotday

Con le slide ho cercato di descrivere al meglio l’Azure Service Bus focalizzandomi sull’Event Hubs e sul suo utilizzo nell’ambito della telemetria IoT :

A queste slide sono legate delle demo nelle quali ho utilizzato la mia ultima libreria Azure SB Lite, grazie alla quale è possibile accedere al Microsoft Azure Service Bus utilizzando le stesse API dell’SDK “originale” ma sulle piattaforme embedded come .Net Micro Framework e .Net Compact Framework oltre che su Mono (quindi Linux) e WinRT (quindi Windows 8.1 e Windows 10). Essa è basata sulla libreria AMQP .Net Lite di cui nasconde i concetti sul protocollo AMQP.

overall

Per quanto riguarda le demo :

  • BLE2Azure : concept di un IoT gateway da dispositive BLE verso Azure (Event Hubs) realizzato con il .Net Micro Framework e le board FEZ Spider e Netduino 3 Wi-Fi
  • Azure SB Lite Examples : esempi di utilizzo della libreria Azure SB Lite che mi hanno permesso (in quel di Venezia) di spiegare come funziona realmente l’accesso al Service Bus attraverso il protocollo AMQP e scoprire cosa ci sia al di sotto delle semplici APIs.

 Ovviamente non mi fermo qui nonostante il meritato riposo !

🙂

Netduino : la nuova “terza” generazione anche con Wi-Fi integrato

Ed ora … posso finalmente scrivere qualcosa !! 🙂

Circa due settimane fa ho ricevuto un bel regalo dalla Secret Labs (grazie a Chris Walker) … la nuova scheda Netduino 3 Wi-Fi !

WP_20150429_22_18_19_ProWP_20150429_22_18_35_Pro

Personalmente, ho iniziato la mia “carriera” con il .Net Micro Framework utilizzando le board Netudino e Netduino Plus (prima e seconda generazione), divertendomi tantissimo nello sviluppo di driver gestiti per i componenti ad esse collegati. Con l’esplosione dell’Internet of Things, ho iniziato a sviluppare la mia libreria M2Mqtt ed a testarla sulla versione della board dotata di connessione Ethernet, ma per quanto riguarda il collegamento con i servizi Azure come il Service Bus (event hubs, queues e topics/subscription) mi sono dovuto fermare a causa di un grosso problema: il mancato supporto per il protocollo SSL/TLS ! (necessario per Azure).

Ufficialmente a partire da ieri (ma poche settimane fa per me) … non abbiamo questo limite ! La “terza” generazione delle board della famiglia Netduino supporta i protocolli sicuri come SSL/TLS e quindi fornisce la possibilità di connettersi a tutti i servizi Microsoft Azure ! 🙂

Per ora, solo la versione Wi-Fi è già disponibile su Amazon qui e la versione Ethernet sarà disponibile nel mese di giugno qui.

L’hardware

Parlando della Netduino 3 Wi-Fi, questa scheda ha un STM32 MCU (microcontrollore a 32 bit) Cortex-M4 a 168Mhz con 2 MB di Flash dual-bank e 256 KB di RAM. Naturalmente, a causa del .Net Micro Framework TinyCLR abbiamo fino a 1408 KB per il nostro codice applicativo (in Flash) e circa 164 KB di RAM disponibile. Per me, si tratta di enormi quantità di memoria per le applicazioni embedded complesse !

netduino3wifi

Abbiamo lo stesso pulsante ed il led come le schede precedenti e tutti i pin, 22 pin digitali e analogici come GPIO, che possono essere utilizzate con le seguenti caratteristiche specifiche :

  • Porte UART
  • Segnali PWM
  • Porte SPI
  • Porte I2C

La grande differenza con le schede precedenti è la presenza di 3 porte GoBus 2.0 e sembra che la Secret Labs stia sviluppando nuovi componenti da connettere ad essi. Se volete sapere che cosa è GoBus, potete approfondire con il seguente articolo : sembra essere una caratteristica simile a .Net Gadgeteer ma ha molteplici differenze.

Il modulo Wi-Fi è una grande caratteristica in più perché è completamente integrato sulla scheda senza la necessità di un dispositivo esterno. Il chip è un TI CC3100 (Texas Instruments), con tutte le certificazioni necessarie e supporta 802.11 b/g  n con SSL/TLS ed i tre livelli di sicurezza: aperto, WEP e WPA2.

Ultima caratteristica ma non meno importante è il connettore microSD (fino a 2 GB) per la memorizzazione dei dati.

Il software

Naturalmente le nuove schede Netduino sono tutti basate sulla più recente versione del .Net Micro Framework (4.3 QFE2-RTM) e tutto il codice è open source: si può trovare il porting per Netduino su GitHub.

Una grande differenza con il passato è il Netduino.IP: il nuovo stack TCP/IP per .Net Micro Framework. Come sappiamo, uno dei grandi problemi del .Net Micro Framework è lo stack di rete che non è molto affidabile. Per questo motivo, Secret Labs ha deciso di iniziare il nuovo progetto di cui sopra con lo sviluppo di uno stack TCP/IP completamente gestito ed avere il pieno controllo su di esso. Naturalmente, questo nuovo “nato” è ancora in Technical Preview e sotto test ogni giorno per migliorare le sue featues e prestazioni. La buona notizia è che ha supporta per le classi standard in System.Net  (Socket, HttpWebRequest, …) per garantire retrocompatibilità ed utilizza solo 4 KB di RAM. Come progetto open source, è disponibile su GitHub per due chip Ethernet: il solito Microchip ENC28J60 e Asix AX88796C.

Per quanto riguarda il supporto Wi-Fi, lo stack TCP/IP per il TI CC3100 è in un altro progetto (che sarà assimilato nel Netduino.IP) disponibile qui. In questo caso, abbiamo il pieno supporto per la classe SslStream per SSL/TLS 1.2. Questo progetto è in fase di sviluppo ed ha alcune alcune limitazioni relative al numero di socket aperte simultaneamente e buffer. Le prestazioni potrebbero essere superiori perché la versione corrente usa l’UART per comunicare con il chip ma il supporto SPI arriverà presto.

Dal punto di vista degli sviluppatori, abbiamo Visual Studio 2013 ma è già pronto il supporto per Visual Studio 2015.

Infinite possibilità

Con questa nuova terza generazione, ora abbiamo molte possibilità nell’ambito dell’Internet of Things con la famiglia delle board Netduino. Il grande vantaggio è l’accesso a tutti i servizi Microsoft Azure come Event Hubs (e tutti gli altri servizi del Service Bus) e di tutti i servizi on-line che hanno bisogno di supporto SSL (le Twitter APIs per esempio). Ho già provato la mia board nelle ultime due settimane ed ho avuto buoni risultati usando la libreria AMQP Net Lite per la connessione al Service Bus e con la mia libreria M2Mqtt con un broker MQTT nell’iinviare e ricevere molteplici messaggi. Tutti i miei test sono correlati al lato client dell’uso della board poichè non concordo nell’avere un server su un dispositivo embedded per motivi di sicurezza, quindi non ho approfondito le funzionalità disponibili per sviluppare un server HTTP(S) a bordo. La scheda con tutti i relativi stack software sembra essere affidabile ma la performance potrebbero essere migliorate. So che Chris lavorerà duramente nei prossimi mesi per fornire nuove funzionalità e miglioramenti per darci un prodotto migliore per collegare le “nostre” cose all’Internet degli oggetti in rete.

Quail : una nuova board basata su .Net Micro Framework … in città !

C’è una nuova board per .Net Micro Framework in città !

Negli ultimi mesi, MikroElektronika ha rilasciato la Quail board come una soluzione per la creazione di prototipi hardware utilizzando tutte le migliori caratteristiche del .Net Micro Framework e le relative schede, note come “click” board, per differenti tipi di dispositivi esterni, come i sensori (umidità, temperatura , …), modulo WiFi, OLED e così via.

quail_board

La Quail board si basa sul sull’MCU STM32F427, un Cortex-M4 a 180 Mhz con 2 MB di Flash e 256 KB di RAM con il relativo porting di .Net Micro Framework 4.3. Insieme alla MCU possiamo trovare 8 MB di Flash esterna, una porta USB per una memoria di massa esterna (oltre che alla porta USB per il debug e l’alimentazione della scheda da PC) e 24 “morsetti a vite” (per evitare di utilizzare una “click” board e collegare un dispositivo direttamente alla scheda).
Per semplificare la prototipazione, ha quattro socket su cui è possibile utilizzare a quattro “click” board, senza necessità di saldare i componenti. Queste socket non sono come i socket .NET Gadgeteer che conosciamo ma MikroElektronika ha sviluppato un nuovo tipo di socket standard chiamato MikroBUS.

mikroBUS

Una socket MikroBUS è costituita da due collettori femmina entrambe con 8 pin relativi alle funzioni più utilizzate della MCU :

  • SPI, UART e I2C pin per la comunicazione con altri componenti come sensori e così via;
  • Pins con funzione singola come PWM, interrupt, ingresso analogico, Reset e Chip Select;
  • Pins per l’alimentazione di dispositivi esterni con + 5V, + 3.3V e la massa;

Tutte le schede fornite da MikroElektronika che supportano il MikroBUS sono chiamate “click” board (circa 50 finora) perché è così semplice collegarli alla Quail … con un semplice “click”!

L’idea di questa nuova scheda con il relativo supporto per il .Net Micro Framework è partita grazie ad una collaborazione tra MikroElektronika e un team di professionisti di software e hardware dalla Francia chiamato MikroBUS.Net. Grazie a questa squadra abbiamo a disposizione un SDK per l’utilizzo del MikroBUS a bordo della Quail (come altri SDK per schede Netduino e .Net Gadgeteer) e il codice sorgente (in C#) dei driver scritti per tutte le “click” board.

Oltre alle “click” board è possibile riutilizzare i moduli .NET Gadgeteer (da GHI Electronics), grazie ai G-Adapters che sono in grado di adattare la socket .Net Gadgeteer con la socket MikroBUS. Fino ad oggi non tutti i driver sono disponibili per tutti i moduli, ma il team sta ancora lavorando su di essi. Un’altra caratteristica interessante è la “Virtual Soscket”: è possibile collegare un componente alla scheda utilizzando i morsetti a vite senza usare il MikroBUS. In questo modo è possibile utilizzare il driver fornito, anche se non si ha il componente montato su una “click” board.

Naturalmente è possibile sviluppare le applicazioni utilizzando un IDE di prima classe come Visual Studio 2013 (anche la Community Edition) ed in codice gestito con C # come linguaggio.

Questa è solo una breve introduzione, ma in futuro entreremo nel dettaglio per capire come utilizzare e sviluppare con questa interessantissima scheda !

Internet of Things a Napoli : una giornata all’insegna delle “cose” e del “cloud”

Ieri si è tenuta a Napoli la terza edizione della Microsoft Embedded Conference, ormai rinominata in Internet of Things Conference ed organizzata dalla community DotNetCampania grazie al supporto di Microsoft Italia.

Come ogni anno la giornata, completamente gratuita, ha avuto un ottimo riscontro considerando soprattutto l’argomento trattato ed il livello elevatissimo degli speaker, tutti Microsoft MVP per Windows Embedded ed IoT. Ad essi si sono aggiunti Erica Barone, Techincal Evangelist di Microsoft Italia, e Olivier Bloch (con una sessione remota da Redmond), Techical Evangelist di Microsoft Open Tech.

La giornata è iniziata proprio con Erica che ci ha fornito una panoramica generale su come Microsoft intende l’IoT e quali sono tutti i servizi Cloud che mette a disposizione per la realizzazione di sistemi più o meno complessi. A seguire, io ho tenuto una sessione tecnica ed approfondita sull’ultimo nato tra i servizi del Service Bus di Azure : l’Event Hubs. La mattinata si è conclusa con Mirco Vanini che ci ha illustrato il programma Windows Developer for IoT parlando ovviamente anche della Intel Galileo.

DSC_0342 DSC_0384

DSC_0389 WP_20150418_12_21_02_Pro - Copia

Il pomeriggio è iniziato con Beppe Platania e Gianni Rosa Gallina che ci hanno prima illustrato una soluzione reale di IoT implementata anche attraverso l’utilizzo del .Net Micro Framework e successivamente alcuni interessanti progetti su cui stanno lavorando nell’ambito dei wereable e della realtà aumentata. A seguire, la sessione di Lorenzo Maiorfi sull’utilizzo del progetto Orleans nell’ambito IoT : Lorenzo ha avuto un enorme successo con la sua demo basata anche su Bluetooth e Beacon che mi ha visto protagonista come “navetta” per la quale riuscirne a tracciare il percorso effettuato.

DSC_0390 DSC_0405

DSC_0411 DSC_0427

DSC_0438 DSC_0445

La giornata si è conclusa con una sessione in coppia con Valter Minute e, direttamente da Redmond in remoto, Olivier Bloch che si è svegliato molto presto (alle 6:00 del mattino) solo per noi. Ovviamente, a lui va un ringraziamento particolare !

Come sempre la giornata è stata resa possibile grazie all’aiuto di tutti i ragazzi della commnunity : Antonio Liccardi che ha gestito interamente la logistica, Carmine Alfano ed Emanuele Garofalo che da ottimi fotografi ci hanno regalato i momenti principali dell’evento ed i principali sponsor come Nova Tech Consulting (Mario Saccoia), Blexin (Michele Aponte, presidente del DotNetCampania) e QT2000 (Gaetano Criscuolo). Un grazie va anche a tutti gli altri che vi hanno partecipato con grande intersse !

Grazie a tutti … ed arrivederci all’anno prossimo !

😉

Agenda piena : In viaggio per l’Internet of Things !

IoYT - Campaign_500

E’ stato e sarà un periodo molto intenso per me … e se volete sentirmi parlare di Internet of Things in giro per l’italia (e per il “mondo”) non vi resta che leggere l’agenda dei prossimi appuntamenti !

Domani, Sabato 18 Aprile, ci sarà la terza edizione della Microsoft Embedded Conference a Napoli ormai diventata Internet of Things Conference organizzata come sempre dalla community DotNetCampania anche grazie alla sponsorizzazione di Microsoft Italia.

Il 28 Aprile sono stato invitato come speaker alla più importante conferenza italiana sull’M2M : l’M2M Forum. In quel di Milano avrò una sessione sulla “Azure IoT Suite” insieme a Roberto Andreoli ed Erica Barone di Microsoft Italia.

Sabato 25 Aprile, il mio amico statunitense Samuel Phung mi ha gentilmente invitato a tenere una sessione remota per il Global Azure Bootcamp che si terrà in California. Sarà per me un’altra esperienza di una presentazione in inglese dopo quella a Seattle con la Toradex.

Infine, chiuderò l’8 Maggio a Venezia con l’IoT Day organizzato dalla community XeDotNet di cui fa parte Mirco Vanini (che ringrazio per l’invito).

Tutte le sessioni avranno un unico filo conduttore quale Azure e l’Event Hubs ed a Venezia la sessione sarà anche un “under the hood” entrando nelle stanze oscure del protocollo AMQP.

Insomma … agenda piena … e voi … avete voglia di ascoltare qualcosa sull’IoT ?

😉

MQTT & Eclipse Paho : nuove versioni per il client M2Mqtt ed il broker GnatMQ !!

Finalmente la nuova versione M2Mqtt 4.1 è stata rilasciata !

Negli ultimi mesi, la mia libreria è stata messa sotto pressione grazie ai miei amici Olivier Vigliengo (Adeneo) e Nicolas Besson (Microsoft MVP su Windows Embedded, Adeneo). Essi hanno usato il client MQTT per i loro progetti hobbistici, stressandolo non poco !

Dopo un fitto scambio di email e letture di log traces, ho risolto una serie di bug ed aggiunto degli miglioramenti :

  • L’evento di “published” fornisce la flag IsPublished (nell’event args) grazie alla quale poter capire se il messaggio è stato realmente pubblicato oppure no a causa del timeout (l’evento viene sollevato lo stesso);
  • Alcuni cambi “interni” per la gestione degli eventi;
  • Fixato un bug su timeout negativo;
  • Migliorata la stabilità della libreria in condizioni di rete poco affidabile;
  • Fixato un bug sulla gestione delle sessioni;
  • Aggiunte le informazioni di trace sul “queueing” dei messaggi;

Ovviamente, questi cambiamenti hanno avuto il loro impatto anche sul broker GnatMQ che è ancora in Beta ma che mi piacerebbe rilasciare al più presto : spero che le persone che lo usino mi diano dei feedback (sembra che il team di XSocket lo stia usando per fornire il supporto MQTT alla loro piattaforma) 🙂

Come sempre potete trovare M2Mqtt nel progetto Eclipse Paho, su CodePlex e su Nuget. Il broker GnatMQ è disponibile solo su CodePlex. Infine, ho aggiornato anche il progetto M2Mqtt4CE (per Windows Embedded Compact 2013) su CodePlex.