Hop til indhold

Pauli Anttila

  • Antal indlæg

  • Medlem siden

  • Senest besøgt

  • Days Won


Pauli Anttila last won the day on July 5

Pauli Anttila had the most liked content!

1 Følger

Om Pauli Anttila

  • Rang

Seneste besøgende på profilen

Blokken med seneste besøgende er deaktiveret, og bliver ikke vist til andre

  1. Pauli Anttila

    openHAB2 IHC binding

    Did you already checked the wiki? There is an example. Channels: Type push-button-trigger : my_test_trigger [ resourceId=3988827, shortPressMaxTime=1000, longPressMaxTime=2000, extraLongPressMaxTime=4000 ] } Will trigger LONG_PRESS when button is pressed more than 1000ms but less than 2000ms. Other triggers are SHORT_PRESS and EXTRA_LONG_PRESS. when Channel 'ihc:controller:elko:my_test_trigger' triggered LONG_PRESS then logInfo("Test","Long press detected") end
  2. Pauli Anttila

    openHAB2 IHC binding

    Thanks for the offer.
  3. Pauli Anttila

    openHAB2 IHC binding

    Great Tags are added to items and items are not related to bindings. Bindings communicate via channels.
  4. Pauli Anttila

    openHAB2 IHC binding

    I added airlink_relay, airlink_dimming and resource_humidity_level support to auto discovery. I don't own those devices, so can't test the support either. So someone who own those could try this version. Wireless dimmers supports only direct level adjustment (0-100). So increase and decrease functionality is not directly supported.
  5. Pauli Anttila

    IHC Nøglering og rules - Hvordan fanger man tryk?

    @Henrik Skaarup, trigger channels works without items and can be used directly in rules. rule "Short press" when Channel 'ihc:controller:d1a7b4dc:Keychain_Top' triggered SHORT_PRESS then // do something end
  6. Pauli Anttila

    openHAB2 IHC binding

    That's not correct. Wireless actuators are supported. Only limitation is the auto discovery, where only airlink_inputs and airlink_outputs are automatically discovered. All lego blocks are in place, so what can be configured via ver 1 binding can be manually configured via ver 2 binding as well.
  7. Pauli Anttila

    openHAB2 IHC binding

    @Vagn, I think I have found the reason for you problem. I have only one IHC controller, so I'm not able to test support properly. I made some fixes, so could you try this version? @BrianPedersen, I don't have any wireless dimmers, so I don't have a clue how they are implemented. That's also the reason why I have not included those to auto discovery. Have you used them with binding version 1? If yes, then you should be able add them manually to v2 binding as well. I could add the support, but I need details how they work.
  8. Pauli Anttila

    Læse / skrive IHC timer værdi i OpenHAB

    Some reason Google translator translate pretty "bad" english, so it's pretty hard to fully understand what you try to reach on your example. Anyhow, following configuration is read only from openHAB perpective, meaning that only timer value change in IHC is updated to openHAB item. Number U_TimerVand "Timerværdi for vanding [%.0f]" <time> {ihc="<0x1102410"} So if you change the U_TimerVand item value, it will not be updated to IHC. When every timer value is changed in IHC side (timer is running or you change it via service view), value is updated to openHAB item. Timers are in millisecond resolution in IHC, so I guess that, if timer is running, you will get a lot of updates. Maybe not every millisecond, but very often. So most probably it's not wise to sync timer value between openHAB and IHC. If you just want to change the timer value from openHAB to IHC, you could make it write only (>). If you want to know when timer is expired (counted to 0), your most probably should change the IHC code so that when timer is expired some kind of flag is set, which change is then syncronized to openHAB. Syntax explanation: Syncronization in both directions (IHC <-> openHAB): Number U_TimerVand "Timerværdi for vanding [%.0f]" <time> {ihc="0x1102410"} Read only (IHC -> openHAB): Number U_TimerVand "Timerværdi for vanding [%.0f]" <time> {ihc="<0x1102410"} Write only (openHAB -> IHC): Number U_TimerVand "Timerværdi for vanding [%.0f]" <time> {ihc=">0x1102410"}
  9. Pauli Anttila

    Værdi fra mqtt over til IHC

    You should add comma between different bindings, otherwise it should be correct. Number th01_temp "TH01 Temperatur[%.2f °C]" <temperature> (Sonoff) { mqtt="<[broker:tele/th01/SENSOR:state:JSONPATH($.SI7021.Temperature)]", ihc=">1234567" }
  10. Pauli Anttila

    openHAB2 IHC binding

    I have now used this new version on my "production" openHAB system almost one month without single problem, so it seems to be pretty rock solid. I have done some refactoring to binding since last version (in 1st page). Binding it's not yet merged to openHAB main repo, but official PR snapshot builds can be found here.
  11. Pauli Anttila

    Værdi fra mqtt over til IHC

    Sorry to answer in english, but rules are not needed. It depends how you are using MQTT and openHAB: 1. If you are using MQTT event bus binding configuration (no need to bind items to mqtt as they are binded automatically in event bus level) and you have openHAB item already which have e.g. temperature from MQTT (e.g. mqttTemperature), you just need to bind the item to IHC. Number mqttTemperature "Temperature [%.1f °C]" { ihc=">1234567" } So when ever mqttTemperature is updated, openHAB will send update to IHC resource 1234567. 2. If you are using MQTT item configuration, then you need to add binding to IHC as well. Number mqttTemperature "Temperature [%.1f °C] { mqtt"...", ihc=">1234567" } @Kandersen and @Ejvind Hald can translate if needed
  12. Pauli Anttila

    openHAB2 IHC binding

    @EjvindHald, it works like you have configured it to work . When ever Number item receive a command (1, 2, 3, 4), binding send 1000ms "pulse" to 11390475 resource. When pulseWidth parameter is defined, binding send ON command, wait 1000ms and send OFF command. ON and OFF commands are converted automatically to IHC resource value type. Normally, pulse is used with boolean resource (IHC binary input), but in your case IHC resource value is numeric, therefore binding converts ON command to value 100 and OFF command to value 0. So ultimately binding send value 100 (ON), sleep 1000ms and then send value 0 (OFF). I can't remember why I have selected value 100 when ON command is converted to numeric resource value as conversion functions are taken from OH1 binding. Most probably the reason was that Dimmer item types, value 100 present the full brightness. I guess you want to send a item value rather than generate a pulse, so you shouldn't define pulseWidth in this case. Type number-channel : ihc2number "IHC vent" [resourceId=11390475, direction="WriteOnly"] //vent Then binding send item value (1, 2, 3, 4) to IHC resource, which then match you OH1 configuration ihc="<0xadd90b,>[*:0xadce0b]"
  13. Pauli Anttila

    openHAB2 IHC binding

    If you want that number channel react to all commands, you ignore the whole commandToReact parameter. If you want that channel just react to number 5 then defined so. So commandToReact is exactly the command which you send to items. If pulseWidth is defined, then binding don't send the item value but generate the pulse.
  14. Pauli Anttila

    openHAB2 IHC binding

    Just updated the link to latest binding version. I have made many breaking changes to the binding. I removed pulse output channel as now every channel can send pulse if pulseWidth parameter is defined. Every channel also have now commandToReact parameter which can be used to filter commands. So following should be now possible Type switch-channel : ihcoutput "IHC output" [ resourceId=1736539, direction="ReadOnly" ] Type switch-channel : ihcinput1 "IHC input 1" [ resourceId=2448474, direction="WriteOnly", pulseWidth=1000, commandToReact="ON" ] Type switch-channel : ihcinput2 "IHC input 2" [ resourceId=2448218, direction="WriteOnly", pulseWidth=1000, commandToReact="OFF" ] I have not test new version very well, so there could be bugs.
  15. Pauli Anttila

    openHAB2 IHC binding

    Yes, this is how it works as trigger parameter is not yet implemented

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.