OlavT

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

Er nesten i mål med rekursiv parsing av Cosem objektene, men sliter litt med å se hvordan 3. elementet i denne linjen skal tolkes (fra Aidon dok., eksempel på melding linje 7: 0203 0906 0100010700ff 06 00000552 0202 0f00 161b "0203" = Structure med 3 elementer 1. element: "0906" = Octet string lengde 6: "0100010700ff" = OBIS kode 2. element: "06" = Double long unsigned: "00000552" = verdien 3. element "0202" = Structure med 2 elementer? Men, skal det tolkes som "0f" = integer byte og "00" = verdien? og deretter "16" = enum og "1b" = verdien? I Aidon eksempelet er "0f00" og "161b" gruppert sammen. Det får meg til å tro at de ikke skal tolkes som "0f 00" og "16 1b", men på en annen måte. Noen som har knekt denne?

Har du noe Java kode å dele til inspirasjon? Jeg tror jeg har skjønt det meste av meldingene nå, men sliter litt med gode navn på de forskjellige delene. Har kalt hele meldingene som starter og slutter med 0x7e for HDLCFrame. Meldingen som trekkes ut fra HDLCFrame har jeg kalt AidonAPDU (ikke veldig bra navn). Deretter er jeg usikker på terminologien. For eksempel navn på meldingen som starter med 0109 og som innholder 9 meldinger der hver av de 9 meldingene igjen inneholder x elementer. Har du noen bra navn her?

Noen som har noe kode for å håndtere HDLC "bit-stuffing" av data, slik at data konverteres tilbake på rett måte?

Ser ikke noe kapittel 8.4 i den dokumentasjonen. Siste kapittel er 7 så vidt jeg kunne se.

Flott! Aner du hva linje 2 og 3 er?