1. Home
  2. Docs
  3. Documentation
  4. Avimesa Messages and Avimesa Dialtone

Avimesa Messages and Avimesa Dialtone

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): simple-messaging.png

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: complex-messaging.png

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.