Kandersen

Det er også en seriøst alvorlig fadæse af LK. Selvom IHC controller 6.2 med nyeste firmware og HW 7 løser problemerne med java. Så er der sandsynligvis stadigvæk rigtig mange derude med ældre controllere, som jeg formoder er igennem et marridt hvergang.. Eller, rettelse.. Det er disse mennesker som Lars snakker om, som ikke ændre ved det. De opdager dermed aldrig problemet. Og hvis de skal have ændret på noget, så hyrer de den lokale el-pusher, så længe denne findes. Men hvis vi vender det hele lidt på hovedet, og tænker over det. Hvor tit/ofte har man egentlig brug for at ændre i noget, uanset om det er Philips Hue eller IHC? Måske har man mere brug for det, når det er Philips hue, fordi det for mange er en nyere og løbende investering. Mens IHC nærmest er en færdig pakke. Når det er på plads, så har familien ikke længere brug for at ændre noget, (mener nogen). Philips Hue har også den "fordel", at det er yderste begrænset hvad man kan. Dermed er det nemmere at berettige en app til formålet. Men IHC er ekstrem avanceret set i forholdet, så det bliver langt værre, hvis man skal bruge en app til det.

Jeg har Philips Hue, Jeg har Google Home, jeg har IHC.. Jeg har nærmest det hele.. Ergo er jeg både gammel og ung Øh, det er sgu da også medier. Og jo, medierne er i den grad dem der bar Philips hue frem i starten. Og de gør det stadigvæk.

Explanation.. I think I got it now. Having a switch-channel with direction WriteOnly will stay on.. However, the binding itself will send the OFF to the push button/whatever. And this is exactly what´s needed for Google Home to work, and it still believes the "thing" is ON, when it´s actually OFF. I used ServiceView to make sure.. I used the trail log to see what happens, but in this case I´ll never see the OFF beeing send. The actual item will stay on, but in the IHC controller the push-button will go off. Thats why I got this mixed up. Now, this was good news. Bad news is, that even though this is a standard "Kip" operation in IHC, it wont work with binding settings createChannelsAutomatically=true, because direction=WriteOnly has to be set for the channel. So every push-buttons has to have channels created manually. Is that correct understood? In the old 1.13 binding, direction was set in items. Now it´s on channels setting, and default is both ways (ReadWrite).. Shouldn´t it be default to WriteOnly, when it´s a push-button, so this can be archived using createChannelsAutomatically? Btw. Is there any specific reason why default PulsWidth is 1000ms ? As far as I remember from most Functions bloks in Visual using kip, 400ms is default?

Ahh damit.. It works now. And works with Google Home as well.. I´ll explain later.

I get this error: 2019-03-07 18:36:33.106 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'ihc.things' has errors, therefore ignoring it: [4,27]: extraneous input '' expecting ':' This is my ihc.things file ihc:controller:elko [ ip="10.4.28.6:777", username="admin", password="password", timeout=8000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: Type switch-channel : my_test_trigger "My Test Trigger" [ resourceId=20058, direction="WriteOnly", pulseWidth=1000 ] }

Just did (edited). But here it is again: ihc:controller:elko [ ip="10.4.28.6:777", username="admin", password="password", timeout=8000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: Type pulse-output-channel : my_test_trigger "My Test Trigger" [ resourceId=20058, direction="WriteOnly", pulseLength=1000 ] } Btw I dont see pulse-output-channel type mentioned in the Doc.. Is it new?

I cant get it to work.. This is my channel: Type pulse-output-channel : my_test_trigger "My Test Trigger" [ resourceId=30298, direction="WriteOnly", pulseLength=300 ] And this is the error I get: 2019-03-07 17:36:00.317 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'ihc.things' has errors, therefore ignoring it: [3,25]: mismatched input '' expecting ':' [3,26]: missing '}' at 'l' [3,33]: no viable alternative at input 'my_test_trigger' [3,77]: no viable alternative at input 'resourceId' [3,88]: no viable alternative at input '30298' [3,95]: no viable alternative at input 'direction' [3,118]: no viable alternative at input 'pulseLength' [3,130]: no viable alternative at input '300' Just tried with a fresh file .things file ihc:controller:elko [ ip="10.4.28.6:777", username="admin", password="password", timeout=8000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: Type pulse-output-channel : my_test_trigger "My Test Trigger" [ resourceId=20058, direction="WriteOnly", pulseLength=1000 ] } Gave this error: 2019-03-07 17:45:19.161 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'ihc.things' 2019-03-07 17:45:19.184 [ERROR] [.thing.internal.GenericThingProvider] - Channel type ihc:pulse-output-channel could not be resolved.

Øh nej. Tværtimod skriver jeg at forbrugerne bliver mere og mere bevidste om "noget". Det er pudsigt nok også disse "unge" som er fremtiden. I øvrigt er jeg glad for, at du kategorisere mig som ung Her er jeg direkte uenig.. Jeg kan ikke finde den lige nu, men jeg mener sidste år blev der lavet en undersøgelse af, hvilken aldersgruppe der køber fx Philips Hue. Det er faktisk fra ung til middelalderende, (primært mandlige køn). Og det er primært den gruppe, som fx kunne kunne finde på at købe/bygge/ombygge hus. Mja.. Nok er vi en lille gruppe. Problemet med at tiltrække opmærksomhed skyldes nok mere, at man ved man ikke bliver lyttet til alligevel. Men ellers er jeg enig. Og det er her jeg synes du tager fejl. Medierne gør faktisk rigtig meget ved dette. Ellers ville et produkt som fx Philips Hue slet ikke sælge i den udstrækning det har gjort, og haft den udvikling.

Her tror jeg du tager lidt fejl af den almindelige forbruger. Flere og flere forbrugere får øjnene op for "smart styring" . Og der kommer langt flere henvendelser på div medier netop med spørgsmål om, hvad skal de vælge for at få "smart styring" i hjemmet, specielt når der skal bygges nyt hus eller bare ombygge, dog endnu primært fokuseret på lysstyring. Men også eksisterende installationer. Funktioner som stemmestyring tager i den grad fart. Siden Google Home blev lanceret i DK tilbage i oktober/november 2018, så er det gået som varmt brød, (endda på trods af flere start vanskeligheder og visse udfordringer). Og den del stopper ikke, tværtimod går den stærkere hele tiden. Problemet med det er, at de alle søger mere i retningen af nemme og simple løsninger som Philips Hue og deslige. Her har Google home ikke gjort det bedre, fordi disse forbrugere tror, at Philips Hue/lign er den hellige gral da det kan integreres direkte samme eksisterende installation og med Google Home/Homekit på en måde selv en alderende dansk forbruger forstår sig på, og i et "sprog" som de hører om nærmest dagligt. Men stadigvæk er trenden primært fokuseret på lysstyring. Det er det jo også, når en familie fx bygger nyt hus. Så får de tilbudt IHC med fokus på lysstyring og evt varme/ventilation (klima som de kalder det), i en, for mig at se, komplet skrabet udgave og til en økonomisk sum der gør, at en familie med en vis viden og økonomisk omtanke takker nej, og vælger den simple løsning med fx Philips Hue, fordi, det er det de har hørt/læst om i forbindelse med "smart styring", og det koster en brøkdel. Her dør IHC helt automatisk ud, fordi forbrugerne stiller flere krav om "smart styring" som elinstallatøren/firmaerne ikke kan leve op til med IHC løsningen. Det er fremtiden. Andre LK´s produkter løser heller ikke problemet, (KNX, Dali etc), så vidt jeg ved. Der er faktisk ikke mange "færdig lavet" systemer, som løser de stigende krav om "smartstyring" som forbrugerne hører/læser om hver dag i medierne, i forbindelse med Philips Hue ligende systemer. Det er to forskellige verdener, hvor de færdige lavet systemer er dem der "nøler" i det, selvom de sidder med nogle temmelig gode kort på hånden. Og de andre "simple" systemer, de suser derudaf og overhaler det ene system efter det andet, på trods af de er ekstremt begrænset, og på visse punkter tåbelige ubegavet systemer. Man kan kun undre sig over, at det er på den måde. Men det er dælme kun firmaernes egen skyld, godt hjulpet af idiotisk rådgivning/sælgere til mindre vidende forbrugere. Men der bliver færre og færre af disse mindre vidende forbrugere.

Correct, there is the standard Kip function block. But the wired dimmers needs it (on/off puls) as well, to turn on/off from a single button. I have answered in the topic.. The question is better placed in that topic I guess.

Hi @Pauli Anttila I assume you refere to the above (from page 3)? And then @EjvindHald example (from page 2): item: Switch IHC2Spisebord "Spisebord" {channel="ihc:controller:haldIHC:ihcoutput", channel="ihc:controller:haldIHC:ihcinput1", channel="ihc:controller:haldIHC:ihcinput2"} things: Type switch-channel : ihcoutput "IHC output" [resourceId=3932434, direction="ReadOnly"] //output Type pulse-output-channel : ihcinput1 "IHC input1" [resourceId=3931665, direction="WriteOnly", pulseLength=1000, trigger="ON"] //input1 Type pulse-output-channel : ihcinput2 "IHC input2" [resourceId=3931921, direction="WriteOnly", pulseLength=1000, trigger="OFF"] //input2 First of all - Does it require to do both channels manually for each switch (pushbutton)? (Maybe @EjvindHald can answer this) or is it possible to set read/write direction in the item settings? I really fail to understand how come standard IHC operations like kip and pulse has to be done manually at channel level in the 2.4 binding.. Perhaps this is what I´m misunderstanding here? Second - The above looks like it´s an example using two different buttons? (one button for ON and one button for OFF)? I use single button for the kip (toggle) and dimming (wired dimmers) operations.( In my example from 1.13 binding, you´ll notice I use the same resourceID for both ON and OFF). is it possible to define the same resourceID to two difference channels, like this: Type pulse-output-channel : ihcinput1 "IHC input1" [resourceId=3931665, direction="WriteOnly", pulseLength=1000, trigger="ON"] //input1Type pulse-output-channel : ihcinput2 "IHC input2" [resourceId=3931665, direction="WriteOnly", pulseLength=1000, trigger="OFF"] //input2 It doesnt look right, or?

Jeg tror desværre Henning tager fejl i at IHC vil være en stor spiller i fremtiden på markedet. Og hvis det er, så er det desværre ikke pga LK, men derimod netop pga Hennings pkt 1, som jeg personligt finder dybt foruroligende. At man kan aggere fagmand og lykkedes med at sælge et produkt, som blot giver kunde store bekymringer nu og i fremtiden, det er mig simpelthen en gåde. Men selvfølgelig, hvis kunden ikke får nogen anden mulighed, så er det svært ikke at lykkes med det. Og det er nok her det reelle problem ligger begravet..

Hi @Pauli Anttila Exactly.. This is what I figured as well. Telling Google Home to turn OFF a switch which is already OFF, doesnt get through the binding. I can.. This is what happens when I ask google home to turn on my test item: 2019-03-04 23:22:37.378 [ome.event.ItemCommandEvent] - Item 'testIHClysKip' received command ON 2019-03-04 23:22:37.393 [nt.ItemStatePredictedEvent] - testIHClysKip predicted to become ON 2019-03-04 23:22:37.405 [vent.ItemStateChangedEvent] - testIHClysKip changed from OFF to ON 2019-03-04 23:22:37.408 [GroupItemStateChangedEvent] - gV changed from OFF to ON through testIHClysKip 2019-03-04 23:22:37.708 [ome.event.ItemCommandEvent] - Item 'testIHClysKip' received command OFF 2019-03-04 23:22:37.717 [nt.ItemStatePredictedEvent] - testIHClysKip predicted to become OFF 2019-03-04 23:22:37.727 [vent.ItemStateChangedEvent] - testIHClysKip changed from ON to OFF 2019-03-04 23:22:37.740 [GroupItemStateChangedEvent] - gV changed from ON to OFF through testIHClysKip And this is what happens, when I ask google to turn off the same item: 2019-03-04 23:24:43.345 [ome.event.ItemCommandEvent] - Item 'testIHClysKip' received command OFF 2019-03-04 23:24:43.360 [nt.ItemStatePredictedEvent] - testIHClysKip predicted to become OFF This is my test item: Switch testIHClysKip "Stue M2 kip [%s]" <switch> (gV) [ "Lighting" ] { channel="ihc:controller:elko:input30298" } (gV) is the rule to turn the switch off. This doesnt work.. And I fail to understand how to get it to work. The old 1.13 binding this will work fine using google home to turn it on and off by this simple item: Switch stort_badDimmerLys "Halogenlys i StortBad [%s]" <WallSwitch> [ "Lighting" ] {ihc="<5537553,>[ON:20314:100],>[OFF:20314:100]"} How can I do the same using the new 2.4 binding? I simply don´t get it

Næsten rigtigt Firmwaren hedder 2.8.4 (jeg er ikke bekendt med en firmware 2.8.6) og Visual hedder 2.8

Har du installeret den Visual som følger med firmwaren? (mener den hedder 2.8). Den gamle Visual du brugte, den virker ikke med nyeste firmware.

Perfekt!

Follow up on this one. I can get Google Home to turn the switch ON and OFF fine if I dont use the (gV) rule to force the switch to turn OFF.. I have a feeling the new binding actually read the state of the switch, and because it´s OFF, it never change state when asking Google Home to turn it OFF. This will ofcouse become a major issue using push buttons.. Anyway, I have a way to deal with this @Christian Bille Fjerne dine switces hvor du bruger Kip funktionblok. Det kommer ikke til at virke. I stedet så bruger du resourceID direkte fra lampeudtaget (udgangen) i din items. På den måde kan du tænde/slukke lampeudtaget via Google home, og også via de fysiske tryk i dit hjem som du plejer. Det er egentlig også den helt rigtige måde at gøre det på. Man skal bare passe på med at aktivere et produkt direkte, for hvis ikke der er tilbagemelding til Fbén, så kan funktionen gå ud af sync i Controllerne. Men i det her tilfælde kan det ikke ske, dels fordi udgangen også følger med i funktionsblokken. Men også fordi det er en Kip blok, så den er ret ligeglad med, om dit lys er tændt eller slukket i forvejen. Hvilket selvfølgelig er uhyre logisk, når man lige får tænkt lidt dybere over det. ResourceID fra lampeudtaget tages her: (se vedhæftet billede). Og sådan her ser item ud: Switch testIHClys "Stue M2 lys [%s]" <light> [ "Lighting" ] { channel="ihc:controller:elko:output27995" } PS. Husk at synkronisere dine enheder i Google Home :-)

Nu har jeg siddet og rodet lidt med det, (har installeret IHC binding 2.4 på min almindelig Rpi som også køre IHC binding 1.13). Jeg når samme resultat som dig. Og det er vildt mystisk, for der absolut intet, når man beder Google om at slukke. Det må simpelthen være den binding der er anderledes, for det virker fint med Binding 1.13.... Jeg tror vi er nødt til at skal have Pauli med på råd her.. Hey @Pauli Anttila I think there is a issue with the latest IHC binding (org.openhab.binding.ihc_2.4.0.201901091843). Using Google Home/voice command seems to be a problem which the old IHC binding 1.13 don´t have. I have configured a Switch (push button) to control a kip functionblok in Visual. Plain an simple. This is the item: Switch testIHC "Stue M1 [%s]" <switch> (gV) [ "Switchable" ] { channel="ihc:controller:elko:input30298" } ((gV) is because I use a rule to switch off the switch (toggle effect)). What happens is: When I tell Google Home to turn ON "Stuen M1" it works just fine. The switch toggles and the Kip functionblok toggles, and the light turns on. (switch turns ON, and my rule turn it OFF 200ms after). But when I tell Google Home to turn OFF "Stuen M1", nothing happens. The switch doesnt react at all. Google Home return with an "okay....". But the command never goes to the binding (or through the binding). I have also tried using the profile "Toggle" as well, It makes no differences. Toggle the switch from a sitemap works fine both turning ON and OFF. My first thought was, this has to be something wrong in the Google Home connection. But doing exactly the same using the old 1.13 Binding, Google Home will toggle the switch each time I tell it to turn ON and OFF. So I believe this is a binding problem somewhere. Can you help in some way?? PS. I have both bindings installed on the same Rpi running the same openhab 2.5, so it cant hardly be an openhab problem. I´m pretty positive this is a binding issue in the org.openhab.binding.ihc_2.4.0.201901091843.

Har du husket at installere den Visual der skal bruges sammen med 2.8.4 firmwaren?

Jeg kigger lige på det senere i aften.

Kan du vise lidt mere af loggen efter 19:13:50

Du kan hente filen her: https://www.dropbox.com/s/opmqiym14hch478/org.openhab.binding.ihc_2.4.0.201901091843.jar?dl=0 Den skal lægges ind på din Rpi i folderen /usr/share/openhab2/addons Husk at kig efter i loggen når du har lagt den ind. Der går lige et par sekunder, så skulle openhab gerne selv opdage den og starte den.

Så vidt jeg husker, så gemte jeg den på dit skrivebord.. Den hedder .jar søg efter den. Ja det er den gamle. Den skulle du ikke bruge mere Afinstaller den bare igen.

Har du kopieret den nye binding ind i /user/share/openhab2/addons mappen ?? Det burde fremgå af loggen, når du starter op. Hvis ikke IHC bindingen starter, så har du nok glemt det.

Du burde ikke mangle mere. Hvad virker ikke?