Location Services

 View Only
last person joined: 9 days ago 

Location-based mobile app development and Bluetooth-based asset tracking with Meridian. Gathering analytics and business intelligence from Wi-Fi with Analytics and Location Engine (ALE).

ALE API Publish/Subscribe API

This thread has been viewed 18 times
  • 1.  ALE API Publish/Subscribe API

    Posted Jun 29, 2020 10:54 AM

    Hi,

     

    I'm developing an app wich uses ALE data, I was using HTTP ALE REST API, but 3 days ago I noticed that ALE has a Publish/Subscribe API, so I start to dig a little more to make my code more efficient, what I found was poor information about ALE Publish/Subscribe API.

     

    Now I achieved what I was trying to do, be able to recieve events instead of send HTTP request each X secs. So I want to share some knwoldge with you.

     

    Before start your ALE server should be able to send events to know that please run the following command:

     

    /opt/ale/bin/feed-reader

     

    you should be able to see events with it's own data, if is not the case, solve the problem.

     

    ALE uses protobuffers wich is a secure method that google developed some time ago, so all messages and events will came as buffer type, unreadable unless you use kind of template to know wich fields and types cames from the buffer. Those 'templates' are called .proto files, so a proto file has the structure from a message wich can be used to decode the buffer.

    evanegasal_1-1593442066394.png

    It isn't enough to have the event structure on the .proto file, because the buffer message cames with a lot of data indeed, that's why we need to use a global message structure, to know those data. Aruba ALE documentation mention that as a nb_event message, that structure must be used to decode all messages you required to, obviously you could change part of the structure.

    evanegasal_0-1593441889554.png

    In the case of event name, which as I mentioned is a buffer too, it is not necessary to have a message structure, to get the event name you need to convert hex to char for example.

     

    <Buffer 70 72 65 73 65 6e 63 65>
                  P  R   E  S   E  N   C   E

     

    With the event name decoded, now you can handle different events.

    When a message is completely decode, and you see some Buffer types, just convert hex to char or to number as needed. This could happened with ip's.

     

    I created a github repo with an example made in NodeJS:

     

    Github repository 


    #ALE