NilsOF

Mener jeg dro kjensel på Palo Alto i slippern sitt innlegg. Den er jo en slags proxy, men er kapabel til mere enn http/https. Slike ting krever hestekrefter, så minimal vil jeg ikke kalle det. Da har du begynt riktig etter min mening 🙂 . Dersom du bruker en DNS-provider som filtrerer ut farlige domener så har man øket sikkerheten ganske så mange hakk. Problemet er å slå ihel kryptert DNS trafikk fra innsiden av routeren for deretter å mate dnscrypt-softwaren på routeren med ukrypert DNS trafikk til videre foredling. Jeg har bare researchet dette til nå, men om man nekter tilgang til internet-servere som tar imot DNS over https (og dets like) så skal i teorien Firefox, MS-greier, Google-greier og andre-greier, falle tilbake til gammeldags DNS. Om man i tillegg har ett eget lokalt DNS-filter så kan man sperre mange anonseservere og trackere. Pi-hole er en slik "proxy". (Men, det store problemet med Pi-hole er å få tak i kvaltetsikrede black-lister og dermed faller hele stasen med pi-hole samen) En minimal og enkel DNS-proxy er å sette opp dnsmasq feks. Openwrt bruker vel nftables nå? I tilfelle kan deler av brannmurreglene som feks. adresse-grupper oppdateres dynamisk av script.

Vel, jeg har ganske mange timer tuklet Palo Alto. Riktignok er ikke min erfaring helt fersk, men likevel: På ett vis likte jeg de veldig godt. På et annet vis hatet jeg de som pesten. Det er ett supert verktøy for oversikt og content-scanning når den er satt opp som content-scanning firewall mellom fiendtlig (internet) og beskyttet sone. Som tradisjonell brannmur og router faller den igjennom. Men sikkert bra nok i masser for mindre nettverk. Jeg vil påstå at utfordringen i dag ligger mye på DNS-siden. Nåvel, jeg beveger meg kraftig offtopic nå, så jeg stopper hær 🙂 Ellers er jeg mye enig med @slippern om oppsett. Bare ikke sluk alt som kommer fra nevnte produsent rått!

Den ene er en Fibaro dimmer 2. Den kan resettes til fabrikk-instillinger (og den har en knapp) https://manuals.fibaro.com/dimmer-2/ Jeg kjenner ikke de andre, men Fibaroene jeg har klepet i har stort sett samme funksjonaliteten i så måte. Men, dersom du får tak i styregreiene som var der før og tenker å bruke den; ikke tilbakestill de! 😉

Jeg brukte openwrt før jeg oppgraderte til Ubiquiti Unifi på trådløssiden. Såvidt jeg husker så støtter Openwrt både vlan og tilknytning pr. SSID mot vlan. Men det kommer an på hardwaren også. Og der er det mye rart. Noen typer/modeller bruker ett vlan pr. port og bridger mellom disse vilt og uhemmet. Andre har brukbare switcher på kortet som muliggjør bruk av vlan. Men rett frem plankekjøring blir det uansett ikke. Og ikke regn med at port-nummereringen bak stemmer med nummereringen i OSet. Når det gjelder oppdelingen av nettverkene; Chromeplugs og annet som bruker broadcast for å detektere potensielle samtalepartnere bør stå i samme nettverkssegment. Altså PCer, telefoner, nettbrett og dingser som Chromecast bør har sin egen lekegrind. Det er disse dingsene er også de som er farlige for "IOT"-greiene. Derfor er det lurt å sette automasjons-servere og administrasjons-grensesnitt til switcher ol. i et eget beskyttet segment. Om automasjons-server skal snakke med chromeplugs så er en mulighet å ha to interfacer (her regner jeg også ett vlan som ett nettverksinterface). Om man holder tunga rett i munnen og bruker brannmur-regler på port og IP-nivå så er det fullt mulig å begrense automasjonsserveren til kun å prate med chromeplugs. Smådjevlene ligger i detaljene. Og det er mange detaljer å passe på i slike oppsett. Absolutt gjennomføringsbart om man er bevæpnet med kunnskaper på NAT, routing, DHCP, vlan, nettmasker/gateways og brannmurregler (som feks. iptables eller nftables) 😉

Heltun har en. Den ligger ikke i databasen til OpenHAB, og jeg har en liggende. Kanskje jeg får finner tid i påska.. https://www.tronika.no/no/smarthus/zwave-produkter/z-wave-apparatstyring/bryter-1-veis-he-hls01.html

Da blir det Bitdefender, eller hva det nå heter. Mye nytt når man ikke plukker på slike ting til hverdags lengre. Takker for svar 🙂

Ah, så den nå, når jeg omsider tilsynelatende har klart å ordne en USB-pinne som ikke installeringen annser som "korupt". Tenkte at dette var noe lilleblaut hadde avviklet siden den ikke virker på den gamle maskinen. Den fungerte helt utmerket før, så da blir det ingen forskjell. Da er det nok kommet seg noe dritt innpå den gamle, så på høy tid med en oppgradering..

Jeg har anskaffet en NUC til mine foreldre, og det skal brukes Windows 10 på den. Det er 4 år siden jeg sist lot mine klamme fingre berøre en fysisk maskin med windos på. Og nå jeg først bruker windos så er det uten antivirus til få og bestemte oppgaver. Derfor aner jeg ikke hva som er lett og uten forstyrrelser innen antivirus lengre. Publikummet er god voksne, så antivirusen må ikke komme med popups og spørsmåls-plakater før det faktisk har skjedd noe galt. All oppdatering må skje i bakgrunnen uten behov for hjelpende hånd. Brukerkontoene blir satt opp uten administrator-tilgang. Kort sagt: Det må bare virke! Har dere noen tips?

hm, slå på (parameter 40) "Selective Reporting" Sensoren vil da sende uppdatering når sensorverdiene har endret seg som angitt i parameter 41-44. Hvor dere skal sette parametrene i HA og HS er kaudervelsk for meg.. Det ser ut fra screen-shotsene over som at de er borte i brukervennlighetens navn? Parametrene finnes dokumentert og nummerert i manualen for MS6. Sånn ser det ut i OpenHAB (iallefall begynnelsen av parameterinstillingene):

Sonoff/Itead har sluppet en Zigbee 3.0 USB Dongle i første omgang 1000 eksemplarer. Bestilte to stk for å teste, 6.99$ pr. stk. klarer jeg på tabbekvoten. https://www.itead.cc/zigbee-3-0-usb-dongle.html

Såvidt jeg husker så kan man sette hvor mye endring som skal til før den rapporterer.

Hehe, du har nok i overkant av det jeg vil kalle en liten hytteinstallasjon der 😉 Men det spiller forsåvidt liten rolle. Det som utgjør en stor fare for feil er skriving til disk/kort. Dess mere man putter på installasjonen, dess mere skrive-trafikk får man. Og kombinerer man skriving til disk med strømbrudd så har man fått en korrupt disk. Når man i tillegg tar med i betraktningen at minne-kortene bruker lengre tid på en skriveoperasjon så økes sjansen for feil.

Det er flere ting jeg synest skal taes i betraktning når man velger hardware. Dersom systemet skal holdes minimalt og det ikke spiller noen rolle om man mister logger og data når strømmen går, så er Rpi4 et godt valg. En stor ulempe med Rpi og tilhørende caching av logger og databaser i RAM er at kompleksiteten i systemoppsettet øker. Med caching til RAM kan en Rpi tåle mye av strømbrudd da data skrives til disk i bulk på tidsintervall. Det er også billig å ha backup hw og minnekort liggende klar på hylla i tilfelle anton. Jeg er ikke i tvil om at en Intel NUC med SSD er bedre egnet når man vil ha databaser feks. Og kanskje drar man video inn i systemet? En NUC på en UPS er meget behagelig når det gjelder vedlikehold. På en annen side kan en NUC uten UPS bli meget ubehagelig ved strømbrudd og man får ett korrupt filsystem ( selv om dette har blitt meget robust de siste årene). Jeg vil si at en Rpi satt opp med caching til RAM er en god begynnelse. Spesielt på en hytte som muligens er litt langt unna når noe skjærer seg. En UPS er også lurt hær, selv om skriving til minnekortet bør settes opp til å skje i bulk. Edit: kom til å tenke på at ikke alle vil sette opp en automasjons-server mest mulig minimalistisk og headless som førstevalg. Dersom man skal ha fullt grafisk grensesnitt så definitivt gå for en løsning som feks. Intel NUC.

Jeg kjenner ikke SmartThings så jeg vet ikke om det er kapabelt til å snakke med en Hue hub, eller kanskje ST snakker zigbee direkte? Uansett ett Hue startkit, med eller uten hub, alt ettersom ST kan støtte er kanskje veien å begynne på. Du må glemme den eksisterende bryteren du har, bruk Hue sin dimmer/bryter/fjernkontroll og eksperimenter deg frem. La dimmer/bryter/fjernkontroll ligge fremme, og etterhvert får den gamle lysbryteren være i fred. dvs. stå i på. 🙂 Edit: må bare tilføye en liten advarsel om at dette kan bli vanedannende.

Den ser jo snasen ut. Men den passerte ikke zigbee alliance sine tester: https://zigbeealliance.org/zigbee_products/mi-light-detection-sensor/ Så da spørs det hva det er for noe rart med den..

Den store feilen har de ikke fikset enda. Ikea må oppgradere utviklingsplatformen sin først..

Det er (var?) en bug i SDK fra silabs for chippen som Ikea bruker i noen av pærene. Mener det var en buffer overflow i forbindelse med routing-beskjeder i meshet. Når man legger til dingser så vil routingen i meshet nødvendigvis bygge seg opp på nytt. Og dess flere dingser man har dess oftere vil man trigge denne feilen.

Nå har jeg aldri plukket på Openzwave, men det ser jo ut som noe køes opp og sendes ut til node32 også. Og node 32 svarer på forespørselen. Overivrig polling? Hær må nesten noen som har erfaring på ozw kime inn. Edit: dess mere jeg kikker på logsnippet dess mere forvirret blir jeg. Det ser ut som verdiene flipper mellom 35 og 47 og så plutselig 0. Kanskje prøve å disable alle reglene for å se om det oppfører seg da?

Jeg burde egentlig IKKE svare på denne, da jeg syns at homeseer (med andre) blir for mye heft mellom meg og metallet.. For all del sjekk ut alternativene, det kan jo hende du har flaks og finner noe som er skinnende blankt med de funksjonene du trenger. Men dersom du mener seriøst å styre noe så se bort i fra skinnende blankt og finn heller noe som setter virkemåten i førersetet. Det er de tingene som virker helt uten at noen behøver å gjøre noe som helst, og aller helst ingen legger merke til som betyr noe. Nåvel, det er min filosofi, andre bør selvfølgelig finne sin egen vei 😉 🙂

Hm, mye node 32, men for alt jeg vet skjer dette over mange timer.. Det sier med andre ord ikke så mye, annet enn at node 32 dominerer i dette utklippet. Og det kan jo være akkurat som det skal være om det er da noen ruller på hjulet..

Tviler sterkt på at du vil se noen forskjell mellom G5 og UZB1. I bunn og grunn er det samme kretsen med veldig lik firmware. Du bør nok se på dimmeren og hva som skjer i meshet.

Den er spesifisert til 16A, 2300W bør da gå bra siden man har ca. 1/3 "å gå på". Uansett, slike plugger er noe jeg følger litt med på. Jeg sjekker om de blir varme, tar de ut og kjenner på "pinnene" også. Anskaffet en slik Apex for å teste, men ikke fått prøvd den enda.

Du må nesten se på trafikken i meshet. Du har sikkert en logg som kan studeres? Kanskje er det andre dingser som bruker mye båndbredde sånn at det tipper over når det vries på en dimmer? Jeg kjenner ikke z-dim og vet ikke hvor god firmwaren er i disse.

Heller ikke jeg kan hjelpe med zwave2mqtt. På de fleste z-wave dingser kan man endre den faste rapporteringstiden og også deltaverdier som trigger rapportering. Så man kan skru opp den faste rapporteringstiden og øke deltaverdiene som trigger rapportering (som eksempel). Noe trafikk trengs for at systemet kan se at dingsen er i live. Og litt trafikk hjelper også de andre dingsene når det gjelder routing. Men man kan nok skru ganske hardt til. Har du mange dingser tett samen så er det bedre dess mindre trafikk det er. Med få dingser spredt ut i grensen til radiodekningen så er det en fordel med litt trafikk etter min erfaring. Som Marhil nevner; z-trm2fx gjorde z-wave nettet mitt totalt ubrukelig pga. defekt i firmware. Den kastet så mye såpass fort ut i meshet at de andre dingsene hadde trøbbel med å smette innpå. Hvilke type/merke/modell er det du vil dempe trafikkmenden på?

2"x4" boltet fast. Om man lar bilen rulle inn så skal det godt gjøres å få noe mere nøyaktig med sensorer som avhenger av reaksjonstid både på sjåførens sanser og elektronikk.