quackyo

Ja, Mill gen 3 gjør dette. Det er strålende.

Mill gen3 er helt strålende til dette. Settes de opp med "local API only, NO CLOUD" kan ikke Mills crappy cloud-løsning ødelegge noe for deg og de er dønn stabile. (Jeg har mange, flere står også i hytter som jeg styrer via VPN..)

Vil bare igjen nevne at de mill-ovnene jeg har satt opp i ren local API mode (No cloud) fungerer prikkfritt fremdeles. Så det er ikke bare sorgen.

Ah, det er kjekt å vite.

Hei. Jeg har god erfaring med den "gamle" Namron Zigbee Touch termostaten. (den med lite touch-display og touch-knapper) Dønn stabil i 7-8 eksemplarer rundt forbi. (Både via ZHA og Zigbee2MQTT). Trenger nå muligens et par til fordelt på hus og ei familiehytte. Spørsmålet er om det er smart å gå for den nye med større touch-skjerm, eller om det er bedre å velge den jeg vet er 100% stabil. Link til den gamle: https://www.elektroimportoren.no/namron-zigbee-touch-termostat-16a-hvit/4512737/Product.html nye: https://www.elektroimportoren.no/namron-zigbee-touch-termostat-16a-hvit/4512752/Product.html Noen som har noe førstehåndserfaring med den nye?

Temp (og dermed muligheten for alarm) har redda våre matvarer flere ganger ihvertfall. Men det kan jo like godt løses med en aqara temp-sak til 100 kroner. (Jeg har det. batteri trengs å bytte ca 1 gang i året).

Absolutt. Mindre støy, MYE raskere, og ift en sikkert gammel snurredisk mye mindre sannsynlig at den ryker.

Thanx @servercookie .

Ikke forsøkt dette enda nei, får kjøre gjennom i kveld. Men da er det altså en kjent Firmware-feil? Merkelig at den dukket opp hos meg nå, hvis det er relatert til fw/migreringskrøllet.

Jeg har en Mill Gen 2 som plutselig forsvant for meg. Displayet viser "OF". Slår jeg av og på viser den innstilt temperatur i noen sekunder, så går den over til å vise "OF" og lar seg ikke hverken styre eksternt (hverken via Mill app eller HomeAssistant-integrasjon). Noen som vet om dette er defekt ovn eller om det er cloudgreiene som krøller? Den har virket fint helt fram til for et par dager siden, også etter "migreringskrisa". Ingen endringer i WIFI i huset, og jeg har flere andre gen2-ovner i huset som ikke har mistet forbindelse.

Det er ikke noe "triksing" - men ganske standard routing som skal til. Og eventuell brannmuråpning. Du må sørge for at du har har ruter begge veier. EKS: Hjemmenett 10.0.0.0/24 , Router: 10.0.0.1, VPN-server: 10.0.0.5 Hyttenett: 10.10.0.0/24 , Router : 10.10.0.1, VPN-server : 10.10.0.5 I Hjemmenett må du da ha rute til hyttenett for at 10.10.0.0/24 skal rutes via IP-adressen til VPN-serveren din for å fortelle at dette ikke er internett-trafikk. Dette settes ENTEN i rutingtabellen på hovedrouteren din ELLER på den spesifikke maskina du skal nå hyttenett fra. Routingtabell i hjemmenett skal da se noe alla slik ut: Defaultroute for "internett" 0.0.0.0 -> 10.0.0.1 VPNtrafikk 10.10.0.0/24 -> 10.10.0.5 Så er det viktig å gjøre omvendt på "hyttenett", hvis ikke vil du ha enveistrafikk. 🙂 Rutene kan eventuelt begrenses til å bare gjelde spesifikke IPadresser (10.x.y.z/32) om du kun vil route til/fra spesifikke bokser. Når dette er satt (riktig) skal det normalt sett funke. Men det må kanskje åpnes noe brannmur i tillegg på "VPNboks".

Helt korrekt. en VPN-forbindelse er en toveis forbindelse, så når RPi på hytta har koblet opp til VPN-server hjemme vil du fra hytta kunne nå "Hjemme", og omvendt fra hjemme også nå hytte-nett. Begge nettene vil også kunne nås fra andre steder du har VPN-forbindelse til HJEMME fra. F.eks fra en mobiltelefon. Da går du "via" hjemme for å nå hytta. Det er greit å "se for seg" om du tenker at en VPN-forbindelse bare er en jækla lang nettverkskabel. 🙂 Men for å sette dette opp korrekt kreves litt forståelse av IP, ruting og eventuelt brannmur.

Det er korrekt, det gjelder de fleste leverandørene for mobilt bredbånd - du får ikke "public" IP mot routeren din, og ligger dermed bak NAT/CGNAT-løsning til leverandøren. For Telia mener jeg APN for for å få public IP skal være "vpn.telia.no" . For Telenor var det ihvertfall i gamle dager "internet.public" . Setter du dette har du public IP på routeren din, tilsvarende det du har på vanlige hjemmebredbånd. OBS OBS, husk brannmur da, for nå er du plutselig ikke beskyttet av nettleverandør lengre. Du vil også nå i en eller annen grad kunne oppleve at bruteforceangrep osv bruker av mobilt bredbånd-kvoten din. Tipper det er marginalt, men et "hull" kan ha store konsekvenser. Det lureste er å kjøre VPN av noe slag, som initieres fra "innsiden".

Jeg opplevde også at et par ovner satt opp slik - med Cloud (i independent mode), men styrt via lokalt API tilsynelatende "Kranglet" mellom innstillingene. Der opplevdes det litt annerledes, en justering via lokalt api virket i et par sekunder før cloud justerte tilbake til "sin" innstilling. Enden på visa er at jeg har resatt alle til å være "no cloud, local api" only. Da fungerer de fint. Men ganske teit at dette ikke virker, for kombinasjonen kan jo være grei for endel. Konfigurte de forøvrig opp via "reset" og så opp med WIFI AP mode, altså ingen app i det hele tatt.. Gotcha er at jeg med en ny ovn ikke klarte å få til AP mode uten å først ha meldt den litt inn i cloud så den fikk ny firmware.

Skaff deg appen "Wifi Analyzer" eller tilsvarende på Android, og sjekk hvilke nett du faktisk har i lufta der du vil ha den, og hvilke frekvenser. 2,4GHz er det eneste som er interessant i dette tilfellet. Jeg har også opplevd at Arduinos er litt kilne på "roaming", de liker best å være tilkoblet det AP'et de opprinnelig koplet opp mot. Hvis du kan resette devicen og så ta førstegangsoppkoblingen i garasjen kan det være du får annerledes resultat.

ADAX-integrasjonen til Home Assistant sies å støtte local mode out of the box. (Det står noe om at det bare gjelder nyere ovner, hva enn det betyr.) https://www.home-assistant.io/integrations/adax/ Hvis ikke det er HA du bruker kanskje kanskje se i kildekoden til integrasjonen (link til "View sourcecode on github" i linken over) hvordan de gjør det?

Siden du nevner Nordan så vet du det kanskje allerede, men de har integrerte screens i selve vinduet/ramma, så slipper du å ha noe ettermontert på utsiden av vinduet/kledningen. Jeg har dette, med somfy IO styring. Det fungerer helt fint. Men det er jo proprietært og krever egen SOMFY-hub (Connexxon eller Tahoma mener jeg de heter) som snakker med screensene. Så er denne boksen integrert mot Home Assistant. I begynnelsen var det kun cloud-styring, men nå er det lokalt integrasjon rett mot Somfy-HUB'en.

Jepp. Når det gjelder "lite innstillinger" så tror jeg må være integrasjonen i Homey som velger å ikke eksponere alt, via Z2M har jeg mer enn nok ihvertfall 🙂

Namron sine zigbee dimmepiller har ihvertfall vært DØNN stabile for meg i 3-4 år nå. Har 12 stk i nettet mitt. Namron sine zigbee-thermostater har jeg +-10 av i div oppsett rundt forbi i andre hus og hytter, og også dønn stabile (Etter siste FW oppgraderingen, har du gammel FW må de oppgraderes for ikke å gå randomly i "borte-modus"). Namron sine zigbee vridimmere har jeg også et par av, jeg opplever de som litt "billige" og reagerer litt treigere enn jeg forventer. Men de er også stabile. Ingen spam på nettet fra noen av disse, det må være "gammel info" eller defekte greier. (Jeg er forøvrig ingen Namron fanboy, hadde 6 mnd helvete med Namron sine z-wave dimmepiller - de hang seg opp med ujevne mellomrom så de ikke virket med impulsbryter en gang....)

Har du åpna port (443/tcp) og forwardet de til HA-instansen din i routeren din da? Guiden her har jo så vidt jeg har skumlest hoppet glatt over det punktet.

Kjører flow'en din lampe av/på, eller dimmer den opp? Hvis sistnevnte kan det kanskje være at flow'en din starter lampen fra et lavere nivå enn Namrondimmer/lampe støtter? DVS at det tar litt tid å komme fra 0-XX prosent hvor lampen faktisk starter.

Jeg har valgt en annen løsning på to hytter i familien - "dum" zigbee-koordinator utplassert på hyttene, som aksesseres via VPN fra en server (hjemme) hvor jeg kjører en homeassistant-instans pr lokasjon. Dette krever vel litt mer enn normale nettverksskills, og også sannsynligvis noe mer enn vanlig nettverksutstyr. Men det er billig, dønn stabilt inntil videre (har hatt det i drift 6 mnd), og jeg slipper å passe på en "passende gateway" på en lokasjon 20 mil unna. Da har du all verdens muligheter med zigbee-termostater, releer osv. Et annet morsomt alternativ er devicer på WIFI konfigurert til å bruke ekstern/public MQTT-server. F.eks støtter vel Shelly dette. Og alt som kan flashes med Tasmota.

BalleClorin: Jeg har brukt ZHA ja, bare hentet riktig firmware fra Z2M FW-repoet jeg linket over. Så hvis du bruker Z2M så har du sikkert allerede siste FW, den bruker vel det repoet direkte. Teknor: Det funker med .ota , altså slik du har gjort det. Vil tippe du ikke har fått folder riktig, eventuelt ikke riktig permissions. Tror også du må restarte ZHA for at den skal plukke opp nye firmwares, så hvis du la til config for OTA og restartet før du overførte .ota-filene så ta en ny restart. I config så betyr "/config/zigpy_ota" at "zigpy_ota"-mappen skal ligge rett i hoved-config-mappa til Home Assistant btw. Det kan være en felle. slik:

Det var ganske greit , jeg fulgte instruksjonen her mener jeg: https://community.home-assistant.io/t/zha-ota-firmware-update-upgrade/488960 Så må du legge de riktige filene i den zigpy_ota-mappa du definerer i configuration.yaml . Så starter det enten automatisk etter restart av zha, eller du kan trigge manuelt. (Det står også instruksjon i link over)

Dette med Namron termostater og at de går i AWAY-mode randomly skal være fikset i siste firmware som ligger tilgjengelig på zigbee2mqtt OTA firmware-repoet. Ryktene sier at det skjedde fordi de feilaktig reagerte på tilfeldig trafikk i zigbee-nettverket. Jeg oppdaterte 6 termostater fordelt på to lokasjoner for et par uker siden og har ikke opplevd feilen siden. https://github.com/Koenkk/zigbee-OTA/pull/294 "This firmware update resolves the issue with this device using random zigbee devices on the network to control it's occupancy mode (aka. away_mode). This made it randomly activate the away_mode feature on the device."