Kontrakt
LSP nazywa org, tor, auto, sesję, zdarzenia telemetry i etap onboard. Subskrybujesz tor w organizacji. Wiele aut publikuje. Twój produkt odbiera te auta jako zdarzenia.
LapsHub Live
Nazwany kontrakt LapsHub Live. Organizacja → tor → auto → sesja. Live telemetry plus niska latencja kamery. Live API to sposób budowania. Hosted Pit Wall to opcjonalny UI na tym samym protokole.
Zakres org · Partnerzy · Spec przed runtime
LapsHub Streaming Protocol to język streamu toru. Nie nowy format binarny. Zespoły, streamerzy i integratorzy mówią LSP; Live API dokłada sesje, dostęp do streamu i liczniki.
Organization
└── Track (subscribe: all org cars on this circuit)
└── Car
└── Session
├── Telemetry events
└── Stage (onboard) → publish / watch access
LSP nazywa org, tor, auto, sesję, zdarzenia telemetry i etap onboard. Subskrybujesz tor w organizacji. Wiele aut publikuje. Twój produkt odbiera te auta jako zdarzenia.
Kafka albo surowe IoT przenoszą bajty. Nie nazywają, która org, tor, auto albo sesja jest live, ani kiedy otworzyć kamerę. To mapowanie to LSP.
To, co kupujesz, żeby budować: sterowanie sesją, dostęp do streamu i liczniki. Pit wall, overlay, aplikacja serii albo stream są Twoje.
Opcjonalny UI na tym samym protokole. Wolisz gotowy ekran? Ten sam backend Live, ścieżka Hosted Pit Wall.
Podłącz źródło telemetry przez MQTT. Otwórz sesję w GraphQL, weź krótkie poświadczenia i publikuj koperty JSON z urządzenia, loggera albo mostka.
Wywołaj createLiveSession z carId i trackId org. Jedna sesja live na auto na torze.
Wywołaj createTelemetryCredentials z role: PUBLISH. Live API zwraca endpoint, clientId, topicPublish i expiresAt.
Urządzenie łączy się z mqtts://live-mqtt.lapshub.com:8883 przez TLS i publikuje koperty telemetry na topicPublish. Do 50 punktów na wiadomość.
LapsHub device, RaceBox albo Dragy przez mostek, loggery CAN/GPS albo dowolny stack z klientem MQTT i JSON.
JSON przez MQTT, application/json. Wymagane: v, orgId, trackId, carId i points[] z przynajmniej ts. Opcjonalnie: lat, lon, speedMps, headingDeg, lap i skalarne channels (rpm, gaz itd.).
Auta Twojej organizacji na Twoich torach. To nie podłączenie do publicznej aplikacji.
mutation {
createLiveSession(input: { carId: "car_42", trackId: "track_ra" }) {
id
status
}
}
mutation {
createTelemetryCredentials(
sessionId: "sess_1"
input: { role: PUBLISH, ttlSeconds: 3600 }
) {
endpoint
clientId
topicPublish
expiresAt
}
}
{
"endpoint": "mqtts://live-mqtt.lapshub.com:8883",
"clientId": "lh_org_1_car_42_sess_1",
"topicPublish": "live/org_1/track_ra/car_42/telemetry",
"expiresAt": "2026-08-17T19:00:00.000Z"
}
Planowany broker: mqtts://live-mqtt.lapshub.com:8883 (preview, nie live). Poświadczenia są krótkie: odśwież przed wygaśnięciem. HTTPS batch to zapas, gdy urządzenie nie ogarnie MQTT. Na wysokie Hz GPS i CAN preferuj MQTT. Schemat: asyncapi-telemetry-v1.yaml.
Subskrybuj tor w org. Auta, które publikujesz, wysyłają zdarzenia na ten stream na żywo. Weź poświadczenia z role: SUBSCRIBE albo BOTH w createTelemetryCredentials.
Subscribe (your org, one circuit):
live/{orgId}/{trackId}/+/telemetry
Publish (one car):
live/{orgId}/{trackId}/{carId}/telemetry
Live API wydaje krótki dostęp publikacji i subskrypcji. HTTPS batch zostaje zapasem, gdy nie ma klienta streamu.
Jedna koperta, jeden albo więcej punktów. Wersja schematu v: 1. Pełna lista pól dla partnerów: asyncapi-telemetry-v1.yaml.
{
"v": 1,
"orgId": "org_1",
"trackId": "track_ra",
"carId": "car_42",
"sessionId": "sess_1",
"points": [
{
"ts": "2026-08-17T18:00:00.000Z",
"lat": 43.798,
"lon": -87.992,
"speedMps": 42.1,
"headingDeg": 187.2,
"lap": 3,
"channels": { "rpm": 6120, "throttle": 0.82 }
}
]
}
Dane auta o wysokim Hz jadą MQTT, nie API sterowania. Urządzenia publikują na temat auta; pit wall i overlay subskrybują wildcard toru. Przepływ: integracja urządzeń.
Auta albo loggery publikują na live/{orgId}/{trackId}/{carId}/telemetry.
Pit wall, overlay i stacki streamu subskrybują live/{orgId}/{trackId}/+/telemetry i dostają każde auto org na tym torze.
Nie wpychaj punktów GPS o wysokim Hz przez API sesji. Te wywołania otwierają sesje i dostęp. Stream niesie punkty.
Live API otwiera sesje, daje dostęp do streamu i oglądania oraz czyta użycie. Protokół nazywa, co te wywołania znaczą. Kształty na kablu są w recenzji partnerskiej.
Otwieraj i zamykaj sesję live auta na torze w org.
Krótki dostęp publikacji, subskrypcji i oglądania. Oglądanie otwieraj tylko, gdy ktoś patrzy.
Liczniki raportują czas publikacji, czas oglądania i przyjętą objętość telemetry.
mutation {
createLiveSession(input: { carId: "car_42", trackId: "track_ra" }) {
id
status
}
}
Subscribe (your org, one circuit):
live/{orgId}/{trackId}/+/telemetry
Publish (one car):
live/{orgId}/{trackId}/{carId}/telemetry
GraphQL otwiera sesje i etapy. MQTT niesie dane auta. WebRTC niesie kamerę. GraphQL to nie szyna GPS live.
Niskolatencyjna kamera dla widowni (cel poniżej 2 s). Otwórz etap tylko, gdy ktoś ogląda, potem zasil YouTube, Twitch, TV albo ekrany na obiekcie ze swojego stacku.
Uruchom etap dla auta/sesji i wyślij obraz z kamery.
Dostęp do oglądania jest krótki i płatny. Otwieraj tylko, gdy ktoś patrzy.
My trzymamy backend live. Ty decydujesz, jak event trafia na YouTube, Twitch, TV, overlay i własne streamy.
Co liczymy jako użycie. Cenę pilotażu ustalamy z partnerami.
video.publisherSekundy uczestnika, gdy nadawca jest połączony.
video.subscriberSekundy uczestnika, gdy widz jest połączony.
telemetry.messageLiczba przyjętych zdarzeń telemetry albo elementów batch.
Te kontrakty są do recenzji architektury z partnerami. Endpointy runtime nie są jeszcze ogólnie dostępne. Spec może się zmienić przed startem.
Poproś o dostęp partnerski. Opowiedz o produkcie, streamie albo pit wall, a zmapujemy sesje, telemetry i etapy kamery na Twoją roadmapę.
Program partnerski. Wolisz gotowy ekran? Hosted Pit Wall. Szukasz aplikacji kierowcy? Pobierz za darmo.