Skip to content

Overview Xesar Software

You can find a lot of resources in different languages on how to setup and operate Xesar itself. A trusted EVVA partner will help you get started, especially with all the hardware - access components

Xesar provides a third party pub/sub interface via MQTT, that can be used to integrate and orchestrate Xesar from your own services.

Publish/subscribe messaging, is a form of asynchronous machine-2-machine (M2M) communication that can be used in event driven domains.

The main elements in a pub/sub messaging model are:

  • topics: identify an actual communication channel
  • messages: the content that is transmitted on a topic
  • publishers: generate and publish messages to a topic
  • subscribers: subscribe to a topic to receive messages
  • broker: brings publishers and subscribers together by providing the mechanism for receiving messages from publishers and forwarding messages to subscribers for the respective topics.
  • clients: are applications that connect to brokers and can be publishers and/or subscribers.

Any message published to a topic is immediately received by all the subscribers to the topic. A publisher doesn’t need to know who is going to receive the messages that are sent and the subscribers don’t know or need to know who sent the message.

The Pub/sub model allows a loose coupling between client applications in order to increase performance, reliability and scalability.

Publish/Subscribe on a broker

An access control system is a highly asynchronous distributed system.

  • You never exactly know when somebody needs to pass through a door
  • Or when they pass through an update point to receive an actualization for their access credentials
  • Or when access rights need to be changed. Or when an access credential is reported as lost

The domain consists of a lot of not easily predictable events and that is exactly where add-on’s usually come in: you want to extend the system, attaching yourself as a handler to one of these events.

REST is not a good match for this. Sure we could register a lot of callbacks, but then one needs to handle the security and the load of all this http callbacks. And all of this needs to be typed, versioned and handled throughout changes.

We think that a more interactive, better scalable Pub/Sub approach is a natural fit. Also, this interface could still be easily wrapped in a REST Adapter.

Xesar 3 comes with a broker and the backend publishes and subscribes various topics. A summary of these topics is presented in the following tables:

TopicWhatDescriptionXesar is
xs3/1/ces/{EventName}System EventsEmits system events that are generated by commands from the interfaces (M2M or Human UI)PUB
xs3/1/aseAccess Control System EventsEmits access control system events that are generated by the EVVA access control components when they are collected by the system through the maintenance or the virtual network.PUB
xs3/1/cmd/{CommandName}Command RequestsReceives commands to enable uses cases on the M2M interfaceSUB
xs3/1/qQuery RequestsReceives queries for data collected in the system.SUB
xs3/1/{User ID}/qQuery ResultsEmits answers to previously received queries.PUB
xs3/1/{User ID}/errUser-specific error topicEmits errors for previously received queries or commands.PUB
xs3/1/mss/ces/{EventName}Self Service Mode EventsEmits events that are used to support Smartphones as identification media using the Xesar mobile SDKPUB

For the full Xesar Third Party API Documentation, please refer to Third Party Interface API There you can find the link to the latest published and downloads for the current and historical versions.

To help getting started you can use our API client for Node/NestJS. We have build these open source so you can either use them directly or just learn from them if you want implement it in other languages. You are also welcome to contribute to the development directly on GitHub, reporting issues and proposing enhancements or fixes using PR’s.

Tip: It’s based on a nest-mqtt library that provides annotations for MQTT Topics. These can be used as well in parallel to our own client if some function is not supported there, yet.

You can find a part dedicated to how you can obtain access here.

The central use case we built the Mobile SDK for is likely integrating a Xesar Mobile Key in your own Mobile Application. The corresponding guide can be found here.