Hop til indhold
IHC-User.dk

Leaderboard


Popular Content

Showing content with the highest reputation since 28-04-2018 in all areas

  1. 2 points
    Pauli Anttila

    openHAB2 IHC binding

    Even openHAB 1 IHC binding has been rock solid for many years, I finally decided to port the binding to support openHAB 2 features. I could "release" first alpha version for testing purposes if there are any interest to help testing? Some improvements / features: By default, binding create channels automatically from project file (currently all dataline_inputs, dataline_outputs, airlink_inputs, airlink_outputs and resource_temperature). Auto creation can be disabled, and channels can be created manually (then all resource id's are supported). Support both Paper UI and thing files configuration. Channels for basic controller information (state, SW and HW version, controller uptime). Trigger channels support (button short press, long press and extra long press). Support multiple controllers (those who have e.g. two controllers environment).
  2. 2 points
    Det er sku´ utroligt, vi har næsten hukommelse som en elefant - at kunne huske der har været sådan en tråd/indlæg.
  3. 1 point
    Haha, ja det glemte jeg så lige i farten. Havde ellers siddet og lavet det Sgu da godt jeg gemte det i min dropbox, så jeg kan komme til den nu. Har i øvrig lige editeret i ovenstående items og sitemap og markeret de linjer røde, som er dem vi snakker om. Og så får du også lige screendump af hvordan sitemap ser ud i BasicUI. Edit igen.. Nu opdagede jeg lige, at jeg har faktisk lavet en fejl i min items fil i beskrivelse af trykkene. Jeg har byttet om på højre og venstre. Derfor ser det forkert ud i sitemap filen. Men fordi IHC IDén er rigtig, så er det kun rent visuelt at det har betydning. Apropos det med at jeg har linket trykkene, så er det endnu ikke noget jeg har besluttet mig for, om jeg vil gøre fast eller ej. Reelt set behøver man det ikke, da du kan påvirke dimmeren direkte enten i Fbén eller direkte på produkt-siden i Visual. Årsagen til jeg startede ud med at bruge trykkene, det var med den tanke, at hvis jeg en dag ikke gad OpenHab mere, så kan jeg bare slukke Rpién, og IHC controlleren kørere videre som om intet er sket. Men efterhånden som jeg er kommet dybere ind i OpenHab, så hælder jeg mere og mere til at slet ikke tage hensyn til IHC controlleren mere. Faktisk sad jeg den anden dag og overvejede at lave alt i OpenHab. Og IHC programmet bare vil indeholde produkterne. Dvs ingen Fbére overhovedet. Principielt kan man sagtens gøre det sådan. Men man skal tænke sig om, for hvad nu hvis.... Så er det godt at have et fungerende IHC program i baghånden, inden man springer ud i en fuldblods OpenHab løsning. JEg skal bare lige overbevise mig selv om det sidste, plus jeg skal lærer alt indgående i Openhab, specielt i forbindelse med rules.. Det er en hård omgang. Værs´go!
  4. 1 point
    Thomas Boyens

    IHC visual og remote

    Tak for input Lars Jacobsen :-) Har med succes opdateret Controller til 2.8.4 med firmware loader 1.3.3 :-) Så nu spiller Iphone IHC Remote igen.
  5. 1 point
    Prøv at søge lidt i forummet. Vi har tidligere skitseret diagrammer og henvisninger til små tavlemonterede 24v 2 polede skifterelæer i fbm gardin styring der netop skulle skifte polaritet for op/ned.
  6. 1 point
    Lars1

    Fugtstyring

    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.
  7. 1 point
    Lars Jacobsen

    Service view: Missing holiday file

    Til ferie mm var det ikke næmmere bare at have en start og stop værdi/dato som kunne indstilles via app eller lign. Men uanset hvad så bliver det aldrig helt fuldautomatisk og "dynamisk" og kan udskyde hjemkomsten. Men det er vel ikke ikke meningen med en kalender? For meningen er vel at det altid skal være skemalagt som kalenderen siger. Altså den skal IKKE følger den normale døgn/ugerytme, såfremt det er helligdag, eller andet unormalt jvfr. kalenderen. Selve problemet er nok at få vedligeholdt kalenderen og få "aflyst" de faste aftaler. Nå ja og så at den gælder uendelig langt ud i fremtiden. At programmere den 20 år er sikkert ikke langt nok for der skal nok være en eller anden nærrigpind som mig selv der ikke har set nogen grund til at udskifte og opgradere controlleren. If it aint broke, dont fix it
  8. 1 point
    Der er et problem med Visual 3 controller og ntp - man skal gøre det i en bestemt rækkefølge eller ikke have NTP på. Det med at lave styring via IHC Captain er det nyeste jeg tester - nemlig externe moduler og det ville nok være relativt nemt at have en google calendar intergration som den hentede tidspunkter/events fra
  9. 1 point
    Lars1

    Service view: Missing holiday file

    Jeg synes der har været en del skriveri om problemer med helligdags funktionen i Visual 3 controlleren. Hvis jeg husker ret var der et tidligere indlæg, hvor det blev beskrevet at funktionen ikke virker ordentligt medmindre man også har aktiveret NTP, men jeg er ikke 100% sikker.
  10. 1 point
    umiddelbart burde det være nok at fjerne det kabel du har imellem dit vægstik og din computer for at teste det. I Net basis boksen burde der kunne bruges standard kabler. Ude ved vægstikket er det jo tiltænkt at man bruger tripple splitteren til at splitte lederne fra hinanden.
  11. 1 point
    Lars Jacobsen

    Vis indgange og udgange

    Utroligt du ikke har gidet at kikke her i downloadsektionen.
  12. 1 point
    Der er ikke nogen mulighed i IHC controlleren selv, men hvis IHC controlleren er tilsluttet dit netværk via en managed switch eller firewall, kan du højeste sandsynligt trace traffiken deri. Prøv at genstarte IHC controlleren. Det løser problemet hos mig når jeg har et tilsvarende problem. Det er nok at genstarte den via adminview.
  13. 1 point
    Henning Pedersen

    Vis indgange og udgange

    Prøv med lk.dk og se dig om, mon ikke du skal kikke efter noget med IHC. Du har nu været med så længe at jeg forventer at du har været på deres hjemmeside flere gange, og har oprettet en bruger. Hvis ikke, så er det på høje tid.
  14. 1 point
    Jeg ser det som to (idiotiske) onder der møder hinanden, i en tidsalder ingen af delene hører til. IHC Net Basic hører efter min mening slet ikke nutiden til. Det er langt mere effektivt at lave et ordentligt net, evt ved at trække 2 kabler (og opsætte 2 stik). På den anden side møder man en boks, som ikke er bygget til det, som var mere eller mindre standard for et par årtier siden, men som burde være bagudkompatibel. Yousee underskylder jeg delvist, fordi 2 par kabel (eller 10/100mbit) ikke har været normen i rigtig mange år, og det er sandsynligvis ganske få som vil opleve netop dette problem, (sker kun for dem med splitterkabler). Mht til at bruge WiFi. Så er det også lidt noget sludder jeg siger Du har jo alligevel kun max 100mbit til rådighed. Med et godt Wifi net, så burde du få det samme ud af det eller mere. Men principielt, så er jeg langt mere tilhænger af kablet forbindelser specielt når/hvis det kommer til 4K streaming, som boksen jo sagtens kan.
  15. 1 point
    Mikkel Skovgaard

    v1.06 - Captain stopper

    Jo men det kræver min stopper - men jeg tror måske jeg har fundet noget
  16. 1 point
    Hello Lars, I actually succeeded to get the connection now! I executed the IHC Firmware loader and updated the FW on both controllers. Now the IHC Visual connects ok and I was even able to upload the old configuration files to the new HW62. controllers! Thank you very much for your help - I think I am able to continue with the project now!
  17. 1 point
    Mikkel Skovgaard

    IHC Captain til Homebridge

    Det er nu ret nemt at rette på mit - det kan man gøre via UI'et Men ja det er noget træls noget at rode med - jeg er dog ved at se på at lave mit i docker når der kommer nok torsdage i en uge
  18. 1 point
    Martin Abildgaard

    IHC Captain til Homebridge

    Kan godt se din pointe, men både Mikkel Og Claus bruger det at når der af og til kommer major opgrades, så er anbefalingen at man installerer nyt image. Når man har mange forskellige systemer på samme boks, så er det forfra med alle systemerne. Samtidig bruger begge standard porte for web, 80 og 443, så hvis de skal coexiste, så skal man ind og fifle med hvilken port de skal køre på.
  19. 1 point
    Der findes en anden løsning der kan det : Det er lukket kode og bruger en hel masse plugins og tilføjelser. Du kan se om det kan det du efterlyser.
  20. 1 point
  21. 1 point
    Lars1

    TV signal fejler - LK IHC Net Basic

    Har du testet uden at have nogle data drop i brug? Grunden til spørgsmålet er at hvis du bruger alm. patch kabler mellem vægstikket og computeren, så kan du risiker at kortslutte det par som bruges til TV signal. Det mest sandsynlige er dog at TV forstærkeren i IHC NET basic enheden er stået af.
  22. 1 point
    Mikkel Skovgaard

    Teaser...

    Den næste version af IHC Captain kommer med en del nye funktioner nok primært muligheden for at kunne ændre i indstillinger på IHC Controlleren der er mest nyt
  23. 1 point
    Ja, det kan sagtens være muligt. Data-delen er passiv, da den kun kobler ledningerne igennem, hvor imod TV-delen er aktiv. Dvs. der sidder noget elektronik i boksen, der skulle hjælpe med at fordele TV-signalet.
  24. 1 point
    Hermed link : https://1drv.ms/u/s!Ah7CwKgFhTXrm39cuwShDWBGLSUH 7zip af DietPi image sv.t 8gb SD-kort (er mit eget Backup Image efter seneste compile grundet omfattende opdatering af dietpi) Efter flash med fx "Win32DiskImager" af image boot RPi3 med LAN opkobling - DHCP tildelt IP (Image kan evt reduceres i størrelse med PiShrink) SSH session med fx Putty - Login: root, kode: dietpi Få Domoticz til at starte ved boot, kør følgende efter login: cd domoticz cp domoticz.sh /etc/init.d chmod +x /etc/init.d/domoticz.sh update-rc.d domoticz.sh defaults Editér startup scriptet med fx vim eller nano og her ændre USERNAME, DAEMON og DAEMON_ARGS parametre til det ønskede vi /etc/init.d/domoticz.sh Hvis ikke der ændres brugernavn skal det se således ud (ændre port for såvel http og https efter behov) USERNAME=root DAEMON=/root/domoticz/$NAME DAEMON_ARGS="-daemon -www 8080" Image er iøvrigt installeret med: RPImonitor på port 8888: http://ip.add.re.ss:8888 PHPSysinfo på: http://ip.add.re.ss/phpsysinfo/ Webmin på https, port 10000: https://ip.add.re.ss:10000 For at opdatere DietPi kør dietpi-update For at flytte installationen til USB drev (med boot på SD) dietpi-drive_manager For at konfigurere wifi mm dietpi-config Hyg jer
  25. 1 point
    Kandersen

    Hvad er muligt

    Fedt det virker. Men jeg forstår ikke hvorfor du overhovedet har det problem, den er jo nærmest identisk med mine. Og de virker 100%. Een ting er dog sikkert. Ovenstående items er ikke korrekt. du har en [ for meget " [[lighting]" i den linje. Stop lige op og pust ud et øjeblik mens du får lidt ilt til hjernen. Dine punkter skal du vist lige tænke lidt mere over. Hvad er det præcis du gerne vil? Nu har du bevist at din IHC controller kan kommunikere med din OpenHab2 server. Så er det nu du skal tænke over, hvad det så er du vil bruge det til. Som jeg nævnte tidligere, så giver det ingen mening at bede OpenHab2 gøre noget, som IHC controlleren gør mindst lige så godt. Når jeg læser dine punkter herover, så virker det som om du i gang med at gå over åen efter vand. Det kan jeg absolut kun fraråde. Selvom det er muligt, så giver det som sagt ingen mening. Udover det er det en masse unødig arbejde og kommunikation du skal lave i OpenHab2 og IHC controlleren. Så: (lidt lang og måske kedeligt forsøg på pædagogisk forklaring, som jeg ville gøre det og har opfattelsen af, at man bruger en enhed som OpenHab bedst til samme med IHC). Defintion logik: Logik i IHC controlleren = Funktionsblokke Logik i OpenHab = Rules/automatik. A. IHC tryk eller hændelser der skal styre andre IHC komponenter - Hold logikken i IHC controlleren. B. Openhab tryk/komponenter/hændelser (things/items) der skal styre IHC komponenter - Hold logikken i IHC controlleren. C. IHC tryk eller hændelser der skal styre andre (OpenHab) komponenter (things/items) - Hold logikken i Openhab. D. OpenHab komponenter (things/items) der skal styre andre OpenHab komponenter (things/items). Hold logikken i OpenHab. Du skal opfatte OpenHab som et binde-led mellem flere "ting", hvor IHC controlleren er en "ting". Det der adskiller IHC controlleren fra mange andre "ting" er, at den har logik styring og automatik i sig selv, ligesom fx en Philips Hue også har. Det betyder ikke at man SKAL bruge denne logik styring/automatik, men det giver nogle andre muligheder i forbindelse med påvirkninger ud og ind. Og det kan i netop IHC´s tilfælde være en væsentlig fordel at holde logikken i IHC controlleren. Et eksempel på to "ting", der arbejder sammen via OpenHab. 1. ting - IHC controlleren 2. ting - en Zwave PIR. Målet er at bruge zwave PIR til at skabe en hændelse i IHC, fx tænde et (IHC) lys i en bestemt tid. I IHC har mit udvendige lys. Det er dette jeg vil tænde på zwave PIR. Jeg opretter en funktionsblok til PIR styring i IHC, hvor logikken er i, og udgangen til mit udvendige lys også er forbundet. PIR indgangen på denne funktionsblok oprettes som en "item" i OpenHab: item ihc_pir_indgang Zwave PIRén oprettes ligeledes som en "item" i OpenHab. item: zwave_pir Nu kender OpenHab de to "ting" som der skal påvirkes. Nu skal jeg bare kæde dem sammen som var mit mål. Dvs når zwave pir går ON, så skal pir indgangen i IHC funktionsblokken også gå ON. Og når den går OFF, så skal PIR indgangen også gå OFF. Og det gør jeg via en simpel rule som er lig med den jeg sendte tidligere: rule "zwave pir ON" when Item zwave_pir changed from OFF to ON then ihc_pir_indgang.sendCommand(ON) end rule "zwave pir OFF" when Item zwave_pir changed from ON to OFF then ihc_pir_indgang.sendCommand(OFF) end Jeg kunne godt have lavet al logikken i OpenHab, og så sendt en kommando direkte til lys udgangen på IHC controlleren. Men det er her det snedige med IHC controlleren kommer ind. For funktionsblokken i IHC har jo allerede givet mig den logik styring/automatik, som jeg ellers skulle lave i OpenHab. Så hvorfor pokker skulle jeg så ikke bare udnytte det. Egentlig tror jeg også at ovenstående kunne gøres uden en rule, ved at linke de to items direkte sammen. Men jeg har ikke forsøgt det, plus at det ikke giver mig en garanti for, at når den ene er OFF så skal den anden også være OFF, og omvendt. Men jeg vil tro det kan lade sig gøre. Årsagen til at det er så simpelt, det er fordi det bare er en simpel slave funktion. ON=ON / OFF=OFF. I OpenHab kunne man godt have udvidet det til at indholde flere andre hændelser og eller forudsætninger, fx at ovenstående rule kun skal køre, hvis jeg er hjemme (OpenHab kender min mobil/tilstedeværelse). Så ville jeg skulle tilføje en 3. ting, item min_mobil, og så lade den indgå som en forudsætningen i rule i OpenHab, som jeg mener skal gøres med en AND funktion. (har ikke studeret den del så meget endnu, men det kommer jeg snart til). Så: Brug logikstyring/automatikken, der hvor det giver mest mening, nemmest og bedst egnet. Dvs du skal ikke lade et IHC tryk gå ind over OpenHab, for at tænde et IHC lys (uanset om det er wireless eller ON/OFF). Men det kan være en ide at definere dem alle som items i OpenHab, fordi så har du muligheden for at fx lade et andet tryk (zwave tryk) tænde det IHC lys, og et IHC tryk tænde fx en Philips Hue pære. Håber det giver bedre mening og forståelse. Det er meget banalt eksempel jeg stiller op her. Men når man først fanger ideen, så åbner der sig pludselig en helt anden verden, hvor der nærmest ikke er nogen grænser for, hvordan du kan kæde tingene sammen, kombinere dem og bruge det hele på kryds og tværs, og udnytter de enkelt "ting", der hvor de har deres styrke. I Philips Hue, som jeg også har, der har jeg defineret scener. (dvs i selve Hue brigden). Jeg bruger så IHC Captain til at aftaste IHC tryk. Så når jeg trykker på et bestemt IHC tryk, så tænder lamperne i stuen med en bestemt scene, (dvs farve og lysstyrke). Igen, jeg kunne godt definere scenen i OpenHab, (dvs sætte lamperne op i OpenHab via en rule). Men hvorfor gøre det, når nu Philips Hue giver mig en mulighed for at gøre det på en lidt nemmere måde, og jeg så kan bruge IHC Captain til at "kalde scenen". På et tidspunkt vil jeg måske ændre dette, så OpenHab overtager denne del af logikken. Men pt synes jeg det er nemmere i Philips Hue appen og IHC Captain. Så det handler altså også om, hvor man selv synes det er nemmest. Og så udnytte den del. En sidste lille detalje som jeg var lige ved at glemme: OpenHab har også UI (user Interface. BasicUI, ClassicUI eller Habpanel). Og nu bliver det først rigtig "sjovt". Det betyder at du direkte i OpenHab UI kan lave virtuelle items, som du kan bruge til at påvirke udaftil. Fx et virtuelt tryk i BasicUIl, som tænder dit IHC lys. BasicUI kan du så gå til via din PC, mobil eller lign. Dine virtuelle items kan du også kombinere i rules på kryds og tværs. Fx hvis du har defineret et virtuelt tryk i BasciUI som skal tænde dit IHC lys, så kan du i en rule sige, at det kun må lade sig gøre, hvis klokken er noget bestemt, eller skumring er ON, vinden blæser fra nord, solen er gået ned, konen har gjort sig sengeklar osv osv. Er det fx skumring, og du allerede har et skumringsrelæ på din IHC, så kan det igen give mening at bruge logikken i IHC controlleren. Dvs du definere skumringsrelæet som en item i OpenHab. Og vupti - så er du i samme princip som ovenstående eksempel. Min opfattelse er, at hvis man holder tungen lige i munden og tænker over hvad mål man har med fokus på, hvor ens "ting" har hver deres styrke, så kan man virkelig drive det her vidt. Man kan også skære igennem og køre et fuldt ud OpenHab setup, hvor man er ligeglade med alle "tingéne" og deres styrke, og laver alt i OpenHab. Min opfattelse er bare, at det er ikke noget man bare lige såen gør fra den ene dag til den anden. Plus at OpenHab på desværre mange punkter har en rigtig dårlig dokumentation og decideret manglende. Derfor er jeg startet ud med det basale og forsøger hakke mig igennem de udfordringer som OpenHab giver mig. Jeg har endnu ikke knækket nødden med kort/lang tryk. Min foreløbige opfattelse er, at det ikke kan lade sig gøre i OpenHab. Det giver desværre visse begrænsninger fx i forbindelse med fortrådet lysdæmpere Nok om det.. du har en spændende tid foran dig PS - Bemærk at når jeg skriver "ting" så er det med "". Det er fordi det hedder "Thing" i OpenHab. "Thing" har "items". "items" er dem der er interessante og som du bruger til at lave din styring/automatik. Fx min zwave PIR er en "Ting" med 6 forskellige "items" i sig. Motion PIR. Alarm, rystekontakt, lux, temperatur og hmm.. den sidste
This leaderboard is set to København/GMT+02:00
  • Newsletter

    Want to keep up to date with all our latest news and information?

    Sign Up
×

Important Information

Privatlivspolitik og We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.