MQTT · node {{model.status.node}}
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 on this broker carries
{{model.status.environment}}_
(e.g. {{model.status.environment}}_Report_…, {{model.status.environment}}_Activity_…);
the prefix is 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 ? (model.status.intakeSilent ? 'SILENT' : '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.Activity || 0 | number}}
Scan bundles
{{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 · the newest {{FEED_TAKE}} matching the filter · 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 · the {{model.status.topicStats.length}} most recent of {{model.status.topicStatsTotal | number}}
| Topic | Kind | Recv | Sent | Last | ||
|---|---|---|---|---|---|---|
| ● | {{shortTopic(t.topic)}} | {{t.kind}} | {{t.count ? (t.count | number) : '—'}} | {{t.sentCount ? (t.sentCount | 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 whose deliveries are still on file 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. It looks over the whole of how long delivery records are kept, which is deliberate: a handset that drifted three weeks ago and has not delivered since would fall out of a shorter window while its records were still on file. 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