BPAPI Documentation, gateway protocol

Gateways communicate with the backend (server) by TCP/IP.

The backend (server) utilizes an advanced hardware-abstraction model making it capable of understanding a variety of protocols. It is preferred however to keep to some existing patterns, like for instance:

1) The gateway is responsible for initiating the connection with the backend and, after that, to keep the connection 'alive' (that is keeping sessions alive in any in-between firewalls / NAT-points in order to enable the backend to always be able to send messages to the gateway) by regularly (like each 15. minute) sending 'pings' (packets over TCP, usually consisting of just the letter P).

2) The individual messages / commands are separated by \r\n (cr+lf).

3) Messages / commands to the gateway from the backend start with the prefix 'Skm' followed by a one-character backend serial number (which usually cycles through A-Z).
Example: SkmBxxx where B is the backend serial number and xxx is some command to the gateway

4) Messages from the gateway to the backend start with a one-character gateway serial number (which usually cycles through A-Z) immediately followed by the last backend serial number received from the backend. The idea here is to make the backend understand when a specific command is being aknowledged by the gateway (by the gateway always sending back the last backend serial number received) and also to understand when state changes has taken place at the gateway side (by the gateway updating its own serial number whenever its state changes ('pings' are not considered a 'change')).
Example: BTxxx where B is the last backend serial number received, T is the gateway serial number and xxx is some message from the gateway to the backend.

5) All acknowledgements from the gateway repeat the actual command received from the backend (the philosophy at the backend side is to 'trust' commands having been executed only after they have explicitly been acknowledged by the gateway. The implementation at the gateway side should correspondingly only acknowledge commands AFTER they have been executed. If this cannot be done within a reasonable timeframe then a generic response should be send back to the gateway instead).
Example (without the Skm prefix and serial numbers): R041 (turn relay 4 on) is acknowledged by RR104 (turn on executed for relay 4)

6) Standard prefixes are: X for initial connection by gateway (followed by some identification), R for relay on / off, S for current status, Z for hardware information, I for information.

7) Encryption is done outside of the gateway protocol (through VPN) as needed.

Automatically generated from BPAPI source-code 2020-04-05 01:17

Assembly built at 2020-04-01 12:26