Bjørn Mork

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.

D-Link er kjipe med modellbetegnelser, men jeg tror det bare var de Marvell-baserte som kom med slike SFP+RJ45 porter. Ref https://svanheule.net/switches/dgs-1210_series Du kan nok spare et par watt ved å bytte den ut med noe nyere 🙂 Men jeg tviler på at den switchen er spesielt kranglete mht hva slags SFP du bruker. Så du kan mest sannsynlig bare bruke SFPen fra VMG hvis du vil. Altså null utstyrsbehov for egen ruter, så lenge du ikke har for få porter da

Ja, jeg har antatt at det ville funke, men aldri hatt anledning til å teste det i praksis. Godt å ha det bekreftet. Egen SIP-løsning håper jeg de har lagt inn tilstrekkelig med hindringer mot. Vil jo helst ikke ha de kontene på avveie...

Interessant. Jeg kjører Viken/Altibox via egen ruter og har gjort det i mange år, men prøver å holde dekoderen (også Q22) så isolert som mulig på sitt eget VLAN. I gamle dager satte jeg den bare rett på VLAN 101 fra Altibox. Men etter en omlegging for noen år siden måtte jeg flytte den til et separat VLAN og rute mellom disse. Jeg rutet da både multicast og unicast mellom dekoder og VLAN 101. Fremdeles med dekoderen helt isolert fra VLAN 102 (Internett). Det så for meg ut til at Altibox rutet alt som dekoderen trengte fra Internett på VLAN 101 også. Som jo ga mening for deres egen "bridge mode" tjeneste. Dette oppsettet hadde virket et par år når Viaplay strømme-appen brått å funke for noen uker side. Hos meg virket fortsatt NRK. Jeg snoopet litt på trafikken og konstaterte at Viaplay-appen forsøkte å nå noen CDN-adresser uten å få svar på VLAN 101. Aner ikke om det skyldes at tjenesten har byttet adresser, eller tilfeldigvis endte opp på en del av CDNet som Altibox hadde glemt å rute, eller om Altibox hadde endret noe. Uansett, konksekvensen var ihvertfall den samme: For å få både live-TV (vet ikke helt hvorfor jeg bryr meg...) og alle strømme-appene til å virke, så må jeg nå rute multicast via VLAN 101 og det meste annet via VLAN 102. Med unntak av de spesifikke rutene som DHCP-serveren til Altibox på VLAN 101 gir meg. Jeg antar at de går til interne TV-tjenester, og at det derfor er lurest å rute de på TV-VLANet. Men opplegget har altså stadig blitt mer herkete, og unødvendig herkete IMHO. Jeg antar det er en (muligens ubevisst) gradvis nedprioritering av de gamle dekoderene, til fordel for den nye som "bare trenger Internett". Jaja, lang historie. Herk eller ikke, jeg tror løsningen på problemet ditt er egen ruter. Du slipper ikke unna å ha en annen ruter enn Altibox sin mellom dekoderen fiberene dersom du skal få "blandet sammen VLAnene", og da kan du jo like gjerne droppe Altibox sin. Så vidt jeg kan forstå så ahr du allerede det meste (all?) hardwaren du trenger. Ser du skriver "10p" på switchen. Det er ikke tilfeldigvis en 8 RJ45 + 2 SFP? I så fall så kunne du jo ta SFPen fra VMGen og sette inn der, og så trunke VLAN 101 og 102 derfra til pFSense ruteren din. Da ville den sikkert kunne tatt seg av all magien både som TV og Internet ruter. Med forbehold om at jeg ikke har filla peiling på pfSense

Ingen erfaringer å komme med, dessverre. Men takk for pekeren til et svært interessant produkt. Ser jo akkurat ut som det jeg ønsket meg i fjor. Bare synd at fyring med strøm er så "last year" at det ikke gir noen mening å bytte ut panelovner med nye... Regner med at det bør være kakestykke å få styrt disse ovnene fra det meste av åpne Zigbee gateways. Men jeg fant dem ikke hos f.eks. zigbee2mqtt, så det kan godt tenkes at støtten ikke er på plass ennå. I så fall må du enten legge til den støtten selv eller vente på at noen andre gjør det. Nå burde det være en ganske grei sak. Ser at ovnene kommer med komplett Zigbee interface-dokumentasjon: https://www.elektroimportoren.no/docs/lib/5401395-Manual-18.pdf Blir ikke bedre enn det. Ellers noterer jeg meg følgende i den ordinære brukerveiledningen: Og med et greit direkte brukergrensesnitt med display og knapper på ovnen, så ser det nesten ut til at noen har hatt min ønskeliste for panelovner i bakhodet når de designet denne 🙂 EDIT: Om noen skulle ha lyst til å legge til ovnene i zigbee2mqtt så ser jeg at Namron har beholdt sånn ca kompatibilitet med termostatene sine. Mange (alle?) vendor-spesifikke properties under termostat-clusteret er de samme. Så du kan mer eller mindre bare bruke denne converteren direkte: https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/converters/fromZigbee.js#L1716 Og ellers er jo det meste standard-properties

Det støtter selvsagt esphome Joda, men det er vel ikke mange dingser som har det?

Det argumentet kjøper jeg. Selv om jeg tror bruksområdet på en slik ferdig-dings uten sensorer og RTC er nokså begrenset. Men kaffetrakter-timer er jo en mulighet.

Her føler jeg et behov for litt voksen-opplæring. Som uerfaren med begge så må jeg innrømme at valget var nokså tilfeldig for min del. Tasmota har såpass lang historie at den var det første som dukket opp i bakhodet. Og det virker jo helt greit. Web-UIet suger selvsagt, men det er uansett ikke noe jeg kommer til å bruke etter førstegangs konfigurasjon. Men kommentaren din fikk meg til å lure - hva går jeg glipp av med Tasmota? Jeg kommer nok også til å legge til denne i Home Assistant, selv om jeg ikke er helt sikker på om jeg egentlig kommer til å automatisere noe rundt den. Mitt primære bruksområde, foreløpig ihvertfall, er bare fjernstyring. Og da er det enklere å poste en kommando via MQTT direkte. Uansett, du fikk meg til å Google og jeg fant bla https://community.home-assistant.io/t/goodbye-tasmota/436293/64 Men jeg ble jo ikke noe klokere av det. Tvert imot faktisk. Kom ikke så langt før jeg så og det gir jo bare ingen som helst mening. En av de tingene jeg virkelig liker er å ah MQTT som et lag mellom HA og whatever. Det isolerer HA som frontend fullstendig fra hardware, slik at jeg - i teorien ihverfall - enkelt kan bytte ut HA om jeg skulle føle for det. Men enda viktigere er at jeg slipper å gå gjennom HA når jeg ikke vil/føler behov. Jeg kan feede sensor-data til en remote broker via en MQTT bridge, og mate det inn i influx der uten at HA er involvert i det hele tatt. Samtidig som HA også sitter med de samme sensorene og kan gjøre sine ting med dataene. Og jeg kan lett scripte ting både mot Zigbee-brytere og denne Tasmota-dingsen, uten at jeg trenger å forholde meg til noe annet enn MQTT. Det nevnes også https og kryptering som feaures med esphome, og den nytteverdien kan jeg se. Det spiller bare ikke noen rolle i mitt nettverk (isolert IOT-nett med lokal MQTT-broler), og da vil jeg uasnett ikke ofre ESP-ressursene på slikt. Så hvorfor esphome? Enklere å bygge egen firmware? Sikkert. Ser ikke helt behovet akkurat nå. Kanskje hvis strømskinna faktisk har en ads1115. Ellers ga Tasmota meg fjernstyring og status for de 4 reléene via MQTT, samt lokal kontroll med hver utgang vha den ene knappen skinna har. Mulig jeg er en enkel sjel, men det er alt jeg har fantasi til å ønske meg