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.