Avimesa Messages is the cloud platform powering the Avimesa IoT Solution. Avimesa Messages has two major (Internet) endpoints you’ll need to know about in order to work with it: a device-side endpoint, devices.avimesacorp.net, that manages TCP connections from all Avimesa-enabled devices and an application-side endpoint, queues.avimesacorp.net, that manages AMQP connections via a RabbitMQ cluster. Avimesa clients will use Avimesa Gadget to enable any Linux-based device with TCP connectivity to our cloud and will almost assuredly use our Avimesa Client API for RabbitMQ connectivity.
Avimesa Dialtone, or simply Dialtone, is the language of the Avimesa IoT ecosystem. The Dialtone protocol, defined by Avimesa, is being used under the hood of Avimesa.Live and in almost every other building block of the Avimesa IoT Solution. Dialtone is used by Avimesa Messages to transmit an OTA DFU (over-the-air device firmware update) to an Avimesa-enabled device out in the field, it’s being used by an Avimesa Gadget client to transmit data into the cloud, and it’s being used to administer your Avimesa-enabled system when using the Avimesa Client API. Dailtone, from a developer’s standpoint, is more simply a JSON-based (JavaScript Object Notation) data schema used for communication with and control of the Avimesa IoT ecosystem. Most of the tools we offer, namely Gadget and our Client API, handle a lot of the Dialtone heavy lifting but there are areas in the Avimesa IoT ecosystem where a client is required to interact with Dialtone.
Avimesa Messages
Provided here are summaries of the technologies users will encounter when working with Avimesa Messages.
RabbitMQ and AMQP and Avimesa Client Credentials
Avimesa manages a RabbitMQ cluster within our cloud for client application communication. RabbitMQ uses a communication protocol known as AMQP for secure, queue-based messaging over the internet. Avimesa’s clients are provided with and granted access to a grouping of queues, namely a virtual host, which serves as the main interaction point between client applications and our cloud. The Avimesa Client API we provide completely implements an AMQP client tailored for communication with our RabbitMQ cluster.
Your Avimesa Client Credentials can be found in your Avimesa.Live account and are primarily used to access your virtual host in our RabbitMQ cluster.
We highly recommend that developers wishing to develop their own application around the Avimesa IoT Solution use our API: it will reduce your explicit exposure to Dialtone and greatly reduce development time. A developer could theoretically build their own AMQP client for our RabbitMQ cluster. However, any AMQP client designed to target our RabbitMQ cluster would have to explicitly use quite a bit of Dialtone and adhere to our specific, authoritative virtual host architecture which cannot be altered, resulting in a rather exhaustive list of design requirements. Please send any questions you might have to support@avimesa.com.
The JavaScript Runtime
This is where quite a bit of you’re explicit Dialtone interaction will occur. The JavaScript runtime is a JavaScript Engine, adhering to ECMAScript 5.1, that is used to run a per-device script on device communication with our cloud. The script, either the default we’ve upload for you upon device creation or a custom one you’ve uploaded via our Client API, must initially deal with device data in the Dialtone format. The default script scenario: the JSON-formatted Dialtone message is unaltered and passed along to RabbitMQ. The custom scenario: your uploaded script either terminates the JSON-formatted Dialtone message through transposition and passes it along to RabbitMQ or it is unaltered and passed along to RabbitMQ. A side note: you can also choose to simply drop some or all of your Dialtone data during JavaScript runtime execution…
Messaging Directions
This section is somewhat supplemental and can be skipped if you’re no stranger to messaging over the internet.
It’s very important that we make clear that there are two directions in which messages flow in almost any IoT Solution (including Avimesa’s): 
Here we see a message flowing from an application to the cloud and then to a device and following we see a message flowing from a device to the cloud and then to an application. This is pretty important stuff when it comes to successfully developing an IoT Solutions but it’s not enough. For completeness: 
Here, we see the same patterns from the first depiction plus acknowledgements. At first glance, acknowledgements from the cloud may seem secondary but they’re arguably just as important as our actual messages. Acknowledgements are digital handshakes – I got your request!
The Dialtone Schema
A skinny, need-to-know look into Avimesa’s JSON-based Dialtone schema and what you’ll explicitly be dealing with when using Avimesa as your IoT provider.
Device Data (Sending and Receiving)
You’ll encounter this JSON-formatted Dialtone either in the cloud (the JavaScript runtime) or in your application (unaltered and passed on by the JavaScript runtime). You’ll also encounter a portion of this JSON when using Avimesa Gadget to send data.
Here’s exactly what it’ll look like:
{
api_maj: 0,
api_min: 11,
dts: 1536783776,
dev: {
dev_id: "000102030405060708090a0b0c0d0e0f",
dev_data: {
dev_type: 1,
fw: 1,
hw_rev: 48,
bat: 100.00,
rssi: 0,
temp: 25.00,
dev_sts: 1
},
chans: [{
ch_idx: 0,
ch_data: [{
data_idx: 0,
units: 1,
val: 0.003
},
{
data_idx: 1,
units: 1,
val: 7.53
}]
},
{
ch_idx: 1,
ch_data: [{
data_idx: 0,
units: 1,
val: 5.0
}]
}]
}
}
And here’s a table of what all of this means:
| Attribute | Description | Data Type |
|---|---|---|
| api_maj | Dialtone Schema Major Revision | Number |
| api_min | Dialtone Schema Minor Revision | Number |
| dts | Timestamp applied in cloud upon device communication – Unix Epoch | Number |
| dev | Device object | Object |
| dev.dev_id | Device ID of communicating device | String |
| dev.dev_data | Device metadata object | Object |
| dev.dev_data.dev_type | Device type where message originated – Avimesa 1000, Avimesa Gateway, Gadget Client | Number |
| dev.dev_data.fw | Device firmware / software revision | Number |
| dev.dev_data.hw_rev | Device hardware revision | Number |
| dev.dev_data.bat | Battery level | Number |
| dev.dev_data.rssi | BLE Received Signal Strength Indicator | Number |
| dev.dev_data.temp | Device onboard temperature | Number |
| dev.dev_data.dev_sts | Device status (dependent on dev.dev_data.dev_type) | Number |
| dev.chans | Device data channel array | Array |
| dev.chans[…].ch_idx | Data channel index (think of it as data channel number or ID…) | Number |
| dev.chans[…].ch_data | Data channel data array | Array |
| dev.chans[…].ch_data[…].data_idx | Data channel data index (think of it as data channel data number or ID…) | Number |
| dev.chans[…].ch_data[…].units | Data channel data data type (1 – Number – only data type at this time) | Number |
| dev.chans[…].ch_data[…].val | Data channel data data – (actual data) | Number |
Implicit Dialtone
The Client API obscures almost all client-initiated Dialtone and also handles cloud acknowledgements, AMQP events, AMQP errors, and cloud errors. Again, we highly recommend using our AMQP Client API. But if you just have to develop your own Avimesa AMQP client, you can start here.