phloggen

HUS: data-opsamling og -distribution

Jeg lovede at vende tilbage med en forklaring om det system jeg bruger til opsamling af måledata på mit 'gamle' hus.

Lad mig starte med at slå fast at det er et gammelt system, her er f.eks 10 års udetemperaturer, fra en sensor der ikke er monteret specielt smart:

Illustration: Privatfoto

Systemet hedder "measured" og har sin oprindelse omkring 1996 hvor jeg havde brug for at holde øje med nogle tids-signaler.

Min erfaring, allerede dengang, var at dataopsamling var den mindste del af opgaven, det er datadistributionen der er der hårde problem.

I mit tilfælde ville jeg gerne kombinere data fra DMI med data fra en GPS modtager og måledata fra nogle HP instrumenter, men samtidig skulle jeg også bruge de serielle data fra GPS modtageren i mindst to andre programmer på to andre computere.

Resultatet var at jeg skrev den første version af "measured", der grundlæggende set kunne opsamle en bestemt slags data og gøre dem tilgængelige, i real-tid, til et antal TCP forbindelser.

En af de første "klienter" var et Tcl-script (vi taler 1996...) som abonnerede på "alt" og fyldte det ned i Tobi's RRdTool, så det var nemt at plotte kurver over data.

Plottet ovenfor er lavet på præcis den måde.

Efterfølgende skete der forskellig knopskydning på measured programmet og det nåede sin endelige form for ca. 12 år siden.

I denne form er der en central konfigurationsfil, hvor man f.eks kan skrive::

load kamstrup 
kamstrup 24 debug 0
kamstrup 24 serial ps2:2007
kamstrup 24 var 60 type counter
kamstrup 24 var 68 type counter
kamstrup 24 var 74 
[...]

Det loader "kamstrup" biblioteket, som er på 366 linier C-kode der implementerer den underlige seriel-protokol Kamstrups målere betjener sig af.

I tidens løb har jeg skrevet omkring 25 moduler til measured, som takket være en masse god "infrastruktur-support" i measured typisk kun er på 200-400 linier C-kode hver.

Dernæst konfigureres "gruppe" 24 til at være en kamstrup måler der er forbundet via en TCP/IP-serielport dims og nogle forskellige variabler konfigureres.

Disse variabler polles nu regelmæssigt og kan tilgås via TCP/IP::

[...]
}PATTERN 0.24.60
}EVENTS
E 000.024.060 P NEW counter
E 000.024.060 P LABEL "E1 Energy register 1: Heat energy"
E 000.024.060 P FORMAT %g
E 000.024.060 P UNIT MWh
E 000.024.060 P LOW nan
E 000.024.060 P SAG nan
E 000.024.060 P RAISE nan
E 000.024.060 P HIGH nan
E 000.024.060 P LIMITDELAY 0
E 000.024.060 P HYSTERESIS 0
E 000.024.060 P TIMEOUT 120
E 000.024.060 P TRAP 0
E 000.024.060 P VALUE 106.325 1470842581.095142
E 000.024.060 P LIMIT normal 0 0
E 000.024.060 P VALUE 106.325 1470842586.925210
E 000.024.060 P VALUE 106.325 1470842592.666778
E 000.024.060 P VALUE 106.325 1470842598.403607

Kommandoen "PATTERN" definerer hvilke målepunkter vi vil høre om, og "EVENTS" starter abonnementet på dem.

De første linier indeholder metadata for dette ene punkt og derefter følger målingerne, med tilhørende timestamp.

Målepunktets "address" består af tre dele, 000.024.060, Det første tal siger at målingen er lokal, andet tal er gruppen og tredje tal er målepunktet i gruppen.

Der er nemlig et særligt modul til measured, som kan kontakte en anden measured og importere alle dens lokale målinger::

slave 34 hostname shus.dc.freebsd.dk

Disse målepunkter kommer f.eks til at hedde 034.004.001 og har præcis de samme egenskaber og muligheder som lokale målepunkter.

Measured indeholder også en meget primitiv webserver, så man fra sin browser kan se hvad der sker:

Som den vågne læser vil kunne gennemskue, er det også muligt at definere forskellige alarmer per punkt, to lave og to høje og alarmtilstanden distribueres naturligvis via TCP klientforbindelserne sammen med data.

Det er også muligt at styre udgange den anden vej og derfor kan man skrive et lille kontrolpanel i sit favorit-GUI som kan vise status og styre ting i den fjerne ende af netværket.

Det er faktisk ikke så tosset, alt i alt. Et par af mine kunder bruger det af samme grund også.

Men der er nogle steder hvor det halter og derfor er jeg ikke sikker på at det kommer med over i det nye hus og heller ikke alt for begejstret for at kaste det på github så andre kan arbejde med det.

For det første er alle målepunkter per definition et tal og det betyder at man skal hen og definere tilstande om til tal. Det er fint nok med "tændt/slukket", men noget rod når f.eks solcelle-inverteren har 200 mulige forskellige fejltilstande.

For det andet mangler der noget seriøs adgangskontrol. I de nuværende installationer er det klaret med VPN og firewalls, men fremover og i andres hænder, skal der en eller anden form for adgangskontrol på.

Endelig begynder koden at vise sin alder, på forskellig vis.

Men selve ideen, at det er distributionen man skal fokusere på, frem for opsamlingen, fejler ingenting.

phk

Poul-Henning Kamp er selvstændig open source-softwareudvikler. Han skriver blandt andet om politik, hysteri, spin, monopoler, frihedskampe gør-det-selv-teknologi og humor.
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Og en google søgning gav svarende på resten af mine spørgsmål :)

Ser frem til at høre om hvad du finder ud af i det nye hus!

  • 0
  • 0

Umiddelbart lyder ZMQ til at være et oplagt valg til distributionsdelen

  • 0
  • 0

M-BUS er standardkommunikation for varme-, vand- og gasmålere og stammer fra starten af 0-erne. Kamstrup kan også levere elmålere med M-BUS, for elsektoren ville ikke være med generelt.

Altså: En protokol for alle målere.

Jeg synes du skulle investere i standarden.

  • 0
  • 0

Jeg ville bare koble samtlige sensorer, målere, GPS'er, aktuatorer, lamper, alarmsystemer, adgangskontrol og hvad du ellers måtte have ind på et multimasternetværk baseret på publisher/subscriber modellen. Så er samtlige data tilgængelige for samtlige enheder i realtid. Alt det TCP/IP med evt. tilhørende routere giver et enormt overhead.

I mit tilfælde ville jeg gerne kombinere data fra DMI med data fra en GPS modtager og måledata fra nogle HP instrumenter, men samtidig skulle jeg også bruge de serielle data fra GPS modtageren i mindst to andre programmer på to andre computere.

Det er bl.a. her, et sådant system kommer til sin ret. Når f.eks. GPS modtageren udsender/publicerer data, kan de 3 enheder, der skal bruge dem, blot "snuppe" dem uden nogen tidsforsinkelse. Det kræver bare et acceptance filter i de enkelte enheder, som sættes op til at modtage de data, enheden vi abonnere på. Det er meget simplere og hurtigere end at skulle route alle data via en central database og masterenhed, og der er intet, der skal sættes op globalt, og som man skal huske at nedlægge igen, hvis en enhed fjernes.

Master-slave systemer som M-bus er i praksis håbløse at have med at gøre og meget ineffektive, fordi alt nødvendigvis skal via masterenheden. Man kan ikke bare hægte en debugger eller et fjernkontrolsystem på og så snakke med alle enheder og logge kommunikationen. M-bus er oven i købet kun en sensorbus, da slave kommunikationen er baseret på en lille strømvariation, der ville totalt drukne i strøm til aktuatorer, lamper etc. Jeg forlod master-slave princippet i 1984, da jeg designede mit første multimasternet (STL-net), og det burde du også gøre, hvis du vil ret meget mere visionært med det husstyringssystem end blot at logge fundamentstemperaturen og tilstanden af dit solfangersystem engang imellem.

I stedet for de 3 intetsigende, numeriske værdier i din kodning, som er umulige at huske, ville jeg så blot lave en "identifier" til de enkelte værdier baseret på skiftevis bogstaver og tal som f.eks. HX127AT4 for Heat Exchanger 127A Temperature 4. Der findes allerede en international standard (ISO 3511) for brugen af ét bogstav til at specificere f.eks. temperatur, spænding, strøm etc.; men den er nok ikke helt dækkende til dit brug, og jeg har også måttet modificere den til mit, da den bl.a. ikke kan skelne mellem hastighed, omdrejninger pr. minut og frekvens. Bemærk, at med publisher/subscriber modellen er det den enkelte værdi, der har et navn (identifier) - i princippet ikke den enhed, som udsender den, selv om det i praksis er lettere at debugge, hvis der er et sammenfald.

Her er en link til, hvad jeg er igang med på området: http://www.max-i.org ; men en CAN-bus vil nok også kunne opfylde dit behov bortset fra, at det er svært at presse ialtfald et industrielt nummereringssystem, som det jeg har udviklet (PNS), ind i en 29-bit identifier (går lige akkurat med 31 bit). Desuden udnytter mange CAN protokoller ikke den geniale publisher/subscriber model; men de fleste CAN protokoller er alligevel så unødvendig komplicerede, at man lige så godt kan lave sin egen, hvis man ikke er tvunget til at skulle interface til en given protokol. KISS!

  • 1
  • 1

Lidt afklarende oplysninger omkring M-bus. Disclaimer, jeg er aktiv i dette standardiseringsarbejde.

M-bus er en multi-drop arkitektur. Den klassiske M-bus er en to-tråds arkitektur. Den signalerer med spænding fra master til slave og med strøm fra slave til master. Den er i stand til at levere en lille strøm til den enkelte slave. EN 1434 serien af standarder specificerer fjernvarmemålere. EN 1434-3 (part 3) specificerede oprindeligt selve M-bus'en. I dag gør den det kun i begrænset omfang, nemlig kun det der er meget fjernvarme specifikt. Selve kommunikationen er i dag specificeret i EN 13757 serien af standarder. Selve bus'en er i dagspecificeret i EN 13757-2. Dataformatet er specificeret i EN 13757-3. Det dækker i dag også data for elmålere. Standarden er sidenhen blevet udvidet til også at inkludere radio, populært kaldet Wireless M-bus. Den er specificeret i EN 13757-4 og EN 13757-5. Man kan ikke købe en 'ren' EN standard. Det er kun de nationale udgaver d.v.s. DS/EN, DIN/EN o.s.v. Vær her opmærksom på at de tyske udgaver er oversat til tysk, de franske ligeså.

  • 0
  • 0

M-bus er en multi-drop arkitektur. [...]

Og det er fint, men 100% inderligt ligegyldigt for mig, for jeg får aldrig et system hvor alting køre på samme protokol, M-bus eller anderledes.

Men skulle der dukke nogle M-bus enheder op, vil mit system også suge dem ind og gøre deres data tilgængelige, præcis som jeg gør med Modbus, Modbus over radio, TCP/IP, Kamstrup, 1-wire og alle mulige andre "standard protokoller" idag.

  • 3
  • 0

Og det er fint, men 100% inderligt ligegyldigt for mig, for jeg får aldrig et system hvor alting køre på samme protokol, M-bus eller anderledes.

Men skulle der dukke nogle M-bus enheder op, vil mit system også suge dem ind og gøre deres data tilgængelige, præcis som jeg gør med Modbus, Modbus over radio, TCP/IP, Kamstrup, 1-wire og alle mulige andre "standard protokoller" idag.

Så længe der er talrige standarder, bliver man nødt til at foretage en protokolkonvertering - spørgsmålet er bare hvor - ved kilden eller ved modtageren?

Her ville jeg absolut gøre det ved kilden for at kunne drage nytte af en multimasterbus baseret på publisher/subscriber modellen, hvor du tilsyneladende vil gøre det ved modtageren, hvilket kræver megen kabling i form af punkt-til-punkt forbindelser til de enkelte enheder, da de jo ikke bare kan kobles ind på samme (ring)net. Det giver dig desuden en flaskehals og en tidsforsinkelse, og gør samtlige enheder afhængig af, at masterenheden fungerer.

  • 0
  • 0

...at PHK's løsning lyder til at være smart og meget alsidig. Håber han finder tid til en opgraderet version.

  • 1
  • 0
Bidrag med din viden – log ind og deltag i debatten