Lars1

Heldigvis er PDS standarden designet til at være lige igennem så ben 1 er altid ben 1, ligegyldigt hvordan du vender og drejer stikkene eller hvor patchninger du skal igennem for at forbinde 2 enheder. Alt krydsning sker i de aktive enheder. Hvis du bruger den metode jeg beskrev med at terminer IHC NET BASIC kablerne i dit patch panel, flytter du jo bare væg stik termineringen ud i patch panelet, og kan så patche videre derfra som i en hver anden PDS installation. Det er IMHO den bedste løsning.

Du vil ikke være den første som laver den ændring, så det kan du sagtens gøre. Isteddet for at lave patch kabler til IHC NET BASIC boksen, så terminer kablerne fra den i patch panelet. På denne måde kan du nemt patche det du har brug for, og de slipper for stive installations kabler som patch kabler.

Det var først efter vi var blevet enig om en pris og ikke kunne få kalenderne til at passe at du skrev at du ville lade annoncen være aktiv for andre bud. Jvf. vores korrespondance, så har du været bortrejst fra vi blev enig om en pris og til du igår skrev at du ville sælge til en anden. Når man aksepter et bud, kan man ikke bare sælge til en anden som byder højre senere. Det er normal pli IMHO. Jeg skriver her for at advare andre om at man ikke kan stole på de aftaler man laver med dig.

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.