Kandersen

Har du/I konstateret problemer med trykket. Eller er det for at bruge udelukkelsesmetoden du har byttet rundt på det? Jeg ville nok starte med at bruge Serviceview og logge udgangen evt samme med trykket. Som Henning også er inde på, så er det samtidig vigtigt at vide, om der evt er en pir tændning. Det vil programmet lyn hurtigt afspejle. Hvis det er tilfældet, så er der flere steder, som Henning også nævner, der kan tænde/slukke. Uanset hvad - Jeg ville starte i Serviceview.

Ja, tog lige og splittede det hele ad.. Kan godt se man selvfølgelig kan bruge afbryderskruer.. Dvs en almindelig (vandret) ramme https://www.el-grossisten.dk/ramme-63-softline-2-modul-vandret-dobbelt-hvid.html og afbryderskruer... Så er den ged barberet Ang det med lillemor får revet stik ud.. Det sker kun de steder hvor elektrikeren ikke har spist nok rygbrød og spændt griberne ordentligt

Hej @Bjarne Sørensen Det er muligt du har ret i det med dåsen ikke er air, med derimod den du linker til. Problemet er dog det samme, hvis du ser USB udtaget og enkelt 1modul stik, så skal de jo skrues fast i siderne. Dvs midt i dåsen får de jo ikke noget at skrue fast i fordi deres gribere sidder i siderne. Dem vi har i huset i dag sidder vandret. Det er det der giver problemet.

Det er helt klart også min opfattelse. Det bliver meget interessant.

Flere steder i vores hus har vi disse sidende (vandret selvfølgelig). https://www.el-grossisten.dk/fuga-stikkontakt-2-modul-2-pol-med-jord-hvid.html Jeg overvejer lidt at bygge det om et par steder, så jeg kan få en kombination af dette: https://www.el-grossisten.dk/fuga-2xusb-lader-2-1a-1-modul-hvid.html og dette https://www.el-grossisten.dk/fuga-stikkontakt-1-modul-2-pol-med-jord-hvid-796.html Men så vidt jeg kan læse, så er det ikke muligt når indmuringsdåsen er sådan en her: https://www.el-grossisten.dk/lk-fuga-air-daaser-indmuringsdaase-2-modul.html Eller kan det lade sig gøre på een eller anden måde?

Jeg tror du vil gøre dig selv en stor tjeneste ved at læse lidt mere indgående på OpenHab konceptet. Og dernæst IHC bindingen. Og så forstå, at IHC bindingen blot er en enhed ("Thing") i OpenHab2, som grundet den måde bindingen er lavet på, skal tilføjes manuelt til OpenHab2. Men såen lidt kort. Når OpenHab2 har forbindelse til IHC controlleren, så "henter" den som sådan ikke projektfilen i noget der e læsebart/brugbart for os. Den "henter" den til intern process. Så når du fx har opsat en items i din OpenHab2, som skal tænde noget lys i din IHC installation. Så angiver du hvilken item (enhed) der skal påvirke hvilken IHC enhed (lys). Det gør du ved at angive unikke ID for alle de ting du vil styre og/eller styre med. Dette bruger OpenHab2 IHC projektfilen til. Et banalt eksempel: Du har et lys (udgang) i din IHC installation som har et unikt ID nummer. Det fortæller du OpenHab2. Dernæst har du en kontakt (IKKE en IHC kontakt), fx en z-wave kontakt. Denne har ligeledes en unik ID, som OpenHab2 i det fleste tilfælde selv vil finde ud af. Kunsten er så at fortælle Openhab2, at når du trykker på z-wave kontakten, så skal den sende en ON til lyset i din IHC installation. (Dette hedder en rule i OpenHab2). Jeg vil gerne lige understrege. Det giver INGEN mening at styre IHC lys fra en IHC kontakt via OpenHab2. Man kan godt gøre det, og det er set før, at der er nogen der synes det er sjovt, eller de har gjort det som test. Men det er formålsløst og unødigt. Samt at det i øvrig oftest betyder at man skal ind og ændre IHC programmeringen i Visual, for at tilpasse det så det virker. Personligt synes jeg det er en mystisk måde at gøre det på, også selv som test. Mit formål med Openhab2 er primært, at lade "udefra kommende påvirkninger" gå ind og påvirke IHC installationen. Fx derfor er jeg meget fokuseret i brugen af sensorer. Jeg kan koncentrere mig om disse og OpenHab2, og nærmest helt undlade at pille i IHC programmeringen. Hvis jeg en dag dropper OpenHab2, så er der selvfølgelig ting som ikke virker. Men som udgangspunkt virker IHC installationen som den hele tiden har gjort. Sekundær formål med Openhab2 er overvågning og integrering i et visuelt samlet miljø. Når/hvis dette lader sig gøre en dag (det er en tung process), så skulle jeg gerne ende ud i en eller anden form for visuel overblik over det hele. En slags IHCtable/Viewer, inkl alt andet som er tilkoblet OpenHab2. Z-wave har jeg bevist fungere fint. Til dels også Zigbee, (Philips Hue, i både IHC Captain og OpenHab2). Mit næste punkt at få Nilan ventilations anlægget integreret i OpenHab2. Det håber jeg sker i løbet af næste uge. Og sådan kan jeg blive ved med at tilføje muligheder til OpenHab2, og ganske enkelt overvåge og/eller lade dem påvirke forskellige ting i installationen, inkl i IHC delen, som i bund og grund bare er endnu en enhed til OpenHab2.

Til gengæld skal du ikke forvente en levetid (teknisk levetid) på mere end end 2-4 år. Dit gamle 21" til 10.000 var sandsynligvis ikke til at slå ihjel, og der var ikke en masse software opdateringer osv, som der skal tiden skal vedligeholdes.

Yep kan vi godt finde ud af.

Det er IHC controllerens IP adresse du skal skrive ind i den ihc.cfg. IHC controlleren har KUN en lokal IP adresse, (teoretisk set kan du godt have sat den direkte til internettet, men det tvivler jeg stærkt på). 777 er min IHC controllers port opsætning. Jeg ved ikke hvad din IHC controller er sat op til, det kan du se i IHC administrator. Har du ikke ændret porten, så er den nok 443.

Korrekt. Tænder jeg manuelt på IHC trykket, så er det ikke altid at alle lamper i gruppen (Rum) tænder. Nej jeg har ikke valgt nogle pærer eller andet længere nede, kun 'Stuen' i rubrikken Rum/grupper. I princippet er det jo præcis det samme som IHC Captain 0.996 gjorde, hvor jeg bare sendte en action til gruppen/Rum i APIén direkte ved tryk på IHC trykket. Og det virkede klippe stabilt. Det virker også hvergang, hvis jeg bruger Hue Appén. Det er derfor jeg er noget forundret over, at det i det hele taget kan ske. Det burde ikke kunne lade sig gøre, medmindre du i den nye IHC ikke bruger gruppen (Rum). Men det tvivler jeg på, at du ikke gør, da du jo netop læser og lister Rum/Grupperne fra Hue Bridge. Tiden går det nok med. Det virker jo i det store hele. Der er bare nogle små finurligheder, der skal pudses af

Nej, du skal oprette den selv.. Altså: 1. lav en fil i mappen services. 2. kald filen for ihc.cfg 3. Åben filen i en editor og indskriv konfigurationen til din controller, som beskrevet i hjælpe teksten. Her er en kopi af min ihc.cfg fil. Hvis du bruger den, så husk at rette ip:port, brugernavn og password ihc.cfg

Det skriver min 6.1 controller også. Men det har ingen betydning for fx IHC Captain, OpenHab2 osv. Jeg ved faktisk ikke hvad LK mener med 3.part produkter der hvor de skriver det.

2. Det er sgu underligt.. Tænker lige hvordan jeg kan vise det.. Her er imellemtiden min opsætning i IHC Captain. 3 billeder fra hver opsætning af henholdsvis, Sluk/Tænd, FadeOp og FadeNed:

Hmm.. Jeg tror jeg forstår hvad du mener nu. Indgangene til magnetkontakterne er blevet tilføjet til blokken, og det er det du mener er det nye? Tkhansen´s .vis fil burde give svaret. Og når han ramler ind i problemet igen, så bør loggen indikere, hvad der aktiverede den, (sandsynligvis een af magnetkontakterne). Men de kan vel ikke tilføjes forkert, og stadigvæk have den rette funktion, eller?

Nej, det fandt jeg så ud af på den hårde måde 2. Jeg synes også det ser vildt underligt ud. Som jeg skrev, så prøv at hold øje med faderen i Hue appen, samtidig med du trykker på IHC trykket. Een ting er at der er forsinkelse. Men at den ligefrem kan finde på at fade modsat når man har sluppet trykket, det er vildt underligt. 3. Det ER mystisk. Og som sagt, så burde det slet ikke kunne lade sig gøre, hvis/når du aktivere gruppen/rummet i APIén. Så skal alle tilmeldte lamper jo reagere ens. Det er derfor jeg fatter nada af det.

Men det nye er jo ikke magnetkontakterne. Det "nye" er at Torben fandt ud af, at det er dem der logger "ingen log". Og nu har han tilføjet log teksten korrekt for hver kontakt. Det er det nye. Selve magnetkontakterne er ikke nye. Det bør ende ud i, at Tkhansen næsten gang kan se, præcis hvilke(n) kontakt der udløste den "halve" alarm. Men det forklarer ikke, hvordan den kan udløse en "halv" alarm. Og det er den del jeg synes er mest interessant og som jeg venter meget spændt på.

Du kan godt få screenshot i aften når jeg kommer hjem.. Men det er sat op som skrevet herover 100% identisk med din beskrivelse. Eneste forskel er, at jeg valgte ´stuen´ under punktet Rum/Grupper, da min stue er oprettet som Rum i Hue opsætningen (i appen). I dette rum har jeg så 4 stk Hue lamper som alle tænder ens og på samme scenarie i Hue appen. Her i denne del af opsætningen har jeg valgt min stue under Rum/Grupper, hvor du i dit eksempel har valgt Pære:

Jeg har sat det op 100% som i din anvisning. Eneste forskel er, at jeg bruger et rum med 4 lamper (samme rum). Og du har een lampe/pære med i dit eksempel. Skal du have en pære (E27 fatning) med sammen med motionsensoren?

Men Henning. Det er jo ikke det han skriver i hans første indlæg. Der skriver han netop at de har testet det ved at åbne døren. Og der kommer en "hel" alarm. Se.. Og det er før Torben ændre noget. Hvad får dig til at tro, at de er nye?

Næsten gang det sker hos mig, så skal jeg nok forsøge lave noget dokumentation på det. Men jeg ved ikke helt endnu hvordan.

En ekstra detalje jeg ikke fik skrevet i går.. Virkelig fedt med det betjeningspanel i den nye IHC Captain. Men: I mine test i går aftes, der var der ikke overensstemmelse mellem tændte HUE lamper og indikering i betjeningspanelet. Hue lamper tændt - Indikering viste slukkede. Jeg kunne slukke på knappen, men ikke tænde efterfølgende.

Det er vist forsøgt før uden at LK har villet skele til det. Såvidt jeg har forstået, så kommer de helst ikke uden for firmaets egne vægge. Og slet ikke hvis det er til eventuelle kritik.

Godt at se Torben bar denne her videre. Jeg er godt nok nysgerrig efter, hvad du kommer frem til. Jeg har en mistanke om, at du har fundet en uheldig "feature" i alarm blokken. Jeg kan simpelthen ikke få ind i mit lille hoved, hvordan noget kan udløse en "delvis" alarm som du beskriver det. Eller dvs jeg har en teori omkring reaktionstider. Hvis det er korrekt, så har funktionsblokken en decideret uhensigtmæssighed. Men lad os nu se hvad der sker, når du får en log der viser, hvad der har startet det hele.

Og det er den del som jeg mener LK burde være langt mere OBS på og tage virkelig serøst, og ikke bare smide den der standard frase afsted med "støj eller 3.-part". Det er simpelthen for nemt at blot kaste aben videre, når argumentet på ingen som helst måde er sammenhængende.

Jeg vil gerne være med på vognen her med min (ene) erfaring. Men lad mig slå fast med det samme. Jeg nægter at tro at det her (mit problem) er støj problemer. Det hænger ganske enkelt ikke sammen, primært fordi problemet opstod uden fysisk ændringen nogen steder, og det forsvandt, igen uden nogen fysisk ændringer (slukkede/tændte controlleren hvorefter alt virkede igen). Det ER/må være en eller anden form for fysisk ustabil tendens i lampeudtaget. Alene det at lyset kan forblive tændt, efter at jeg har haft fjernet 230v til udtaget og monteret det igen, og service view melder OFF. Det vidner om at der må være et eller andet som ikke er helt hensigtsmæssigt skruet sammen. Det er IKKE et fænomen som "støj" kan forårsage, efter min bedste overbevisning. Ydermere er det min opfattelse, at begrebet "støj" heller ikke kan forårsage en permanent oplevelse. Det kan/bør aller højest være noget der sker i korte perioder, medmindre man decideret har opsat en støj-kilde i området, som konstant står og "støjer", eller rettere "jammer" signalet. I mit tilfælde var der som nævnt ikke lavet nogle fysiske ændringer overhovedet, hverken før, under eller efter. Det er muligt, som Mosi er inde på, at antenne eller andet kan have en indflydelse. Men min påstand er, at det må være en indflydelse som bør resultere i, at trykket/lampeudtaget engang imellem ikke virker, fx 3 ud af hver 5. tryk på knappen. Hvis det er permanent, så er vi mere ovre i en decideret "jamming" af signalet. Og det er ikke støj. Udstyr: HW 6.2 controller med fw 2.8.4 4 stk ø80 lampudtag Hw 2.05. 4 stk Uni250 1-modul wireless dimmer. 3 stk wieless 2-tast tryk. Resten er fortrådet. Lampeudtag og Uni250 1-modul er monteret ved tavlen ca. 50cm fra controlleren/antenne, (kun et ø80 udtag har fejlet een gang. Det er dog samme udtag, som jeg tidligere har skrevet, kan være længe om at tænde for lyset 2-3 sekunder). Lampeudtaget som fejlede er tilsluttet en jernkerne trafo og 2 stk 35wat GU5.3 halogen spot. IHC captain, Openhab2. IHCRemote og IHCTablet. Z-wave og Zigbee (philipes Hue) trådløse netværk. Ubiquiti LAN og Wifi netværk med AP-UAC lite AP.