Kandersen

Jeg er fuldstændig enig med Henning her. Desværre er min opfattelse, at rigtig mange ny-byggere må lide af, at dem som bygger, (entreprenør/elektriker), at det er dem der sætter begrænsningerne. Personligt ville jeg aldrig nogensinde acceptere sådan en situation, når man står foran et million-byggeri, som gerne skulle være ens hjem i rigtig mange år ude i fremtiden. Det næste er så, at mange ny-byggere lader sig skræmme af noget de mener er høje priser. (Det gælder desværre også entreprenører/elektrikere, som jeg har hørt nærmest direkte advarde imod fx IHC, fordi de mener det er en meget høj pris). Det er selvfølgelig en individuel vurderingsag, men det virker lidt omsonst at have fokus på et smarthjem, og så blive skræmt af priser, der samlet set ligger omkring 5% af hele byggeriet. Og man skal, igen, aldrig lade andre forsøge præge ens eget forhold, bare fordi en tåbelig elektriker mener IHC (eksempelvis) er dyrt. Hvis elektrikeren mener at fx IHC er dyrt, så lad ham komme med et alternativ, som KAN DET SAMME, men som er billigere. (Mit bud, der kommer en larmende tavshed). Og så er der min sidste efterhånden "mærke-sag". Pas på med at lægge sig fast på et grundsystem som låser det fast. Her er jeg desværre nødt til at gå lidt på kompromis med ovenstående. Selvom jeg synes IHC er vanvittig godt, så har man desværre også en tendens til at lade sig låse fast i Fuga materiel i form af brugen af dåser. Det er en fatal fejl i dag, efter min mening. Gå efter EU materiel, så åbner der sig en verden der er langt fra begrænset på samme måde. Mange siger at Fuga er godt fordi det er småt og diskret. Og det er jeg bestemt ikke uenig i. Men man skal ikke negligere den negative side af sagen, at man dermed også har sat sine begrænsninger, hvis man fx en dag vil ud og lave det hele om til et andet system. Det er LK som har fejlen. De burde løse det. Men det er forbrugeren som må leve med valget. Og det kan koste enormt dyrt, at vælge forkert.

Sådan!

Jeg nåede ikke at kigge på det i går. Men at Henning kigger på det og kommentere, så kan du ikke ønske dig bedre hjælpe

Kigger på det senere. Men bliver mere og mere overbevist om, at det er programmeringen

Ja og nej. Du kan ikke få tilbagemelding fra selve dimmeren. Men ved brug af den rette funktionsblok, så kan du få tilbagemeldingen fra den. Det vil stort set altid virke, undtagen hvis funktionsblokken går ud af sync med dimmeren. (det er en potentiel risiko, som jeg aldrig selv har oplevet). Ja, for det er i realiteten sådan dimmeren virker. Den er "snot dum" for at sige det mildt. Så det eneste den kan, det er at toggle. Og derfor kan man lige så godt bruge en KIP blok til at styre sådan en med, som man kan bruge den fortrådet dimmer blok, hvis man bare skal tænde/slukke. Forskellen er, at den fortrådet dimmer funktionsblok bruger langt tryk til at regulere op/ned, (kan man så vidt jeg husker ikke med en KIP blok). Og her kan man indstille threshold for trykket. Og så har den fortrådet dimmer funktionsblok en status på om blokken er tændt/slukket, som nævnt herover. Der er meget lidt magi i en dimmerblok, men derimod ren logik

Jeg havde ikke troet det. Men jeg kan godt mærke, jeg orker ikke lige at tænke på årsagen, når bare det virker

Hvis du flytter dataledningen til et andet modul, så skal du også lave om i programmeringen. Så det kan jeg ikke anbefale, ihvertfald ikke i første omgang.. Hvis det ikke virker efter et tomt program, så er der kun een mulighed tilbage for at kunne hjælpe, og det er at vi kan se programmet.

Hmm. Er det et problem som lige er opstået, af sig selv? Hvilken version af controller er det? Et forsøg: Upload et tomt projekt til din controller (husk at tage en kopi af kørende projekt først). Og derefter dit kørende projekt.

Jeg skal lige forsøge følge med her. Du har en stikkontakt på et 230volt output modul. Du har ydermere et tryk med diode, hvor dioden tænder, når stikkontakten tænder. Er det korrekt forstået? Dit problem er så, at dioden ikke slukker, selvom stikkontakten (230volt output modulet) slukker? Er det korrekt forstået? Måske er det en simpel programmeringsfejl, selvom det lyder som om det skulle være lige til med en KIP blok. Så en ide kunne være at lægge screendump op af Visual programmet for de(n) funktionsblokke der er i spil her. At serviceview ikke registrere output modulet (24volt formoder jeg) slukker, det kan jo godt være korrekt, hvis programmeringen er forkert. Så inden du river det hele fra hinanden, er det måske værd at få kaste et ekstra par øjne på programmeringen

Har aldrig oplevet dette selv. Men det virker på mig som om, at noget programmering måske hænger i controlleren. Umiddelbart bør det jo slet ikke kunne lade sig gøre. Hvilket output modul er det?

Er der andre med UNi250 (1-modul) eller Kombidæmpere som har erfaret, at efter at have kørt en del måneder, så kan de pludselig blive 3-4 sekunder om at reagere (tænde/slukke lyset)? Jeg erfarede det netop med 1 stk UNI250 og 2 stk Kombi dæmpere. Jeg har tidligere erfaret det samme "fænomen" med en anden UNI250 dæmper. Dengang valgte jeg at tage den helt ud af installationen og erstatte den med en anden. Men nu har jeg netop haft samme problem med 3 andre. I stedet for at tage dem ud af installationen, så prøvede jeg i stedet at se, om jeg kunne løse problemet på anden vis. Normalt ville jeg være gået på loftet og slukket det hele (controller og dæmpere), og det har tidligere været en løsning. Men denne gang valgte i stedet at bruge Visual. Jeg opladede et tomt projekt i Visual til controlleren - Ventede nogle minutter, hvorefter jeg oploadede det rigtige projekt. Det lader til at have løst problemet, da dæmperne nu reagere med det samme.

Altså jeg vil sige det sådan. At så længe du kan styre det i serviceview på input, så burde openhab også. Som du selv så tidligere, så gør openhab ikke noget anderledes end hvis du selv stod med fingeren på knappen. Så det er mig en total gåde, hvorfor det ikke virker. Jeg har ikke den fjerneste ide. Er du helt sikker på at din knap ikke slukker på anden vis, end via touch input på funktionsblokken? Her skal du kigge i højre side i Visual, på det tryk du bruger til at tænde/slukke med.

Husk der er forskel på udgange og indgange Udgangene bruges til vinduer, som fx ikke er fjernstyret. (de fjernstyret kommer automatisk ind i KLFén via fjernbetjeningen, fx via KLR200 (den med touch display)). Indgangene bruges til de fysisk tryk du vil styre vinduerne i KLFén fra (uanset om de er fjernstyret eller ej).

Der var lige noget der slog mig.. Kan du tænde/slukke lyset fra Serviceview, hvis du stiller den på input siden i funktionsblokken (den samme som du har linket resourceID fra). Og så bruger spacebar på tastaturet til at tænde/slukke med?

Det tvivler jeg stærkt på. Openhab gør jo som den skal, som de ses ud af servicevieweren.

Det er sgu underligt.. openhab gør fuldstændig som den skal og forventet, og fuldstændig som hvis du bruger knappen. Og alligevel slukker den ikke.. Mit bedste bud er, at når lyset er tændt (dvs funktionsblokken i realiteten er tændt), så skal den have en længere puls for at slukke. (længere end 3-400ms). Jeg ved ikke om du kan skifte til den samme funktionsblok som jeg bruger, for du har også noget specielt med udgang til sluk af 230volt, (som jeg ikke lige kan gennemskue hvad er til). Men det kunne være interessant at se, om du kan få det til at virke med funktionsblok 1.2.02b eller tilsvarende (fortrådet dæmper) i din controller. Ellers må jeg erkende, jeg er totalt blank på hvad det er der går galt. Men det er tydeligt, at det er i funktionsblokken/IHC programmet, at der er noget der ikke virker som det bør gøre.

Skift af firmwaren ændre ikke noget. Der må være noget galt med din type switch.. Helt konkret sker der det, når du switch med pulsewidth: Når du tænder fx i openhab, så sender bindingen en ON til den resourceID som du har linket til. Fordi det er en PulseWidth type, så sender bindingen automatisk en OFF x-antal ms efter. På den måde laver/simulere den et egentligt tryk, ligesom hvis du selv trykkede på knappen. Det er derfor det er vigtig at bruge en PulseWidth switch til fx en KIP funktionsblok eller fortrådet dæmper blok. Så lige nu er jeg lidt blank på, hvorfor det ikke virker for dig. Et værktøj der kan bruges til at se hvad der sker, det er ServiceView. Hvis du starter den, og så går ind og logger det indput du har bruge som resourceID, så burde du kunne se, at det er det bindingen gør. Hvis ikke der sker det forventet, så burde du også kunne se, hvorfor.

Nu bliver jeg lidt nysgerrig.. Hvordan tænder og slukker du normalt for lyset? Er det med to forskellige tryk? Nej det virker vistnok kun med UNI dæmperne.

Det kan du ikke i items. Det skal ske i channel. Du kan editere din channel i PaperUI, og der vil du finde noget der hedder PulseWidth. Som tidligere skrevet, så laver jeg det hele manuelt. Her er fx hvordan mine channels (things) ser ud: Type switch :bryggers_dimmer_fb "Bryggers dimmer Trigger" [ resourceId=12059409, direction="WriteOnly", pulseWidth=100 ] Type switch :bryggers_dimmer_state "Bryggers dimmer state" [ resourceId=12062482, direction="ReadOnly" ] Jeg bruger en standard fortrådet dæmper funktionsblok i Visual. Og her er hvordan disse ovenstående to switches er linket til resourceID: Her er mine items for den: Switch bryggers_DimmerLys "Loftlys i Bryggerset [%s]" <cu_spot> (vLys) [ "Lighting" ] { channel="ihc:controller:elko:bryggers_dimmer_fb", channel="ihc:controller:elko:bryggers_dimmer_state", autoupdate="false" } Bemærk, begge channels indgår i denne ene items. Det er fordi jeg henter state fra funktionerblokken. Så når dæmperen er tændt, så vil den vise ON i openhab. Dæmperen er en UNI400 dæmper.

Rart at vide - Det andet lød også lidt for idiotisk til at være sandt, at det skulle forblive sådan

Nej ikke helt. Indgangene har ikke noget med stemmestyringen at gøre. Du skal skelne mellem indgangene. Der er de 5 til de fysiske tryk, og så er der mulighed for at styre KLFén via netværk (ethernet). Stemmestyringen kommer via openhab. Openhab er forbundet til KLF200 via netværk. Dvs kommandoen fra min stemme bliver omsat i openhab, og sendt direkte til KLFén. Indgangene på KLFén har noget at gøre med, hvor mange fysisk tryk/relæer du kan koble på. KLFén i sig selv kan styre 32 enheder, (så vidt jeg husker). Så hvis du har fyldt op, så kan du fx have 32 vinduer, som du kan styre manuelt via 5 tryk/relæer. Hvordan du så vælger at gruppere dem, det afgøre du inde i KLFén´s software. Når man bruger ethernet interfacet, så er det lidt anderledes. KLFén kan statdigvæk styre 32 enheder. Men via netværket er det det som er koblet på, der afgøre hvordan. En switch i openhab kan jeg sagtens sætte til at køre alle 32 vinduer, eller bare et af vinduerne. Eller jeg kan lave 32, 50 eller 500 switches i openhab, som styre hver deres vindue individuelt. Her er det ren software baseret, så er der ikke den samme fysisk begrænsning. Det burde som nævnt også virke. Jeg kan bare ikke finde årsagen til, at det ikke gør.

Ja det burde det kunne. Hvis du linker din switch item til resourceID på inputsiden i din funktionsblok, så burde switchen tænde og slukke. (Husk det med at sæt tiden ned fx til 200ms. Jeg kan ikke huske om du kan gøre det i PaperUI).

Han kan sagtens bruge de dæmpere i openhab, og specielt hvis han bare vil tænde og slukke. Deres funktion er ikke anderledes UNI400 dæmperne.

Ikke sådan som du mangler det. Der er det desværre indforstået. Ja, vi er et skridt videre. Det er ihvertfald ikke en nyere wireless med tilbagemelding på, som kan styres procentvis. Det er god information, men også lidt skidt information i forbindelse med openhab. Du har to mulighed i openhab: 1. Oprette switch items til den resourceID som svare til det IHC tryk du bruger til at tænde/slukke dit lys med, og sæt tiden ned til fx 200ms eller 300ms. Det løser i mange tilfælde dit problem. Men du kan komme ud for, at openhab "holder" lige en anelse længere på trykket, så dæmperen i stedet begynder at skrue op/ned. Bortset fra denne del, så har du ingen mulighed for at få tilbagemelding fra dimmeren. Dvs i openhab kan du ikke se om lyset er tændt/slukket. 2. Vi skal se lidt på, hvilken funktionsblok du bruger i IHC programmet (dvs et screendump af højreside i Visual, hvor du har funktionsblokken åben). Der kan du også finde resourceID for tænd, men afhængig af funktionsblok, så kan du også finde en mulighed for at få tilbagemelding om funktionsblokken er tændt (det er værd at bemærke, det er IKKE om dæmperen er tændt. Men de vil følge hinanden). Mit bud er du bruger en fortrådet dimmer funktionsblok. Alternativ er det en kip blok med hold, (hvis den eksistere, men jeg tror det ikke). Ulempen ved denne metode er, at du i openhab er nødt til at lave den switch-channel manuelt. Det er forholdsvis simpelt, hvis man holder hovedet lidt kold og tager sig tiden til at forstå ideen med det.

Jeg har ikke rigtig haft tid til at bore så meget i det. Jeg tror det er Google eller måden jeg siger det på når det er vinduer. Men som sagt så giver det ikke mening, for vinduerne er principielt det samme som fx rullegardiner. Så der burde ikke være forskel. Rullegardiner virker fint i procent (Siger andre.. Jeg har ingen rullergardiner). Jeg kan snildt sige til Google, "åben vindue X", og så åbner den vindue X 100%. Og det samme med "luk vindue X", så lukker det. Men hvis jeg siger til Google, "åben vindue X 50%", så melder Google tilbage, at det forstår "hun" ikke. Og der gik jeg så i stå, foreløbig. Nej så skal du bare bruge de begrænset ind/udgange på KLFén. (mener kun der er 5 indgange og udgange). Tilbagemeldingen kan du kun se på fjernbetjeningen (hvis det er en KLR200, touch fjernbetjening). Men det burde virke som en hvilken som helst anden styring til rullegardin/vindue osv, som styres via et tryk. Jeg bruger det bare ikke selv, ikke mindst fordi jeg har 8 vinduer :-) Både den og den med de automatisk lukker når det bliver mørkt udenfor, de er to helt uundværlige funktioner, efter min mening.