Closed mikaelbr closed 1 year ago
Vi har hatt et lite arbeidsmøte og diskutert dette litt. Inspeksjonsresultatet som kommer fra entur-inspeksjons-apiene er mer oppstykket enn dette er. Den feedbacken som skal til den reisende er et "destillat" av mange faktorer. Vi gjør i dag et "destillat" for å vise på NFC-lesere, så MT-Buss kan kan forholde oss til en oppsummert ("destillert") "message" som vi returnerer over mqtt. Denne "code" må vel være en felles tabell et eller annet sted? Må vi ha det? Evt. blir den også definert i denne prosessen? Mt-Buss burde kanskje også lagd en "displayCommand" (ala ledCommand og buzzerCommand) som kan forsøke å si hva som skal presenteres av tekst til den reisende - som også kanskje bør inneholde hvor lenge den teksten skal være framme. Det er også veldig mange typer feilkategorier her - litt som kan ha gått galt i tolkningen av barcoden, men mye forskjellig rundt kontoen og gyldighetsparametre. Dette er forhold som har betydning for hva som må gjøres og av hvem. F.eks. kan billettselger måtte be om å se alderslegitimasjon, eller den reisende kan bli bedt om å bare prøve igjen.
Forslag fra Steinar:
{
"barcode": "tYBCtMBCtABCiQxNzgveldiglangbase64codetmobiletoken....."
"travelcard_serial": "634345123",
"travelcard_token": "7fd6d58a-2515-4e67-b252-d298901d6dd2"
}
Forslag: splitte token lest fra MIFARE og Barcode på egne topics.
Topic må ha:
Andre felter som burde med:
Hardware må ha innebygget timeout på N sek, og viser en venterskjerm med en gang. Bruke konfigurasjon til å spesifisere meldinger som skal brukes? Også konfigurere melding dersom timeout forekommer.
Hva skjer om MT Buss ikke er aktiv:
Innspill til feedback / display:
Behov er at dette er likt på tvers av busser/fartøy og at det er gjenkjenbart. Så det er hensiktsmessig at det ikke er hardkodet inn i devices men kommer som serialiserbar informasjon fra MT Buss.
Merk at følgende vil bli aktuelt for NFC på sikt:
Så den appen som står for å lage ADPU'ene til NFC-leseren vil trenge noe mer info på sikt, også potensielt ting som må hentes på Internet.
Oppfølging: hva skjer om FLV+ ikke får kontakt og timer ut.
Aktuelle hardwares:
ATR210 Halo
FLV+
Should support N devices in parallel.
Scenario and Use Case
Validate QR Code
Trigger
Kunden viser QR-kode mot Passasjerleser. (Er MT-Buss i valideringsmodus?)
Achieved result
MT-Buss har allerede en standard oppførsel med lyd og lys for validering. Bør følge denne. FARA sine tilbakemeldinger er også gode og tunet utfra erfaring.
a. Gyldig enkeltbillett funnet og validert. Passasjerleser viser tekst "OK", OK-farge, OK-lyd. b. Gyldig periodebillett funnet og validert. > 3 dager. Passasjerleser viser tekst "OK", OK-farge, OK-lyd. c. Gyldig periodebillett funnet og validert. 2 - 3 dager. Tekst "OK. X dager igjen.". Passasjerleser viser tekst, Advarsel-farge, Ok-lyd. d. Gyldig periodebillett funnet og validert. Siste dag. Tekst "OK. Siste gyldige dag.". Passasjerleser viser tekst, Advarsel-farge, Advarsel-lyd. På Halo bør lys blinke 2 ganger. e. Ingen gyldig billett funnet. Tekst "Finner ikke billett." Passasjerleser viser tekst, FEIL-farge, FEIL-lyd. Hvis MT-Buss er offline, vil kunden få beskjed som om gyldig billett er funnet.
Hvis valideringsprosessen tar tid bør kanskje et venteikon eller en tekst "Vennligst vent" vises på skjerm. Eventuelt kan dette alltid vises, og overskrives straks et respons kommer.
Sjåfør bør få en tilsvarende informasjon, men forenklet hvis ok.
Prior work
https://adt.transhub.io/2.x/v2.6.0/#operation-publish-pe/sales/validationresult
Example