Hop til indhold

EjvindHald

Members
  • Antal indlæg

    542
  • Medlem siden

  • Senest besøgt

  • Days Won

    28

Indlæg skrevet af EjvindHald

  1. 11 timer siden, Kandersen skrev:

    Er med på dit eksempel. Og også på at channels er smart, når man har flere "ting/funktioner" i samme enhed. Jeg har andre enheder, som også bruger channels. Men i dit eksempel du lagde op her tidligere, der ser det ud for mig som om, at man skal definere en enkelt items flere gange (fx en switch). Så synes jeg lige det smarte går af.  

    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. 

  2. 12 timer siden, Kandersen skrev:

    Er det ovenstående eksempel på den måde den nye binding er? (Jeg har endnu ikke nået at lege med den). altså hvor du både skal definere channels og items. For hvis det er korrekt, så forstår jeg ikke meningen med det. 

    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.

  3. På ‎30‎-‎05‎-‎2018 at 11:13 , Kandersen skrev:

    Ejvind - Hvorfor er det vigtigt for dig at skelne mellem om en items er blevet aktiveret via OpenHab eller fysisk tryk? Resultatet er vel det samme. Så det du skal, det er at kende status på dit item du har påvirket. Det er dog i langt de fleste tilfælde ikke nødvendigt at kende dette i IHC. Og for de funktioner hvor det er, der kan du hente statusmeldingen direkte fra IHC controlleren og bruge den som en item. 

    Jeg er også lidt usikker på, hvorfor du blander rules sammen med, måden items defineres på (channels)? 

    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.

  4. På ‎30‎-‎05‎-‎2018 at 07:14 , Pauli Anttila skrev:

    @EjvindHald, could you post your test items and rules?  

    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.

     

     

     

  5. 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

     

  6. 8 timer siden, Pauli Anttila skrev:

    @EjvindHald, Currently only one resource Id per channel is supported. It could be challenging to model this in openHAB2. What is the real use case behind this and do you (or anyone else) have many items which use this kind configuration. This functionality can always be imitated by several channels, virtual items and rules.

    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.

  7. 1 time siden, Pauli Anttila skrev:

    I have made lot of improvements the binding and now all features which I planned to implement is implemented. I updated the first post, where is a link to latest jar file and also link to the documentation (draft). I have made some breaking modifications to the binding, so you might need to remove existing thing and add it again. I really appreciate all help in documentation side (more detailed descriptions and examples, etc) as I don't need any documentation myself, so it's purely for your purposes :)

    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 ?

  8. 8 timer siden, Pauli Anttila skrev:

    Does anyone have idea what is the scale (min, max, etc) of the battery level and signal strength for wireless devices?

    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.

     

  9. 22 timer siden, Pauli Anttila skrev:

    You can see full channel links e.g. from Paper UI. In my example (test-switch),

    image.png.4884ff8133086d898dcb5cbb5354a5c0.png

    item definition is 

    
    Switch testSwitch { channel="ihc:controller:elko:test-switch" }

     

    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

  10. 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.

  11. 37 minutter siden, Pauli Anttila skrev:

    Did you try to refresh the page (reload the Paper UI page)? I have seen similar problem, but page refresh have always helped (issue is related to Paper UI not the binding itself).

    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.

  12. 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

    ProblemBinding2x.jpg

  13. 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

  14. Jeg har tilsvarende setup og kan genstarte openHAB, uden at Homekit mister disse oplysninger. Der må ske et eller andet, som gør, at ICloud og Homekit tror, at det er en ny bridge device.

    Måske prøve at slette dit hjem i Homekit, log ud og ind igen i ICloud for at tvinge en sync igennem. Og så vent ca. 30 minutter, inden du opretter nyt hjem. Ved ikke hvorfor men det ligner, at der er forsinkelse på opdatering hos Apple. Det har jeg oplevet flere gange.

    Mit setup af openHAB er linux varianten, som afvikles på en Synology NAS server. Jeg ved dog ikke, om det har betydning i dette tilfælde.

     

     

  15. Hej Mads. Du kan oversætte disse værdier til 0, 1, 2 og 3 i en ny variabel via en simpel rule i openHAB. Denne variabel binder du så til et input talfelt i en IHC funktionsblok. Dernæst koder du denne fb, så det passer til formålet.

    Bemærk at sætte en talværdi kan godt kræve en lidt speciel syntaks i item filen i stil med: {ihc="<0xadd90b,>[*:0xadce0b]"} Der er en * på adressen, hvor du vil sætte en værdi. Hvorfor det skal være sådan, ved jeg ikke, men det fungerer, når der skal sættes talværdier. Jeg bruger selv tilsvarende, så jeg kan direkte sætte trin på mit ventilationsanlæg via openHAB IOS app. 

    Det var @Claus Skovgaard, som meget venligt fandt denne mulighed til mig.

×
×
  • Tilføj...

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.

1200x630bb.png

ok