-
Antal indlæg
542 -
Medlem siden
-
Senest besøgt
-
Days Won
28
Indholdstype
Profiler
Forummer
Downloads
Galleri
Alt der er opslået af EjvindHald
-
Yes, I think if you extend it also to capture from on to off, it will solve the toogle scenario, which will be great However, I do not quite see how another typical scenario will fit in . If you have one physical input for on and another physical for off like in this binding 1.x example: Switch ForsteSalGarderobeSpotLoft "Spot loftet" <light> ["Lighting"] {ihc="<0x1a7f5b,>[ON:0x255c5a:100],>[OFF:0x255b5a:100]"} There are 2 different IHC ID's in italic - one for turn on and another for turn off. For openHAB2 you wrote that "openHAB send command to every channel linked to the item", so I guess this is not supported in openHAB using multiple channels ?
-
@Pauli Anttila, thanks - I have tried your suggestion. It works fine with one exception: The lights cannot be turned off. If the switch is set to false in openHAB UI no message is sent to IHC. However, if you try to turn it on again from UI, then it sends a message to the input toogle switch, which then turns off the light. I can see you are using multi channel link in items. I do not know how that works.
-
Se keepalive regel her lavet af @Claus Skovgaard. Det kan muligvis være løsningen på problemet.
-
Ja, præcis. Det er også derfor, at jeg opfordrer Pauli til at medtage den oprindelige funktionalitet fra binding 1.x, hvis det er muligt. Jeg har været nødt til at definere 3 items i mit eksempel: 1 svagstrøms input til kip 1 Output til lyset 1 virtuel item, som bruges til at styre det med i openHAB og det er ikke særlig elegant. Der er præcis derfor, at jeg har spurgt, om det ikke var muligt at få funktionaliteten med <, >, ON og OFF også i binding 2.x, fordi så ville alt blive meget nemmere.
-
Things, Channels og Item er alle begreber indenfor openHAB version 2 - se mere her. Det betyder, at man skal vænne sig til dem, når man arbejder med bindings version 2, uanset om det er til IHC eller andet. Det er ret smart, og giver bl.a. nem adgang til at arbejde med flere IHC controllere på en gang. Men i den nye binding lægge Pauli op til, at funktionerne <, >, ON og OFF forsvinder, hvilket er uheldigt. Det er ret unikke funktioner, og jeg har lavet eksempel på dem i dette indlæg.
-
Jeg prøver blot at genskabe den samme funktionalitet, som jeg opnår med <, >, ON og OFF funktionerne i binding 1.x. Disse funktioner mangler som bekendt i binding 2. Og med mit tiltænkte løsningsforslag til at opnå den samme funktion har jeg brug for at kende disse - ellers kan jeg ikke få det til at virke. Hvis du har et smart forslag til, hvordan man enkelt kan opnå det samme, så vil det være særdeles velkommen. I din eksisterende binding 1.x kan du blot for et enkelt test item undlade at bruge >, <, ON og OFF og så prøve at opnå den samme funktion på anden vis :-) Dvs. ingen direkte ændring af outputs i IHC - alle ændringer skal ske via input. Og konsekvensen af fysiske tryk skal selvfølgelig afspejles direkte i openHAB som du kender det.
-
From ihc.rules: //Spisestue syd test openHAB2 rule "Living room toogle switch - UI" when Item IHC2UI changed then {IHC2SpisebordKip.sendCommand(ON)} Thread::sleep(1000) {IHC2SpisebordKip.sendCommand(OFF) } end //Spisestue syd test openHAB2 rule "Living room toogle switch - physical contact" when Item IHC2Spisebord changed then {postUpdate(IHC2UI,IHC2Spisebord.state)} Thread::sleep(1000) end From ihc.things ihc:controller:haldIHC [ ip="192.168.1.31:444", username="xxxxx", password="yyyyy", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: Type switch-channel : my_test_switch "My test Switch" [resourceId=2845531, direction="ReadOnly"] //output Type switch-channel : SpisestueLoftSydKip "Spisestue syd kip" [resourceId=1417818, direction="WriteOnly"] //input } From ihc.items //IHC binding2 test Switch IHC2Spisebord "Spisebord2" {channel="ihc:controller:haldIHC:my_test_switch"} Switch IHC2SpisebordKip "Spisebord2Kip" {channel="ihc:controller:haldIHC:SpisestueLoftSydKip"} Switch IHC2UI "Spisebord2UI" <phlampe> Comments My preference is to have IHC hold all logic, and therefore I will not modify any outputs directly. Instead, on or off in openHAB should simulate physical press on an input button. By doing that the very same logic in IHC will be executed as if it was pressed. This is very easy in binding 1.x using <, >, on and off, but quite cumbersome in binding 2.x where this functionality in the binding does not exist. Instead, it can be simulated, and I have shown an example here using a toogle input. It is working fine except in the scenario of an ultra short physical press on the button. Suggestions and inputs are welcome. I also tried the new type "pulse-output-channel", but I could not get it working. Item Spisebord2UI is the virtual item. If it is not possible to have these functions in binding 2.x with channels, I will probably just keep using binding 1.x as long time as possible.
-
I have tried with different typs of rules, virtuel items and more channels as you suggested, and I finally found a solution by having the 2 rules with a virtuel item and the correct combination of sendCommand, postUpdate and sleep command. The last is to avoid circular events being triggered on the openHAB bus, when a physical button is pressed. The solution does not work properly in all situations and I do not know why. Anyway, in my case it would mean 2 x 63 = 126 rules, where today I have 0 (zero) rules using openHAB binding 1.x. On top of this comes 63 new virtual items. Therefore, it would be much simpler if it was possible that new binding could have same features as openHAB 1.x with <, >, ON, OFF. Thanks. Ejvind
-
I have 63 switches in my ihc.items file, and they are all using this feature. Besides that I have a few contacts and numbers, and they have mainly readonly definition. One number for the level in my ventilation system has ReadWrite definition. The real use case is that this feature provide a very simple and reliable method of having correct status in openHAB regardless of whether a change was initiated by openHAB UI or a physical input push button attached to IHC. In openHAB it can be quite cumbersome to detect the origin of a change, and suppress additional activities if it was initiated by a physical button, because then everything is done. Before I discovered you smart binding options, I tried a variety of rules including wait, circular refences and sometimes also unintended endless loops inside openHAB. I wrote a posting about this, and it can be read on here (use Chrome to have English translation). With this feature I can map my entire IHC installation quite simple without the need for rules. Rules are only needed, when I would like a special functionality. It is important for me that IHC is the master and holds all relevant logic and status. There are several reasons for this and one is that the installations in the house must always be working without being depending on 3rd party software such as openHAB.
-
Thanks. I have downloaded the new binding 2.x, and it is working fine. Does this mean that the functionality in binding 1.x such as this example in red Switch ForsteSalGarderobeSpotLoft "Spot loftet" <light> ["Lighting"] {ihc="<0x1a7f5b,>[ON:0x255c5a:100],>[OFF:0x255b5a:100]"} will no longer be available using channels in binding 2.x ?
-
I do not know this. Maybe some of the senior guys in this area like @Lars Jacobsen, @Lars1, @Mikkel Skovgaard or @cis2131 can contribute? @Pauli Anttila: Can you provide an example for binding version 2.x of a line in the items file using channel and a Command? In Openhab binding 1.x you had this in the documentation: ihc=">[Command:ResourceId(:VALUE)]" which is a very powerful feature of the binding.
-
Hi Pauli I have it working now, but I do not know the core reason for the problem. After I dropped and recreated it in PaperUI 2 times it suddenly worked. I never received any errors, but no messages were submitted to the IHC controller. At last messages were sent, and the controller reacted to the input. I verified everything in Service View. So everything seems to be fine. Only thing remaining is to test <, > ON, OFF along with milliseconds. This is a very powerful feature of the binding. Looking forward to a line example in the items file for that, so I can test this also. Thanks. Ejvind
-
Thanks - I did add it in the way you have shown, but I could not get it to work in my items file. Can you provide an example of a line in an item file with a manual added channel?
-
I have now tested it again, and it looks good. I can now push and link to an item if needed, and it seems to be fine. However, so far I guess I will just keep an items file, because then everything is scripted which is convient. I have made this test in my items file, and it works fine: Switch IHC2Spisebord "Spisebord2" <phlampe> {channel="ihc:controller:22d2638c:outputs#2845531"} This is really good! I have also tried to add a channel manually, which I could, but I could not get it to work. Maybe because I do not know proper channel naming. @Pauli AnttilaCan you provide an example of a channel like above for a manual added channel belonging to a resource in an function block? From @Pauli AnttilaI would also like a channel example of the <, > ON, OFF, miliiseconds and more cool functions that were in binding 1.x. Then I will test those as well in the new binding. Thanks.
-
In the top built in channels there are only English characters, but in channels in my project there are also national Danish letters. These are not standard, but needs unicode to work. Can this be related?
-
Yes, I have tried refresh and also several different browsers with same result. I do not know if it is related but I am using the new controller hw 7.
-
Hi Pauli Thanks. I have downloaded it and added to addons, and it showing up in Things. Also, it automaticly detects my inputs and outputs as shown below. However, it seems I can only press the blue "O" for the built-in Controller Channels and Signal Strength. All the autodetected content from my installation of type Switch creates no response when the blue "O" is pressed. I am running version 2.3.0. Can you help wit this? Ejvind
-
Hi Pauli Many people including me have benfitted a lot from your original binding 1.x to Openhab. Thank you very much for your effort developing very stable, flexible and robust software which have worked seamlessly for many years now. That you have now decided to develop binding version 2.x for OpenHab2 is the best news in a long time. I would like to participate in testing, and I also have some input to this, which I will send you in a private email. If interested, I can also offer do donate something to you, because your binding has been of great value to me. Ejvind
-
Jeg sammenlignede din items fil med min og kan se, at jeg overalt har Lighting med stor L - dvs. ["Lighting"] . Du benytter et lille L, og jeg ved ikke, om det er case sensitive til homekit, men prøv.
-
Ja, det er nærliggende at tro, at det er årsagen. På dette link har jeg uploadet screen shot fra genstart af min openHAB installation. Der er kun 'Info' rækker og ingen 'Warn' meddelser i min logfil.
-
Check at der er sat korrekt pin code til Homekit og korrekt ip adresse - jeg har lavet et andet indlæg her i ihc user, som viser dette. Prøv evt at pair Homekit igen.
-
HomeKit nulstiller valgte værelse ved OpenHAB genstart
question svarede på EjvindHald's Ole i OpenHAB
Tak for info. Så er konklusionen, at problemet er knyttet til platformen eller rettigheder herpå? -
Ja, det gør jeg. Skriv gerne en privat mail.
-
HomeKit nulstiller valgte værelse ved OpenHAB genstart
question svarede på EjvindHald's Ole i OpenHAB
Tilknytningsforhold til et værelse i Homekit er mig bekendt udelukkende en lokal Homekit setting. Jeg har ikke kendskab til, at man udefra kan diktere, hvor en ny enhed hører til - dvs. heller ikke via sitemap i openHAB. Måske @cis2131 har kendskab til, om det er muligt, fordi han har arbejdet en del med Homekit integration.