Kandersen

Det står i specifikationerne.

Pas på med LED. Det er et rent helvede med LED. Og problemet behøver IKKE ligge i dæmperen. Faktisk vil jeg sige, at der ikke er den store forskel hvad Uni250 og ø80 dæmperne angår på lige dette punkt. De dæmper alt afhængig af kilden de er tilsluttet. Dvs både LED kilde og evt driver/trafo. På 230volt siden, der er det lidt anderledes og nærmest 100% op til kilden. Jeg har både Uni250 og ø80 dæmpere.

Nej de kan ikke det samme. Bla minimumsbelastningen er forskelling. (Se forrige indlæg). Funktionsmæssig er de dog ens, selvom LK har lavet forskellige produkter til dem. (Uni dimmer/Lampeudtag dimmer).

Minimusmbelastningen for de gamle (ver 1) ø80 lampeudtag og Uni250 (1modul) wireless dimmere er: 20 Watt. Minimumsbelastningen for ver. 2 af ø80 dimmer (de nyere) er: 5 Watt.

Prisen er også svær at sluge, når det gælder de trådløse dimmere. Men i nogle tilfælde så har man brug for en funktion, som bare er betydelig nemmere med en trådløs dimmer fremfor en fortrådet. I dag tog jeg selv skridte og udskiftede en Uni400 dimmer med en trådløs (Uni250), fordi jeg havde behov for PIR styring. Og det er bare ikke nemt med en fortrådet dimmer, og slet ikke fleksibelt. Enten skal man fortråde mem1 og 2, eller så skal man ud i at selv lave en Fb som måske/måske ikke kan det. Jeg tog den hårde løsning, ud med uni400 og ind med en uni250. Og nu er der fuld pir styring på, samt ordentlig styring af lyset/dimmeren. Hvis jeg skulle bygge nyt i dag, så ville jeg ikke være i tvivl. 1. Alle kabler SKAL ende i tavlen. 2. Alle kabler SKAL afsluttes i klemmerækker. 3. Alle dimmere skal være trådløs, (og helst ø80) medmindre det er "sekundær" belysning, såsom fx udendørslys. Der kunne man godt argumentere for fortrådet dimmer. Pkt.1 og 2 er ekstrem vigtige, efter min mening, da det er dem som bla er med til at gøre, at fremtidige ændringer bliver en ren leg. Ydermere så er der langt mere overblik og nemhed i det, hvis man fx vælger at droppe IHC og finde på noget andet.

Er det bare mig der er helt galt på den, men er det ikke muligt (ud af standard blokke) at styre en Uni400 med PIR, når ikke memory 1/2 er forbundet? LK foreskriver brugen af Fb 1.2.02.b sammen med Fb1.4.06, men uanset hvad jeg gør, så kan jeg ikke se det er muligt andet end hvis man har forbundet mem1 og mem2 på Dimmeren.. Det kan da ikke være rigtig der ikke findes en med touch udgang. Selvom det er smart nok med høj/lav på dimmeren, så kunne funktionen jo snildt også benyttes uden mem, altså bare som normalt på dimmeren. Men jeg kan simpelthen ikke finde kombinationen af dette. Og pt er det ikke en mulighed at forbinde mem klemmerne, da jeg er løbet tør for udgange, (og indgange, men det er et andet problem) EDIT: Kan man evt smide mem1/2 i 1.4.06 blokken direkte op på touch i 1.2.02.b blokken? Teknisk set burde det jo være det samme.

Jeg har også lidt en mistanke om, at det skal være sådan. Men når nu Henning svare som han gør, så kan man jo godt blive i tvivl

Hmm, det vil jeg ikke afvise. Men jeg ville undre mig, da der jo ikke rigtig er nogle ben i det.. Anyway - Det ser sådan her ud:

Er der nogen der kan forklare, hvorfor nogle dimmere slukker, når man fx har sendt et nyt program til controlleren. Det gælder både mine Uni250 (wireless 1modul) og Uni400 IHC/SA. Mens ø80 dimmerne de slukker ikke?? Jeg synes ikke jeg kan finde noget i de respektive Fbére som skulle afholde dem fra at forblive tændt. Og jeg forstår egentlig heller ikke, hvorfor de slukker. Uni400 skal jo nærmest modtage et "sluk" for at slukke. Og Wireless Uni250 burde være det samme som wireless ø80m. Det er lidt belastende, når man fx sidder om aftenen og roder med IHC programmet.

Kommer an på driveren der bruges. Nogle kan dæmpe, andre kan ikke.

Det ville være en fordel. Men det er enormt krævende og vil koste en krig for en almindelig consumer router med sådan en firewall i. Og ja vi er offtopic.

Det første skridt for en firewall skal være bare nogenlunde effektiv - Det er ved at presse brugeren til at tage stilling til, om det nu også er en god eller en dårlig ide, inden man åbner. Lidt ala det som windows gør. Problemet med det er, at folk oftest har tendens til, at bare give lov, uden at tænke dybere tanker over det. Og så er det lige vidt. Firewall behøver ikke packet inspection - Hvad vil du helt præcist med det?

Hej Ejvind. Jeg spørger kun af ren nysgerrighed (og undre, hvilket sikkert skyldes manglende viden), og ikke mindst fordi jeg selv har lidt udfordringer med vores Nilan anlæg. Jeg har dog lige et par kommentarer: Den her er jeg meget overrasket over. Vi bor i et rimeligt stort hus på ca. 300kvm. I stuen har jeg en Netamo vejr station, som bla også kan måle Co2. Vi har et par gange været ude for, at Co2 niveauet er kommet over 1000, hvilket er rimelig højt. Se vedhæftet billede. Det hele afhænger selvfølgelig af udluftning. Men det viser også, at selv med et ventilationsanlæg og ganske få personer i et rimelig stort hus, så kan Co2 altså komme ret højt, og ret hurtigt. Så det undre mig at ham rådgiveren ikke mente det var aktuelt. PT styre via ventilationsanlægget automatisk med dens indbyggede fugtføler. Og ved siden af det har vi en brugervalg funktion, som vi manuelt kan booste anlægget på i en pre-defineret tids periode. Men Nilans måde at køre med fugt sensoren, den er lidt mystisk. Selvom den reelt er smart nok, så er den mystisk hvis/når fugten variere meget. Og det gør den i DK, specielt i de våde perioder, som vi har haft en temmelig stor del af de sidste 2-3 måneder. Jeg har overvejet lidt at lade IHC anlægget og de fugtfølere jeg har der, styre den brugervalg funktion. Men jeg ved ikke helt om det er en god ide, fremfor en manual måde. Anyway - det var som sagt ren nysgerrighed med det VOC, fordi jeg ikke havde hørt om det før, samt at jeg kunne læse mig til, at det vist ikke er det man skal ligge vågen om natten for.

Mja.. Jeg er ikke helt enig med dig i dette. Det er faktisk blevet enormt mere vanskeligt bla fordi folk efterhånden, (langt om længe) er blevet klar over anti-virus og firewall, (sidstnævnt er dog bare endnu en slags "app" for mindre vidende). Oven i det er der efterhånden lige en router man også skal slås med, selvom den som udgangspunkt nok er åben som en si for trafik indefra og ud. Selvfølgelig er en ani-virus ingen garanti. Tværtimod kan den vise sig at være skidt. Anti-virus kommer altid i 2. række, da det ikke er muligt at opdage noget man ikke kender til. Jeg er dog som udgangspunkt enig med dig i, at man skal virkelig være varsom med "cloud" baseret løsninger, der operere direkte ind i hjemmet, specielt hvis man har alarm funktioner på sin installation.

Tja.. Det er humlebi effekten. Lk siger den ikke kan. Men den gør det alligevel. Jeg ved ikke hvem det siger mest om, humlebien eller LK

Du skal bruge det brugernavn som tillader tilgangen til controlleren. Altså en admin bruger på controlleren.

Jeg kan godt læse det du skriver, Lars. Men jeg forstår ikke hvorfor det er 1. prioritet i Evinds opsætning. Når det dels: 1. Ikke er skadeligt (under normale forhold). Og i øvrigt er relativ parallel med temperatur og dermed fugt. 2. Afhjælpes vha udluftning, præcis som Co2 og fugt. Jeg er lidt i tvivl om Ejvind havde en Co2 føler i forvejen. Men jeg forstod at han i hvert fald havde en fugtsensor i anlægget. Ved at styre det via fugt, (evt Co2) så vil afhjælpningen af disse automatisk få VOC niveaet ned samtidig. Selvfølgelig kan man argumentere for, at fx ved madlavning, der vil VOC stige, mens fugt og co2 nok ikke nødvendigvis vil ændre sig ret meget, (det tror jeg nu alligevel det gør, hvis man har en emhætte. Eller i bedste fald stiger VOC ikke tilnærmelsesvis så meget, når man har en emhætte). Men det virker lidt uforståligt, for mig, at han ligefrem tilføjer en sensore i systemet, som skal måle noget, der dels ikke er skadeligt, (under normale forhold), og dernæst er relativ nemt at få niveauet ned på, ja faktisk så nemt, så det sker helt automatisk ved udluftning.. Men det er nok bare mig der ikke helt forstår det.

Hvorfor overhovedet måle for VOC ? Jeg kendte det ikke førend jeg læste dit indlæg, så jeg har lige kort googlede det. Som jeg forstår det, så er det dels ikke skadeligt, under normale forhold. Og dernæst så formindskes niveauet ved udluftning, hvilket giver god mening som du bruger det. Men hvis du nok havde udgangspunkt i CO2 eller fugt, som jeg forstår kan være langt mere skadeligt, så ville du jo også ende ud med at skulle udlufte der alligevel. Og vupti, så har du automatisk nedsat VOC niveauet. Som sagt, jeg Googlede det kun ganske kort, så måske der kan ligge andre ting til grunde. Men Wikipedia og sundhed.dk er ret enige om at VOC, under normale forhold, ikke er skadelige. https://en.wikipedia.org/wiki/Volatile_organic_compound https://www.sundhed.dk/borger/patienthaandbogen/sundhedsoplysning/indeklima/flygtige-organiske-forbindelser-og-indeklima/

Det er HW 6.2éren også. Det skyldes garanteret firmware 2.8.4

Det gælder ikke for ø80 Uni dimmere. De kan linkes uden belastning.

Der skal en driver/trafo på, og den skal være dæmpbar. Nogle af de LED bånd, de kræver fast spænding og variable strøm (modstand er det nok), mens andre køre med variable spænding. Driver/trafo skal være dæmpbar.

Alt er vinget af hos mig. Mener dog ikke det er sceneview som er afgørende, for det virkede også på min gamle HW 6.1 controller uden viewer. Men hvis du har alt vinget af, så er det ikke problemet. Port 443 står controlleren vist til som standard. Så hvis du ikke har ændret det, så er det den du skal lave portforward på.. Er det i øvrigt ikke også dig der skriver i Ubiquiti gruppen netop omkring hvordan man portforwarder på en Edge router? Måske det er det der driller.

Name: Giv den et navn LAN Host: Lokal IP nummer WAN Host: Dit eksterne IP nummer:port User name: brugernavn du har i din controller Password: password til ovenstående brugernavn Always use WAN: den har jeg sat til ON Controller without viewer: OFF, fordi jeg har en med viewer. Husk at aktivere det i din controller også, under administrator.

Der er et ordsprog der siger, "if it aint broken, dont try fix it". På den led kan man godt beholde den gamle man allerede har. I hvert fald så længe man stadigvæk kan "servicere" den. Og det er så her du ryger ind i problemer med ThermIHC. Det er en udfordring i dag at bare finde en maskine/interface, så du kan få forbindelse til den. Personligt ville jeg ikke døje med den udfordring, hvis det var mig. Stop en halv! Der er flere årsager til, at folk har skiftet. 1. Nogle skifter, bare fordi - Vel nok lidt ala samme årsag, som folk skifter smartphone. Dvs nye funktioner betyder ikke så meget. Det skal bare være den nyeste. 2. Nogle skifter fordi de måske, ligesom dig, er nået til et tidspunkt, hvor de ikke længere kan servicere den model de har, fordi det kræver noget besværligt værktøj (maskine/interface), som er udgået for flere årtier siden. 3. Og lige præcis med den nye (HW 7) controller, der har du et ganske særligt scenarie: IOS11 og ny firmware (2.8.4) set i kontrast til intet-nyt i den nye controller problematikken. Jeg har indikeret det enddog ganske tydeligt tidligere. Jeg mener seriøst man snildt kan få den tanke, at LK/Schneider har en skjult dagsorden i det hele her cirkus med den nye controller, som faktisk ikke rigtig rummer noget særligt nyt, og så opdatering af Apple´s IOS. Og endnu værre er det at se, at Lk/Schneider direkte skriver, at HW 6.1 ikke understøtter IOS 11, når det nu viser sig, at det ikke er korrekt, fordi man faktisk godt kan lægge firmware 2.8.4 på en HW 6.1 controller. Jeg er ret overbevist om, at der er flere Visual 2 brugere (dvs både HW 6.1 og HW 6.2) som mere eller mindre har følt sig presset til at købe den nye controller, fordi LK siger HW 6.1 ikke virker med IOS 11, og HW 6.2 controllerne skal opdateres. Folk som har brugt LK´s IOS apps har mærket det direkte, hvis de har kørt med ældre firmware. Og hele opdateringsprocessen for HW 6.2 er besværligt gjort (som altid) med tonsvis af Java problemer. Hvis du ser tilbage på de sidste 2-3 måneders indlæg, så vil du se en eksplodering i antallet af indlæg, fra folk som er røget ind i problemer (Java) i forbindelse med opdatering af firmwaren og/eller tilgang til controlleren generelt. Og det er ikke kun her på forumet, men nærmest over alt det er væltet ind med problemer. Jeg vil også tro er er mange firmaer/elektrikere som har samme problemer, og så måske kontaktet LK for at høre hvad de skal gøre. Hvis der har været tale om en HW 6.1, så har LK sandsynligvis svaret, at de skal købe en ny controller, (pga deres udmelding om IOS 11 og HW 6.1). Med 6.2 controller har LK muligvis guidet folk igennem processen med at opdatere. Og den process gider man bare ikke gentage hvergang, hvis man er elektriker og arbejder for kunder med controlleren. Så har man måske tendens til at anbefale, at man ganske enkelt skifter controlleren, så man slipper for det fremtidige bøvl (hvilket i øvrigt ikke er en sikkerhed med den nye). Dette er de tre årsager jeg umiddelbart kan komme på, hvorfor folk skifter en i forvejen fungerende installation/controller.

one.com bruger ikke 587. De bruger 465 og 992, synes jeg at jeg så i deres opsætning til mail klienter. Det burde virke med port 465. Men du er vist ikke den eneste der fornylig har haft problemer med one.com. Måske de har ændret noget. DNS adressen skal du passe lidt på med. Jeg tror der er en fejl i 2.8.4, for jeg fik melding om DNS fejl, (i service view), da jeg satte controlleren op til Google´s 8.8.8.8 som sekundær DNS. Det burde ikke ske. Jeg gad ikke rode videre med det, så bruger kun primær nu. Og så har controlleren selv indsat "local" sekundær DNS. Dvs til 127.0.0.1 (hvilket ikke giver meget mening). Du bør bruge din router´s IP nummer på primær DNS. I langt de fleste routere går det bedre.