Skip to main content

BAS-IP Android panels API interaction description

The following document outlines some API routes available for the next models of BAS-IP individual, and multiapartment outdoor panels (but not limited to):

  • Individual panels with 2 MP camera, and with face recognition features:
    • av-08fb
  • Panels with keyboard, 4 inch display, and with face recognition features (face recognition endpoints tagged with FB tag):
    • aa-07fb
    • aa-12fb
    • aa-12fb2m
  • Panels with 10 inch touch screen, and with face recognition features:
    • aa-14fb
    • aa-14fb2m
  • Panels with keyboard, 4 inch display, 1 MP camera, and without face recognition features:
    • aa-07
    • aa-07b
    • aa-07bc
    • aa-07bv
    • aa-07mf
    • aa-09b
    • aa-09bv
    • aa-09e
    • aa-11b
    • aa-11bv
    • aa-11e
    • aa-11m
    • aa-12
    • aa-12b
  • Panels with keyboard, 4 inch display, 2 MP camera, and without face recognition features:
    • aa-07b2m
  • Panels with direct call buttons, without display, and with face recognition features:
    • bi-02fb
    • bi-04fb
    • bi-06fb
    • bi-08fb
    • bi-12fb
  • Panels with direct call buttons, without display, and without face recognition features:
    • bi-02b
    • bi-04b
    • bi-06b
    • bi-08b
    • bi-12b

Shortcomings

This document describes the requests and responses can be sent to and received from the devices, but does not describe device interaction with other structures, such as authorization or token refresh on the Link management server, identifiers validating on the 3d-party remote management servers etc. This information can be obtained upon request and will be added to the documentation in the future.

This document does not describe all the capabilities of the devices, but only the main parts and the key interaction between the components, to familiarize yourself with all the features, please refer to the API specification.

Authentication​

Bearer Authentication​

API offers bearer authentication without support of refresh tokens. Token storage time - 2 hours.

Basic auth​

Basic auth available according to the RFC7617.

Device features​

Getting basic information about the device​

To get basic information about the device - its model, serial number and firmware version, you need to make a GET request to the /api/info endpoint.

In responce you will get similar values:

{
  "firmware_version": "3.10.0",
  "framework_version": "1.2.0",
  "frontend_version": "1.2.0",
  "api_version": "2.1.0",
  "device_name": "AA-07",
  "device_type": "panel",
  "device_serial_number": "203684c4-31d4-49c2-894c-832962f66690",
  "hybrid_enable": true,
  "hybrid_version": "LASKOMEX SW 2.2, HW 0.3R1",
  "commit": "e8e99362d3e03515608165817715d029dc60591e"
}

where

  • hybrid_enable - is there a module in the panel allows communication with analog intercom systems
  • hybrid_version - version of the installed analog communication module

Interaction with Link and 3d-party servers servers occurs using REST API, this document describes requests to the device and device responses, requests from the device will be referenced in the document sections involve corresponding functionality.

Link server, device web interface, and third-party servers use the same API to interact with the device, but there are some differences in how the Link and the web interface interact with the device table entities.

Device web interface allows you to work with table entities such as identifiers, apartments, forwards, and time profiles one at a time, as the user does. When creating an entity, it is created with a local uid, which is unique only within this device and which is used as a unique key for working with the entity.

For management from the server, the ability to use mass entity management is required, besides, a frequent task is to synchronize the same entities on different devices, which makes it impossible to use uid as a unique entity key.

To solve this problem, link_id is used, which is a unique number of the entity on the Link server or a third-party server.

Device auth on server​

Device uses JWT for auth purpsoses.

Device authentication and authorization on the server, and subsequent interaction with requests are performed as follows:

  1. Device sends login/password to the server.
  2. In case of successful authentication, the server sends to the device access token and refresh token.
  3. For each subsequent request, device uses access token in the header.
  4. If server replies that access token's lifetime has expired, then device sends a refresh token to receive a new access token from server.
  5. If server replies that refresh token's lifetime has expired, then device must authenticate with the login/password again to receive a new pair of tokens.

Heartbeat​

On 3d-party server side it's possible to implement the panel's heath status using this feature.

Panel can send a POST request to the server /devices/pong endpoint with its type, model name, and serial number as string resources once every 10 seconds, letting server know that it's still online.

{
  "type": "panel",
  "model": "AA-12",
  "serial_number": "203684c4-31d4-49c2-894c-832962f66690"
}

Feature can be enabled by the heartbeat parameter in the /network/management/link endpoint.

Table entities CRUD and other interaction​

Device has the following entities, which are located in tables and user can interacts with them in a similar way:

  • identifiers
  • apartments
  • forwards
  • time profiles
  • users

Mass CRUD interaction notes​

When requesting to the endpoints for the mass DELETE all requested existing entities will be removed from the list, nonexistent identifiers will be skipped. When requesting to the endpoints for the mass CRUD interaction you will receive status responce about every entity operation was performed - created, updated, deleted etc.

Identifiers​

Identifier - an entity contains information about the type of identifier (card, code, face ID, QR code, license plate, etc.), its number, owner, number of the lock being opened, etc.

Following endpoints are available for basic CRUD operations:

  • Create identifier - POST to the /access/identifier. In response you will get identifier local uid, which is used to interact with identifier in the panel.

    We don't use the identifier number as an ID for it in the panel memory to avoid collisions, because identifier numbers can be the same for different types of identifiers. The same identifier, but recorded in another device may have a different local uid, if you need a unique identifier between several devices, please use link_id.

  • Create face ID identifier from photo - POST to the /access/identifier/item/face/file/{identifierUid}. It's desirable that there is one face image in the photo, otherwise the device may write to the memory the hash of the wrong face than you expect.
  • Read information about identifier - GET to the /access/identifier/item/{identifierUid}. Device will return infomation about identifiers and linked to it other entities, such as apartments, time profiles, link_id etc.
  • Update identifier - PATCH to the /access/identifier/item/{identifierUid}.

    Face ID identifier type can't be changed to another type.

  • Delete identifier - DELETE to the /access/identifier/item/{identifierUid}.

Following endpoints are available for mass CRUD operations:

  • Create/Update multiple identifiers - POST to the /access/identifier/items/link. When adding or updating entities link_id must be used.
  • Read identifiers list - GET to the /access/identifier/items. Device will return identifiers list according to the requested filters.
  • Delete identifiers list by local uids - DELETE to the /access/identifier/items.
  • Delete identifiers list by link_id - DELETE to the /access/identifier/items/link.

Apartments​

Apartment - an entity contains information about the address of the apartment owner within the existing logical addressing "building-unit-floor-apartment" and his name, this is the basic entity to which the other entities are attached - identifiers, and conditional forward rules.

Also, apartment owners names and addresses in the apartments are used in the device address book, which optionally can be displayed on the screen. AA-14 address book support user avatars, images can be uploaded by the /apartment/item/{apartmentUid}/photo endpoint.

Following endpoints are available for basic CRUD operations:

  • Create apartment - POST to the /apartment. In response you will get apartment local uid, which is used to interact with apartment in the panel.
  • Read information about apartment - GET to the /apartment/item/{apartmentUid}. Device will return infomation about apartment and linked to it other entities, such as identifiers uids, and conditional forward rules uids.
  • Update apartment - PATCH to the /apartment​/item​/{apartmentUid}.
  • Delete apartment - DELETE to the /apartment/item/{apartmentUid}.

Following endpoints are available for mass CRUD operations:

  • Create/Update multiple apartments - POST to the /apartment/items/link. When adding or updating entities link_id must be used.
  • Read apartments list - GET to the /apartment/items. Device will return apartments list according to the requested filters.
  • Delete apartments list by local uids - DELETE to the /apartment/items.
  • Delete apartments list by link_id - DELETE to the /apartment/items/link.

Forward rules​

Forward - an entity describing the conditional forwarding rule as "Full apartment number" - "Called SIP number". Each rule can contain up to 8 numbers, call to which can be performed simultaneously or in turn, changing the hop every 20 seconds, depending on the selected mode in the device settings.

Depending on the model, device can forward to the following types of numbers (a special prefix for the number is used):

  • P2P SIP/SIP. Device automatically selects which protocol to call, depending on whether it's registered on the SIP server and whether the specified number is part of this SIP server.
  • Vizit - analog intercom system, can be called using the panel with the corresponding built-in adapter.
  • Laskomex - analog intercom system, can be called using the panel with the corresponding built-in adapter.

Since device can call other devices/SIP phones using both the internal protocol and the forwarding rules, the call is made as follows:

  1. User enter the required number on the keyboard and dial
  2. Device send a broadcast request to the network to search for a BAS-IP response device
  3. If there is no responce to broadcast within 1.5 seconds, then device checks the presence of such a number in the forwarding table and if it finds it, it calls the numbers recorded for this apartment.

User can combine different types of numbers in one rule. The exception is the simultaneous use of the SIP and the Vizit/Laskomex numbers when "All at once" mode is selected - calls to analog devices can only be made in turn.

To interact with these endpoints, a logical address is used, which consists of characters that the user must enter on the device keyboard, usually this is the concatenation of the floor number and apartment number, follows we will call this entity forward_id.

Following endpoints are available for basic CRUD operations:

  • Create/Update forward rule - POST to the /forward/item/{forwardUid}. Unlike other entities, you don't get uid in the response, because forward_id is a unique identifier for this table.
  • Delete forward rule - DELETE to the /forward/item/{forwardUid}.

Following endpoints are available for mass CRUD operations:

  • Create/Update multiple forward rules with a detailed response about the status of the every rule in the request - POST to the /forward/items/link. Unlike other entities, you don't need link_id to be used, because forward_id is a unique identifier for this table. In the response, the value of the forward_id is used as the link_id.
  • Read forward rules list - GET to the /forward/items. Device will return forward rules list according to the requested filters.
  • Delete forward rules list by forward_id - DELETE to the /forward/items.
  • Delete forward rules list by forward_id with a detailed response about the status of the every rule in the request - DELETE to the /forward/items/link. In the response, the value of the forward_id is used as the link_id.

Time profiles​

Time profile - an entity which can be attached to an identifier to restrict its use by date/time/number of passes with flexible repeated rules.

In the identifier settings there is also options for using some time limits and number of passes. If the identifier uses both its own time limits and the restrictions of the associated time profile, then both will be used, but the extreme limits of use will be set by the own identifier settings.

Following endpoints are available for basic CRUD operations:

  • Create time profile - POST to the /access/timeprofile. In response you will get time profile local uid, which is used to interact with time profile in the panel.
  • Read information about time profile - GET to the /access/timeprofile/item/{timeProfileUid}.
  • Update time profile - PATCH to the /access/timeprofile/item/{timeProfileUid}.
  • Delete time profile - DELETE to the /access​/timeprofile​/item​/{timeProfileUid}.

Following endpoints are available for mass CRUD operations:

  • Create/Update multiple time profiles - POST to the /access/timeprofile/items/link. When adding or updating entities link_id must be used.
  • Read time profiles list - GET to the /access/timeprofile/items. Device will return time profiles list according to the requested filters.
  • Delete time profiles list by local uids - DELETE to the /access/timeprofile/items.
  • Delete time profiles list by link_id - POST to the /access/timeprofile/items/link.

Users​

User - an entity, which appeared in the panel firmware in version 3.13.0 along with the multi-factor authentication. User is a unifying entity to which you can bind identifiers, time profiles and apartments, and track logs for this entity, which is more typical for access control systems than the use of apartments.

In addition, for each user, you can specify the locks to open and types of identifiers user can use to access the building, the rules specified in the profile have priority over system ones.

Following endpoints are available for basic CRUD operations:

  • Create user - POST to the /access/user. In response you will get user local uid, which is used to interact with the user in the panel.
  • Read information about the user - GET to the /access/user/item/{userUid}.
  • Update user - PATCH to the /access/user/item/{userUid}.
  • Delete user - DELETE to the /access​/user/item​/{userUid}.

Following endpoints are available for mass CRUD operations:

  • Create/Update multiple users - POST to the /access/user/items/link. When adding or updating entities link_id must be used.
  • Read users list with local uids - GET to the /access/user/items. Device will return users list according to the requested filters.
  • Read users list with link_id - GET to the /access/user/items/link. Device will return users list according to the requested filters.
  • Delete users list by local uids - DELETE to the /access/user/items.
  • Delete users list by link_id - POST to the /access/user/items/link.

Entities linking​

Table entities can be linked, so when you receive data about the apartment entity you can get additional information about identifiers and forward rules in this apartment, or in the logs you can know that the lock was opened by this or that user, a call was made by such a user and so on.

Entities have the following relationships:

  • Time profiles can be linked to identifiers and users.
  • Identifiers can be linked to apartments and users.
  • Forward rules can be linked to apartments.
  • Users can be linked to apartments.

For convenient logs reading and organization of access control, we recommend making entity relationships with each other by linking identifiers, time profiles, and apartments entities with a user entity.

Make linking​

Linking between entities are possible both by local uid and by link_id of these entities.

Making linking by uid:

  • Link time profile to identifier - POST to the /access/identifier/item/{identifierUid}/timeprofile/{timeProfileUid}
  • Link time profile with user (many to many) - POST to the /access/user/item/{userUid}/timeprofile/{timeProfileUid}
  • Link identifier with apartment - POST to the /apartment/item/{apartmentUid}/identifier/{identifierUid}
  • Link identifier with user (many to 1) - POST to the /access/user/{userUid}/identifier/{identifierUid}
  • Link forward rule with apartment - POST to the /apartment/item/{apartmentUid}/forward/{forwardUid}. As forwardUid must be used used apartment_id of the forward rule.
  • Link user with apartment (many to many) - POST to the /apartment/item/{apartmentUid}/user/{userUid}

Making linking between identifiers with time profiles, and identifers with apartments can be done by adding link_id of the time profiles and link_id of the apartment to the identifiers via /access/identifier/items/link endpoint.

Remove linking​

Removing links between entities are possible both by local uid and by link_id of these entities. Removing a link does not delete the entity.

Removing links by uid:

  • Remove identifier from apartment - DELETE to the /apartment/item/unbind/identifier/{identifierUid}.
  • Remove identifier from user - DELETE to the /access/user/{userUid}/identifier/{identifierUid}.
  • Remove time profile from identifier - DELETE to the /access/identifier/item/{identifierUid}/timeprofile/{timeProfileUid}.
  • Remove time profile from user - DELETE to the /access/user/item/{userUid}/timeprofile/{timeProfileUid}.
  • Remove user from apartment - DELETE to the /apartment/item/{apartmentUid}/user/{userUid}.

Removing link between identifiers with time profiles, and identifers with apartments can be done by removing link_id of the time profiles and link_id of the apartment from the identifiers via /access/identifier/items/link endpoint.

Pagination​

Pagination works the same way for all the tables, available options are desribed in the PaginationOptions model.

Filtering in sections​

General filtering mechanism is the same for all tables, but filtering parameters are different. General filtering mechanism and references to specific filters are described in RequestFilterOptions model. For detailed information on filtering each of the tables refer to the models of these tables.

Logs​

Panels supports several modes of sending logs each of which is described below.

The logs are stored in the database for up to 6 months and are cleared every 182 days. Currently there is no limit on the number of stored lines.

Each event in the log has its own priority, category, and name. Currently available log records are presented in the table.

EventPriorityCategoryInitial firmware version
device_bootedLowInfo3.5.0
successful_login_gui_settingsMediumInfo3.6.0
incorrect_login_gui_settingsMediumInfo3.6.0
outgoing_call_webMediumInfo
incoming_callMediumInfo
outgoing_callMediumInfo
outgoing_call_missedMediumInfo
access_granted_by_master_codeMediumAccess
access_granted_by_valid_identifierMediumAccess
access_granted_by_api_callMediumAccess
access_granted_by_remote_server_api_callMediumAccess
access_granted_by_valid_face_identifierMediumAccess
access_granted_by_call_hostMediumAccess
access_granted_by_valid_license_plateMediumAccess3.13.0
lock_was_opened_by_exit_btnMediumAccess
successful_login_api_callMediumSystem
sip_registration_lostMediumInfo3.5.0
door_was_closedMediumAccess3.5.0
door_was_openedMediumAccess3.5.0
door_sensor_was_openedMediumAccess
door_sensor_was_closedMediumAcesss
emergency_lock_is_openedMediumAccess
lock_was_opened_by_free_access_buttonMediumAccess
multi_access_grantedMediumAccess3.13.0
access_denied_by_not_valid_identifierHighAccess
access_denied_by_not_valid_input_codeHighAccess
access_denied_by_not_valid_face_identifierHighAccess3.4.0
access_denied_by_remote_server_api_callHighAccess
access_denied_by_unknown_cardHighAccess
access_denied_by_unknown_qrHighAccess3.8.0
access_denied_by_unknown_qrHighAccess3.8.0
door_was_not_closed_too_longHighEmergency
tamper_eventHighEmergency
incorrect_login_api_callHighSystem
identifiers_without_linkage_to_user_access_deniedHighAccess3.13.0
multi_access_deniedHighAccess3.13.0

Polling​

By default, the device does not send logs anywhere, but you can use polling to get a log by the specified filter, device web interface does the same when you open the tab with the log.

To get the last 10 log entries you need to make a query to the /log/items endpoint in the followind kind:

/log/items?locale=en&limit=10&page_number=1

where

  • locale - required locale
  • limit - limiting the output of data in a request; available values: 10, 20, 30, 50
  • page_number - chosen page number

In response you will receive information about the total number of records on all pages, the number of pages, all records for the specified page and a list of all other available filters.

You can also filter by time, priority, category and event name. The entire list of available filters is described in the endpoint specification.

Realtime​

To send realtime logs to server this feature must be enabled in menu "Network" -> "Management system" of the device web interface or via /network/management/link endpoint.

When sending logs to Link or 3d-party server, device send logs during the origin of these events, but not more often than once per second. If device can't connect to the server then it use a buffer which is cleared when it's filled with 1k records, i.e. panel send the last 1k records to server, skip the rest of the records and Link or 3d-party server must pick them up later on its own, determining the difference by the synchronization timeout. The entire buffer is sent in one packet.

Device must authorize on the server before sending logs, process described in the relevant paragraph above.

Device send logs by the PUT requests to the /devices/logs endpont, the specification can be found in the corresponding document.

With /log/photo/link endpoint you can choose for which events the device will take a photo and send it to the server.

With /device/security/tamper endpoint you can enable or disable the log sending and turning on the siren when the tamper is triggered.

Email​

To send chosen logs events by email, the SMTP protocol is implemented with three types of encryption: TLS, SSL, none.

Via the /log/email endpoint must be set:

  • name of sender, address, login, password
  • server, port and encryption type of SMTP server
  • mail recipient address, and email subject
  • a list of logs events

List of events available via /log/email/eventlist endpoint or device web interface.

After entering the settings, make sure that the panel has access to the email by the test request /log/email/test. In other cases, depending on the security policy of the mail service, you must allow logging into your account through unsafe applications.

Email services limit the number of emails a client can send per day in accordance with the anti-spam policy. The number on average varies from 500 to 1000 per day. Therefore, if you subscribe to many events, then when the limits expire, the recipient will not be able to receive notifications about new events. So, don't overuse it.

Syslog​

Panel can also send its logs to the syslog server, you can specify the appropriate settings via the /syslog/settings endpoint.

To dump a log file in syslog format /syslog/file can be used, for logs clearing - /syslog/file.

The content of the event messages is as follows:

EVENT:{event_type}:{arg1}:{arg2}:{argN}:{text}

Parameters description:

ParameterDescription
{event_type}Event type identifier
{arg1} ... {argN}Arguments characterizing the event, if any
{text}Free-form human-readable description of an event

For example, the event "The door was opened using the master password" might look like this:

EVENT:100:0000:The door was opened using the master password:0000

where 100 is the event identifier "Door opened using the master password", 0000 is the event argument, in this case the key with which the door was opened, and, further, the free-form description of the event "The door was opened using the master password:0000".

Event types

IDDescriptionParametersFacilitySeverityPRI
000Any events not described below8670
100Door is opened, master code usedCode number, door number8670
101Door is opened, access code usedCode number, apartment number, door number8670
102Door is opened, card usedCard number, apartment number, door number8670
103Door is opened, UKEY usedUKEY number, apartment number, door number8670
104Door is opened, face usedFace ID, apartment number, door number8670
105Door is opened by exit button8670
106Door is opened in the callSubscriber number, apartment number, door number8670
107Door is opened by APIDoor number8670
108Door is opened by remote serverDoor number8670
109Door is opened with the free access button8670
110Door is opened with QR codeQR number, door number, lock number8670
111Access denied via multi factor accessIdentifer 18670
112Access denied via multi factor accessIdentifer 1, Identifer 28670
113Access denied via multi factor accessIdentifer 1, Identifer 2, Identifer 38670
114Access denied via multi factor accessIdentifer 1, Identifer 2, Identifer 3, Identifer 48670
115Access denied via multi factor accessIdentifer 1, Identifer 2, Identifer 3, Identifer 4, Identifer 58670
116Access granted via multi factor accessIdentifer 18670
117Access granted via multi factor accessIdentifer 1, Identifer 28670
118Access granted via multi factor accessIdentifer 1, Identifer 2, Identifer 38670
119Access granted via multi factor accessIdentifer 1, Identifer 2, Identifer 3, Identifer 48670
120Access granted via multi factor accessIdentifer 1, Identifer 2, Identifer 3, Identifer 4, Identifer 58670
121Access denied to identifiers without linkage to userIdentifier number, identifier type8670
122Door is opened with QR codeQR number, door number, lock number8670
123Access granted via license plateIdentifier number, user, lock number8670
124Access denied by unknown license plateIdentifier number8670
200Door was not closed too longTime in seconds how long the door has been opened8670
201Motion detected8670
202Door open detected by the door sensorSensor type8670
300Unknown card usedCard number8670
301Unknown access code usedCode number8670
302Invalid card usedCard number, apartment number8670
303Invalid access code usedCode number, apartment number8670
304Invalid UKEY usedUKEY number, apartment number8670
305Invalid Face ID usedFace ID number, apartment number8670
306Access denied by remote server8670
307Invalid QR code usedQR number, apartment number8670
308Unknown QR code usedQR number8670
309Door is opened by alarmLock number, opening time8670
400SIP registration OK8670
401SIP error8670
402Device rebooted8670
403Email sentRecipient email, event ID2622
404Email sending errorRecipient email, event ID2622
500Outgoing callApartment number, subscriber number8670
501Incoming callSubscriber number8670
502Outgoing call, connection errorApartment number, subscriber number8670
600Login to the web interface10686
601Incorrect web interface password used10686

App Name

Field format:

TAG:{model}_{version}_{mac}

Field description

FieldDescriptionExample.
TAGDevice TAG, optionallyPanel near the bridge
{model}Device model nameAA-12FB
{version}Firmware version3.10.0
{mac}MAC address without delimiters706979EEEEEE

Access management​

Access management includes:

  • Common settings.
  • Identifiers management.
  • Access restrictions management.
  • Free access function.

Common settings​

In the common setting you can:

  • Read/set master card, which can be used by adding user cards by GET/POST to the /access/general/unlock/card/master endpoint. When administrator put this card to the reader, panel will wait 10 seconds for a new user card to be brought to the reader for adding. When a user card is brought, it will be written into memory and linked to the first apartment, therefore, this method of entering cards requires subsequent data management if you want the cards to have different owners.
  • Enable/disable and read/set master code for panels with keyboards by GET/POST to the /access/general/unlock/input/code endpoint. Using this code the user can open the first lock connected to the panel. For better security it's recommended to use individual codes.
  • Read/set lock open time for both locks by GET/POST to the /access/general/lock/timeout/{lockNumber} endpoint.

    The panels have only one built-in relay for controlling the lock, the second lock is controlled by connecting the additional module SH-42.

  • Read/set lock open delay time for both locks (after receiving a command to open the lock device will wait this time before open) by GET/POST to the /access/general/lock/delay/{lockNumber} endpoint.
  • Read/set panel floor number by GET/POST to the /access/general/elevator/floor. If an elevator module EVRC-IP is installed in the system, then the response devices will be able to send the elevator to the panel floor when the lock is opened.
  • Read/set status of security mode feature by GET/POST to the /access/general/security/monitor endpoint. If the feature is enabled, then when the card is brought to the panel reader, the security on the monitor in the apartment to which this card is linked will be turned off.

Remote access​

Remote access function can be used in projects in which it's undesirable to store data about identifiers in panels. When this function is enabled, the device sends any submitted identifier to the server and waits for a response from it for 10 seconds. Both Link and a third-party server can be used as a server. If the device has not received a response from the server within 10 seconds, then it checks for the presence of an identifier in its database and makes a decision on its own.

To control the function endpoint /access/general/remote/control/settings used.

Device sends identifiers to server for validation to the /identifiers/validate endpoint. More information about request available here.

After serrver have checked identifier and want to deny access, then server need to send GET requests to the /access/general/lock/open/remote/control/accepted/{lockNumber} endpoint. After receiving it, the device will play an error sound and show on the screen that access is denied.

Locks remote opening​

You can open the first, second or both locks in the following ways:

  • GET request to the /access/general/lock/open/remote/accepted/{lockNumber} endpoint.
  • GET request to the /access/general/lock/open/remote/control/accepted/{lockNumber} endpoint.

The difference between this two endpoint is what the panel will write in its journal. When using the first endpoint, the panel will record that the door was opened by API (the same endpoint uses the web interface), when using the second - the door was opened from a remote server, which is convenient when using the feature above.

Emergency mode​

Device can open the selected lock for a time from 1 to 604800 seconds (1 week) by the POST request to the /access/general/lock/open/emergency endpoint. If the device device rebooted, the timer will be reset.

To cancel the emergency endpoint /access/general/lock/close/emergency used.

Door sensor contacts operating modes​

Device has a pair of dry contacts that can be used in different modes. Mode settings can be changed using /access/door/sensor endpoint.

  • Door sensor mode. In this mode device detects the opening of contacts and sends information about this to the server after specified in the settings time, and repeats sending with the interval, which also specified in the settings. In addition, it's possible to check the status of contacts using a GET request to the /access/door/status endpoint.
  • Door entry button mode. In this mode you can connect external button, used in the same way as the exit button. When used in the logs there will be an inscription "The door is opened by the entry button".
  • Concierge call mode. Device will call to the concierge when the contacts are closed. Feature can be used when connecting an additional button for people with limited mobility.

Conditional call forwarding​

Interaction with entities in the forwarding table is described in one of the sections above.

Rules in the call forwarding table are needed if you want to make calls via P2P, SIP or analogue system (only for devices with installed hybrid module) to SIP or analogue device. The logic of device calls is as follows:

  1. Device sent broadcast to the network with called device logical address consist of building # + unit # + floor # + apartment # and wait for the answer up to 1.5 seconds. If there is a response device in the network, then the device does not use the forwarding rules and call via internal protocol.
  2. If device does not receive a response, then it looks for a rule in the forwarding table and calls the list of numbers are specified for this rule.

The forwarding table consists of entries of the form "number entered on the keyboard" - "list of called P2P/SIP/analogue numbers".

Multi-factor authentication​

Starting from firmware 3.13.0 all Android panels support the ability to use multiple factors to grant access to the premises.

You can check the list of supported identifier types for your device model using /access/auth/factors endpoint. Identifiers types depend on the device model and can be as follows:

  • RFID card
  • UKEY
  • Access code
  • QR code
  • Face
  • License plate

Feature has several modes of operation:

  • Global - applies the specified factors to all users/identifiers in the system. Prohibits the use of identifiers are not linked with a user entity.
    • Normal mode support - if the identifier is linked to a user, then the global mode rules or the rules specified in the user settings will be applied to it. If the identifier is not linked to the user, but added to the device memory, then when this option is enabled, their usage will be allowed.
  • Normal - allows the use of identifiers in single mode, as it was before 3.13.0. The identifier may not be linked with a user or an apartment entities.

Modes settings can also be overridden in the user profile - here you can specify the types of identifiers a particular user must use to be admitted to the premises, thus different users may have different security requirements.

Linking users with time profiles​

Temporary profiles can be linked with both identifiers and users, so entities in the device can be flexible linked like "User -> Identifiers -> Time profiles" or "User -> Identifiers" and "User -> Time profiles".

Our time profiles are permissive, therefore, regardless of whether time profiles are linked with a user or an identifier, if at least one of them is valid, access will be allowed.

Some examples:

  • User have 2 identifiers

  • An invalid time profile was linked twitho the RFID identifier

  • There are no time profiles on the keycode

  • Actual result - Access denied

  • User have 3 identifiers

  • An invalid time profile was linked with the RFID identifier

  • Another invalid time profile was linked with the access code

  • Valid time profile was linked with the user profile

  • Actual result - Access granted

License plate recognition​

Axis cameras with a built-in ALRP can be connected to the outdoor panels for license plate checking and gates opening.

For the function to work, you need:

  • Add license plate number to the panel memory as "License plate" identifier type.
  • In the camera settings specify link to the endpoint /access/plate/check endpoint with basic auth in URL. URL example - http://admin:[email protected]/api/v1/access/plate/check.

Parking terminal feature​

Feature allows to close the first relay if access is allowed and the second relay if access is denied when using the SH-42 module. Thus, the feature allows you to connect various actuators to the relay, such as locks and lights, which can signal to the user if access is allowed or denied.

Feature can be configures with /access/parking/terminal endpoint.

Temperature sensor​

You can connect a BAS-IP temperature sensor to the outdoor panel and the tenant or concierge can find out the temperature of the guest during an incoming call.

To check the status of the sensor you can use /device/temperature/sensor endpoint

Custom notifications​

Screen notifications​

Device allows to display a custom screen saver in standby mode and change some of the labels in the different menus.

For screensaver feature webview is used, so you can add a link to your page, a static image, a video, RTSP stream and device will play it. To interact with this feature you can use /advanced/announcement endpoint.

Device allows to change standard prompts and labels in the following menus:

  • Home screen prompts can be changed using /advanced/notification/button/press/text endpoint.

    Endpoint not available for AA-14 panel. Endpoints for working with AA-14 prompts are described below.

  • Text on the screen during a call can be changed using /advanced/notification/ringing/tone/text endpoint.
  • Text on the screen during the lock opening can be changed using /advanced/notification/lock/open/text endpoint.
  • Text on the screen when access is denied can be changed using /advanced/notification/error/text endpoint.
  • Text on the screen during an emergency can be changed using /advanced/notification/emergency/text endpoint.

Sound notifications​

Device allows to change standard sounds for the next events:

  • Buttons press sound can be changed using /advanced/notification/button/press/sound endpoint.
  • Outgoing call sound can be changed using /advanced/notification/ringing/tone/sound endpoint.
  • Lock opening sound can be changed using /advanced/notification/lock/open/sound endpoint.
  • Access denied sound can be changed using /advanced​/notification​/error​/sound endpoint.
  • Emergency sound can be changed using /advanced/notification/emergency/sound endpoint.

Additional settings​

RTSP feed​

RTSP feed feature allows to change the video source when talking with the panel to one from the list by sending the corresponding DTMF codes.

To change the image source you need:

  1. Specify a list of additional RTSP streams for device using /advanced/rtsp/feed endpoint.
  2. Call from/to device, answer the call.
  3. Press DTMF from 0 to 5, 0 - device own camera stream, 1-4 - additional RTSP streams.

AA-14 additional settings​

AA-14 is a device with a 10 inch touch screen, unlike other panels, therefore it has wider possibilities of interaction.

Text announcements​

Device allows to display text announcements from concierge alerts on the screen in the form of cards in the list.

Following endpoints are available for CRUD operations:

  • Create announcement - PUT to the /desktop/message. Device return uid which can be used in the enpdoints below.
  • Update announcement by uid - PATCH to the /desktop​/message​/item​/{uid}.
  • Delete announcement by uid - DELETE to the /desktop​/message​/item​/{uid}.

Following endpoints are available for mass CRUD operations:

  • Create/Update multiple announcements - POST to the /desktop/message/items/link. When adding or updating entities link_id must be used.
  • Read announcements list - GET to the /desktop/message/items. Device will return apartments list according to the requested filters.
  • Delete announcements list by uid - DELETE to the /desktop/message/items.
  • Delete announcements list by link_id - DELETE to the /desktop/message/items/link.

Weather widget​

Device allows to display the weather conditions for the selected settlement (do not ask us why this is needed for the device that mounted at the entrance).

Using /desktop/weather you can specify the temperature and wind speed reference systems, and location. We use Accuweather API, so location key can be get from their API for desired location.

Statusbar​

Device has a status bar in its GUI , which is usually used by clients to record and display the geographic address at which the device is located.

Using /desktop/statusbar you can get or set text values for 2 fields in the statusbar.

Wallpaper​

Device allows to set custom wallpapers instead of default ones using /desktop/wallpaper endpoint.

GUI settings password​

Through the GUI you can change a certain limited number of device settings, to change the password for access to this menu, you can use /desktop/settings/access endpoint.

Password change​

There are 2 users in the panel, admin and manager. Admin has access to all settings, the manager does not have access to the ACS settings.

  • Admin password can be changed by POST request to the /security/password/admin endpoint.
  • Manager password can be changed by POST request to the /security/password/manager endpoint.

Backup/restore​

System has 2 types of settings backups, which are performed separately:

  • Tables data (identifiers, apartments, forwards, time profiles) backup/restore can be done using /system/settings/tables endpoint.
  • General data backup/restore can be done using /system/settings/backup/all endpoint.

System also makes an automatic backup when updating the firmware to a higher version. When rolling back the firmware to a previous version, if the database version has changed, the device will automatically restore the old data to ensure its operability, therefore it is always recommended to make backups of settings and user data when manually updating the firmware.

Clear tables data​

Device has option to delete all data from the specified tables by POST request to the /system/data/clear endpoint:

  • Apartments
  • Identifiers
  • Time profiles
  • Forward rules
  • Messages. Available only for AA-14 panel.
  • Event log

Default settings​

Resetting the settings deletes all user data, set default settings for the common data and device automatically reboots.

You can restore default settings by the POST request to the /system/settings/default endpoint.

Firmware upgrade​

Device can update the firmware from the BAS-IP server or from the user server, for example, if the user has custom features and does not want to receive general updates. It's also possible to manually update using the firmware file.

To update firmware from the server you need:

  • Check update status one the server using GET request to the /system/firmware/check/status endpoint.
  • To start the update send POST request to the /system/firmware/update/server endpoint.
  • To get the updating status send GET request to the /system/firmware/update/status endpoint.

After finishing the update device reboot automatically.

To update firmware form the file you need:

  • Upload firmware image using POST request to the /system/firmware/update/file endpoint.
  • To start the update send POST request to the /system/firmware/update/server endpoint.

It is always recommended to make backups of settings and user data when updating the firmware.

Debug​

Device has several options to debug encountered problems.

When there are problems with calls, you can make a call from the panel to the specified number and get the SIP response codes, this can help debug calls if you don't have access to the SIP server logs.

  • To start the call send POST request to the /system/call/start endpoint.
  • To get the status of the call send GET request to the /system/call/status endpoint.
  • To end the call send POST request to the /system/call/end endpoint.

The following call statuses are available:

  • QUERY - call enters the queue, request in progress.
  • CALL - dialing begins, waiting for the repsonce from calling SIP number.
  • RINGING - got responce from calling number, call in progress.
  • TALK - calling number answered, talk in progress.
  • NO_FORWARD_AVAILABLE - forward rule for calling number is not configured.
  • RESET - call step has been completed.
  • Call on VIZIT/LASKOMEX %s - call goes to the hybrid module.
  • Number %s status %d - call number and SIP status.
  • STOP_BY_USER - call was ended by the user.

If you have problems with the functionality of the device, then you can download the system log and send it to us for debugging.

  • To download the logs send GET request to the /system/debug/log endpoint.
  • To clear the system logs send DELETE request to the /system/debug/log endpoint. This can be useful if you want to repeat the problem and send us a log without unnecessary data, which can help when debugging.

Settings requiring device reboot​

Device reboots automatically when performing the following operations:

  • Backups import.
  • Tables data import.
  • Reset to default settings
  • Firmware update.