Today, I finally got around to add a heater element to the rain sensor. In theory, I will now be able to measure the precipitation that comes as snow as well.
What I did was to put two 18 ohm (10 watt) resistors, in parallel, on the inside of the collector. I'll need to play a bit with it to find the optimal current, but right now it works just fine with ~0.5 amps, generating about 5 watts in total.
I guess the next logical step would be to add a temperature sensor and a control loop, to steer the power depending on temperature. Then I wouldn't need to turn it off manually summertime :)
Simplicity has its own beauty...
mandag 28. desember 2009
søndag 27. desember 2009
WMR200 weather station and Linux
Some time ago, we purchased a couple of Oregon Scientific WMR200 weather stations. We already had a WMR968 that did a good enough job at our weekend house, but we wanted to have a unit at home as well.
When the new units arrived, I was surprised to see that they had a USB interface instead of the serial interface on the '968. The serial protocol of the '968 is fairly well documented, but the '200 became a challenge. This posting attempts to document my findings.
USB interface
The '200 implements the USB HID profile, and to use it an initialization command has to be issued. Then, in a loop, a "ready for more data" command is sent, and we start waiting for USB "interrupts". A message from the '200 can consist of one or more interrupt frames. Each interrupt frame is 8 octets long, where the first octet says how many of the remaining octets are valid.
Protocol
The first octet of each message frame is the message type. The second is usually the frame length (including the type and length octets). The last two octets are usually a checksum.
Several of the frame types include date and time. These are coded in octet 2-6, with one octet each for minute, hour, day, month and year-2000 .
Frame type 0xD1
This is a one byte message (no length field or checksum)
Frame type 0xD2
Still unknown. May be for historical data.
Frame type 0xD3
Wind data
D3 - type
10 - length (0x10)
mm - minute
hh - hour
dd - day
MM - month
yy - year
d1 - wind direction in 22.5 degrees increments (0-15)
gs - gust wind (* 0.1 m/s)
xx - unknown ?
xx
xx
xx
xx
cs - checksum
cs - checksum
Frame type 0xD4
Rain data, length = 16 octets
0 - type (D4)
1 - length (0x10)
2-6 datetime
7-8 rate (0.01 inches/hour)
9-10 last hour (0.01 inches)
11-12 last 24 hours (0.01 inches)
13-14 accumulated (0.01 inches)
Frame type 0xD5
Unknown. length=10 octets
Frame type 0xD6
Barometric pressure and forecast. length=13 octets
0 - type (0xD6)
1 - length (13)
2-6 datetime
7 - unknown
8-9 pressure (in hPa)
Frame type 0xD7
Temperature. length=16 octets
0 - type (0xD7)
1 - length (10)
2-6 datetime
7 - sensor id (low nibble)
8-9 temperature (0.1°C)
10 - humidity (%)
Frame type 0xD8
Not seen
Frame type 0xD9
Unknown. length=8 octets
When the new units arrived, I was surprised to see that they had a USB interface instead of the serial interface on the '968. The serial protocol of the '968 is fairly well documented, but the '200 became a challenge. This posting attempts to document my findings.
USB interface
The '200 implements the USB HID profile, and to use it an initialization command has to be issued. Then, in a loop, a "ready for more data" command is sent, and we start waiting for USB "interrupts". A message from the '200 can consist of one or more interrupt frames. Each interrupt frame is 8 octets long, where the first octet says how many of the remaining octets are valid.
Protocol
The first octet of each message frame is the message type. The second is usually the frame length (including the type and length octets). The last two octets are usually a checksum.
Several of the frame types include date and time. These are coded in octet 2-6, with one octet each for minute, hour, day, month and year-2000 .
Frame type 0xD1
This is a one byte message (no length field or checksum)
Frame type 0xD2
Still unknown. May be for historical data.
Frame type 0xD3
Wind data
D3 - type
10 - length (0x10)
mm - minute
hh - hour
dd - day
MM - month
yy - year
d1 - wind direction in 22.5 degrees increments (0-15)
gs - gust wind (* 0.1 m/s)
xx - unknown ?
xx
xx
xx
xx
cs - checksum
cs - checksum
Frame type 0xD4
Rain data, length = 16 octets
0 - type (D4)
1 - length (0x10)
2-6 datetime
7-8 rate (0.01 inches/hour)
9-10 last hour (0.01 inches)
11-12 last 24 hours (0.01 inches)
13-14 accumulated (0.01 inches)
Frame type 0xD5
Unknown. length=10 octets
Frame type 0xD6
Barometric pressure and forecast. length=13 octets
0 - type (0xD6)
1 - length (13)
2-6 datetime
7 - unknown
8-9 pressure (in hPa)
Frame type 0xD7
Temperature. length=16 octets
0 - type (0xD7)
1 - length (10)
2-6 datetime
7 - sensor id (low nibble)
8-9 temperature (0.1°C)
10 - humidity (%)
Frame type 0xD8
Not seen
Frame type 0xD9
Unknown. length=8 octets
torsdag 17. desember 2009
Trondheim Bystyre - et teknologisk roterom?
Møtene på nett
Som vararepresentant til Trondheim Bystyre ser jeg på det som en plikt å prøve å følge med på bystyrets møter, uansett om jeg møter selv eller sitter hjemme. Siden møtene streames på nett skulle det ikke være vanskelig å holde seg orientert selv om man ikke sitter i salen.
Det siste året har det vært en rekke problemer. Under ett av møtene var det umulig å følge med fordi streamen gikk ned ca. én gang pr. minutt. Under møtet nå i kveld er det bilde, men ingen lyd. Hadde det vært omvendt hadde problemet vært vesentlig mindre ...
Streamingløsning
Trondheim kommune installerte denne sommeren/høsten et nytt system for streaming av møtene. Dette systemet ser ut til kun å ha vært testet blant brukere som også er kunder hos Microsoft. For oss som bruker operativsystem og vevlesere fra andre leverandører er det noe mindre smertefritt. Ingenting av det tekniske er spesielt komplisert, så det skulle ikke være noe problem for en kompetent systemleverandør å få det til å fungere i henhold til gjeldende standarder, i stedet for kun mot en enkelt vevleser.
For å kunne følge med på strømmen trenger en medieavspiller som skjønner Microsofts proprietære bilde- og lydformater. Dette finnes å få tak i for MacOSX, Linux og Solaris, men ikke nødvendigvis på en lovlig måte.
Ved siden av videostrømmen har man en vevside som viser informasjon om hvilken sak som behandles. Denne siden blir ikke oppdatert når man ikke benytter Internet Explorer, så det er tydelig at her benyttes proprietære utvidelser. Dersom jeg reloader siden (eller framen) får jeg oppdatert den, men det må altså gjøres manuelt.
Hva vil jeg ha?
Som bruker av system hadde jeg kunnet tenkt meg å ha lyd og bilde fra talerstolen. Dette fungerer nesten hver gang, og da er det bra nok. Det neste er at jeg gjerne kunne tenkt meg å se voteringstavlen under votering. Denne får vi se i videostrømmen av og til, men kanskje hadde det vært en idé å få denne opp som et eget skjermbilde? Det tredje er talerlisten. Denne får man, som regel, se når man sitter i salen, og den kunne det vært kjekt å se som eget skjermbilde.
Hva kan kommunen gjøre?
Det enkleste kommunen kan gjøre er å legge ut en URL i klartekst, som peker direkte til strømmen. Dette gjør at man ikke trenger en vevleser med støtte for de proprietære taggene/skriptene/funksjonene som kun finnes i Internet Explorer. Da kan man bare peke mediespilleren sin rett til strømmen, og få denne.
Noe mer komplisert vil det kanskje være å bruke en åpen standard for strømmen? Dette kan f.eks være basert på MPEG-4 eller Ogg Theora, begge velkjente og fungerende.
Videre bør man ha en vevside som holder seg til åpne standarder, og ikke bruker proprietære utvidelser i IE. Ingenting av det vevsiden til Trondheim kommunes streamløsning gjør er noe vanskeligere å få til selv om man gjør det med standard HTML og standard ECMAScript/JavaScript. En meta-tag som gir automatisk omlasting av side en gang i minuttet kunne f.eks løst problemet med at sakssiden ikke oppdateres.
Trondheim kommune må i fremtiden sikre at leveranser av slike systemer benytter åpne standarder, og ikke gjør at brukerne må være kunder av ett selskap (Microsoft) for å kunne ha full glede av den. Det er ikke vanskeligere å lage slike løsninger, men det krever at leverandøren er kompetent, og faktisk har en forståelse for at lukkede proprietære løsninger ikke er noe Trondheim kommune kan benytte.
Som vararepresentant til Trondheim Bystyre ser jeg på det som en plikt å prøve å følge med på bystyrets møter, uansett om jeg møter selv eller sitter hjemme. Siden møtene streames på nett skulle det ikke være vanskelig å holde seg orientert selv om man ikke sitter i salen.
Det siste året har det vært en rekke problemer. Under ett av møtene var det umulig å følge med fordi streamen gikk ned ca. én gang pr. minutt. Under møtet nå i kveld er det bilde, men ingen lyd. Hadde det vært omvendt hadde problemet vært vesentlig mindre ...
Streamingløsning
Trondheim kommune installerte denne sommeren/høsten et nytt system for streaming av møtene. Dette systemet ser ut til kun å ha vært testet blant brukere som også er kunder hos Microsoft. For oss som bruker operativsystem og vevlesere fra andre leverandører er det noe mindre smertefritt. Ingenting av det tekniske er spesielt komplisert, så det skulle ikke være noe problem for en kompetent systemleverandør å få det til å fungere i henhold til gjeldende standarder, i stedet for kun mot en enkelt vevleser.
For å kunne følge med på strømmen trenger en medieavspiller som skjønner Microsofts proprietære bilde- og lydformater. Dette finnes å få tak i for MacOSX, Linux og Solaris, men ikke nødvendigvis på en lovlig måte.
Ved siden av videostrømmen har man en vevside som viser informasjon om hvilken sak som behandles. Denne siden blir ikke oppdatert når man ikke benytter Internet Explorer, så det er tydelig at her benyttes proprietære utvidelser. Dersom jeg reloader siden (eller framen) får jeg oppdatert den, men det må altså gjøres manuelt.
Hva vil jeg ha?
Som bruker av system hadde jeg kunnet tenkt meg å ha lyd og bilde fra talerstolen. Dette fungerer nesten hver gang, og da er det bra nok. Det neste er at jeg gjerne kunne tenkt meg å se voteringstavlen under votering. Denne får vi se i videostrømmen av og til, men kanskje hadde det vært en idé å få denne opp som et eget skjermbilde? Det tredje er talerlisten. Denne får man, som regel, se når man sitter i salen, og den kunne det vært kjekt å se som eget skjermbilde.
Hva kan kommunen gjøre?
Det enkleste kommunen kan gjøre er å legge ut en URL i klartekst, som peker direkte til strømmen. Dette gjør at man ikke trenger en vevleser med støtte for de proprietære taggene/skriptene/funksjonene som kun finnes i Internet Explorer. Da kan man bare peke mediespilleren sin rett til strømmen, og få denne.
Noe mer komplisert vil det kanskje være å bruke en åpen standard for strømmen? Dette kan f.eks være basert på MPEG-4 eller Ogg Theora, begge velkjente og fungerende.
Videre bør man ha en vevside som holder seg til åpne standarder, og ikke bruker proprietære utvidelser i IE. Ingenting av det vevsiden til Trondheim kommunes streamløsning gjør er noe vanskeligere å få til selv om man gjør det med standard HTML og standard ECMAScript/JavaScript. En meta-tag som gir automatisk omlasting av side en gang i minuttet kunne f.eks løst problemet med at sakssiden ikke oppdateres.
Trondheim kommune må i fremtiden sikre at leveranser av slike systemer benytter åpne standarder, og ikke gjør at brukerne må være kunder av ett selskap (Microsoft) for å kunne ha full glede av den. Det er ikke vanskeligere å lage slike løsninger, men det krever at leverandøren er kompetent, og faktisk har en forståelse for at lukkede proprietære løsninger ikke er noe Trondheim kommune kan benytte.
søndag 13. desember 2009
Reduksjon av Bystyret
Som nevnt tidligere så foregår det en prosess der man bl.a ser på å redusere antall representanter i kommunestyret i Trondheim. Lovens minimum (jfr. koml.§7) vil være 43 representanter, mens antallet i dag er 85.
Jeg har forsøkt å regne litt på hva som vil skje med kommunestyrets sammensetning ved en endring i representanttall. Som utgangspunkt har jeg brukt stemmetallene fra valget 2007. Tabellen under viser hvordan resultatet ville blitt, med størrelser fra 100 og ned til 43 representanter.
Allerede ved en størrelse på 80 så faller Demokratene helt ut. De er i dag kun representert ved Svein Otto Nilsen. Ved 74 mister RV ett av sine tre, og ved 72 mister MDG det ene av sine to.
KrF mister sitt første (av tre) ved 69, og Venstre sitt første (av tre) ved 60.
Vi må helt ned i 46 før nok et parti faller ut, nemlig Pensjonistpartiet, som i dag har én representant.
Jeg har forsøkt å regne litt på hva som vil skje med kommunestyrets sammensetning ved en endring i representanttall. Som utgangspunkt har jeg brukt stemmetallene fra valget 2007. Tabellen under viser hvordan resultatet ville blitt, med størrelser fra 100 og ned til 43 representanter.
Allerede ved en størrelse på 80 så faller Demokratene helt ut. De er i dag kun representert ved Svein Otto Nilsen. Ved 74 mister RV ett av sine tre, og ved 72 mister MDG det ene av sine to.
KrF mister sitt første (av tre) ved 69, og Venstre sitt første (av tre) ved 60.
Vi må helt ned i 46 før nok et parti faller ut, nemlig Pensjonistpartiet, som i dag har én representant.
| AP | SV | RV | SP | KRF | V | H | FRP | DEM | MDG | NKP | PP | |
| 44 | 8 | 3 | 3 | 4 | 4 | 15 | 15 | 1 | 2 | 0 | 1 | |
| 44 | 8 | 3 | 3 | 3 | 4 | 15 | 15 | 1 | 2 | 0 | 1 | |
| 43 | 8 | 3 | 3 | 3 | 4 | 15 | 15 | 1 | 2 | 0 | 1 | |
| 43 | 8 | 3 | 3 | 3 | 4 | 15 | 14 | 1 | 2 | 0 | 1 | |
| 43 | 8 | 3 | 3 | 3 | 4 | 14 | 14 | 1 | 2 | 0 | 1 | |
| 42 | 8 | 3 | 3 | 3 | 4 | 14 | 14 | 1 | 2 | 0 | 1 | |
| 41 | 8 | 3 | 3 | 3 | 4 | 14 | 14 | 1 | 2 | 0 | 1 | |
| 41 | 8 | 3 | 2 | 3 | 4 | 14 | 14 | 1 | 2 | 0 | 1 | |
| 41 | 8 | 3 | 2 | 3 | 4 | 14 | 13 | 1 | 2 | 0 | 1 | |
| 40 | 8 | 3 | 2 | 3 | 4 | 14 | 13 | 1 | 2 | 0 | 1 | |
| 40 | 7 | 3 | 2 | 3 | 4 | 14 | 13 | 1 | 2 | 0 | 1 | |
| 40 | 7 | 3 | 2 | 3 | 4 | 13 | 13 | 1 | 2 | 0 | 1 | |
| 39 | 7 | 3 | 2 | 3 | 4 | 13 | 13 | 1 | 2 | 0 | 1 | |
| 38 | 7 | 3 | 2 | 3 | 4 | 13 | 13 | 1 | 2 | 0 | 1 | |
| 38 | 7 | 3 | 2 | 3 | 3 | 13 | 13 | 1 | 2 | 0 | 1 | |
| 37 | 7 | 3 | 2 | 3 | 3 | 13 | 13 | 1 | 2 | 0 | 1 | |
| 37 | 7 | 3 | 2 | 3 | 3 | 13 | 12 | 1 | 2 | 0 | 1 | |
| 37 | 7 | 3 | 2 | 3 | 3 | 12 | 12 | 1 | 2 | 0 | 1 | |
| 36 | 7 | 3 | 2 | 3 | 3 | 12 | 12 | 1 | 2 | 0 | 1 | |
| 35 | 7 | 3 | 2 | 3 | 3 | 12 | 12 | 1 | 2 | 0 | 1 | |
| 35 | 7 | 3 | 2 | 3 | 3 | 12 | 12 | 0 | 2 | 0 | 1 | |
| 35 | 6 | 3 | 2 | 3 | 3 | 12 | 12 | 0 | 2 | 0 | 1 | |
| 35 | 6 | 3 | 2 | 3 | 3 | 12 | 11 | 0 | 2 | 0 | 1 | |
| 34 | 6 | 3 | 2 | 3 | 3 | 12 | 11 | 0 | 2 | 0 | 1 | |
| 34 | 6 | 3 | 2 | 3 | 3 | 11 | 11 | 0 | 2 | 0 | 1 | |
| 33 | 6 | 3 | 2 | 3 | 3 | 11 | 11 | 0 | 2 | 0 | 1 | |
| 33 | 6 | 2 | 2 | 3 | 3 | 11 | 11 | 0 | 2 | 0 | 1 | |
| 32 | 6 | 2 | 2 | 3 | 3 | 11 | 11 | 0 | 2 | 0 | 1 | |
| 32 | 6 | 2 | 2 | 3 | 3 | 11 | 11 | 0 | 1 | 0 | 1 | |
| 31 | 6 | 2 | 2 | 3 | 3 | 11 | 11 | 0 | 1 | 0 | 1 | |
| 31 | 6 | 2 | 2 | 3 | 3 | 11 | 10 | 0 | 1 | 0 | 1 | |
| 31 | 6 | 2 | 2 | 2 | 3 | 11 | 10 | 0 | 1 | 0 | 1 | |
| 31 | 6 | 2 | 2 | 2 | 3 | 10 | 10 | 0 | 1 | 0 | 1 | |
| 30 | 6 | 2 | 2 | 2 | 3 | 10 | 10 | 0 | 1 | 0 | 1 | |
| 29 | 6 | 2 | 2 | 2 | 3 | 10 | 10 | 0 | 1 | 0 | 1 | |
| 29 | 5 | 2 | 2 | 2 | 3 | 10 | 10 | 0 | 1 | 0 | 1 | |
| 29 | 5 | 2 | 2 | 2 | 3 | 10 | 9 | 0 | 1 | 0 | 1 | |
| 28 | 5 | 2 | 2 | 2 | 3 | 10 | 9 | 0 | 1 | 0 | 1 | |
| 28 | 5 | 2 | 2 | 2 | 3 | 9 | 9 | 0 | 1 | 0 | 1 | |
| 27 | 5 | 2 | 2 | 2 | 3 | 9 | 9 | 0 | 1 | 0 | 1 | |
| 27 | 5 | 2 | 2 | 2 | 2 | 9 | 9 | 0 | 1 | 0 | 1 | |
| 26 | 5 | 2 | 2 | 2 | 2 | 9 | 9 | 0 | 1 | 0 | 1 | |
| 25 | 5 | 2 | 2 | 2 | 2 | 9 | 9 | 0 | 1 | 0 | 1 | |
| 25 | 5 | 2 | 2 | 2 | 2 | 9 | 8 | 0 | 1 | 0 | 1 | |
| 25 | 5 | 2 | 2 | 2 | 2 | 8 | 8 | 0 | 1 | 0 | 1 | |
| 24 | 5 | 2 | 2 | 2 | 2 | 8 | 8 | 0 | 1 | 0 | 1 | |
| 24 | 5 | 2 | 1 | 2 | 2 | 8 | 8 | 0 | 1 | 0 | 1 | |
| 24 | 4 | 2 | 1 | 2 | 2 | 8 | 8 | 0 | 1 | 0 | 1 | |
| 23 | 4 | 2 | 1 | 2 | 2 | 8 | 8 | 0 | 1 | 0 | 1 | |
| 22 | 4 | 2 | 1 | 2 | 2 | 8 | 8 | 0 | 1 | 0 | 1 | |
| 22 | 4 | 2 | 1 | 2 | 2 | 8 | 7 | 0 | 1 | 0 | 1 | |
| 22 | 4 | 2 | 1 | 2 | 2 | 7 | 7 | 0 | 1 | 0 | 1 | |
| 21 | 4 | 2 | 1 | 2 | 2 | 7 | 7 | 0 | 1 | 0 | 1 | |
| 20 | 4 | 2 | 1 | 2 | 2 | 7 | 7 | 0 | 1 | 0 | 1 | |
| 20 | 4 | 2 | 1 | 2 | 2 | 7 | 7 | 0 | 1 | 0 | 0 | |
| 20 | 4 | 1 | 1 | 2 | 2 | 7 | 7 | 0 | 1 | 0 | 0 | |
| 20 | 4 | 1 | 1 | 2 | 2 | 7 | 6 | 0 | 1 | 0 | 0 | |
| 19 | 4 | 1 | 1 | 2 | 2 | 7 | 6 | 0 | 1 | 0 | 0 |
fredag 4. desember 2009
Politisk representasjon
I Trondheim pågår det for tiden en debatt om sammensetningen av bystyret, og hvordan byen skal styres. Tidligere har forslag om å gå over til en form for byparlamentarisme, slik det er blitt gjort i Oslo og Bergen, vært oppe, men det virker kanskje som om det ikke er så stor stemning for det denne gangen. Arbeiderpartiet har tidligere vært for å innføre byregjering, men kanskje er tanken på å måtte sitte der og svare for sine venner i flertallskonstellasjonen ikke så innbydende.
Trondheim har landets nest største folkevalgte forsamling, med 85 representanter i kommunestyret. Det er blitt hevdet at dette er for mange, at det er for dyrt, og at det gjør at møtene i kommunestyret tar for lang tid. Det kan være et gyldig poeng, men jeg har sett litt på de andre større kommunene i landet, for å se hvordan Trondheim kommer ut. Jeg har sett på antall kommunestyrerepresentanter, antall i bydelsutvalg for de kommunene som har direkte folkevalgte i slike, og regnet på hvor mange innbyggere det er pr. valgte representant.
Det man først og fremst kan lese av tallene er at Trondheim allerede ligger i det nedre skiktet i forhold til representasjon, slik at kutt i bystyrets størrelse ikke er en selvsagt konklusjon.
Det er neppe i forhold til selve bystyremøtet at den representasjonen vi har i dag er nødvendig, men snarere i forhold til det virkelige arbeidet som utføres i komiteene. Det er i komiteene de store debattene tas, og det er der mesteparten av beslutningene egentlig tas. En reduksjon av bystyret uten å gjøre noe med komiteene vil nødvendigvis medføre at færre hoder, færre syn, og færre partier er med i debatten. Vi risikerer både at arbeidsbelastningen på de som sitter der blir større enn den bør være, og at ikke alle relevante momenter kommer inn i debatten som leder frem til vedtak og innstilling.
Trondheim har landets nest største folkevalgte forsamling, med 85 representanter i kommunestyret. Det er blitt hevdet at dette er for mange, at det er for dyrt, og at det gjør at møtene i kommunestyret tar for lang tid. Det kan være et gyldig poeng, men jeg har sett litt på de andre større kommunene i landet, for å se hvordan Trondheim kommer ut. Jeg har sett på antall kommunestyrerepresentanter, antall i bydelsutvalg for de kommunene som har direkte folkevalgte i slike, og regnet på hvor mange innbyggere det er pr. valgte representant.
| Kommune | Innbyggertall | Repr. | Bydelsutv | Tot. repr. | Innbyggere pr. repr |
|---|---|---|---|---|---|
| Oslo | 578 870 | 59 | 225 | 284 | 2038 |
| Bergen | 252 918 | 67 | 82 | 149 | 1697 |
| Trondheim | 168 988 | 85 | 0 | 85 | 1988 |
| Stavanger | 122 162 | 67 | 0 | 67 | 1823 |
| Bærum | 110 048 | 51 | 0 | 51 | 2158 |
| Kristiansand | 80 410 | 53 | 0 | 53 | 1517 |
| Fredrikstad | 72 935 | 53 | 0 | 53 | 1376 |
| Tromsø | 66 772 | 43 | 0 | 43 | 1553 |
Det man først og fremst kan lese av tallene er at Trondheim allerede ligger i det nedre skiktet i forhold til representasjon, slik at kutt i bystyrets størrelse ikke er en selvsagt konklusjon.
Det er neppe i forhold til selve bystyremøtet at den representasjonen vi har i dag er nødvendig, men snarere i forhold til det virkelige arbeidet som utføres i komiteene. Det er i komiteene de store debattene tas, og det er der mesteparten av beslutningene egentlig tas. En reduksjon av bystyret uten å gjøre noe med komiteene vil nødvendigvis medføre at færre hoder, færre syn, og færre partier er med i debatten. Vi risikerer både at arbeidsbelastningen på de som sitter der blir større enn den bør være, og at ikke alle relevante momenter kommer inn i debatten som leder frem til vedtak og innstilling.
Abonner på:
Innlegg (Atom)
