MQTT
Live broker link between this scanner server, the devices and Adriaticket: scans, commands and ticket pushes all travel here. Stats since API start ({{model.status.startedAtUtc | date:'dd.MM. HH:mm'}}).ⓘ
Env prefix: every topic here carries
{{model.status.environment}}_
(e.g. {{model.status.environment}}_Scanned_…) are stripped from the lists below for readability.
Environment isolation: a message on a {{model.status.environment}}_ topic reaches only this
environment's devices, never prod (and vice-versa).
{{model.status.connected ? 'ONLINE' : 'OFFLINE'}}
Broker
{{model.status.secondsSinceLastMessage != null ? model.status.secondsSinceLastMessage + 's' : '—'}}
Last message
{{model.status.devicesOnline || 0}}/{{model.status.devicesKnown || 0}}
Devices online
{{model.status.subscribedTopics}}
Topics
{{model.status.totalMessages | number}}
Messages
{{model.status.perKind.Scan || 0 | number}}
Scans
{{model.status.warnMessages || 0 | number}}
Warnings
{{model.status.errorMessages || 0 | number}}
Errors
{{model.status.reconnects || 0}}
Reconnects
Traffic - messages per minute all messagesscans (last 30 min, hover a bar for exact numbers)
{{model.status.minuteBuckets[0].minuteUtc | date:'HH:mm'}}now
{{v | number}} {{k}}
Live feed · newest first · sent (↑) + received (↓) · commands & acks kept longer
| Time ({{tzLabel}}) | Kind | Topic | Size | Payload | ||
|---|---|---|---|---|---|---|
| ! × | {{m.direction === 'out' ? '↑' : '↓'}} | {{m.atUtc | date:'HH:mm:ss'}} | {{m.kind}} | {{shortTopic(m.topic)}} | {{m.bytes}} B | {{m.preview | limitTo:140}}{{m.preview.length > 140 ? '…' : ''}} |
No messages match the filter (yet).
Channels · by last activity
| Topic | Kind | Msgs | Last | ||
|---|---|---|---|---|---|
| ● | {{shortTopic(t.topic)}} | {{t.kind}} | {{t.count | number}} | {{t.lastAtUtc | date:'HH:mm:ss'}} | Command Center → |
No traffic seen since API start.
{{model_skew.open ? '▾' : '▸'}} Scanners whose clock disagrees with ours
Measured from the only pair of times a delivery can produce: when a scanner said it sent, against when we received it. Every scan time in every report is the scanner's own, so a wrong clock shows up nowhere else until somebody is reading a report that makes no sense.
Reading it…
The clock check could not be read. That is this panel failing, not a statement about the fleet.
Every scanner that delivered in the last seven days is within a minute of us. Only those further out than that are listed, so an empty list here is the fleet agreeing.
| Scanner | Out by | Worst | Deliveries | Last heard | |
|---|---|---|---|---|---|
| {{s.deviceName || s.deviceGuid}} {{s.deviceGuid}} | ● {{s.isOnline ? 'online' : 'offline'}} | {{events.skewUsual(s)}} | {{events.skewWorst(s) | number}} min | {{s.bundles | number}} | {{s.lastSeenUtc | date:'dd.MM HH:mm'}} |
Times are {{tzLabel}}. A scanner is listed on its worst reading, so a usual gap of under a minute beside a large worst one is a clock that was corrected rather than one that is permanently adrift. Ahead of us is the direction worth acting on first. Seven days, which is as far back as the delivery records go. A scanner listed here is not broken and its scans are not lost; what is wrong is the TIME on them, so set the handset to network time and the next deliveries come back into step.
not updating · last read {{events.lastGoodText() || 'never'}} · try now
next refresh in {{model.countdown}}s · refresh now
paused · resume
paused while reading