Jump to content

Pauli Anttila

  • Content Count

  • Joined

  • Days Won


Pauli Anttila last won the day on March 16

Pauli Anttila had the most liked content!

About Pauli Anttila

  • Rank
    Tekniknørd :-D

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I still think that you ihc binding version is wrong. Log shows that controller address in the log is IP not hostname as it should. Connecting to IHC / ELKO LS controller [IP='' Old binding versions defines channel types with channel prefix (switch-channel not just switch), so most probably that's the reason for "Channel type ihc:switch could not be resolved" errors.
  2. @EjvindHald, you log is somehow weird as it miss lot of log information what should be logged in trace and debug level. Please update the latest binding version, clear openHAB caches, etc. You should clear the log file as well. Start whole openHAB and send new logs so that we can see that startup procedure is correct. By command "bundle:list org.openhab.binding.ihc" in Karaf console you should see which ihc binding version you are really using.
  3. @EjvindHald, contact channels have direction which is not support as contact is nativily read only channel, but those shouldn't cause any problems. Otherwise I didn't spot any mistakes. Could you enable trace level logs and sent them as well? Btw, you are not using latest version, but I can't remember if there has been any problems. Here is a link to latest version which I have copied to my dropbox: https://www.dropbox.com/s/xgfj233wdtezlje/org.openhab.binding.ihc-
  4. @Morten H, did you modify auto discovered channel or did you add new custom channel which you modified? I quickly tested with custom channel and pulse width editing works fine on my environment.
  5. Yes, openHAB (exactly speaking the Karaf) have cache folder which can contain old version of the binding. If you are using openhabian, cache folder is /var/lib/openhab2/cache/. Search openHAB forum more. From karat console you can see which version is running. openhab> bundle:list org.openhab.binding.ihc START LEVEL 100 , List Threshold: 50 ID │ State │ Lvl │ Version │ Name ────┼────────┼─────┼────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 300 │ Active │ 80 │ │ IHC / ELKO Binding When handling bindings manually by adding and removing them from add-on folder, it's always wise to stop the current binding before remove it by command bundle:stop org.openhab.binding.ihc And check that bundle State is Resolved before remove it.
  6. @EjvindHald, ip parameter has been changed to hostname very lately. Version which you running still use ip parameter. This can be seen from the debug 2019-04-27 07:58:51.924 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Connecting to IHC / ELKO LS controller [IP='something', username='openhabSVC']. Latest version should debug following 2019-04-27 07:58:51.924 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Connecting to IHC / ELKO LS controller [hostname='something', username='openhabSVC'].
  7. OH1 bindings support both item updates and commands. OH2 bindings supports only commans to channels. Your zwave sensor updates the item state, so update is not propagated to ihc item and therefore not to linked ihc channel. Thats why you need profiles or rule. Follow profile create command from item update, and that command is then send to ihc channel.
  8. @Gilbert, Could you provide debug logs
  9. @Gilbert, If fact, it doesn't work without rules as your zwave sensor doesn't send command but update to the item. So you need to introduce simple rule or use "follow" profile in item definition.
  10. You have different channel names in item and thing files. Item file channels are divhus_ and thing file have drivhus_. Simplifying the setup, I added only one channel to following example. When ever that work, you can add more channels. ihc:controller:elko [ hostname="", username="admin", password="password", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: Type number : drivhus_ihctemp "My Test temp" [ resourceId=2935316, direction="WriteOnly" ] } Number drivhus_sensor_ihctemp (drivhus) { channel="ihc:controller:elko:drivhus_ihctemp" } First of all, I assume that you have linked item drivhus_sensor_ihctemp to your zwave node temperature channel as well (e.g. via PaperUI)? So when ever item drivhus_sensor_ihctemp is update by the zwave node, IHC binding will send item drivhus_sensor_ihctemp value to resourceId 2935316. WriteOnly direction make sure that drivhus_sensor_ihctemp item is never updated from IHC controller (binding just mirror the value from item to IHC). WriteOnly direction is same as '>' in IHC v1 binding. You try to update value to IHC lux / temperatue sensor product? Do you have real lux / temperature sensor device connected to that or is it just virtual device in IHC side? I'm not sure if it's possible to write data to that (never tried that), but if that has been work with OH1 binding then it should work OH2 binding as well.
  11. @Kandersen, I think that is openHAB core issue and not related to binding. I assume that correct level is used if you restart the openHAB?
  12. @Kandersen, from here you can find first test version for configurable ON level. It should work with dimmer channels and you need to add onLevel channel parameter (e.g. onLevel=70). I don't have IHC dimmers so I didn't test it well.
  13. Not sure what do you mean by this? OH2 binding doesn’t have any dependencies to OH1 binding. Or do you mean that is all OH1 features supported by the OH2 binding? If yes, it’s pretty impossible the say as there is so many different ways one can use the binding, so basically you need to try by you self and see if you can fully replace OH1 binding by OH2 binding.
  14. Changes are merged, so latest official snapshot should be ok. Yes, I'm aware of what is happening on development side pretty well. Latest 7 years, I have developed over 10 OH1 bindings, 8 OH2 bindings (+2 is in pipeline), several transformation services and countless amount of improvements and bug fixes to many other bindings and core features.
  15. @Kandersen, the fixes are now merged to main repo. I also fixed the Dimmer ON command bug. Binding now set Dimmer to 100 when ON command is received. In fact, binding set resource to resource max value by ON command and to resource min value by OFF command. Dimmer min is 0 and max is 100, but some other resources min and max could be something else. I didn't introduce configurable level yet.
  • Create New...

Important Information

Privacy Policy 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.