Bjørn Mork

Hmm, ser at tråden også viser til DCS-8000LH oppskriften min 🙂 Men som forventet var ikke den noen suksess med dette kameraet. Egentlig ikke så rart. Hvis DCS‑830xLH allerede har rtsp enablet så er jo problemstillengen en helt annen. Det er heller ikke å forvente at blåtann-hacket funker med nyere firmware. D-Link var rimelig kjappe med å stenge akkurat det hullet. Det er enn nok andre hull å ta av, men jeg går fort lei av whack-a-mole.

vnc er jo så mangt... Har ikke noe erfaring med rpi-os, men i følge google så er det realvnc de leverer. Den skal visstnok støtte xrandr. Tips her: https://stackoverflow.com/questions/15816/changing-the-resolution-of-a-vnc-session-in-linux "--scale-from " kan også være ganske nyttig med xrandr for å slippe at desktopen må endre størrelse hver gang du endrer skjerm-størrelse. Det er mest det som er herkete, f.eks. ved at deler av desktopen havner utenfor skjermen.

Grensesnittet Telenor selger dem mot sluttbruker er 1000BaseTX-porten på ONT. Det er ikke noe teknisk problem å støtte en hvilken som helst hjemmeruter på innsiden av denne. Det er helt opp til Homenet. Se https://www.telenorwholesale.no/produkter/vula/ for detaljer

Er det ikke ocpp som er den hellige gral mht elbil-ladere? Lokal sådan, selvsagt. Jeg har registrert at noen produsenter forvirrer ved å markedføre en skybasert ocpp-løsning. Det ser jeg ikke noe poeng i.

Takk. Joda, jeg vet at det er andre måter å lese av måleren. men da blir det et prosjekt hvor jeg må beregne nytteverdien, og den er nok forsvinnende liten i mitt tilfelle. Trådløs avlesning vekket interessen fordi det bare var der uten noe behov for ekstra utstyr ved måleren.

sånn, eller en annen størrelse/utførelse? litt vanskelig å se ut fra bildet ditt https://www.ebay.com/itm/303491550670

Jeg sitter nok dessverre med en Axioma-måler, mens naboene stort sett ser ut til å ha Kamstrup. Takk uansett for bekreftelsen. Sikkert ikke. Men til deres forsvar så har de ihvertfall svart relativt kjapt og så godt de kunne. Og tydeligivs også korrekt. Dette høres interessant ut. All info mottas med takk. Hvis Freeze virker så er iaffal den nyttig. Ikke at jeg aner hvordan jeg evt skulle verifisere at den virker 😉

Trenger du det da? Filtrering vil jo ikke endre strukturen på noen måte. Får du ikke ut det du vil med noe ala u8x8.print(doc["ea"]["h"]["u"].as<float>() ,1); eller misforstår jeg hvor du vil? Evt med litt mer feilsjekk hvis vi du kræsje på forutsigbare måter selvsagt...

Antar du tenker på denne? https://prisguiden.no/produkt/develco-smart-io-module-542888 Den forsvant helt fra markedet for en stund siden, uten at jeg har funnet noen god erstatning noe sted.

Fromt ønske, men jeg har dessverre ikke en komplett oppskrift å gi bort. Jeg fikk aldri noen nøkkel til min måler, så jeg kom meg aldri videre fra eksperiment-stadiet. Uten noen dekrypterte måleverdier er det jo ingenting å dytte inn i HA. Men for å få det inn i HA så ville jeg ihvertfall gått via MQTT. Det er helt sikkert flere muligheter, og det er mulig jeg bare velger MQTT fordi jeg er vant med det, men jeg synes det gjør alt mye enklere med et slikt mellomlag der jeg kan fikle og debugge data i tekstformat. Så kan GUI-konvertering komme til slutt når jeg vet jeg får måleverdier som kan brukes. Den innebygde wmbus dekoderen i rtl_433 er et fint sted å starte for å verifisere at mottakeren klarer å fange opp noe som helst fra måleren. Selv om den antageligvis ikke holder når du skal begynne med dekryptering. Fra "rtl_433 -R help" finner du f.eks. [104] Wireless M-Bus, Mode C&T, 100kbps (-f 868950000 -s 1200000) Der det også er angitt abefalt frekvens og symbolrate ettersom det aviker fra default. F.eks noe ala rtl_433 -f 868950000 -s 1200000 -R 104 -F json -M level og det burde etterhvert dukke opp json-formatterte meldinger i "topic" med innhold ala det jeg postet her tidligere, der "data" fremdeles er kryptert: { "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 } Når du får det til å virke så langt så er det på tide å fikle med dekryptering. Da tror jeg det er https://github.com/weetmuts/wmbusmeters som gelder Du kan bruke "rtl433" som device, evt med flere parametre om nødvendig.Eller "rtlwmbus" hvis du heller vil det. Det er eksempler i README.md i wmbusmeters. Ellers har jo Google en del tips og triks å komme med som vanlig. Dette ser f.eks ut som et bra sted å starte: https://the78mole.de/wmbus-meters-and-how-to-get-it-into-home-assistant/ Det er i prinsippet "bare" å mate dekrypterte målinger som json fra wmbusmeters til mosquitto_pub. Når du først har dataene i et topic i MQTT så kan HA konfigureres med de MQTT sensorene du har lyst på. Jeg har ikke noe bedre forslag. Blir nok en del fikling. Men det er jo det som er gøy med slike prosjekter 😉

Høres ut som et bra nyttårsforsett

Nå fikk du meg nervøs nok til å lese manualen for fryseboksen vi har på hytta... Den sier Jeg velger å tolke "fungerer best" som at det er problemfritt med andre temperaturer, men muligens ikke optimalt.

Nå ble jeg jo veldig nysgjerring som vanlig. Er det en slik greie du har? https://rtv.sabaj.pl/en/advantages-of-an-active-rj-45-port-in-our-tv-lifts/ Ser i så fall ut som de strever hardt med å ikke dokumentere det grensesnittet for å få solgt tilleggsutstyr. Men ut fra bilder og beskrivelse så kan det se ut til å være 100% proprietert, der RJ46-pluggen bare er en praktisk måte å pakke 7 (eller 6 + Vcc?) IO-pinner. På bildet på https://sabajgroup.uk/products/hidden-ir-repeater-system/#gallery det se ut som "IR emitter" utgangen på repeateren er koblet til kun pinne 1 og 2. Men via en magisk boks så det er jo ikke godt å si hva slags signal som går der.

Serieport kanskje? Pinout kan i så fall være varierende

Er vel også en temperatursensor eller to her et sted?

Det står ingenting om wmbus-støtte der, og kan heller ikke se noen av de aktielle vannmålerene nevnt. Kan kanskje bli litt utviklingsjobb hvis wmbus-støtten ikke er der fra før? Også litt uklart om radioene du peker til faktisk støtter 860 - 870 MHz?

Burde det. Kvaliteten og presisjonen er nok som du kan forvente, men holder i lange baner for formålet. Den der ligner til forveksling på de to jeg har, uten at det trenger bety noe som helst

Jeg har brukt en helt ordinær RTL2838 dongle til å lytte på min (og naboenes 🙂 vannmålere. Dessverre er Asker mye vanskeligere av seg enn Lillestrøm mht nøkler, så prosjektet gikk ingen vei. Men mottak funket ihvertfall helt fint med den samme donglen som jeg nå bruker til diverse 433 MHz sensorer. Jeg tullet rundt med wmbusmeters og rtl-wmbus i starten. Men det er jo bare unødvendg kronglete. rtl_433 støtter også wmbus på 869 MHz til tross for navnet.

Ser ut som de kanskje har fjernet den? Utsolgt? Jeg finner den ihvertfall ikke hos OBS lenger. Men hvis det er en slik: https://www.power.no/smarte-hjem/smart-varmestyring-og-klima/luftkvalitets-maaler/qnect-smart-temperatursensor-zigbee-hvit/p-1149244/ så kjøpte jeg en på OBS i september (var alt de hadde igjen i den butikken jeg var i). Ikke store statistikk-grunnlaget men den har nå iaffal funket helt som forventet for meg siden da. Måtte ofre et nytt batteri siden det som fulgte med manglet polbeskyttelse, til tross for "forseglet" eske. Greit nok kjøp til en hundrings eller mindre. Ville ikke betalt tre hundre.... Dukker opp som en slik i zigbee2mqtt: https://www.zigbee2mqtt.io/devices/TT001ZAV20.html Som er det samme som f.eks https://www.kjell.com/no/produkter/smarte-hjem/smarte-sensorer/smarte-temperatursensor/nedis-smart-klimasensor-p51712

Slike? https://www.sectoralarm.no/boligalarm/magnetkontakt/ 868 MHz sier i så fall specen. Det er forsåvidt også mest sannsynlig selv om du har en annen modell. Tror man anser 433 MHz som litt for støy-preget for slike "proff"-løsninger Burde uansett la seg fange opp med rtl_433. Den støtter helt fint 868 MHz på tross av navnet.

Vil anbefale zigbee2mqtt i stedet hvis det er slik at du er vant til at Zigbee betyr trøbbel. Da tror jeg det må være noe galt med systemet ditt, uten at jeg skal påberope meg noen erfaring med hverken DeConz eller JowiHue. Men det er jo selvsagt ikke bare-bare å migrere heller...

Usikker på om jeg skal si noe om dette eller ikke, men.... Litt avhengig av hvor godt isolert det kaldloftet er, så er det mulig du skal levne en liten tanke til fuktsperra også. Sørg gjerne for at den er tett rundt kabelhullet. Ellers har du fort en liten muggfarm der. Ellers ville jeg også bare dratt kabelen gjennom et minst mulig hull i platene, og evt inn i et rør på den usynlige siden hvis ønskelig/nødvendig. Utførselsen er vel egentlig mest avhengig av kabelføringen videre på den sylige siden. Hvis du legger åpen kabel på vegg eller himling så vil jo ikke et hull i himlingsplata der dette ser mest naturlig ut være spesielt prangende. Forstår det slik at du uansett har behov for å føre kabler nedover, men har du vurdert å plassere AP for den øverste etasjen oppe på kaldloftet? Gjorde det på hytta og angrer ikke. Installasjonen blir ikke mer usynlig enn det. Og dekningsmessig så spiller det jo ikke noen som helst rolle med noen få cm glava og noen tynne plater mellom. Hadde uansett tenkt å trekke ethernet-kablene via kaldloftet. Droppet bare å trekke dem ned igjen der APene skulle være. Bruker PoE, så trenger ikke tenke på strøm-opplegg på loftet.

Etter at vi fikk VMG ville DHCP-serveren på VLAN 101 bare svare mac-adresser som lignet på VMGen sin. Trenger ikke være identisk, men OUI må være den samme tror jeg

På hytta bruker jeg en Pi4 med PoE hat og USB-pinne. Den har forsåvidt vært dønn stabil, men jeg er god på å kødde til ting selv. Gjerne mens jeg sitter hjemme... En stor fordel med PoE er at du kontrollerer av/på fra switchen som er PSE. Men siden RPien er router/server/altmulig på bytta så ble remote tilgang til switchen bak litt vanskelig hvis Pien først feilet. Løste dette med en cron-jobb på switchen: */5 * * * * ping -A -c 180 -i 1 -W 1 -w 0 192.168.99.3 >/dev/null || reboot der 192.168.99.3 er management-adressen på Pien og normalt nåbar fra switchen uansett nettverksstatus ellers. Brukte såpass lang timeout som 180 sekunder for at dette ikke skulle trigge ved normal boot av Pien. Denne switchen er såpass teit at den kutter PoE ut når den booter. Derfor virker "reboot" av switchen som "resett hele nettet, inkludert PoE aksesspunkter og Pi" Nå passer neppe denne løsningen overalt. Grunnen til at jeg kan kjøre en cron-jobb på switchen er at den kjører OpenWrt. Men tenkte jeg kunne nevne muligheten. Hovedpoenget er PoE som fjernstyringsmekanisme for Pi, i tilleg til å være en kraftig og stabil strømforsyning

Doh! Leseferdighetene er skrale for tiden. Nå er jo ikke en slik SFP store utgiften uansett, men da blir det litt mer pes ja.