Hi Christian.
It’s normal that you encounter “many problems” if you do not read the manual (RTFM).
The first 2 problems you encountered are well documented and explained in the README of the binding in the installation instructions. Just read it.
The 3rd one is a bundle loading error (I am registering the bundle twice), but it does not affect the normal functionality of the binding, so simply leave it there.
Regarding the other errors about INVALID FRAME, it’s true they are not supported yet.
I guess these are rollershutters that use command translation (1000#), meaning they are connected to some non-BTicino system, is this correct?
Are your rollershutters WHERE 11, 12, 21, 31, 32, 42, 51, 52 workin? can be controlled by the binding ?
You may want to file a new issue here to have these commands supported.
correct: these are not implemented, but there already an (old) issue about that.
In any case I will change the log level to avoid rising an ERROR for frames unsupported by the binding.
Hi Luciano,
this issue has been already reported here.
There are some drawbacks about asking a refresh of the state each time a thing is created or a system start.
You can comment your issue there so you can also track its resolution.
bye
massi
@massi
I have now installed the updates from 2.4.0 M5 to 2.4.0 M6, this is the error.
2018-11-21 01:23:20.990 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2018-11-21 01:23:21.833 [ERROR] [org.openhab.binding.openwebnet ] - FrameworkEvent ERROR - org.openhab.binding.openwebnet
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.openwebnet [77]
Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:="optional"
Unresolved requirement: Import-Package: org.osgi.service.component.annotations; resolution:="optional"
Unresolved requirement: Import-Package: org.jupnp.model.meta
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1613) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528) ~[?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
2018-11-21 01:23:39.064 [.ItemChannelLinkAddedEvent] - Link 'Luce_sala-openwebnet:bus_on_off_switch:mybridge:mylig_sala:switch' has been added.
==> /var/log/openhab2/openhab.log <==
2018-11-21 01:23:40.270 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.1.20:8080
2018-11-21 01:23:40.276 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.1.20:8443
2018-11-21 01:23:41.544 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2018-11-21 01:23:46.941 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.openwebnet-2.4.0-b8.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.openwebnet [77]
Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:="optional"
Unresolved requirement: Import-Package: org.osgi.service.component.annotations; resolution:="optional"
Unresolved requirement: Import-Package: org.jupnp.model.meta
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
Hi Massimo I’m italian but if you prefer I can reply to your question in English.
I had already read your RTFM and searched in various posts of internet for a reply to my problems and for this I decided to write this information in this post.
The devices (11, 12, 21, 31, 32, 42, 51, 52) are rollershutters biticino F411/4, and sometimes they do not activate and give me that error message. I have many rollershutters in scheduled rules and I don’t know why they don’t work fine. I wrote this to help you to resolve a BUG. But if for you the ERROR written in the log is good because it is an unsupported command, for me it is not a problem, although I think you should mark it as a WARNING.
Thx for your time.
Christian
@massi
I’m running tests with windows covering and also node-red
Are you sure the percentages are not reversed?
You indicate:
100% closed (minimum light)
0% open (maximum light)
Reading the specifications of Homekit they say the opposite:
100% open
0% closed
I’ll report the portion of the text
Current Position pag. 170
This characteristic describes the current position of accessories.
This characteristic can be used with door, windows, awnings or windows covering. For windows and doors, a value of 0 indicates that a windows (or door) is fully closed while a value of 100 indicates a fully open position. For blinds/shdes/awing, a value of 0 indicates a position that permits the least light and a valueof 100 indicates a position that allows most light.
Me too. That’s the last feature I need to move from Domoticz to OH2.
I have a curiosity: does the actual WHO=4 support the reading of a F430 actuator status? If yes, how?
hello, i’m trying this binding and for the moment (not yet tested connected to my LCD gateway) i only have one issue:
i’ve set all my 5 rollershutters in gPersist and declared * in persist file, but all switches and lights are persited perfectly, but not rollershutters. after openhab service restart, all my rollershutters are showed in sitemap as (for example) “Tapparella Sala -%”.
i also see temperature settings (automatic-manual-antigelo and so on) are not saved after openhab restart…it’s only saved my manual “set_temp” item.
also i got in “openhab.log” an error showing all my openwebnet items ad duplicate, and each item is reported as duplicate for 3-4 times.
is this normal? can you please give me a feedback?
Hi Christian,
the problem with your rollershutters is that they are configured as an external system which uses particular syntax for BUS commands (1000# prefix) that is not supported yet in the binding.
I have added an issue for that, so it will be solved in future releases. In fact the message for unsupported messages should be WARN and not ERROR, i will also correct this.
this is normal and the right thing to do, because after a OH2 restart the state of the devices could have be changed meanwhile , so OH2 does not know the position of the rollershutter anymore, for example.
In any case there is already an issue about this point, but there are good reasons and bad reasons to wait for an update from the BUS before updating the device state after a restart.
is very difficult to understand what is going on and if there is any error without seeing you log at DEBUG level. Read here.
I understand very well the private and work needs.
I saw that the issues 12 AUX there is no planning.
I wondered if it was possible to anticipate AUX.
I abandoned the OH Homekit binding, too much time without knowing anything and no response to posts.
I switched to Node-Red to interface your Openwebnet with Ios.
I will modify the Node-red function to reverse the Rollershutter recognition.
hello Massimo, finally i’ve connected my raspberry back to my LCD/gateway…everything seem to be okay, but i’ve found another “issue”. after openhab service restart, excet blinds that not show the right position, also thermostat settings are not kept with the last setting used. i mean if it’s in manual, automatic, anti-freeze…
i’ve set everything (*) to persist file but these settings aren’t saved. because if i have to restart openhab daily, and i have scheduled at 9am to send up to rollershutter, it doesn’t work correctly.
i suggest to allow to persist for everything (temperature/shutters) at least if i don’t want to persist, i will exclude items i don’t want to. but just give us the possibility to decide this is just a suggestion
another question, is the translation of thermostat settings. have to transform to a map file to make the translation possible?
last: with my thermostats, anti-freeze, normal, off aren’t reported correctly. with one thermostat, normal is reported as anti-freeze. tell me how can help you more…
thanks for all!
edit: here one error, but maybe it’s related to homekit plugin…
2018-12-06 13:44:15.820 [ERROR] [al.accessories.HomekitThermostatImpl] - Unrecognized heating cooling target mode: off. Expected cool, heat, auto, or off strings in value.
this is just a suggestion 