[Changelog] tacho-bridge protocol

EvgenyShatilo

Here we will post information about tacho-bridge new features and bugfixes.

EvgenyShatilo

Note

The protocol is a bridge for interaction between the company card and the tachograph so that it is possible to remotely download data from the tachograph.

The protocol implements 2 types of devices:
Tacho Bridge App - Needed to monitor the status of the application and its remote configuration. (These features will be added in the very near future). Detailed configuration of the application is described here.
The application entity identifier is currently custom. It must be used in the same form in the application.

Tacho Bridge Card - Needed for communication between the company card and the tracker. So that the server understands which tracker interacts with which company card.
The company card number that was used to configure the card in the application is used as the device identifier.

EvgenyShatilo

Changes have been made to the company card configuration field on the device.
According to Annex 1C regulation, (EU) 2016/799, the company card number must be 16 characters long and contain the characters A-Z, 0-9.

EvgenyShatilo

Changed format of the Device identifier field: now the identifier must comply with the EU regulation as in the configuration field. (Annex 1C regulation, (EU) 2016/799, must be 16 characters, A-Z, 0-9)
Added checking of connection types when connecting to the server. Now the server checks the identifier and type of the device when connecting, if the device does not have a type (that is, the device is not created or created incorrectly), the connection will be broken. In the application the green connection icon will not light until the configuration is completed. Stricter configuration rules will help avoid false connections and misunderstandings.

EvgenyShatilo

Detailed error text when the type of the connected TBA device is selected incorrectly.
For the application device:
"The connected App device must have the device type: 'Tacho Bridge App'."
For the card device:
"The connected card must have the device type: 'Tacho Bridge Card'."

EvgenyShatilo

Rewrote the three connection-rejection Error messages to state the cause and report what the card sent vs what the server expected:

"unexpected publication without session" -> "no active session: card sent response for request_id=%s sender=%s while server has no pending command"
"unexpected sender=%s, current=%s" -> "sender mismatch: card response is for sender=%s, but the active session belongs to sender=%s"
"unexpected request_id=%s, current=%s" -> "request_id mismatch: card sent response for request_id=%s, but server awaits %s (late or duplicate response)"
Internal changes of processing channel that shouldn't affect current operation.

EvgenyShatilo

Important bug fix: late or duplicate responses from the Tacho Bridge App no longer break the card connection, fixing the reconnect cycles that disrupted tachograph authentication.

EvgenyShatilo

Note: currently only available in v0.8.0-alpha.4 (Pre-release)

Added read-only app_info device setting for Tacho Bridge App devices - the application now reports its version, OS, and architecture right after connecting, visible in the device settings.
Changing the communication command to control the T protocol.
There are also many other changes, including critical ones. See the Alpha version history.

EvgenyShatilo

Card rack support: reliability fixes:

A rack no longer goes silent after a failed start-up scan. When the initial scan of a rack hit a communication error, the rack was left with no cards listed and nothing monitoring it — it stayed that way until the application reconnected. The scan now keeps every card it managed to identify, keeps monitoring the rack, and picks up the remaining slots on its own as soon as the rack settles.
Reply timings for the rack link are now two separate limits instead of one: how long to wait for the rack to start answering, and how long a pause means the answer is complete. Sharing a single limit between the two was the root cause of long commands failing (see the application changelog below).
An unresponsive card is reported with a clear reason — the message now states that the card needs a reset and that the next session start performs it, instead of a bare error code.

EvgenyShatilo

v0.8.0-alpha.12

Built-in auto-update — the app now checks for updates on startup or on demand and installs them in one click with an automatic restart.
Pre-release channel — a new "Receive pre-release updates" toggle in Settings. Off by default (stable only); turn it on to get alpha/beta builds as soon as they ship and help us test.
New unified Settings dialog — server address, theme, update channel, manual update check and a built-in changelog viewer, all behind the gear icon.
Lisle card rack fixes — correct detection on Windows (by USB descriptors), no more COM port lockups, a clear notification when another app holds the port, and a fix for authentication timing out on large commands.
Per-card T0/T1 protocol — the card's protocol is now detected once, stored in the config and reused on every connect and reset; the server can also request a specific protocol per session.
Stability fixes — an empty cards: key no longer wipes your whole config, rack logs are far less noisy, and the app reports its version/OS/architecture to the server for easier support.

Full changelog is here.

EvgenyShatilo

A new fetch_logs command is available for Tacho Bridge App devices. It requests the application log for a selected period — 1 day, 1 week, or 1 month — counted back from the moment of the request.

The application slices the requested period out of its log files, packs it into a zip archive, and uploads it to the platform. The resulting file is stored in the flespi CDN and attached to the command result, so it can be downloaded right from the device commands history; a message with the media.log reference is also stored for the device.

Notes:

Requires Tacho Bridge App 0.8.0-alpha.14 or newer. Older app versions ignore the request, and the command fails with a timeout once its queue TTL expires.
If the requested period reaches further back than the retained log files, the upload contains everything available.
The command allows up to 5 minutes for the collection and upload before timing out.