Lars1
Members-
Antal indlæg
3.892 -
Medlem siden
-
Senest besøgt
-
Days Won
124
Indholdstype
Profiler
Forummer
Downloads
Galleri
Alt der er opslået af Lars1
-
Pas på med at handle med denne bruger. I kan ikke stole på de aftaler i laver med ham. Jeg afgav et bud (lavt) på hele stakken, og vi var blevet enig om en pris efter lidt forhandling frem og tilbage. Eftersom jeg jævnligt køre tæt forbi hvor han bor, aftalte vi at jeg skulle komme forbi og hente udstyret i denne weekend. Det bliver imidlertid udsat til næste weekend, og nu har jeg så lige fået en SMS om at han har fået et bedre bud og derfor sælger til den nye køber. Jeg ved godt at mit bud var lavt, og jeg ikke har lagt skjul på at jeg kun bød for at sikre mig nogle reservedele, men en aftale er vel en aftale. Det er kun lidt over en uge side vi blev enig om en pris, og han har ikke været hjemme siden, så jeg kunne hente tingene.
-
Det er længe siden jeg har rodet med linkning af wireless enheder sidst. Har du den gamle controller aktiv fortsat, og er de unlinket derfra?
-
Uden controller kan man måske bruge dette wireless input modul http://www1.lk.dk/servlet/context?n1=14&n2=23&n3=2462&n4=2537 Det kræver fortsat potentialfrie kontakt sæt på Sonoff relæerne, men man kan muligvis undvære IHC controlleren alt efter hvor komplex styring man vil lave. Det er ikke en løsning jeg personligt vil gå efter, men det skyldes mere at jeg har svært ved at se hvorfor man overhovedet vil brug IHC wireless i standalone, med mindre det er for at lave et par enkelte ændringer som ellers ville kræve rillefræsning m.m.
-
Hvis du har gulvvarme i badeværelset bør du helt klart have en temp. sensor med gulv føler. Hvis ventilations anlægget selv kan reguler op og ned afhængig af fugt niveau, har det sikkert sin egen fugt sensor i udsugningen. Dertil kommer at LK's fugt sensor næppe kan kommuniker med dit ventilations anlæg, og LK's Nilan integration indeholder ikke noget som reager på fugt. Sidst men ikke mindst. Der findes desværre ikke en LK temp sensor med gulvføler og fugt sensor. Så hvis du har behov for begge skal du have 2 temp. sensor.
-
Har du prøvet at resette dine wireless enheder, jvf. den medfølgende villedning, før du linker? Og så er du selvfølgelig opmærksom på at de fleste gamle wireless enheder kræver mindst 5W belastning for at kunne linke. En spare pære eller LED er ofte ikke nok.
-
Umiddelbart ser de ud til at være potential frie, men du er nød til at checke dokumentationen for at være sikker. Værd iøvrigt også opmærksom på at sålænge en IHC indgang er sluttet, så trækker den strøm. 3mA hvis det er et 24/3 input modul og 24mA hvis det er et 24/24 input modul. Ved 24V er det 0,72W eller 5,76W.
-
Er indikering af alarm - Røg forbundet til andre produkter/FB'er?
-
Hvis Sonoff relæerne har et potentialt frit kontakt sæt bør det ikke være noget problem. Hvis ikke skal du have overdragelses relæer mellem IHC input modulerne og Sonoff relæerne.
-
Tja. Der er vi jo så forskellige. Jeg vil fortrække at være hjemme, så jeg kan forsøge at slukke branden inden den æder hele huset.
-
Den udgang på alarm FB'en, som trikker e-mail'en er det den samme som tænder lyset og starter sirenen og sender entry til alarm loggen? Hvis ikke, er den udgang så linket til andet, som kunne være skyld i at der bliver sendt en alarm mail?
-
Der findes såvidt jeg husker ingen firmware 2.7.349, men der findes en Visual version 2.7.349. Der er firmware versionen i controlleren som er vigtig. Den finder du via adminview.
-
Du reager på et indlæg fra 2007. At linket ikke længere virker er vel meget naturligt.
-
Hvilken firmware version ligger der i controlleren? Det skal mindst være 2.7.220 såvidt jeg husker, ellers er fugt sensor ikke understøttet. Hvis det er den version, så prøv at genstarte controlleren inden du uploader programmet.
-
Hvis den anden FB ikke løser dit problem, kan du bare linke rum temperaturen på din temp. sensor til gulv temperaturen på FB'en og vælge gulv styring i FB'en.
-
Jeg kunne ikke lige finde et bedre fora til dette indlæg, så skyd mig ikke hvis mener indlægget er malplaceret. Dette er et rigtig godt eksempel på hvorfor cloud services er en rigtig dårlig ide til IHC installationer. https://www.dr.dk/nyheder/indland/danmarks-stoerste-sikkerhedsfirma-oplever-teknisk-nedbrud Det er IMHO ret grotesk at man ikke engang kan slå alarmen fra hvis forbindelsen til cloud servicen er nede.
-
Med den forklaring så bør du kunne se ændring i lysstyrken på lampeudtags produktet i serviceview, hvad enten lysstyrken rent faktisk ændre sig eller ej. Lys indikation tror jeg ikke du kan sætte via openhab. Den kommer fra de fysiske lampeudtag, og hvis din controller ikke kan kommuniker med lampeudtaget, vil lys indikationen ikke ændre sig selvom du sætter lysstyrken til 0% via FB'en eller openhab. I det mindste er det sådan jeg husker det da jeg sidst legede med de wireless dimmer. Det er relativt nemt at test. Prøv at sætte lysstyrken til f.eks. 50%, fjern strømmen til lampeudtaget, og prøv så at sætte lysstyrken til 0% og se hvad der sker. Når du tilslutter stømmen til lampe udtaget igen, så vil det tænde på de 50%, og du vil ikke se nogen ændring i serviceview før du selv ændre på lysstyrken. Lampe udtagne husker desværre det niveau de havde da strømmen røg, og der sker ingen tilbage melding når strømmen kommer tilbage. Det har snyt mig et par gange når der var gået en pære. Det sker selvfølgelig ALTID når de er tændt
-
Det kan kalenderen ikke tage højde for, men igen med kalenderen har du op til 80 dage om året hvor du på forhånd kan forudsige unormal døgnrythme, og der med på forhånd tilpasse husets tilstand, mens du uden kalenderen vil have 80 dage hvor du vil have en forsinket tilpassning af husets tilstand.
-
Blinker den blå diode på controlleren når du ændre på lysstyrken? Jeg ved godt hvordan man finder ID'erne, men det fortælle mig fortsat ikke hvordan openhab styre lyset.
-
Well. Alt efter hvornår helligdagene falder har du mellem 10 og 15 helligdage som falder på en hverdag. Læg dertil 5-6 ugers ferie. så ender du pludselig på 40-50 dage om året, som giver en unormal døgn rythme. Har du børn i skole alderen er der yderlig op til 30 dage. Alle samme dage som med fordel kan lægge i en kalender, så man kan forudsige unormal døgn rythme.
-
Jeg må indrømme at jeg kan ikke følge dine tests. Når du skriver at lampeudtaget bliver påvirket, er det så at lyset ændret sig, eller at du i service view kan se at lys styrken ændre sig i lampeudtags produktet? Nu bruger jeg ikke openhab, så jeg ved ikke hvordan den styre lampeudtag m.m. Men det ændre ikke ved at du via serviceview kan styre lampeudtaget manuelt og direkte uden brug af FB'en, men når du gør dette sker der en tilbage melding til FB. Hvis du f.eks. går fra 50% til 0%, så går lys indikering off. Om lysniveauet også bliver sendt tilbage til FB'en er jeg i tvivl om. Jeg bruger fortsat de gamle touch FB'er.
-
Så du vil heller have 20 dage om året som ikke passer med din døgn rythme end 1 dag som ikke passer?
-
Dette er jeg ikke enig. Den "kalender" funktion som findes i LK IHC idag er knap 20 år gammel. Den stammer fra en tid hvor time managers i fysisk form var mere normal en en online kalender på en computer eller en telefon. På det tidspunkt var LK IHC langt foran hvad mange kunne forstillig sig at bruge det til, men som med så meget andet i LK IHC har udviklingen desværre stået stille, så de idag er håbløst bagefter. En ægte nørd bliver aldrig færdig med at videre udvikle på sin IHC installation. Kalenderen bliver IMHO aldrig overflødig. Den skal som Lars Jakobson beskriver jo netop bruges til proaktivt at forudsige unormal opførsel, fremfor dit setup, som reaktivt reager på unormal opførsel. Med en kalender kan du f.eks. forudsige at det er helligdag i morgen, og derfor går du senere seng idag og står senere op i morgen. Natsænkningen kan dermed tilpasses dette. Det er lidt kedeligt først at hæve temperaturen i huset når du står op. Specielt på hverdage vil du ikke få gavn af den hævede temperatur før du tager afsted på arbejde, og så er det tid for at sænke temperaturen igen.
-
Jeg har muligvis overset noget, men såvidt jeg kan se så må jeg sige nej. I det senario hvor en påvirkning af trykket, ikke får lyset til at ændre sig har du ikke været nede og kigge på detaljerne, som om trykket når til FB'etc. Du har genbrugt konklusionerne fra det senario, hvor en påvirkning af trykket får lyset til at ændre sig, men eftersom slut resultet her er forskelligt, kan du ikke bare assume at det som virkede før også virker her. Som jeg plejre at sige til de IT arkitekter jeg har til at arbejde for mig på div. projekter. Assumptions are the mother of all f...ups. Der er ikke nødvendigvis tale om 2 fejl. Når du påvirker et lampeudtag direkte via serviceview, sker der en tilbagemelding til FB'en, og denne tilbagemelding kan ændre på hvordan FB'en reager når du næste gang påvirker trykket.
-
Hvis du ikke går systematisk frem og checker hvert led i kæden et efter et, så vil du lede efter en nål i en stor høstak. Det er meget nemmer at finde nålen hvis du kan fjerne halvdelen af hø stakken. Prøv at tænke på en juletræs kæde. Her sidder pærene i serie, og hvis en af dem springer holder hele kæden op med at lyse. Hvis du prøver at skifte dem en efter en, og gør dette ustruktureret tager det lang tid før du finder den som er sprunget. Hvis du der imod fjerner den miderster først, og måler om der er gennemgang fra midten og til stikket, kan du hurtigt udelukke halvdelen af lyskæden som en mulig fejl kilde. Herefter tager du igen den miderste pære i den halvdel som er fejl ramt. Sådan fortsætter du til du har lokaliseret den pære som er sprunget. Ved en lyskæde med 100 pære kan du finde den defekte pære med 7 tests eller mindre. Ved fejlsøgning er det mindst ligeså vigtigt at dokumenter hvad virker, som at dokumenter hvad ikke virker. Problemet med din fejlsøgnings metode er at dine tests kan påvirke resultatet af den næste test, fordi et flag i FB'en kan ændre sig selvom lyset ikke ændre sig. Tænk bare på alle de cases der har været hvor nogen har undret sig over at de skulle trykke 2 gange på en afbr. for at lyset tænder eller slukker. Samtlige jeg kan huske skyldes at første tryk bringer FB'en i sync med lyset, hvorefter andet tryk udføre den handling man forventede første tryk ville udføre.
-
Har du prøvet at kigge på LK's normale varmestyrings FB's? De har alle alarm for høj gulv temperatur såvidt jeg husker.

