smt - Samfundets MenneskeTeller

(Jada, lamt akronym. :-)

smt er et program (skrevet i C) for å hente ut informasjon fra Studentersamfundets radartellere, og fungerer stort sett som erstatning for det VB-baserte programmet som fulgte med systemet (det er dog ikke i nærheten av like fleksibelt, dog – systemet er f.eks. stort sett låst til én sentralboks og fire tellere, og det er skrevet ut fra en veldig mangelfull forståelse av seriellprotokollen som benyttes). Systemet har to operasjonsmodi – kommandolinjebasert og webbasert. Det kommandolinjebaserte systemet er det som blir beskrevet her; forskjellen fra websystemet vil beskrives lenger ned.

Selve programmet med source ligger på /home/cassarossa/itk/felles/smt. Utførlig dokumentasjon på hvordan programmet fungerer finnes i selve sourcen. For øyeblikket kjører smt på kanskje.samfundet.no, men den burde etterhvert flyttes til en maskin som er mer serverorientert (type cirkus). smt i seg selv er bare et pollprogram for å hente ut øyeblikksdata – før har man hatt MRTG-grafer som har benyttet denne informasjonen, men i seinere tid er dette blitt knyttet opp mot websystemet (se under).

Bias-filen

Systemet har én fil som leses og skrives, per default ligger denne i /var/run/smt/bias (burde denne flyttes til /var/lib?) – programmet trenger vanligvis fulle lese- og skriverettigheter til denne, og pga. låsemetoden (se lock_file() i kildekoden) burde den helst ligge på lokal disk. biasfilen brukes til to formål:

Det inneholder en korreksjon (bias) for hver av de tre områdene "offentlig", "nordre sideloft" og "søndre sideloft". Disse verdiene legges på ved utskrift til skjerm for å få tallet riktigere enn rådataene man får fra tellerne. Bias kalibreres ved å bruke -reset-switchene med gitte verdier – typisk har man gode verdier ved siling (når alle på sideloftene faktisk telles) og rundt 5-6 om morgenen på hverdag. En cronjob vil typisk utføre -reset 0 om morgenen når man antar at det nesten er helt tomt i de offentlige områdene, slik at telleren justeres mot dette.
I tillegg inneholder filen informasjon om de aktuelle tellerne ved forrige avlesning. Disse dataene brukes ved -nopoll, men kanskje enda viktigere brukes de som referanse for å finne ut når sentralen har nullstilt tellerne sine. Siden sentralen er beregnet på shoppingsentre og ikke utesteder, går alle tellere på den tilbake til null ved midnatt, noe som er lite hendig for oss. Programmet sammenligner derfor tellerne (hver sensor på sentralen har separat inn/ut-teller) med de forrige verdiene – dersom minst én av tellerne er lavere enn ved forrige avlesning, kan man anta at sentralen har nullstilt seg. I dette tilfellet vil antall mennesker ved forrige avlesing legges til bias, slik at man altså fortsetter som om ingenting var hendt.

Biasfilen blir låst ved flock() så lenge programmet bruker den, slik at to instanser av programmet ikke kan tråkke hverandre på tærne. Kun første linje i biasfilen blir noensinne vurdert – resten blir ignorert.

Dokumentasjon på kommandolinjeparametre kan fåes ved "./smt -help" – utover dette burde programmet være relativt selvforklarende. Ved -public, -north eller -south vil en eller flere tellere skrives ut på stdout (de man har angitt på kommandolinjen, naturlig nok – merk at disse kommer i rekkefølgen public, nord, sør UAVHENGIG av hvor på kommandolinjen de ble angitt). Ved -reset, -northreset eller -southreset (som ikke kan kombineres med -public, -north eller -south) kalibreres biaset slik at antallet mennesker blir 0, eller det oppgitte antallet (om det er oppgitt noe).

Nullstilt biasfil

Hvis man skulle trenge en ny biasfil er denne en grei start:

bias:0 biasnorth:0 biassouth:0 in1:0 out1:0 in2:0 out2:0 in3:0 out3:0 in4:0 out4:0

Vær dog obs på at tellerne er på syre (de returnerer helt sære data i protokollen, dvs. et offset av noe slag), så man burde nok resette ting litt etter å ha laget biasfil.

Protokollinfo

Det lille man kjenner til (og strengt tatt trenger) av protokollen går som følger:

Enheten tar tydeligvis enkelte AT-kommandoer, men gir aldri noe svar på dette. VB-programmet sender "AT+CPIN=0815\r" (der \r er ASCII 13; det sendes aldri noe linefeed, underlig nok) på oppstart før den går rett i sin egen binære protokoll. (Dette er en kommando for å sette PIN på modemene leverandøren bruker, såvidt jeg har forstått.)

For å spørre om data fra sensorer sender PCen følgende 9 bytes:

65 0D 68 00 02 01 06 07 16

Hva 65 0D er er ukjent – det fungerer i hvert fall helt greit bare å droppe det, kanskje det er en slags reset-kode. 68 ser ut til å starte kommando av noe slag. 00 02 er lengden på pakken. 0x01=/=0xFF (se neste pakke for et eksempel på sistnevnte) kan være en "request/answer"-byte, men dette er ren spekulasjon ATM. Likeledes kan 0x06 være en kommandobyte av noe slag, og 0x07 virker som en checksum – saken tar i hvert fall masse andre (ukjente) kommandoer som begynner på 68 00 02 01, men ingen hvor ikke nest siste byte er nøyaktig høyere enn tredje siste (ikke testet alle mulige kombinasjoner, men en ganske god del). 0x16 virker som en slags terminatorbyte, men det er ikke noe i veien for at denne verdien kan brukes inne i pakken.

Svaret vil da f.eks. bli (23 bytes)

68 00 12 FF 06 02 AA 00 AE 01 34 01 6D 00 00 00 00 00 A1 00 B7 5A 16

68 00 12 FF 06 er igjen et header av samme type – det er mao. 0x00 0x12 (=18) bytes i selve pakken. I vårt tilfelle har vi fire sensorer – hver har en inn- og en ut-teller. Hver av disse ligger lagret i big-endian (hvilket betyr at vi må byteswappe dem på x86), med 16 bits per verdi. Disse ligger som in1, out1, in2, out2, osv.. "in" for en sensor er antall innganger som er registrert siden midnatt, og "ut" er antall utganger som er registrert siden midnatt. VB-programmet ser ut til ukritisk å bruke formelen

(in1 - out1) + (in2 - out2) + (in3 - out3) + (in4 - out4)

uten noen form for bias (siden man ikke kan sette eller resette dette i selve VB-programmet) og så bare printe ut 0 hvis denne verdien blir negativ. (Tsk. ;-) ) I skrivende stund er sensormappingen slik:

Inngang 1 (sensor 1 og 2): Rundhallen frontinngang, dør midt på (hovedinngang)
Inngang 2 (sensor 3, 4 og 5): Nordre sideloft (3,4), søndre sideloft (5)
Inngang 3 (sensor 6): Strossa inngang
Inngang 4 (sensor 7): Daglighallen

Nest siste byte virker som sagt som en checksum av noe slag, muligens bare en ren sum av bytene, modulo 256. smt bruker den i alle fall ikke.

VB-programmet ser ut til å vente noen sekunder selv etter å ha mottatt den første pakken (gir timeglass-peker); dette kan indikere at dersom det er flere kontrollbokser vil det komme flere slike pakker. Dette er uansett ganske uinteressant for oss.

Ellers kan man sikkert sniffe protokollen videre for å få økt forståelse av systemet, men det virker per dags dato ikke veldig viktig – man har spurt leverandøren om å få protokollspesifikasjon, men såvidt jeg vet har ingenting skjedd. (Vi har stort sett det vi trenger uansett. :-) )

Super-sekrit admin-meny

Hvis man kobler seg på med f.eks. minicom kan man holde nede "0" og så trykke "." (punktum) etterpå, hvorpå man kommer inn i den fine og flotte adminmenyen (*host*)... Fikling her anbefales ikke med mindre man vet hva man holder på med. :-) Videre har man "0" og så "1" (dvs. 1-32 avhengig av sentral, men vi har bare én sentral), "a" (identifisér sentraler på kjeden) og sikkert noen andre også. :-)

Websystem

Som tidligere nevnt er ikke smt enormt mye verdt uten et system som tracker ting over lengre tid. Derfor har man begynt å lage et litt mer omfattende system rundt det hele, konsistent nok med akkurat det samme lamme akronymet (smt) som navn.

Tellerne polles jevnlig (hvert minutt, via crontab) ved hjelp av smt (altså kommandolinjeapplikasjonen) og legges inn i en PostgreSQL-database. smt brukes med "-raw"-flagget, som kun leser ut rådataene fra tellerne – mao. brukes eller oppdateres ingen bias-fil, og det gjøres dermed heller ingen korreksjon. Mye av logikken som vanligvis ligger i smt mht. å justere bias automatisk ved wraparound osv. er blitt duplisert i poll-scriptet (poll.pl), med en viktig forskjell: Man har ikke bare en fast biasfil, men lagrer alle biasverdier med timestamp i en egen tabell ("resets"). Hver måling som gjøres og lagres (i tabellen "poll") linkes mot den biasposten som var aktiv ved den gjeldende avlesningen. Slik sett kan man legge inn manuelle justeringer for bias osv. i ettertid. Det er estimert at i løpet av et år vil dette produsere ca. en halv million rader i poll-tabellen; vi regner med at PostgreSQL vil skalere rimelig greit, men dette gjenstår selvsagt å se.

Alle resets har i tillegg til informasjonen i biasfilen (dvs. bias for offentlige områder, nordre og søndre sideloft) en grunn, i feltet "reason". Dette kan være en av tre:

manual: Manuell justering, ala "-reset" i smt. Brukes typisk etter siling o.l.
regular: Automatisk justering, noe som gjøres hver hverdag (dvs. mandag-fredag 04:00) siden man da har huset i en rimelig kjent tilstand (dvs. nesten tomt).
on-decrement: Automatisk justering som gjøres av poll.pl idet den merker at en eller flere tellere er gått nedover. Dette er tegn på at boksen har nullstilt seg selv fordi den tror det er midnatt, og bias justeres derfor for automatisk å motvirke denne effekten.

Informasjonen i "poll" og "resets" slås sammen i viewet "processed_results", som gir ut ferdige tall (korrigert for bias) for offentlige områder, nordre og søndre. Dette brukes videre i et webinterface på http://itk.samfundet.no/smt/ (skrevet i Perl, da det er Steinar som har laget saken :-) ) til å dytte ut enkel statistikk og en liten graf. Med tiden vil det forhåpentligvis komme litt mer mulighet for historikk osv., men for øyeblikket er sentralboksen ikke i helt godt humør, så det er ikke så mye poeng i å utvikle alt for mye på dette ennå.

Kontaktinfo, IMAS

Bjørn Harald Kirkerud
mob: 95113532
tlf: 64862040
fax: 64867784
mail: imas@imas.net

Hardware

Kommunikasjonen mellom den sorte (egentlig aluminium-farget) boksen og serieporten er som følger. Telleboksen har 2 RS485 porter som er av typen 6 pins RJ12. Egentlig holder det med 4 pins RJ11, da en bare bruker pinne 2-5 (de i midten). 2 og 5 er kommunikasjon mens 3 og 4 er 5 volts spenningskilde. RS485 <-> RS232 konverteren bruker denne spenningskilden. Kabelen mellom tellesystemet og konverteringsboksen skal være 1-1. RS232 porten på konverteren er en DB9(han) og den er antagligvis en DTE (Data Terminal Equipment). Vanlige PC'er er også DTE og kobling mellom slike skjer hva null-modem-kabel (2-3, 3-2, 5-5). Tellesystemet kommuniserer på 9600 8N1.

Kalibreringsinformasjon

Sensor 1: 50/35/35, 1
Sensor 2: 50/35/35, 1
Sensor 3: 60/25/25, 0
Sensor 4: 75/40/40, 0
Sensor 5: 40/35/35, 0
Sensor 6: 30/35/35, 1
Sensor 7: 30/50/50, 0

Lenker: Start, gammel dokumentasjon, itkaclintro