Hop til indhold
IHC-User.dk

Pauli Anttila

Members
  • Antal indlæg

    56
  • Medlem siden

  • Senest besøgt

  • Days Won

    2

Pauli Anttila last won the day on July 5

Pauli Anttila had the most liked content!

Om Pauli Anttila

  • Rang
    Member

Seneste besøgende på profilen

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

  1. 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"}
  2. 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" }
  3. 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.
  4. 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
  5. 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]"
  6. 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.
  7. 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.
  8. Pauli Anttila

    openHAB2 IHC binding

    Yes, this is how it works as trigger parameter is not yet implemented
  9. Pauli Anttila

    openHAB2 IHC binding

    Well, my idea was to introduce trigger parameter to pulse output channel, where you can choose when pulse is send (ON->OFF, OFF->ON, Both) Then following should work. Type switch-channel : ihcoutput "IHC output" [ resourceId=1736539, direction="ReadOnly" ] Type pulse-output-channel : ihcinput1 "IHC input 1" [ resourceId=2448474, direction="WriteOnly", pulseLength=1000, trigger="ON" ] Type pulse-output-channel : ihcinput2 "IHC input 2" [ resourceId=2448218, direction="WriteOnly", pulseLength=1000, trigger="OFF" ]
  10. Pauli Anttila

    openHAB2 IHC binding

    OK, reason why it doesn't work is that currently pulse output channel only send pulse when state changes from off to on. So if I extended the pulse output channel so that pulse can be configured to send also when state changes from on to off, it most probably work fine then. OpenHAB support multi channel linking and it doesn't have any black magic behind. When item receive a command, openHAB send command to every channel linked to the item. When channels are updated, item state is updated as well. IHC binding channels support direction configuration parameter, so if ReadOnly is enabled, IHC binding doesn't send any commands from item to configured IHC resource. If IHC binding receive update from IHC controller, channel is updated. If WriteOnly is enabled, binding just send commands to IHC controller, but doesn't update the channel state when update is received from IHC controller. So direction works exactly like < and > operators in version 1 binding.
  11. Pauli Anttila

    openHAB2 IHC binding

    @EjvindHald, I think following should work fine? Channels: Type switch-channel : ihcoutput "IHC output" [ resourceId=2845531, direction="ReadOnly" ] //output Type pulse-output-channel : ihcinput "IHC input" [ resourceId=1417818, direction="WriteOnly", pulseLength=1000 ] //input Items: Switch IHC2Spisebord "Spisebord" { channel="ihc:controller:haldIHC:ihcoutput", channel="ihc:controller:haldIHC:ihcinput" }
  12. Pauli Anttila

    openHAB2 IHC binding

    @EjvindHald, could you post your test items and rules?
  13. Pauli Anttila

    openHAB2 IHC binding

    @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.
  14. Pauli Anttila

    openHAB2 IHC binding

    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
  15. Pauli Anttila

    openHAB2 IHC binding

    Thanks Mikkel
×

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.