Claus Skovgaard

Jeg ville styre på trykkene for ikke at få nogle forkerte tilstande i IHC controlleren. se evt samt tråden om openHAB Best practice Mvh Claus

Ja, jeg ville programmere en FB i IHC og koble udgangen derfra over i OpenHAB. På den måde er det nemt at bruge trykket også til andre ting (kort/langt tryk osv) som ikke er så nemt at lave i OpenHAB (kræver rules og lige så snart vi snakker timing i millisekunder er min erfaring ikke at forbindelsen mellem OpenHAB og IHC er god nok til det)

Jeg vil lige komme med en update på dette issue efter at have kørt med overstående work-around i over et år. Jeg har selv erfaret at det åbenbart ikke er nok at have en keep-alive til at helt at undgå problemet, da det ind i mellem opstår alligevel. Jeg vil gætte på at ca. hver anden måned er der, ret pludseligt, igen lange svartider. Der er så blevet "løst" ved at gensarte openHAB eller controlleren. For nogen tid siden besluttede jeg mig så for at se, hvor meget der skulle til for at få forbindelsen stabil igen, og lavede derfor nogle programmatiske funktioner til genstart af IHC bindingen, openHAB samt min RPi (fra openHAB). Erfaringen er nu at det, når problemet kommer, er nok at genstarte IHC bindingen, så det vil jeg dele med jer andre der måske også stadig oplever disse udfald. Så når man oplever det, er det blot at gå ind i sin "restart" menu og genstarte IHC bindingen. Efter et par minutter skulle alt være klart igen. Jeg er klar over det stadig er en work-around, men for mig er det pt en acceptabel løsning da det ikke sker oftere. Jeg inkluderer alle tre niveauer af genstart til de interesserede. Kræver "exec" bindingen og virker på Linux systemer. På Windows kan man bruge copy i stedet for touch (copy /b ...\openhab\addons\org.openhab.binding.ihc-1.9.0-SNAPSHOT.jar +,,) og igen andre kald til at genstarte hhv. openHAB og maskinen. .items Switch restart_ihc_binding "Genstart IHC binding" <info> Switch restart_openhab "Genstart OpenHAB" <info> Switch restart_pi "Genstart System" <info> .rules rule "Restart IHC Binding" when Item restart_ihc_binding received update ON then logInfo("IHCRestart", "Restarting IHC binding") //Update IHC binding path to the correct in your setup. Touch will make openHAB reload the jar. executeCommandLine("touch@@/usr/share/openhab/addons/org.openhab.binding.ihc-1.9.0-SNAPSHOT.jar@@") postUpdate(restart_ihc_binding, OFF) end rule "Restart OpenHAB" when Item restart_openhab received update ON then logInfo("openhabRestart", "Restarting OpenHAB") executeCommandLine("systemctl@@restart@@openhab.service@@") postUpdate(restart_openhab, OFF) end rule "Restart Pi" when Item restart_pi received update ON then logInfo("piRestart", "Restarting Pi") executeCommandLine("reboot") postUpdate(restart_pi, OFF) end .sitemap Switch item=restart_ihc_binding mappings=[ON="Genstart"] Switch item=restart_openhab mappings=[ON="Genstart"] Switch item=restart_pi mappings=[ON="Genstart"]

Hvis du anskaffer fx en Raspberry Pi med OpenHAB, så åbner der sig en verden med integrering utallige komponenter og systemer, herunder styring af standard Wavin gulvarmeanlæg, Nilan ventilationsanlæg, Sonos, TV og receiver, push-besked services o.m.a. stort set uden yderligere omkostninger. (https://docs.openhab.org/addons/bindings.html) Mvh Claus

Det lader til de seneste versioner af OpenHAB er blevet strengere i forhold til timeouts? Du kan prøve at sætte IHC timeout værdien op og se om det hjælper, og evt. lave en keep-alive update rule som beskrevet i den tråd du nævner.

Det lyder til at der ikke er forbindelse til controlleren, eller får du opdateringer fra fysiske tryk ind i OpenHAB? Tjek i service view at du kan tænde og slukke dimmeren Er det noget logik i IHC der slukker igen inden du når at se det? Fjern alle links til din dimmer. Får du evt. timeout/fejl i loggen? Nogen gange kan forbindelsen til controlleren være langsom. Prøv at vent 15 sekunder fra du har tændt for du gør andet. Og hav service view åben i mens til at holde øje med hvad der sker. Genstart IHC og OpenHAB

Du burde jo kunne tænde med det kode, men ikke slukke igen. Den linje i loggen der ændrer dimmeren fra 100 til 1 synes jeg ser meget speciel ud, med mindre du har noget mere kode/rules et sted? Husk at du ved et fysisk tryk både vil få en event der går OFF->ON og efterfølgende ON->OFF. Du kan prøve at indsætte din dimmer i din sitemap (Slider) for at se om du kan styre den direkte. Generelt vil jeg anbefale dig at have al logik på IHC controlleren, så OpenHAB bliver et add-on til din installation. Dvs. undgå generelt at styre IHC udgange direkte, men simuler i stedet et tryk og lad IHC FB'erne håndtere udgangene.

Det kan sagtens være samme tryk du mapper til til ON + OFF. Og input mappes til en indikering på IHC siden. På den måde kan du bruge en OpenHAB switch i kombination med IHC trykkene, og OpenHAB switchen opdateres også når du bruger de fysiske knapper. Fx: .items: Switch ihc_tryk_feedback "Stuelampe" <onoff> {ihc="<0x143cc712,>[ON:0x143cc311:100],>[OFF:0x143cc311:100]"} .sitemap Switch item=ihc_tryk_feedback Se mere om mulighederne her:

Rationalet i at have linket både dimmer og kontakt samt at have en regel på den måde er uklart for mig. Det kan godt være noget overlap af IHC/OpenHAB logik der driller dig. Kan du ikke uddybe hvad du vil opnå samt beskrive hvad præcist dine to items er linket til og endelig hvad IHC controlleren er programmeret til ved et tryk på kontakten? Mvh Claus

Du skulle gerne ende med en knap ala: Måske er det nødvendigt at tilføje en mapping i din Sitemap ala: Switch item=ihc_Godnat mappings=[ON="Aktiver"] autoupdate angiver om knappen kan/skal opdateres fra bindingens side (IHC) > betyder en binding udelukkende med kommunikation til IHC (og ikke retur)

Hej Ole. Du mangler blot at indsætte selve strengværdien i dit item. Altså tilføje "[%s]". Fx: String V_MarkiseTilstand "Tilstand for terrasse markise: [%s]" <rollershutter> {ihc="<0x15BC70F"} eller blot: String V_MarkiseTilstand "[%s]" <rollershutter> {ihc="<0x15BC70F"} Mvh Claus

Jeg bruger godt nok ikke selv kombinerede bindinger pt., men har set eksempler på det andre steder (godt nok den anden vej, fra http til IHC): Number Weather_Temperature "Outside Temp. (Yahoo) [%.1f °C]" <temperature> (Weather_Chart) { http="<[http://weather.yahooapis.com/forecastrss?w=638242&u=c:60000:XSLT(demo_yahoo_weather.xsl)]", ihc=">1234567" } Så det du siger er at item "sonoff_2" ikke får værdien (ON/OFF) af dit output fra kip FB'en? Prøv evt. at sende det ud til noget andet en mqtt for at se om det gør en forskel. Hvis det ikke kan virke, så må du lave to separate items til IHC og mqtt, og så lave en regel der ved ændring af IHC item, sender en kommando til mqtt item. Den regel jeg skrev skal rettes en smule til, hvis du linker IHC item til kip-FB'en i IHC.

Prøv lige at definere hvad du mener med "installation". Tastaturerne har jo ikke "viden" om IHC komponenterne/installationen ud over en "IHC status". Installationen må udelukkende være de kodetastaturer der er serieforbundne. Og hvis nu konceptet master findes, og Mads's tastatur også er master, hvad sker der så, når det indsættes i din installation? Jeg startede med 2 tastaturer. Da jeg oprettede koder på et tilfældigt af dem, opdateredes det andet. Hvis jeg nu fjerner et af mine tastaturer (fx den som er master), bliver det tilbageværende så master i stedet. Og hvis jeg så tilføjer det jeg fjernede igen, hvad sker der så? :-)

Mit bedste bud er at "ændringer" skal forstås som "når administratorkoden indtastes og en kode ændres" Nej det tyder det ikke umiddelbart på. Det enkelte tastatur ved jo heller ikke om det er tilsluttet et IHC input modul, da det jo er envejskommunikation, og det er jo endvidere heller ikke ulovligt at koble alle på. Mit bud er at det kodetastatur der indtastes admin koden på (og en brugerkode dernæst oprettes/ændres), efterfølgende udsender hele sin opsætning til de andre tastaturer. Altså hvis der, som @Lars1 skriver, sættes et nyt tastatur i serie (som man kender admin koden på), kan man via denne "nulstille" de andre. Jeg har ikke prøvet det, så ved ikke om det virker. Et sidespørgsmål er hvordan man kan slette brugerkoder? Det står ikke beskrevet i dokumentationen.

Der er flere måder at angribe det på. Denne første er en ren OpenHAB løsning: Opret et IHC item til dit tryk med det korrekte link: Switch ihc_tryk1 "sonoff lyttetryk" {ihc="<0x13d5c95a"} Opret et mqtt sonoff item med on/off/status kommandoer (du har det nok allerede, som jeg forstår ovenstående): Switch sonoff_sw1 "Sonoff switch 1" {mqtt="<[theBroker:stat/sonoff/POWER:state:default], >[theBroker:cmnd/sonoff/power:command:ON:on],>[theBroker:cmnd/sonoff/power:command:OFF:off]", autoUpdate="false"} Link det sammen med en regel: rule "Turn sonoff on/off" when Item ihc_tryk1 received update then if(sonoff_sw1.state == OFF && ihc_tryk1.state == ON) { //Tænd sendCommand(sonoff_sw1, ON) } else if (sonoff_sw1.state == ON && ihc_tryk1.state == ON) { //Sluk sendCommand(sonoff_sw1, OFF) } end En anden tilgang er at forberede en lille del i IHC Visual, som så sparer dig noget kode i OpenHAB. Link dit tryk til en simpel kip funktionsblok: Tilføj i OpenHAB et kombineret IHC/mqtt sonoff item med input fra IHC og output til mqtt: Switch sonoff_sw1 "Sonoff switch 1" {ihc="<0x5312", mqtt=">[theBroker:cmnd/sonoff/power:command:ON:on],>[theBroker:cmnd/sonoff/power:command:OFF:off]", autoUpdate="false"}

Jeg bruger også bolig konceptet og er som sådan godt tilfreds med det. Dog synes jeg det virker noget tungt for kontrolleren, ikke mindst fordi jeg har en større installation. For at tage trykket fra kontrolleren overvejer jeg derfor også noget i samme stil. Men i stedet for at skifte ud med standard blokkene, tænker jeg dog at modificere og optimere boligblokkene til mit eget behov. Hvis man ønsker at bevare noget af det smarte ved boligkonceptet, men ikke vil skrive det hele om, er en mulighed jo også at beholde master og alarm delen (evt. tilpasse det lidt), og så bruge standard blokke til resten.

Søg og du skal finde :-) http://www.ihc-user.dk/forum/search/?&q=ingen kontakt, svarer på ping

Jo, det er korrekt.

Mht. den fysiske installation, så skal du finde jord, nul og fase i loftdåsen og forbinde til det nye wireless udtag. Den nuværende tændledning sætter du en muffe på. Hvis du er tvivl om dette, så få en kyndig til at hjælpe dig. I Visual må du finde den FB der styrer det nuværende lampeudtag og så fx erstatte den som i forslaget herover, hvor du linker input til det/de samme tryk og output til det nye udtag i stedet. Der skal også linkes en tilbagemelding mellem udtaget og FB'en.

Der findes allerede en glimrende vejledning her: http://docs.openhab.org/tutorials/migration

Det tror jeg kommer an på hvor hurtigt relæet kobler over. Et solid state relæ kan koble over på mikrosekunder. Dog bliver et sådant varmt i forhold til strømmen der løber, så det koster i sig selv noget strøm!

Faktisk har jeg ofte glæde af min. Fx når noget i tavlen eller andensteds skal serviceres eller tilpasses. Eller hvis sikringen går, når nogen kommer til at trække lidt mere end 10A. Eller at ens nye kompressor trækker relæet (den er nu ombyttet). Det er ikke livsvigtigt, men rart at modem, teknik og servere kører videre i disse situationer.

Ja, den koster lidt strøm, mere præcist ca 5% af forbruget på den. i mit tilfælde sidder den i teknikskabet og trækker nok max 50W. For eksemplets skyld kan vi sige 100W. Det svarer til omkostning på ca 100kr om året. Det synes jeg ikke er galt. I modsætning til en forsikring, koster det ikke forholdsvis mere at sikre værdifulde dele af installationen (med mindre det er strømslugende dele). For at opnå den mest økonomiske installation, må du starte med at flytte de pågældende lys/udtag over på samme lysgruppe så du kan nøjes med én ups som indsættes umiddelbart efter gruppesikringen. IHC strømforsyningen må også sidde på denne gruppe for at 230V output modulerne er tændte (ellers skal de med på 12V IHC backup'en) For at spare på UPS strømtabet, ville jeg indsætte et relæ som kan bypasse UPS'en når man fx er hjemme og kun koble den til når man er ude (og forbruget så også samtidigt er minimalt, undtaget hvis man har hjemmesimulering selvfølgelig)

Jeg havde gået med tanker om et backup 3G/4G modem eller lign., men faldt en dag ved oprydning over et gammelt datakabel og tænkte det måtte kunne bruges på Pi'en. Med https://www.gnokii.org/ er det faktisk ret nemt at både sende og modtage/læse SMS. Man kan også lave og besvare opkald. Har man en gammel mobil, men ikke datakabel, kan de stadig fås for en slik fx her: http://www.mytrendyphone.dk/shop/datakabel-kompatibel-2681p.html

Jeg har også ligesom Bjarne IHC delen på eget kombirelæ, og bruger så denne fætter https://www.proshop.dk/UPS/Bluewalker-PowerWalker-VI-650-SE/2426910?utm_source=edbpriser&utm_medium=cpc&utm_campaign=pricesite til backupstrøm af modem, switche, RPi's, kameraer m.m. Det fungerer godt. Så kan man også få besked ved strømafbrydelser el. Har endvidere en gammel Nokia koblet på min RPi, så i fald internettet er nede, får jeg alm. SMS via denne i stedet.