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"}