Kandersen

Ja det er sgu godt nok noget lort... Der må være andre som også har problemer med den release. Lidt offtopic. De der Xiaomi, det er zigbee tingester, ikk? Hvilket gateway bruger du til dem? Og kan de holde batteri længe nok til at det er brugbart?

Hmm det virker som om det er ihc bindingen der timer ud?? Jeg køre med 2.1.0 release build. Det er i øvrig på en Rpi3. Jeg ved ikke om der er forskel på dem.

Det er port 9001.. (jeg mener ikke jeg har ændret den fra default). Ahh, ja sorry.. IP .3 er jo din IHC controller.. Det er selvfølgelig IP adressen til din OpenHab2 (synology) du skal skrive ind. http://192.168.1.4:9001 Hvis du køre ssl, så skal du nok bruge https://192.168.1.4:9001 Det burde være adressen til loggen, så du kan følge med i den (live log). Der er også en rigtig logfil. Men jeg bruger den aldrig, og kan ikke huske stien på den.

Har du tjekket loggen?

Sker det samme hvis du bruger habpanel? Jeg mistænker stærkt at BasicUI har nogle gevaldige problemer ind imellem. Jeg har også erfaret at den engang imellem ikke vil reagere. Men habpanel virker fint, når det sker. Det er specielt hvis man har lavet nogle ændringer i sitemap, at den pludselig ikke længere vil. Event loggen kan også finde på at vise fejl i en sitemap fil, selvom der reelt ikke er fejl i. Både BasicUI og Habpanel er een af årsager til, at jeg stadigvæk er i "test fasen" med dette og muligvis aldrig kommer videre. Jeg synes simpelthen ikke de er brugervenlige nok, og da slet ikke Habpanel, som tilsyneladende har store vanskeligheder med at skalere ikoner til fx en tablet med lavere opløsning. Jeg har enormt svært ved at fatte, at man skal sætte det op på en PC som har en opløsning. Og når man så går til den fra fx en tablet eller smartphone med en anden opløsning, så ser det helt råddent ud. Oven i det er det en kunst i sig selv at finde en browser som virker med BasicUI. Det skal være en kiosk browser. Jeg bruger Fully Kiosk Browser på min Android smartphone/tablet. I BasicUI døjer jeg primært med at få slidere oa til at virke. I alle tilfælde er dokumentationen som en by i Rusland. Enten ikke eksisterende eller smæk fyldt med fejl, (fordi det er Openhab dokumentationen og ikke OpenHab2). Hjælpen der kan findes, består som oftest i folk, der ikke selv har erfaring med lige det man sidder med. Så de de foreslår nogle ting man kan prøve. Og det kan man så gøre i evigheder. Det er desværre hvad man må forvente at et produkt som er opensource og primært udviklet af nørder til nørder (nørder skal ikke opfattes negativt, men et udtryk for, at det er folk der er på et helt andet niveau og lægger adskillige timer i projektet hver eneste dag). Og når man som jeg, ikke længere har den samme slags tålmodighed og slet ikke den samme tid til sådan noget mere, så bliver det en massiv udfordring

En simpel 24volt DC strømforsyning.

Lars, kunne du gøre det uden at lyset står og blinker imellem skiftene?

Kig i Openhab loggen, (ligger default på port 9001, mener jeg. Dvs din adresse er http://192.168.1.3:9001). Der burde du kunne se en ændring, når du trykker på trykket, og se der bliver sendt en ON/OFF til udtaget. Prøv lige port 9000, hvis 9001 ikke virker. Jeg har den liggende som en genvej, så jeg kan ikke huske porten præcist Nej du skal ikke genstarte med de ændringer vi snakker om her. Hvergang du laver en ændring i en items, sitemap, rules eller andet fil, så vil OpenHab automatisk loade den med det samme du har gemt filen. Det samme hvis du tilføjer nye items osv filer.

Her er min items for et 4tast tryk i vores køkken. Switch koekken_oev "Tryk øverste venstre" <light> ["lighting"] {ihc=">[ON:35162:100]", autoupdate="false"} Switch koekken_oeh "Tryk øverste højre" <light> ["lighting"] {ihc=">[ON:35418:100]", autoupdate="false"} Switch koekken_nh "Tryk nederste venstre" <light> ["lighting"] {ihc=">[ON:35930:100]", autoupdate="false"} Switch koekken_nv "Tryk nederste højre" <light> ["lighting"] {ihc=">[ON:35674:100]", autoupdate="false"} Det som står inde i [ ] behøver du ikke. Det virker også uden. autoupdate="false" betyder, at Openhab2 opfatter det som et kip tryk. Skal du bruge det i basicUI, så skal du definere et kip tryk i sitemap filen. Her er items for et wireless ø80 lampeudtag (dimmer): Switch koekken_vasklys "Dimmer status" <light> ["lighting"] {ihc="13957917"} Number koekken_vasklys_niv "Dimmer niveau [%.1f %%]" <light> ["lighting"] {ihc="13957725"} Den første er bare til en indikering af lyset tændt/slukket Den anden er til brug for en slider i fx Habpanel.

Ja, men jeg må også erkende, at skiftet til HW 6.2 ikke rigtig har gjort noget godt for det jeg savnede, nemlig en ordentlig hastighed når man tilslutter til den og skal sende/modtage i visual. Jeg synes den er mindst lige så gabende langsom som min HW 6.1 er/var.

Der skal ikke tilføjes 0x foran. Du skal vælge om du vil tage det ene tal eller det andet (dec eller hex tal). Jeg bruger kun decimaltal. Dvs dine items med decimal tal herover ser således ud: Switch Køkken_lys_overbord "Lys over køkkenbord" <switch> (IHC,køkken,Lights) ["Lighting"] {ihc="2113115"} Switch T10_Køkken_Skråvæg "T10_Køkken_Skråvæg" <switch> (IHC,køkken,Lights) ["Lighting"] {ihc="16939793"} Og din rule: rule "Lys kokkenbord ON" when Item Køkken_tryk_Skraveg changed from OFF to ON then Køkken_lys_overbord.sendCommand(ON) end rule "Lys kokkenbord OFF" when Item Køkken_tryk_Skraveg changed from ON to OFF then Køkken_lys_overbord.sendCommand(OFF) end Et godt råd: Lad være med at bruge æ, ø og å. Jeg har ikke testet om OpenHab kan håndtere det, men helt generelt bruger jeg det ikke, fordi jeg tit har været ude for, at det giver ballade i sådanne konfigurations filer. Ydermere er der noget med store og små bogstaver, som også kan give knas, så det benytter jeg heller ikke, medmindre jeg absolut minder mig selv om at konsekvent gøre det ens (hvilket man kan have tendens til at glemme, hvorfor jeg som regel altid bruger kun små bogstaver). Det skal nemlig skrives præcis ens. Så Køkken_lys_overbord vil jeg ændre til koekken_lys_overbord Og ligeledes med T10_Køkken_Skråvæg til t10_koekken_skraavaeg. Så er det ihvertfald ikke det du skal slås med, hvis det ikke virker

Det er zigza temperaturfølere jeg bruger, og de melder ind 4-5 gange oftere end LK´s følere. Og så svinger det alt efter temperatur ændringerne. Det er vel omkring 20-30 gange i minuttet for alle 12 følere. Så det er nærmest et konstant flow mellem IHC controlleren og OpenHab2.

Sidder ikke lige ved min maskine, men du kan få en items linje i aften. Og ja, det er bare at linke til resourcen for trykket i OpenHab. Jeg har gjort det med en hel del tryk i vores hus, og det fungere ganske udmærket. Det eneste du ikke kan, det er "langt" tryk. Det fatter OpenHab2 simpelthen slet ikke. Så det har jeg opgivet at få til at virke. Jeg kan dog ikke hjælpe med Homekit, for det bruger jeg ikke.

Jeg kender ikke ovenstående trick. Jeg har et par gange fået timeout efter jeg opdaterede firmwaren i controlleren til 2.8.4. Men det virker som om det har hjulpet, når jeg har sat timeout tiden op i ihc.cfg filen. Årsagen til at jeg nok ikke mærker det så meget, det kan evt skyldes at jeg har et konstant flow fra 12 IHC temperaturfølere som melder sig i OpenHab.

Forstår godt hvad du mener, men det er endnu vanskeligere at finde LED´s der fungere sådan som du gerne vil det. Det bedste jeg kan anbefale dig, det er meget høj Ra LED som også er dimtone. Dimtone betyder at kelvingraden ændre sig i takt med du dæmper dem, og giver et mere blødt/gult lys som fx stearinlys. De dimtone LED´s jeg har set, de dæmper fra 2700 til 2200 kelvin. Men jeg har aldrig set dem live. Jeg mener Bjarne her på forumet bruger dimtone LED´s. Prøv at hør ham hvilke det er.

Det er en svær opgave, og jeg vil tro den er nærmest umulig at finde en dæmper der kan dæmpe 0-100%.

Kan du også, og ganske snedigt endda. Se min anden besvarelse i din anden tråd. Tag det evt op i et mere egnet område.

Det kan sandsynligvis godt laves, men jeg tvivler på det bliver et kønt syn at se på. De der scene switch skifter jo i bestemt rækkefølge, og mig bekendt uden memory. Dvs. hvis du skal aktivere til scene 2, så kræver det at Fbén først tænder til scene, og derefter til scene 2. Dvs lyset vil blinke mens Fbén skifter til det som du nu engang vælger. Det andet med at have et tryk for hver scene, det vil ikke fungere, da du ikke kan definere scenerne fast. Igen er du nødt til at lave det som, at du altid starter fra udgangspunktet. Dvs. scene 1 = 100%, og så kan du definere trykket (fx scene 3), og når du trykker på det, så vil lyset starte på 100%, slukke og tænde igen på 75%, slukke og tænde igen på 50%, eller hvordan det nu lige er scenerne er defineret i pæren. Jeg tvivler på det bliver til at holde ud at se på. Men det bør klart kunne laves i IHC controlleren, da det "bare" er antallet af Kip´s der skal bruges som tæller.

Nu er begrebet "meget langt ned" jo ret defust. Men de spot jeg bruger til en wireless Uni250 (1 modul) dimmer. Det er 4.3w dæmbar Ledon GU10 spot. Jeg har kun disse lige pt. i vores udhæng i indgangspartiet. Og jeg synes da de dæmper ret langt ned.

Dan - Jeg er lidt lost i dit indlæg. Du starter ud med at nævne en udfordring. Men dit mål lader til at være noget helt andet, når jeg læsere videre. Og jeg tror det delvist skyldes du ikke helt har forstået det. For når du senere skriver, at du vil bevise at OpenHab2 kan snakket med IHC controlleren og styre On/off fra et IHC tryk, så mener jeg du er i gang med at misforstå det hele. Det behøver du jo ikke OpenHab2 til. Det klare controlleren helt fint selv (altså On/off på en IHC dimmer med et IHC tryk). Hvis du derimod vil kunne tænde/slukke din dimmer fra OpenHab2 interfacet, så er det det du skal fokusere på. Og så er det ret ligegyldigt hvilken dimmer du bruger, (LK´s dimmer, Fibaro, Aeotech eller fx Hansman, alle er mulige). Det du skal, det er: 1. Oprette et visuel kontakt/tryk i OpenHab, og linke dette tryk til en Fb funktion på IHC controlleren (dvs en item som du har skrevet herover). Der har du en switch (kontakt) som du kalder Køkken_lys_overbord. <-- Dette er din virtuelle kontakt i OpenHab2. På samme linje har du fortalt, at den skal aktivere IHC="0x2113115 " hvilket jeg formoder er lys niveauet på din IHC dimmer. Det skal nemlig via lysniveau på dimmeren i din Fb (eller samme resource). Så bør tænd/sluk virke. Men langt/kort tryk må du kigge langt efter. OpenHab2 kan ikke umiddelbart håndtere det. Men simpel tænd/sluk, det virker helt fint. Jeg har det selv på indtil flere wireless Uni 250 dimmere, og i øvrig også på Uni 400 dimmere. På wireless dimmerne har jeg også slidere i HabPanel. Da kort/langt tryk ikke er skide godt i OpenHab, så er problemet med fortrådet dimmere (Lk´s) omvendt et massivt problem. Du kan tænde/slukke dem, men du kan ikke skrue op/ned for dem. Det er et problem som jeg ikke har fundet løsningen på. Der er mange forslag, men ingen der virker. Hvis jeg så skal gætte mig lidt frem til, hvad det i virkeligheden er du vil, så er mit gæt, at du gerne vil frem til at styre en anden dimmer (Fibaro fx) fra et IHC tryk via OpeHab2 ? Hvis det er korrekt forstået, så er det faktisk lige så nemt. I stedet for din ovenstående item til dit lampeudtag, så skal du i stedet definere dit IHC tryk i en item. Og så skal du bruge denne item til hvad du end vil i OpenHab. Fx. switch køkken_trykOEV "tryk ØV ved dør" <switch> (IHC,køkken,Lights) [ "Lighting" ] { ihc="xxxxxxxxx " } <-- resource ID på dit tryk i Visual. Din Fibaro dimmer har allerede items, når du linker den til OpenHab. Derefter laver du en rule der fortælle OpenHab2, at når du trykker på trykket "køkken_trykOEV", så skal den on/off Fibaro dimmeren på dens item. Her er en simpel rule for samme princip. Det er godt nok med en PIR styring, men det er principielt det samme: "Multisensor6_MotionAlarm" og "garage_zwave_pir" er begge defineret items i OpenHab2. rule "Zwave PIR ON" when Item Multisensor6_MotionAlarm changed from OFF to ON then garage_zwave_pir.sendCommand(ON) end rule "Zwave PIR OFF" when Item Multisensor6_MotionAlarm changed from ON to OFF then garage_zwave_pir.sendCommand(OFF) end Ovenstående bruger jeg en z-wave PIR som "slave" til en PIR styring Fb i IHC controlleren. Så lige så snart "garage_zwave_pir" går off, så aktiveres PIR Fbén i IHC, præcis som hvis det var en IHC PIR. (IHC controlleren vil aldrig opdage om det er en zwave PIR eller andet).

Som jeg skrev, "Men at man igennem 2-3 årtier stadigvæk ikke har fattet det, det kan man kun undre sig voldsomt over. Det er ikke specielt ' Intelligent' ". Hvilket i korte træk betyder, at LK har haft mere end adskillige muligheder for at gøre noget ved "problemet". At Visual 3 controlleren er udstykket med den konfiguration som den er, det er og bliver skandaløst i år 2017. Det kan simpelthen slet ikke debatteres. At den skal være bagud kompatible, det bør ikke være en årsag til, at ikke gøre den mere moderne og følge med udviklingen, tværtimod burde det faktisk forpligtige. Men alt det her har vi været igennem til hudløshed.

Taget i betragtning af, at der tilsyneladende ikke er meget udvikling i IHC net, så mener jeg kun der er een vej, hvis du med 'gammeldags'' mener almindeligt netværk. Og så med mindst Cat6 installation. Til TV er det lidt værre, da jeg ikke er bekendt med nogle gode løsninger. Men spørgsmålet er også om der behøver at komme det, for flere er begyndt at fravælge TV antenne (coax baseret) fordi der streames mere via netværk. Jeg må dog erkende, at indtil videre vil jeg ikke anbefale at man dropper coax TV. Men hvis man fravælger coax, så bør man trække tilsvarene flere Cat6/7 (FTP) kabler til samtlige rum. Alle kabler bør trækkes i stjerne installation og afsluttes i et decideret patchpanel evt i et teknikrum. Nogle vil mene at trådet netværk også er passé efterhånden og vælger en trådløs løsning. Den kan jeg slet ikke følge. Med det stigende behov der er for streaming, og ikke mindst den efterhånden rimelig voldsomt øget kvalitet på streaming, så vil det lægge voldsomt press på de almindelige consumer trådløse netværksprodukter.

Som udgangspunkt synes jeg 128 ind/udgange er et okay valg til den almindelige bolig (House), så der kan laves smarte (Intelligent) styring (Control). (Jeg gad at vide om LK overhovedet selv har forstået hvad disse ord betyder). Men hvad jeg ikke fatter er, at man ikke har lavet et BUS/Datalinje interface til fx at koble flere controllere sammen, så det kan bruges direkte fra samme Visual program. Det ville have givet langt mere mening at gøre det sådan. Eller en anden form for datalinje udvidelse. Det der redder LK´s r*v i dette tilfælde er, at de omvendt har lavet wireless komponenter, som netop kompensere for begrænsningen i ind/udgange. Det er bare en ekstrem voldsom dyr måde at gøre det på, selvom det selvfølgelig også har andre fordele. 13 stk wireless 4tast tryk, (eks input moduler) eller 7 stk ø80m lampeudtag dimmer, så har man faktisk betalt det samme som en ny controller. Årsagen skal højst sandsynligt findes i, at man dengang man designede IHC ikke havde forestillet sig et forholdsvis stort behov for mange datalinje produkter i almindelige boliger. Men at man igennem 2-3 årtier stadigvæk ikke har fattet det, det kan man kun undre sig voldsomt over. Det er ikke specielt ' Intelligent'

Bortset fra jeg skrev input 16, hvori adskiller det jeg skrev sig fra, det som står på side 20 her i denne pdf? http://www.lk.dk/globalassets/pdf-arkiv/download/Manualer/IHCControl200_maj2006.pdf Pt er jeg løbet tør for input (datalinjer), men har rigelig ledige output datalinjer, på controlleren. Jeg har foreløbig løst mine input problemer ved at udskifte fortrådet tryk til trådløse. Men det er ikke en specielt økonomisk god ide, samt at de trådløse vil før eller siden løbe tør for strøm, og sandsynligvis sker det når det er allermest ubelejligt Oven i det påtænker jeg en større operation med PIR´s til styring af en masse lys (inde og ude), og det koster jo en indgang hver gang, medmindre jeg tager z-wave vejen.

LK har faktisk lave en god foreskrift for, hvordan man kobler to controllere sammen rent fysisk. De har så bare ikke lige forklaret, hvordan man gør derfra Lars1, du har ganske ret. LK anbefaler at man bruger klemmerne 15 & 16 på input modulet og 7 & 8 på output modulet, og så 16 -> 7 og 15 -> 8. Hvilket netop skulle gøre det (hvad det så end er), mere overskueligt. Jeg sad og læste på det for et par uger siden, netop fordi jeg nu har 2 controllere og tænkte, hvad jeg mon så kunne drive det til. Men jeg gik simpelthen kold i resten af forklaringen. Jeg kan, kort sagt, ikke gennemskue hvordan jeg får in/output meldinger fra den ene til den anden controllere. Men man skal også passe på hvad man ligger i det, for når de er koblet sammen, så skal de stadigvæk programmeres individuelt, og opfattes som to forskellige. Og så knækkede min film helt. For hvad pokker skal man så koble dem sammen for.