Kandersen

Mikkel, har du en Rpi4 som booter fra en SSD via USB? (Spørger fordi den mulighed ikke virkede lige da Rpi4 kom på gaden. Jeg har ikke fulgt nok med til at vide, om de har fået det fixet).

Synes både deres G3 cams og deres cloudkey 2 er alt for peberet i forhold til hvad de giver. Specielt deres cams som eftersigende er nærmest låst fast til at kun køre via deres software/NVR. Det er lidt skidt. Derfor har jeg hverken deres cams eller deres cloudkey 2. Har til gengæld deres USG, cloudkey v.1 og 3 APére (1 pro og 2 lite). Og så et par switches med og uden POE.

Klovne? Det her er skam dybt seriøst og ret vigtigt, når der er nogen der råder en anden til at bruge wireless/trådløs netvæk, uden tage forbehold for behov og ikke mindst omstændighederne. Jeg håber så sandelige at Mikkel har læst noget af det, og forstår, at nok kan trådløst være et okay alternativ, hvis altså routeren/AP står umiddelbart i nærheden af den PC han vil have på, og forbruget/behovet er derefter. Jeg kan ikke bare tage disse ting for givet. Og slet ikke med en oplysning om, at der er tale om en bygning med IHC net i forvejen, hvilket fortæller mig, at der er nok ikke tale om en 2-værelses lejlighed her. Tværtimod er vi nok ude i noget mere parcelhus agtig, hvor man snildt kan formode, at router/AP netop ikke er placeret lige i området hvor behovet er. Hvis det er tilfældet, så kan hans mulighed for 100mbit kablet netværk lyn hurtigt vise sig at være en bedre løsning, hvis han altså kan finde den splitter til det. Til gengæld har jeg heller ikke mere at tilføje.

Kollisioner er gensendelse af tabte pakker. Kollisioner bliver værre, jo dårligere støj/signalet og udstyret er. Billedligt talt, så svare det til at pakkeposten taber nogle pakker på vejen, og skal tilbage og samle dem op - Hvilket resultere i, at han er længere tid om at levere pakkerne, jo flere pakker han skal tilbage og hente. Et netværk som lider af voldsom støj/dårlig dækning, der vil kollisionerne være voldsomt forværret, fordi enheder/AP/Switch/whatever skal gen-sende de tabte pakker. Og tiden fra collision detect og til enheden AP/Switch/whatever skal bruge, har betydning for, hvor meget tid der kan bruges til evt andre enheder tilsluttet samme enhed. <-- Her har du principielt ret i at antallet af enheder KAN have en betydning. Men det er ikke det samme som at sige, at antallet klienter har betydning for, hvor god kvalitet (signal/støj forhold) der er på det trådløse net). Det er to forskellige problemstillinger, som dog resultere i det samme - lavere effektivitet. Een klient kan principielt "vælte" et AP så meget, så kvaliteten for andre klienter er mærkbar. Men rent praktisk vil man næppe mærke det, medmindre vi er ude i virkelig ekstreme forhold eller virkelig dårligt/ældre udstyr. AP/klient vil oftest afbryde forbindelse før det sker på trådløse netværk. Omvendt kan 50 enheder med god/optimal dækning/minimal støj få langt bedre resultat ud af det samme AP, (forudsat at AP er bygget til at håndtere 50 klienter). Det er værd at bemærke - Kollisioner sker både i kablet og trådløse net. De er uundgåelige, fordi der fx altid vil være noget støj, (bemærk vi snakker almindelige netvæk, ikke laboratori forsøg). Kunsten er at minimere kollisioner, så AP/router/Switch kan bruge tiden på det de er bedst til. Det kan man kun gøre med ordentligt udstyr og god signal kvalitet. Men det nytter altså ikke noget at sidde med det absolut bedste Cisco udstyr og så tro, at man kan hive 50-100MB/Sek trådløs data ud igennem et rum som er bygget af bly, (overdrivelse fremmer forhåbentlig forståelsen), selvom der kun er ganske få meter mellem een klient og AP. Det kan simpelthen ikke fysisk lade sig gøre. Der vil ikke være kollisioner på sådan et netvæk, for der vil ikke være en forbindelse/link overhovedet, og dermed intet netvæk.

Reelt burde du ikke måle på link hastighed, men derimod på overførelses i MB/Sek (mega byte/sek), da det er det som er afgørende for, hvor meget data du reelt kan presse igennem din forbindelse. Det er ikke data hastigheden ind/ud på internettet. Det er derimod på det lokale net, som bør få den første opmærksomhed. Det gøres "nemmeste" ved at overføre en fil fra en computer til en anden. Og så se på hvad lang tid det tager at lave denne overførelse, i forhold til filens størrelse. Bemærk, en mere "rigtig" metode er at bruge flere filer i forskellige størrelser. Det er ikke nemt, hvis ikke man har værktøjet til det, og de to computere skal være super optimeret til netop den form for test. (dvs flaskehalsen må IKKE ligge i computerne). Det er dog værd at bemærke, at man OGSÅ samtidig tester, hvor god routeren (evt switch) er til dette. Rigtig mange ISP routere (specielt de ældre af dem) er ikke specielt gode, hvorfor problemet lige så vel kan ligge i den, som i den forbindelse man tester. Det opdager man, når man tester med hjælp af kabel. Dernæst er der latenzy som du selv er inde på. Latenzy vil først og fremmest vise sig, når du begynder at "presse" dækningens effektivitet. Jo dårligere signal, desto højere latenzy. Specielt online gamere kan lyn hurtig mærke selv ganske små latenzy svingninger. Streamer man vil man næppe mærke selv en meget høj latenzy, bla fordi streaming protokoller også indeholder en buffer, (dermed er latenzy principielt slet ikke et issue mere medmindre vi er ude i virkelige ekstremer). Præcis! Som jeg skrev i forrige indlæg - Andre kan IKKE lave en vurdering af dette. Det er forbrugeren selv der skal fastsætte behovet. Dernæst kan man råde og vejlede ud fra det. Kender forbrugeren ikke sit behov, (hvilket er meget typisk for rigtig mange forbrugere), så kan man kun råde og vejlede ud fra de kendte fordele/ulemper ved de forskellige teknologier. Om wireless er nok til OP ved jeg ikke. Men jeg ved, at hvis OP ikke ved det (eller kender sit behov), så kan det vise sig at blive et rent helvede at begive sin ind i wireless muligheden, eller alternativt, det bliver en dyrt købt oplevelse, hvor man måske skal flytte husets router, og måske endda opsætte flere APére (hvilket kan betyde mere kabeltræk). Jeg beklager jeg måske er lidt "larmende" hvad det her angår. Men det er altså et område jeg har temmelig indgående kendskab til siden wireles protokollen 802.11 kom på markedet i 1997, og det dengang hed op til 11mbit. Og jeg har professionelt arbejdet med rigtig mange forbrugere igennem tiden med bla wireless og internet forbindelser.

Antallet af enheder (klienter) er absolut ligegyldig over for spørgsmål om dårligt signal/dækning/whatever i trådløse net. (Er du uenig, så skriv i PM. Jeg vil ikke ud i vanvittige diskussioner med dig om det her). Vurderingen af om wireless er godt alternativ eller trække kabler, det skal helt og aldeles vurderes af den forbruger der skal bruge det. Det kan andre ikke vurdere. Andre kan kun fortælle, hvad man skal være opmærksom, når man skal vurdere sit behov ud fra det ene eller det andet, (trådløs kontra kabel). Det er det jeg har forsøgt at redegøre for her, som jeg bestemt ikke mener er absurd. (Medmindre OP allerede ved alt dette).

Du kan jo prøve om du kan "genskabe" samme problem

Du kan ikke skrue op/ned for en Uni400 dimmer sådan som du fx kan med andre dimmere. UNI400 har ikke tilbagemelding om dimmeres status. Funktionsblokken har tilbagemelding. Og fra den kan du få at vide, om Dimmer er tændt eller slukket. Thats it. Principielt kan du godt vha to tryk/switches skrue op og ned for dimmeren. Men det er desværre en begrænsning som er ekstremt, ja nærmest umulig at få til at virke tilfredsstillende, da du er ude i så korte tider så det bliver svært at styre det bare nogenlunde meningsfyldt. Så jeg kan ikke anbefale du forsøger det. Lev med UNI400 dimmeren kan bruges som og vise tænd/slukket (via funktionsblokken). Udskift den til en wireless, hvis du ønsker at kunne styre lyset mere direkte på dimmeren. Det er desværre eneste reelle mulighed.

Generelt for trådløse netværk. 802.11ac HAR helt principielt kortere rækkevidde end 802.ab/n da det er 5ghz kontra 2.4ghz. Det er faktum, det ikke kan debatteres, gradbøjes eller på anden vise afvises. Jo højere frekvens, desto lavere afstand, i forhold til effektiviteten. Enhver der vil påstå noget som helst andet har ikke forstået en tøddel af teknologien! Det betyder ikke at 2.4hgz er bedre, bare fordi det har længere rækkevidde, for det er også mere følsomt over for støj, specielt ude i de længere afstande. Samtidig er link hastigheden på 2.4ghz mindre end det som 5ghz kan opnå. 5ghz derimod lider af, at man skal ikke langt væk fra AP, eller have mange (læs - få) vægge imellem, så er signalet så svagt, så effektiviteten ikke står mål med resultatet. (Bemærk, vi snakker ganske få meter ala 5-10m som næsten kan halveres, hvis der er væg imellem). Alt dette ved folk, som har indgående kendskab til den trådløse teknologi!! Det er ikke faktum jeg opfinder eller synes er sjovt at skrive. Det er bare sådan trådløse netvæk er. 802.11ax kommer måske til at rette på noget af dette. Men støj, afstande og bygningskonstruktioner vil ALTID være en udfordring for selv de absolut bedste APére. Det er IKKE uden grund jeg siger at, man bør bruge kabel for hver en pris, hvis det er muligt. Det er simpelthen ikke slåskampen værd at slås med elendigt trådløs net, medmindre man har indgående kendskab til det, og ved præcist hvad det er man vil opnå. Det gør de fleste almindelige forbrugere ikke, uanset hvad nogen andre forsøger at sige.

Du har ret hvis du læser det som, at for få kanaler skulle være skyld i dårlig rækkevidde. Men ellers så er der så absolut ingen grund til, at man ikke skulle kunne opleve begge dele. Specielt i områder hvor der er voldsomt mange APére (inkl wireless routere da de også indeholder AP). Netop som Lars Jakobsen siger, er lejlighedskompleks faktisk en enorm stor udfordring for netop trådløse netvæk. Dels fordi der er mange der slås om få kanaler, og fordi de støjer som bare pokker for hinanden.

Godt råd. Men prøv at bevæge dig ud til hr og fru danmark, og du vil erfarer, at Wifi er for mange problem. Det ligger i teknologien wireless. Alt wireless are sårbar over for bla støj og ikke mindst bygningernes opbygning, materialer osv.. Og så har langt de fleste bare rigtig dårlige accesspoints/routere oftest fra deres udbydere. Er du ikke enig i dette, så er det nok fordi du ikke kommer nok ud.

Optimer dem, fordi jeg ved noget om dette, i stedet for at slås med wifi som rent principielt ikke kan være lige så stabilt.

Det kommer helt an på, hvad "søn og PC" har i tankerne at skal udføre sammen. Min erfaring siger mig, at hvis ikke nu, så snart vil "søn og PC" sidde og game online spil. Og "søn og PC" vil meget hurtigt mærke, at wireless bare ikke er specielt godt til det formål. Og så vil søn uden tvivl vende sig til sin far og beklage sig højlydt. Skal "søn og PC" sidde og streame, så ser det anderledes ud, fordi der i streaming protokollerne er indbygget fejlkorrigering hvor streamingen tilpasses hastigheden, så de opdager slet ikke de samme problemer. Helt generelt - Det er IKKE det værd at slås med dårlig Wifi, når/hvis der er kablet forbindelse. Og god (optimeret) WiFi kræver indgående viden om WiFi.

Til det specifikke forbrug med IHC captain, der tror jeg ikke du kommer til at mærke nogen mærkbar forskel. Jeg køre IHC Captain på en Rpi3B (med SD kort). Og den er rimelig hurtig. En Rpi4 vil nok være en del hurtigere, men flaskehalsen vil ligge i SD kortet. Så ud fra det behov, så kan du sagens nøjes med en Rpi4 1GB.. Personligt ville jeg ikke spare de få kroner der er fra 1GB til 2GB, eller måske endda 4GB.

Det kan være et skidt alternativ at bruge Wireless når/hvis man har en kablet forbindelse, også selvom denne kablet forbindelse "kun" er 100mbit. Wireless skal enten være super optimeret, (hvilket de fleste ikke er) ellers kommer det aldrig i nærheden af den samme stabilitet som et kablet 100mbit net. Har du brug for mere end de 100mbit, så er der næppe nogen god vej uden om, at der skal noget ombygning til.

Jeg kender ikke Nilan connect, så jeg kan ikke hjælpe hvad det angår. Men jeg kan foreslå et alternativ i form af en Rasberry Pi, et USB<>RS485 interface og så OpenHAb2 som noget relativt nemt software, hvis det kun er Nilan anlægget du vil have på. Via modbus kan du nærmest hive alle informationer ud af Nilan anlægget på den måde. Og via Openhab Cloud samt deres App, så kan du nemt se det ude fra. Men det kræver man er lidt indstillet på at få det grundlæggende i Rpién med openHAB2 op og køre. Resten kan jeg sagtens hjælpe dig med.

Derfor!

Ja, nu argumentere du jo netop selv for, at de er helt malplaceret i det panel

EDIT igen... Jeg tror jeg ved årsagen nu.. Du er nødt til at definere dit channel som et "Type push-button-trigger". Jeg ved ikke om du kan sætte det på en autotmatisk læst kanal. Ellers skal du lave den manuelt.. Hvis du kigger på IHC docs, så vil du også se, at den skal definere som push-button-trigger, ellers virker shortpress osv garanteret slet ikke. EDIT igen igen.. Jeg tjekkede lige PaperUI. Jeg kan ikke se man kan sætte typen på en automatisk indlæst kanal. (Jeg ved ikke om det er en forglemmelse fra @Pauli Anttila eller om det slet ikke er muligt). Så du er nok nødt til at lave den channel manuelt.

Enig, men netop IHC ligger jo lige til højrebenet for netop det område de debattere i det panel.

Hvad mener du med at "fange" dem.. Hvis du linker et item til et tryk så burde du kunne se i openhab loggen, når du fx trykker på trykket.

Ikke flere på samme system, men systemer på flere computere. Jeg ved ikke hvad HA som du oprindelig spørger til. Men openHab2 er. Nej, det er linket til HA (Home Assistant). Openhab2 er et andet system. https://www.openhab.org/docs/

Fordi de ikke tidligere har været specielt åbne og imødekommende over for andre eller samarbejde med andre.

Køb 2Rpiér og kør både IHC Captain og fx HA (eller openHAB2). På den måde kan man prøve sig frem, uden at gøre sig speciel afhængig af platformen førend man ved hvor man vil hen Jeg har to Rpi3B+ og én Odroid C2 kørende = 2 x openHAB2 og 1 x IHC Captain. Har også en tredje Rpi3B+ som er tilsluttet en 24" FHD skærm. Den skærm skal splittes i atomer og bygges op i en small ramme inkl Rpién, for at være monitor til hele hjemmesystemet, muligvis indbygget direkte i en væg, når/hvis jeg engang når så langt. (Sandsynligvis et pensionsalder projekt ). Begge openHAB installationer kører med SSD (Odroid med MCC kort). IHC Captain kører med SD kort, (endnu), fordi aktiviteten er væsentlig begrænset i forhold til openHAB. Jeg overvejer at udskifte alle Rpi3 til Rpi4. Det var planen her i juleferien at min "main-Rpi" skulle lade livet enten til Odroid eller så til en Rpi4.. Men jeg når det desværre ikke alligevel.

Man kan da ikke andet end at undre sig over, hvad Schneider Electric laver i den her forsamling: https://arstechnica.com/gadgets/2019/12/apple-google-and-amazon-team-up-for-joint-smart-home-standard/#