Vinnerliste

Da er det tydelig vis flere som har tenkt på det samme og har valgt å bruke samme felle som utgangspunkt. Ser helt klart fordel av å bruke lora men har ikke erfaring med å bygge eller implementere lora. Jeg vet om bare en "ferdig" chip for lora som kan kjøre arduino kode direkte men den koster over 10 usd + frakt pr stk så da blir det dyrere en esp8266 og wifi løsning, men går da på bekostning av dårligere rekkevidde på wifi. Jeg har lenge lekt med tanken om å lage en musefelle med wifi. Jeg begynte selv å eksperimentere med Arduino og ESP8266 i 2020 og har bygd noen smartløsninger basert på denne brikken. Har brukt nodemcu protoboard i testfaser men har valgt å lage egne kretskort til mine prosjekt. Mitt første test med musefelle så var en av utfordringene strømforbruk, noe som er spesielt viktig når ting skal kjøres på batteri. Eksperimenterte litt med deepsleep, den bruker 20uA når den sover men maks sleep tid er 71 minutter ved bruk av intern klokke og den bruker mye mer hver gang den våkner ca en gang i timen så strømforbruket var fortsatt høyt for å kjøre på batteri. Jeg har valgt en løsning hvor esp8266 er i dvale helt til fellen blir utløst og esp8266 blir vekket, under dvale er strømforbruket bare 3uA og den kan kjøre i flere måneder på et lite batteri. Når fellen blir utløst så måler den batterispenningen og sender melding til meg på Whatsapp med navn på fellen, spenning på batteriet og status på mikrobryteren før den går i deepsleep i 60 minutter før den våkner igjen og sender ny melding med status. Jeg kan også om ønskelig få den til å gå i deepsleep uten å våkne igjen om jeg ønsker det. Jeg ønsket å bruke en felle som var lett tilgjengelig på markedet og som det var mulig å skjule elektronikk og batteri i selve fellen. Av de fellene jeg kom over var den som Jula selger en jeg så kunne passe og kostet bare 49,- for 2 stk. Litt spesielt å bestille batteri etter plassen som var under fellen, men jeg ønsket å modifiser fellen minst mulig og samtidig ha størst mulig batteri. Jeg var også inne på tanken å lage kretskortet slik at det også kunne fungere som lokk men lot vær å gjøre det da det var plass nok til å kunne designe et kort som fikk plass i sporet under fellen.

Samme her. Kjører 4.2.7.0 som service på Windows Server 2019 Standard. Fungerer stabilt. Eneste problemet er at Deconz fremdeles trenger auto-logon og auto-start.

Jeg har testet, eller rettere sagt jeg kjører på 4.2.7.0 som service under win 10. Fungerer utmerket.

Ja, jeg har bare tenkt på det i 3 år... Jeg får vel sette meg ned å gjøre det.

Ny her på forumet, installerte Home Assistant litt før jul for å leke litt og kom over denne tråden mtp vannmåleren. Leste LarsH sitt innlegg om å bruke en SDR dongle istedenfor de dyre W-Mbus donglene (som ikke er å få tak i uansett), og det hadde eg jo liggende i hylla... Som sagt så gjort, fyrte opp en VM med Ubuntu og installerte rtl-sdr og wmbusmeters for å teste, fikk etter litt fram og tilbake kontakt med måleren og sendte epost til kommunen i romjula for å få tak i .kem fila (har en Kamstrup FlowIQ 2200). 3 timer(!) senere fikk eg svar vedlagt .kem fil og passord, dekrypterte og fikk jaggu lesbare verdier ut fra måleren og! Fått verdiene inn i HA via MQTT og utlity meter, må tweake og tune litt men det var mye lettere enn eg hadde sett for meg etter at eg hadde googlet litt om emnet tidligere...

Her tror jeg du har misforstått. Måleverdien leveres som en float. Det opp til presentasjonen å velge hvor mange desimaler som vises. Dokumentasjonen for spenning sier "0,5 second RMS voltage L1, with resolution of 0.1 V, Format 3.1". Oppløsningen er 1 desimal, men nøyalktigheten er ikke spesifisert. Tre desimaler er bare tull. Spenning kan man presentere uten desimaler.

Jeg har endret min egen konfigurasjon også. Det var ingen gode grunner for å bruke sensor.avg_electricity_price i det konkrete tilfellet.

rnbWeather (gratis) har fungerende YR integrasjon. Som dere ser har den vært stabil den siste måneden (siden sist serveren ble restartet)

Kjører kombo med UI fra både NodeRed og HomeSeer/HSTouch. Foreløpig ser jeg ikke helt at det ene kan erstatte det andre men i NodeRed har jeg i alle fall en mengde muligheter jeg ikke finner i HSTouch (samtidig som HSTouch gir meg en del friheter jeg ikke har i NR):

Jeg vil påstå at Home Assistant trenger ingenting. Det er dine ønsker om å automatisere som trenger det. Regler for hvordan ting skal slås av og på må settes opp i alle system. Hvis en holder seg til det enkle så er det ikke veldig vanskelig i Home Assistant og ikke noe jeg vil kalle "programmering"

jeg oppgraderte til hs4 til slutt på HomeTroller SEL (Ubuntu), det gikk veldig fint. Homesseer har en bra oppgraderingsløsning. Eneste jeg fikk litt problem med var noen eventer som mista en innledende IF, så oppretta de på nytt. Pluss at Mono i Ubuntu måtte oppgraderes, men de hadde de som en del av oppgraderingsløsningen.

Det er jo en viss framgang her, men ikke helt i boks ennå: https://github.com/Koenkk/zigbee2mqtt/issues/7975

Man betaler for fjerntilgang, ala VPN, så gir mening at det er slik. Overskuddet går direkte til å lønne de få utviklerne som er ansatt på heltit for å jobbe med HA, så det gjør det hele mer spiselig ift. å sponse aksjonærene i andre store selskap

Jeg lagde en enkel binærsensor basert på nordpool integrasjonen som er on i de x antall billigste timene og er off i de resterende timene, eller når prisen er høyere enn en maksimalgrense. https://gist.github.com/jorgror/8e9fb54d7236bdba131931eabd90961b

Den store har jeg endret så mye på nå, at den skiller ikke lengre på i dag og i morgen - den viser nå 3 timer bakover og inntil 18 timer fremover…

Har endelig somlet meg til å få bekreftet denne teorien. Eksempel på måling mottatt fra naboens måler av rtl_433 (med options "-f 868950000 -s 1200000 -M level"): { "time": "2021-11-18 17:18:55", "model": "Wireless-MBus", "mode": "C", "M": "KAM", "id": 76845462, "version": 27, "type": 22, "type_string": "Cold Water", "C": 68, "data_length": 41, "data": "2a442d2c625484761b168d2a0114b76522cbaa96817c787f3183f757807e0a2fecf5a6ac0c35e3cd19d027", "mic": "CRC", "mod": "FSK", "freq1": 868.93299, "freq2": 868.95712, "rssi": -1.52101, "snr": 12.20334, "noise": -13.7244 } Nettien poster da dette til https://agent.dd.onsmartliv.no/api/agent: Host: agent.dd.onsmartliv.no User-Agent: DeviceDrive/WRF01/5.0 Content-Type: application/json; charset=utf-8 Accept: application/json DeviceDrive-Header: {"mac":"2cf43248d7a5","firmware":"5.0","hardware":"WRF01","token":"c7fc5808155cc8d9649b042a1619858b","product_key":"1ad22182-ca0c-4087-b79b-9b7971bbc95c","version":"2.3","transfer_type":"data"} Content-Length: 411 { "smartliv.netti.system": { "alive": 423653, "batt_status": "USB", "batt_v": 3.3, "conf_water_meter": "", "hw": "1.3", "sn": "191010832", "t": 1637252085, "usb": 1, "wifi_rssi": -70 }, "smartliv.netti.water": { "raw_water_msg": "543D2C442D2C625484761B168D200114B76522CBAA96817C787F3183F757807E0A2FECF5A6AC0C35E3CD19D02786B9", "water_rssi": -86, "water_sn": "76845462", "water_status": 183, "water_t": 1637252085 } } og får innimellom en imponerende mengde 500,502 og 503 en slik ack tilbake: Cache-Control: no-cache Pragma: no-cache Content-Length: 24 Content-Type: application/json; charset=utf-8 Expires: -1 Request-Context: appId=cid-v1:283644af-6b78-4018-bd1f-5a8797ddc96b Access-Control-Expose-Headers: Request-Context Set-Cookie: ARRAffinity=3e6f5debd8a2718fff20e474e8397f908da7dc3bb3105a4dd67e2d68ff65108e;Path=/;HttpOnly;Secure;Domain=agent.dd.onsmartliv.no Set-Cookie: ARRAffinitySameSite=3e6f5debd8a2718fff20e474e8397f908da7dc3bb3105a4dd67e2d68ff65108e;Path=/;HttpOnly;SameSite=None;Secure;Domain=agent.dd.onsmartliv.no Date: Thu, 18 Nov 2021 16:21:25 GMT { "timestamp": 1637252447 } Nettiens "raw_water_msg" er nesten en tro kopi av "data" fra rtl_433. Nettien legger til 4 siffer først og sist (sjekksum+?), og lengde-byten (byte 0 fra rtl_433 eller byte 2 fra Netti) er økt med 2. Kompensasjon for de to bytene på slutten? I tillegg er to bits inne i meldingen flippet: 8d2a har blitt til 8d20. Veldig pussig. Men det er uansett i headeren før den krypterte payloaden, så det ødelegger jo ikke noe. wmbusmeters dekoder denne meldingen slik: (simulation) from file "2a442d2c625484761b168d2a0114b76522cbaa96817c787f3183f757807e0a2fecf5a6ac0c35e3cd19d027" (wmbus) ff a dll crc first (calculated ccd8) did not match (expected 8d2a) for bytes 0-10! (wmbus) parseDLL @0 43 (telegram) DLL L=2a C=44 (from meter SND_NR) M=2c2d (KAM) A=76845462 VER=1b TYPE=16 (Cold water meter) (driver multical21) DEV= RSSI=0 (wmbus) parseELL @10 33 (telegram) ELL CI=8d CC=2a (slow_resp sync prio) ACC=01 SN=14b76522 (AES_CTR session=4 time=2513777) CRC=cbaa Received telegram from: 76845462 manufacturer: (KAM) Kamstrup Energi (0x2c2d) type: Cold water meter (0x16) ver: 0x1b driver: multical21 (wmbus) 00: 2a length (42 bytes) (wmbus) 01: 44 dll-c (from meter SND_NR) (wmbus) 02: 2d2c dll-mfct (KAM) (wmbus) 04: 62548476 dll-id (76845462) (wmbus) 08: 1b dll-version (wmbus) 09: 16 dll-type (Cold water meter) (wmbus) 0a: 8d ell-ci-field (ELL: Extended Link Layer II (8 Byte)) (wmbus) 0b: 2a ell-cc (slow_resp sync prio) (wmbus) 0c: 01 ell-acc (wmbus) 0d: 14b76522 sn (AES_CTR) (wmbus) 11: cbaa payload crc (calculated e70b ERROR) telegram=||2A442D2C625484761B168D2A0114B76522CBAA96817C787F3183F757807E0A2FECF5A6AC0C35E3CD19D027|+0 (serial) stopping manager Har dessverre ikke klart å få ut nøkkelen fra hverken Asker kommune eller Smartliv (som mest sannsynlig heller ikke har den). Så det der er vel omtrent så langt jeg kommer. Når det gjellder "Netti" hardwaren så er det sikkert noen her som er interessert i å vite at den oppgir hostnavnet "ESP-48D7A5" og at mac-adressen i DeviceDrive-Header er korrekt. DeviceDrive ser ut til å være et firma som driver omtrent som Tuya - selger halvferdig dingsedesign sammen med en app-/sky-løsning. Mer info på https://devicedrive.com/download/wrf01-hardware-specification/

Ingen grunn til å dra på hytta for å tømme feller ennå. Av 7 feller er bare en opptatt. Og jeg kan lese av vannmåler og sjekke om det er alarm på bæsjpumpa. 30ggr zoom + pan og tilt er ikke ille.