Steve0

Gjorde det! Har nå kjørt stabilt med Aidon måler i Home Assistant (zwave2mqtt) i over et halvt år. Så kult at jeg fanget interessen Er bortreist til 7. januar, men kan se om jeg har noe deler / pcb’er til deg etter at jeg er tilbake? Send gjerne pm om det er av interesse.

Da hadde folk bare tatt ut batteriene for å unngå at forbruket blir målt

Det finnes vel strengt tatt et argument for at GDPR kommer i spillet. Dette skyldes da at vannmålerens nøkkel ikke kan byttes ut når du flytter ut - og i motsetning til strømmåleren må man ikke ha fysisk tilgang for å hente ut data. Dvs. når du selger huset, og har fått krypteringsnøkkelen til vannmåleren, kan du lese av vannforbruket til den nye eieren. Personlig synes jeg at det er veldig tynt grunnlag for å nekte deg tilgang, men når man har med en offentlig etat å gjøre er det vel fort ingenting man får endret i rutinene dems.

Vent i en uke til Siste versjon av zwave-js er ikke kompatibel med logikken inne i forrige versjoner av HA, så *akkurat nå* er det litt rar tilstand. 2021.3 er i pre-release siden i går, kommer til å bli sluppet på onsdag neste uke.

Gjør ikke det heller. HA kjører websocket mot zwavejs2mqtt. Men fordi jeg måtte velge en eller annen docker uansett, valgte jeg som @Offpisteden som har et kult kontrollgrensesnitt så lenge HA-addon ikke presenterer noe lignende.

Jepp. Jeg kjører ‘alt’ av brologikk på en raspberry pi, mens min Home Assistant instans kjører på en annen fysisk maskin (esxi server).

Visst. Men det er ikke så enkelt om man bare laster inn zwavejs2mqtt Docker'n. Må sikkert grave litt mer og bli kjent med hvordan npm/yarn fungerer for å få det til selv. Har dog troa på utviklerne gitt hastigheten de jobber med nå: https://github.com/zwave-js/node-zwave-js/pulls

Jeg byttet i helgen Z-Wave backend for andre gang ila en måned. Var så uheldig å ha gått over til OZW 1.6 i romjula... Må dog sies, Zwave-JS er allerede i mye bedre tilstand enn OZW 1.6 (beta) noen gang har vaert. Bortsett fra device-databasen, men den saken jobbes med synlig på Github.

@babjerke jeg henger meg på det som ble sagt. Opamp-kretsen i mitt design (og sikkert de andre også) fungerer like bra som den spesialiserte transceiveren til en brøkdel av prisen og areal.

Og v2 mockup print idag 🥳

Mens jeg fortsatt venter på nye PCB'er, har jeg gjort litt varmluft rework på en av de mislykka kortene... Og nå funker den! Har også prøvd meg på 3D-design og printing. Må finne en god måte å printe en lokk på, men dette kommer i boks altså. Kjører med 30sek rapport-interval, og det er på ingen måte problematisk i Z-Wave nettet mitt med ~20 noder. Må kun få meg en liten pigtail antennekabel for å kunne plassere antennen på utsiden av det metalliske målerskapet 😅

Da var den store dagen kommet. Koblet den opp mot HAN-porten, og... Ingenting. Naermere inspeksjon avslørte at det var en loddefeil i DCDC'en som hadde utsatt Z-Wave modulen for 24V, sa den er nok død... Men, jeg hadde et kort til uten modul på (eller, rettere sagt: ett der jeg mislykket med å lodde den på), til testing. Og den fungerer ganske greit, koblet opp mot devkit! Her kom data direkte inn i Home Assistant via Z-Wave: Testkortet tar seg av strømforsyning til levelkonverterne og konversjon av HAN til TTL, samt fungerer som brukerinterface til Z-Wave (gule lyset blinker for hver 'list 2' pakke, og mens inclusion/exclusion pågår, og knappen brukes til inclusion/exclusion/sende NIF/factory reset). Så resultatet av søndagen er at jeg bestiller opp litt flere deler, og tar en runde til for å komme til sluttmålet av selvforsynt HAN adapter 🎉

Fikk alt jeg trengte inn i går, så jeg måtte bare sette i gang loddingen... Funker fjell i test, her med utviklingsverktøyet 'PC Controller'. Litt synd at det er ca 10 minusgrader ute (og måleren min står selvfølgelig ute...) så jeg er ikke akkurat veldig fristet til å stå ute å debugge med denne her. Får bli til helga. Energiforbruket på 3V3 av hele oppsettet ligger rett under 45mW, så det er masse margin selv for Kamstrup.

Da fikk jeg startet prosjektet på Github, og PCB-ene (med stencil...) og kompenentene er underveis. Dette blir spennende! https://github.com/stevew817/AMS2ZWAVE

Gjenstår å se hva som teller som 'effekttopp' i måleren. Om effekttariffen blir avregnet på punktlast i sekundet blir det jo nesten umulig å få feedback-loopen raskt nok til å unngå toppene basert på HAN data. Dersom den derimot blir beregnet etter et større gjennomsnittsvindu finnes det kanskje muligheter... Om man virkelig vil skal det jo være mulig å rapportere like raskt som måleren i et Z-Wave nett... Men da må man kunne tåle litt forsinkelse i andre operasjoner på nettet Båndbredden i Z-Wave er på 100kbit/s s lenge man ikke har noen elgamle noder, og en kjapp målerpakke med effektrapport ligger på 10 bytes (som så riktignok skal encapsuleres i MAC/PHY), men et konservativ anslag er da at man kan få ca. 500 pakker gjennom luften i sekundet. En sånn pakke skal bekreftes, så da blir det 250. Og om nettverket ditt trenger flere 'hops' mellom måleren og hub'en, skal man dele 250 tilsvarende. Usannsynlig at det da i praksis blir noe stort problem, bortsett fra når man har veldig mange noder i nettet, eller har fryktelig mange hops (Eller driver å saturere nettet ellers ved å 'polle' andre noder med hub-logikk...)

Akkurat. Den eneste grunnen jeg kjenner til for å få såpass hyppige oppdateringer er når man skal drive med aktiv last-balansering. F.eks. redusere elbilladestrøm når panna slår seg på for å unngå at hovedsikringen ryker. Men det blir fort en komplisert ting å få til for en gjennomsnitts smarthus-entusiast, samt at de fleste elbilladere jeg kjenner til som støtter ekstern signal for å redusere ladestrømmen har sine egne løsninger for dette. Og på toppen av det hele, tåler hovedsikringen (og sløyfesikringene) jo en kortvarig overbelastning. Tar man utgangspunkt i en B-kurve, så kan den overbelastes med 1.5 ganger nominell strøm i 3-5 minutter før den slår ut. Så selv da holder det så absolutt med oppdateringer i minutt eller 2 minutters oppløsning.

Da har jeg lært meg KiCAD i samme sleng... Jeg kan egentlig Eagle fra før (er en del år siden, gitt), men de har tydeligvis gått over til betalende lisenser siden Autodesk-oppkjøpet. Anyway, PCB'en er designet og jeg satser på å sette den i bestilling ila morgendagen. De feirer vel ikke jul i Kina, så tipper jeg får dem levert rett over nyåret Har prøvd meg på å legge til en 'billigere' variant av HAN-signal-konvertering. Siden 3V3 uansett trenges til SoC'en, og HAN signalene er 24V i idle og spenningen faller når data kommer på bus, burde det gå an å bare ha en opamp-comparator med spenningsdeler og fast referansepunkt. Når jeg setter en deler på 1/12, og legger referansepunktet på 1.7V, så burde den detektere alt der bus'en er idle i 21V~36V området, og bitsene sendes i 10V~19V området. Siden referansen er en vanlig spenningsdeler, er det lett gjort å endre på den om det trenges. Og for å unngå at jeg må kaste PCB'ene i tilfellet det ikke skulle funke, har jeg tatt med den kjente transceiveren også. Velger input til SoC'en med en enkel loddebro

Only one way to find out :) Det blir jo definitivt konfigurerbart rapport-interval, for folk har forskjellige forventninger om hvor kjappe oppdateringer man skal få. Ikke alle målere klarer å levere hvert 2.5s heller (Kamstrup rapporterer hvert 10.). Jeg personlig kunne godt levd med å få minutt-oppløsning istedenfor 24 oppdateringer i minuttet. Og jeg kan godt tenke meg at det er noen som ikke nødvendigvis trenger å spore effekt, men bare logger utviklingen i total levert energi, som uansett ikke oppdateres fra måleren oftere enn 1 gang i timen...

Til de som skulle fortsatt fulgt med dette topic her, så har jeg tatt opp prosjektet igjen. Fikk plutselig masse ledig tid i juleferien Utgangspunktet mitt er at jeg lager en adapter som 'snakker' Z-Wave. Måleren min henger utenfor huset, fritt tilgjengelig, og fra et sikkerhetsperspektiv liker jeg ikke særlig å ha dingser hengende ute som inneholder adgangskoder til mitt wifi-nett. Jeg har en del Z-Wave i huset fra før av, dermed prøver jeg meg på det istedenfor å skaffe enda et nettverk (Zigbee) og kjøpe Develco sin dongle (dog, det hadde sikkert spart en del tid det). En annen fordel med Z-Wave er at den bruker såpass lite strøm, at selv Kamstrup-målere burde være fornøyde med mating over m-bus, og det helt uten bufferkondensator. Jeg har målt maks strømtrekk til ca 14mA på 3V3, som er 46mW. Kontinuerlig/gjennomsnitt ligger på ca. 10mA. Kamstrup sin grense ligger på 6mA * 24V = 144mW. Så det er fortsatt veldig mye å gå på, såfremt spenningen forsynes av en DCDC og ikke bare LDO'es ned. Status etter snaue to dager er at jeg har Z-Wave biten fungerende, samt en ren C parser som klarer å hente ut måleverdier fra data som jeg mater inn manuelt over seriellporten (tatt fra litt diverse kilder rundomkring). Det er så langt jeg kommer i prototypingen uten å starte å snekre sammen litt hardware. Tenkte å sette i gang med det snart og ta utgangspunkt i designet som tidligere ble lagt ut her. Unless you still have a spare PCB somewhere for me to prototype on, @spenceme?

@bompi75 Kanskje litt sen svar (har du funnet ut av dette allerede?), men har du sjekket om XML-fila inneholder en tag `<CipherValue>`? kem-import.py støtter kun krypterte .kem-filer, så om din er ikke kryptert kan det hende du må dra ut nøkkelen for hånd. Kan du evt. legge inn en sladret kopi av .kem-filen din?

Husker jeg hadde veldig mye krøll med å få disse inn i HA på en skikkelig måte, for de ble tilsynelatende sett på som alltid-på devicer istedenfor sovende devicer. Det førte til at nettverket ble ustabil hver gang den restartet (OZW prøver å få kontakt med alle devicer når nettet startes). Når jeg etterhvert fikk OZW til å skjønne at disse switchene faktisk sover, var alle problemene borte. Litt for lenge siden til å huske alle detaljene, med skal forsøke å finne fram min XML fil til deg.

Har OZW fått med seg at bryteren er en sovende node? Sjekk zwcfg_*.xml fila... Detter er min 4-veis bryter (8 knapper): <Node id="14" name="" location="" basic="4" generic="24" specific="1" roletype="4" devicetype="5632" nodetype="0" type="Basic Wall Controller" listening="false" frequentListening="false" beaming="true" routing="true" max_baud_rate="40000" version="4" query_stage="Complete"> både 'listening' og 'frequentlistening' bør være satt til false.

Problemet med Namron-bryteren, som jeg også sa etter å ha lagt den til, er at 4-veis bryteren rapporterer en 'manufacturer ID' som nåværende versjon av OpenZWave ikke kjenner til. Namron har tydeligvis fått sin egen ID, der de andre produktene de selger bruker Sunricher sin ID. Dette ser ut til å få konsekvens at OpenZWave tror at bryteren er en always-on node, istedenfor sleeping node som den faktisk er. Jeg måtte krangle med hass.io og Z-Wave opplegget mitt i helgen også, etter at halvparten av nodene ble utilgjengelige etter oppdatering fra 0.103 til 0.106. Det som funket til slutt var en kombinasjon av mye omstart, banning, lese logfil, legge til Namron sin manufacturer ID i en lokal versjon av OpenZWave device database, og manuell editering av zwcfg fila og diverse HA config. Det gikk ca 6 timer der...

Har jeg gått glipp av noe? Dokumentasjonen dems tilsier vel max 6mA / 4 slave units?

Litt enig i @tronde sin kommentar. Mistenker også at dette designet ikke oppfører seg ihht M-Bus standarden, dersom helheten ikke oppfører seg som konstant strømlast? Sitter selv og tenker på hvordan dette kan forbedres. Kanskje legge til en 'current sink' med målemotstand som måler strømbruk direkte fra M-Bus, og en mosfet/transistor for å bruke forskjellen mellom DCDC-ens strømtrekk og en konstant 6mA last?