OlavT

Micro Matic´s elektronisk døgn-/ukeur har automatisk korrigering av sommer-/vintertid. Kontakturet er beregnet for DIN skinnemontering. Uret er meget lette å programmere etter utførlig bruksanvisning på norsk. Pris: 590kr • Automatisk sommer-/vintertidveksling • Døgn/uke program med 30 programplasser • Korteste innkoplingstid 1 minutt • Impulsfunksjon 1- 59 sekunder • Manuell overstyring • Enkel programmering • Enkel kontrollrutine for sjekk av program • Ferieprogram • Display med lys. • 230V • IP20. • BxH: 35,8x90 mm.

Interessant å se hvordan rutene fra en node til kontroller endres over tid. Startet kontrolleren i går kveld.

Er det noen Z-Wave eksperter her? Jeg registrerer at HeatIt TRM-3 sender ut slike meldinger regelmessig: 26.01.2022 22:49:58.107 - INFO: Received: SOF Length=0x0e REQUEST FUNC_ID_APPLICATION_COMMAND_HANDLER ReceiveStatus=Multi NodeId=0x09 PayloadLength=0x06 SENSOR_MULTILEVEL 0x05 0x01 0x22 0x00 0xd1 RSSI=179 0x00 0x87 Jeg har bare satt opp Multi Channel Associations og hadde forventet at alle meldinger som ble sendt fra TRM-3 da ville være Multi Channel encapsulated. Jeg får i tillegg som forventet Multi Channel encapsulated meldinger også: 26.01.2022 22:47:58.227 - INFO: Received: SOF Length=0x12 REQUEST FUNC_ID_APPLICATION_COMMAND_HANDLER ReceiveStatus=Single NodeId=0x09 PayloadLength=0x0a MULTI_CHANNEL 0x0d 0x02 0x00 0x31 0x05 0x01 0x22 0x00 0xd1 RSSI=187 0x00 0xf8 26.01.2022 22:47:58.228 - INFO: MultiChannel.HandleEncap: NodeId=0x09 sourceEndPoint=2 destinationEndPointIsBitMask=False destinationEndPoint=0 SENSOR_MULTILEVEL 26.01.2022 22:47:58.229 - INFO: ZWaveNode.HandleApplicationCommand: NodeId=0x09 EndPointNumber=2 Command=SENSOR_MULTILEVEL 0x05 0x01 0x22 0x00 0xd1 26.01.2022 22:47:58.229 - INFO: SensorMultilevel.HandleReport: sensorType=AirTemperature size=2 scaleId=0 precision=1 sensorValue=20.9 Jeg registrerer også at meldingen som ikke er Multi Channel Encapsulated er en multicast frame. Noen som vet hvorfor?

Hvor finner en FW filene fra HeatIt? Før lå de ute på web-sidene, men har ikke sett noe til de i det siste.

Det SV egentlig mener er at de (staten) skal dele ut en rasjon strøm og så betaler en dyrt for all bruk over det. Det gjelder enten en trenger det for å varme opp et gammelt hus, koke kaffe, varme opp boblebadet, lage middag eller vaske klær.

Nei, dimmerene blir "døde" og svarer ikke. Det er mange som har rapportert problemer med Namron sine Z-Wave dimmere. Steinel IS 140-2 svarer, men med "korrupt" info. Har du erfaringer selv med Steinel IS 140-2?

MIn konklusjon når det gjelder Namron sin 200 Watt Z-Wave dimmer er at den "henger seg opp" etter noen dagers drift. Når dette skjer svarer den ikke på Z-Wave meldinger. Strøm av / på løser problemet til det oppstår igjen om noen dager.

Er det noen som har erfaring med Steinel IS 140-2 bevelgelses sensor? Min erfaring er at etter noen dagers drift (etter strøm på), så blir den på en måte "korrupt". Det vil si at den rapporterer feil i Node Information Frame til kontroller i forhold til hvilke command classes den støtter. Strøm av / på løser problemet. Noen som har denne?

Dersom dette er avrunder så blir nok summen av timene ganske likt som å ta siste måling for måneden og trekke fra første. Noen ganger vil jo HAN-data for en time ligger under Elhub og andre ganger over så dette jevner seg ut over måneden. Jeg har lagt inn en sak hos Elvia så får vi se hva de svarer. Jeg synes fortsatt det er merkelig at oppløsningen til nettselskapene / Elhub er forskjellig fra HAN-data.

Nei, hadde ikke tenkt å gå langt enda. Ville bare sjekke om jeg fikk samme tall som på elhub. Men, det kunne jo vært artig å tatt det helt ut til en full avregning.

Var ikke hele poenget med HAN-porten at forbruker skulle ha tilgang til de samme data for avregining som nettleverandøren? Det har jo noe med å kunne etterprøve faktureringsgrunnlaget for eksempel. Men, det kan se ut som om Elhub opererer med 3 siffer og HAN med 2 siffer bak komma på kWh. Dersom jeg tar siste verdi for en måned og trekker fra første verdi så stemmer det fortsatt ganske bra (et ekstra siffer bak komma på Elhub). Tror nok at konklusjonen kan være at data til nettleverandør og det som kommer ut på HAN-porten er litt forskjellig. Dette er forøvrig koden min for akkurat dette: CosemUnsigned32 value = (CosemUnsigned32)cosemStructure[1]; CosemStructure scaleUnitStructure = (CosemStructure)cosemStructure[2]; CosemInteger8 scale = (CosemInteger8)scaleUnitStructure[0]; double kwh = value.Value * Math.Pow(10, scale.Value) / 1000;

Tror ikke det skal være noen avrunding noe sted. Jeg tar data fra HAN porten og deler på 1000 for å få kWh. Tallet er alltid rent og pent med to desimaler. Jeg runder ikke av noe. Det som går ut på HAN porten skal vel være det samme som går til nettselskapet? Jeg har sendt en henvendelse til Elvia og bedt om en forklaring på hvordan de regner ut det som rapporteres til Elhub. Min tanke var om reactive verdiene inngår i regnestykket.

Her er et eksempel fra mine data: 7:00 8:00 9:00 Cumulative hourly active import energy (A+) (Q1+Q4) 81288.81 81291.23 81292.31 Cumulative hourly active export energy (A-) (Q2+Q3) 0 0 0 Cumulative hourly reactive import energy (R+) (Q1+Q2) 30332.1 30333.82 30333.82 Cumulative hourly reactive export energy (R-) (Q3+Q4) 1979.08 1979.18 1979.37 Diff 2.42 1.08 Elhub 2.421 1.082 Som dere ser så er målerverdiene fra Elhub nesten identiske med differansen i "Cumulative hourly active import energy (A+) (Q1+Q4)", men ikke 100%.

Hvilken nettleverandør har du?

Dette tallet stemmer ikke 100% med det som vises på Elhub. Det er et lite avvik.

AMS måleren leverer følgende data ut fra HAN-porten hver time: Cumulative hourly active import energy (A+) (Q1+Q4) Wh Cumulative hourly active export energy (A-) (Q2+Q3) Wh Cumulative hourly reactive import energy (R+) (Q1+Q2) VArh Cumulative hourly reactive export energy (R-) (Q3+Q4) VArh Hvordan bergner jeg kWh forbruket som jeg finner igjen i Elhub portalen? Dersom jeg tar bare med Wh i regnestykket mitt får jeg et lite avvik i forhold til tallet i Elhub.

Jeg har den suspekte. Men, er det typisk at den bare klarer å lese 1 byte (0x07) og ingenting mer? Har bestilt meg en ny leser også. Synd at den med en USB-kabel på ikke fungerer for den er litt mer praktisk.

Har akkurat fått koblet meg opp til Hafslund / Aidon over HAN, men får bare en byte 0x07 hvert 2.5 sekund. Har fått beskjed om at porten skulle vært åpnet, men er det slik den ville oppført seg om den ikke er korrekt åpnet?

Har en eldre varmepumpe som jeg kunne tenkte meg å styre uten å måtte fysisk trykke på kontrollpanelet. Alt slikt utstyr burde hatt en RS232 port og en dokumentert protokoll for styring av funksjonaliteten! Jeg mistenker at selv nytt utstyr har lukkede løsninger og er da i praksis nesten ubrukelige til å inngå i en helhet. Noen som har noen tips?

Er på jakt etter en utendørs Z-Wave bevegelsessensor, men finner lite å få kjøpt? Noen som har noe å anbefale?

Ja, men da må den skrus på veggen der strømkabelen kommer ut av veggen ved varmtvamsberederen og jeg vet ikke hvor tilgjengelig det punktet er.

Har en varmtvannsbereder som er fast montert med strøm. Hva er de beste Z-Wave devicene for å styre denne samt å måle strømforbruket? Disse? https://www.tronika.no/en/consumption-meters/960-power-meter-zmnhtd1.html https://www.tronika.no/en/smarthome-accessories/959-contactor-ika232-20.html Andre alternativer?

Fant forøvrig en litt merkelig kWh måling i meldingen som blir sendt hver time. Den var identisk to timer på rad enda det var rapportert effekt den timen. Her er tallene: 00: 16787.3 01: 16788.54 (+1.24) 02: 16790.57 (+2.03) 03: 16790.57 (0.00) 04: 16793.37 (+2.80) 05: 16794.9 (+1.53) Noen som har sett lignende?

Takk for all hjelp. Da har jeg kode som leser og tolker alle Aidon HAN meldingene. Det er nyttig å kunne sjekke dataene fra strømmåleren. Synes det er merkelig mye aktivitet på hytta som står med 6 grader innetemperatur. Det er sikkert panelovnene, men de går i såfall av og på hele tiden. Hadde trodd de skulle ha en hysterese som gjorde at de tok seg litt lengre pauser. Jeg får dobbeltsjekke etterhvert. Uansett artig og kunne få data.

Ok, da har jeg laget kode for å parse Cosem meldingene slik: 04.02.2019 15:00:01.142 - INFO: Reading from HAN port 04.02.2019 15:00:02.386 - INFO: FormatType=10 FrameLength=42 04.02.2019 15:00:02.389 - INFO: DestinationAddressLength=1 SourceAddressLength=2 04.02.2019 15:00:02.391 - INFO: Control=19 04.02.2019 15:00:02.394 - INFO: buffer.Length=29 04.02.2019 15:00:02.401 - INFO: 0f 40 00 00 00 00 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 f9 02 02 0f 00 16 1b 04.02.2019 15:00:02.403 - INFO: buffer.Length=23 04.02.2019 15:00:02.405 - INFO: 01 01 02 03 09 06 01 00 01 07 00 ff 06 00 00 06 f9 02 02 0f 00 16 1b 04.02.2019 15:00:02.407 - INFO: Creating CosemArray with 1 elements 04.02.2019 15:00:02.409 - INFO: Creating CosemStructure with 3 elements 04.02.2019 15:00:02.411 - INFO: Created CosemOctetString with Value=01 00 01 07 00 ff 04.02.2019 15:00:02.415 - INFO: Created CosemDoubleLongUnsigned with Value=1785 04.02.2019 15:00:02.417 - INFO: Creating CosemStructure with 2 elements 04.02.2019 15:00:02.419 - INFO: Created CosemInteger8 with Value=0 04.02.2019 15:00:02.422 - INFO: Created CosemEnum with Value=Watt 04.02.2019 15:00:02.425 - INFO: Created CosemStructure with 2 elements 04.02.2019 15:00:02.426 - INFO: Created CosemStructure with 3 elements 04.02.2019 15:00:02.429 - INFO: Created CosemArray with 1 elements