NilsOF

@JarlesbTakk for godt samendrag! Dette gjelder nok for de fleste systemer.

Høres bra ut, dette blir godt over snittet i "hi-end" 🙂 Jeg ville brukt lys-sensor hær også. Men sørg for å skaffe en med god oppløsning i den lavere enden. Plassering/sikteretning er viktig i så måte. Jeg er meget enig med din samboer! Meg og min bedre halvdel har konkludert med ingen kamera og heller ingen mikrofoner inne!

Det kommer an på.. ..nesten så jeg tror du har AC ut i fra beskrivelsen. Men, som sagt: Den eneste måten å bli sikker er å måle. 🙂

Sjekk med kommandoen "rfkill". Med den kan man slå av og på de forskjellige radioene. (Skulle ønske den hadde muligheten til å slå av 2.4ghz mens 5ghz var på.. Det hadde hjulpet med evt. interferens mot zigbee)

@ZoRaC Gulle godt, jeg visste ikke at NRK hadde en API før i dag, takk for tips! Så var det bare jobben igjen med å legge Dagsnytt radio til "vekkerklokka" mi. Enda ett punkt til på todo-lista. 🙂

Hm, ser ut som det kan bli litt tull mens programmet er på lufta; Startet ni-sendingen Dagsnytt kl 9.03 sånn ca, avpillingen startet programmet fra begynnelsen og ble avbrutt ca tre minutter uti. Kun prøvd på Ipad med safari en gang. Men ellers er det genialt. 🙂 Sjekket kjapt NRK sin API https://psapi-ne.nrk.no/documentation/ Den ser jo overkommelig ut. Om ikke annet så skal man kunne loppe ut en programoversikt.

Kanskje det finnes noe her: https://lyd.nrk.no

Dette er jo enkelt å måle med ett multimeter. Er det AC som mater spotene så kan man sette inn en likeretter og glattekondensator. Mål så spenningen og sjekk at spotene tåler spenningen.

La bare stå, z-wave nettet trenger noen gode timer på å komme seg i lage. Eller mest sansynlig sånn. Evt. kjør "healing" ( eller hva det nå heter på ditt system) Likevel kan det ta noen gode timer før alt er på plass.

Om kvaliteten står i forhold til prisen, så er det greit. Jeg fant ingen pris på Feks. dør/vindusensorene nå. Men klart at det blir fort mye penger i forskjell når antallet blir stort. Installatørene kommer nok til å like Elko-huben og alle dingsene. Det er ett skikkelig potensiale for mersalg og fakturerbar oppfølging. Forutsatt at dingsene er stabile..

..eller bytte til raspian? Eventuelt kompilere inn det du trenger i Hassos selv. Men først ville jeg sjekket ut hva alsa sier den ser av hw. Jeg tipper at: aplay -l er riktig kommando. eventuelt "alsamixer" eller "amixer"

Det første jeg tenker på er avkopling av støy i reguleringskretsene. Det krever noen ekstra komponenter. Disse ekstra komponentene finnes ikke på billige kretser. Eller bare i den grad at kretsen fungerer når kortet sendes fra fabrikk. Og komponentene endrer litt på verdiene når de eldes. Spesielt fort eldes komponenter som blir varme (de som behandler effekt). Jeg ser mye støy fra Rpi4 også (LQI er dårligere når zigbeestikka står i en Rpi4 kontra min Intel NUC - begge med avslått WiFi radio) Jepp, ingen grunn til å tro at støy er begrenset til det området man ser effekten av det. I forrige årtusen så hadde vi også støyskjermer på kretskortene. Om disse skjermene ikke har forsvunnet helt, så var nok det ett fenomen som hører forrige årtusen til (på forbrukerelektronikk).

En motstand og en transistor, og man trekke både så høy spenning og strøm som transistoren takler. 3.3volt bør alltid buffres. (buffer = transistor)

Hm, finnes det z-wave pærer til fornuftig pris? I såfall, tenk på begge mesh-nettene og dekning. Om man plugger begge sånn passe så hvorfor ikke? Og det gjelder ikke bare lyspærer. Man kan dra det beste fra to verdener 🙂

Tja, jeg har noen Ikea lyspærer i utendørsbelysning. Det fungerer helt utmerket som routere i meshet. Nå har jeg enda tilgode å se hvordan det fungerer i 20-25 minus, men siden radioen er på konstant forventer jeg ingen overaskelser da jeg anntar at kretsene lager nok varme i seg selv til at de holder seg inne på funksjonsnivå.

Hehe, jeg begynte å tenke på broadcasts og hvordan det vil oppføre seg, og da havnet jeg på ville veier 🙂 For var det sånn at det ikke var sånn eller var det som jeg først tenkte eller var det i andre gjenommgang av tankegangen første gang.. Ja, og det tenker jeg er en av grunnene til at routede nett er å foretrekke 🙂 Ingen ninjatriks, maskiner og tilhørende nettverkssegment befinner seg kun på ett sted og kan nåes med mere oversiktelig ruting.

Ser man det! takker! Trodde man måtte ha kjøpt ett fullt SDK med tilhørende signering av NDA.. Ett kjapt søk forteller at flere har konvertert Aeon gen5 til zniffer-stikke. Men man kan muligens ikke konvertere tilbake til normal tilstand. Jeg har ekstra Aeon-stikker liggende, må prøve 🙂

Nei, det vil ikke fungere uten. Man må heller spørre seg om man trenger å ha det sånn. Broadcasts vil feks. forplante seg på begge sider av VPN-linken selv om de mest sannsynlig er relevante kun på den siden av linken de sendes fra. Unødvendig da man har en begrenset link som man kanskje også må betale for pr. byte. Fyr opp tcpdump og se 😉 Edit: Det er nok bare arp-broadcast som slenges over, så ikke så mange bytes at det vill lage huller i lommeboka. Rutede subnett er enklere å jobbe med, man kan med ett blikk i hvilken som helst logg kjapt identifisere hvor trafikken kommer fra eller hvor den skal. Ulempen er at man må sette opp DHCP på begge sider. Og så må man ha routing ett sted. Og det har man uansett. Men har man disse på plass så bruker man TCP/IP som det er ment til å brukes. hehe, ja 🙂 tcpdump er vår venn på alle dingser som man har skall-tillgang på.

Tja, om man skal gjøre det enklest mulig med VPN så må man velge om man skal ha bridged eller routed VPN. Bridged: samme subnett på begge sider av VPNforbindelsen. Routed: Unike subnett på begge sider Begge har sine fordeler og ulemper. Må si at routede nett er sterkt å foretrekke, og spesielt når det er geografi og hastighetsforskjeller med ukjent forsinkelse ute og går. Når det gjelder å forenkle dette oppsettet, så er det nok lite man kan gjøre. LTE/4g er hva det er. man kan kanskje sette HuHei-modemet i bridge, men man har nok fint lite igjen for den ekstra jobben som også bør dokumenteres. Det hadde nok fungert med 192.168.1.x mellom HuHei og mikrotik også. Dvs. Automatikken i Mikrotiken takler det i og med at Mikrotiken bare maskerer alt bak IPen på interfacet (masqerading i Linux). Da er det værre med mennesker som skal ta igjen oppsettet og endre på det ved senere anledning. Og om det er noe administrator-grensesnitt på HuHei så er det mere enn greit at det kan nåes på en unik IP. Jeg håper du har fått tingene til å virke! Det er lett å gå seg vill før virkemåten av alle funksjonene i kjeden er forstått. Men jeg er fortsatt nysgjerrig på hvorfor du vil ha samme maskin på begge sider av VPNen 😉

Oh, nå ser jeg hva du prøver å gjøre 🙂 Og lurer fælt på hvorfor.. Det er sikkert mulig men, igjen hvorfor gjøre det så komplisert? Er det noe som ikke virker med routing? Edit: om Mikrotikene støtter bridgedVPN så er kanskje det veien å gå? For at en maskin skal eksistere i to nett: Jeg har brukt opp hodet mitt for i dag.. ..adressa må eksistere i Mikrotiken og så må det NATes. Altså adresseomskriving. Når det i tillegg er tre ledd med NATing allerede i denne kjeden (eller også fire alt ettersom hvordan mobiloperatøren gjør det)..

Det kan være en filtrering i Mikrotiken (og som muligens du går inn bakveien på med 192.168.1.x som del av transportnettet). Om du kan nå de andre 192.168.88.x -maskinene så er du godt igang. Edit: Jeg forutsetter at begge Mikrotikene er satt opp som routing-VPN (og ikke en som bridging VPN). Og at begge Mikrotikene er fortalt at det andre nettet ligger bak VPN -tunellen.

Hva slags VPN-tunnel brukes hær? Det ser ut for meg som at 192.168.1.x er brukt som både transportnett og som endenett? 192.168.1.1 finnes to steder..? Dette lager nok god kaos i routinga. Det enkleste er kanskje å endre HuHei 😄 -boksen til å bruke ett annet nett enn 192.168.1.0/24. (Jeg regner med at HuHei -boksen NATer og samtidig deler ut IP til RouterOS-boksen med DHCP ?)

På Z-wave så er det også en del forsinket/utsatt intervjuing som må ventes på. I mellomtiden har man kanskje delvis nye og delvis gamle settings. Det er i slike tilfeller man skulle hatt en pålitelig sniffer..

Det jeg ønsker meg aller mest på z-wave er en god sniffer som kan si meg i detalj hva som foregår. Men jeg tror ikke noe slikt finnes, iallefall ikke til en fornuftig pengepris..

@berland Jeg sympatiserer med mange av betraktningene dine vedr. HabApp. Den største utfordringen med HabApp som jeg ser det er de ekstra rundene som signalene må gå over APIet, med den forsinkelse som det medfører. Jeg er ingen programmerer, men koden til HabApp synest for meg grei nok til at også jeg skjønner oppbygningen når jeg stirrer lenge nok 🙂 Alt i alt så lander HabApp positivt for meg. Å ha all konfigurasjon for Things (Channels, Items) tilgjengelig (og editerbar om de ikke er låst med konfigfil) er også ett kjempestort pluss.