Main documentation for openHAB3 OpenWebNet binding >>>
Readme
General information discussion >>>
Thread for openHAB4 discussions >>>
3 Likes
Hi,
Are there any plans to add the dry contact sensors (who25) to the binding? These are used to integrate BTicino BUS with standard switches, contacts and relays. I use many for checking the state of sensors eg weather sensors, door positions etc.They used to work in openHAB 2.
I am not sure if its relevant but CEN plus is also who25, so maybe its not so much work to add the dry contacts 3477, F428 if CENplus is now also working.
gitHub request is here
update⊠there was a problem with the Alexa skill beta sign up which meant that I hadnât really been on the Alexa beta skill when I thought I was. All sorted now.
I am happy to report that the new Alexa beta skill works with openwebnet binding and that the STOP command for blinds no longer needs Alexa routine and mode controller workaround
I deleted the rest belowâŠ
If the shutter position is unknown to the binding , this is the correct message log you get.
I imagine you have set shutterRun. Yet position can become unknown if the binding looses connection to the Bticino gateway.
This is all explained in the binding README
Post crossover. See above edit in my post.
hello!
iâme trying to understand why after 4 days openhab log stops to write log files till i reboot the raspberryâŠ
and looking into log for any hint, iâve seen from time to time this message:
2021-11-23 15:07:59.372 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found device urn:schemas-bticino-it:device:touchscreen:1
2021-11-23 15:07:59.374 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - |- LN4890 (BTicino S.p.A.)
2021-11-23 15:07:59.379 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found BTicino device: not a OpenWebNet gateway or is not supported (UDN=pnp-touchscreen-4_0-00:03:50:A4:AD:6A)
and i get also same messages for devices like Sony TV and other UPNP devices. is this message
related to binding? any idea on how to disable this function?
Good evening all,
Iâm on OH3.2.0.M4, on Windows 10 machine.
Using USB Legrand dongle, to pilot 4 roller shutter.
Everything worked fine for monthes, but since several days, after OH3 re-start, if all works well during a certain period of time (at least, I can open/close shutters using a switch item), it does not anymore the next morning.
I donât know if linked (I can remember if this error was existing before), but I encounter the following error (warning only) at each OH3 server re-start:
2021-11-29 22:17:42.352 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IllegalArgumentException: UID must have at least 4 segments.
at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:71) ~[?:?]
at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:49) ~[?:?]
at org.openhab.core.thing.UID.<init>(UID.java:48) ~[?:?]
at org.openhab.core.thing.ChannelUID.<init>(ChannelUID.java:51) ~[?:?]
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetAutomationHandler.refreshDevice(OpenWebNetAutomationHandler.java:174) ~[?:?]
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetBridgeHandler.refreshAllDevices(OpenWebNetBridgeHandler.java:400) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
I deleted & re-created bridge & things, no change.
What is strange is that it works for some minutes/hours right after re-start (even after this warning error), but no more the next morning. All automatic opening/closing fired by rules does not work as a consequence.
Any idea on where it could come from?
Thanks in advance
Some of my MH202 scenarios stop working after I reboot the RPi4. The âonly ifâ conditions for the affected scenarios stop working and the scenarios do not run. The affected scenarios are CEN activated from another MH202 scenario. Like a subroutine. The âonly ifâ conditions are a test for a boolean value and a test for switch on or off state. Toggling the switch does not help get the routine running again but if I remove the conditions on one of the affected scenarios then it runs but others do not.
What does the binding do at start up that could cause this and is the start up behaviour different from disable/enable (REST API) and stop/start ( Karaf console) ?
I have the RPi on a UPS, so reboots only happen when I command it. Even so, I need to rely on the MH202 scenarios running when I am away. If they stop I have to reboot the MH202 to get them working again. I do not think I can do that remotely and have to press the physical reset button on the MH202.
yes the log message is produced by the openwebnet binding. I lowered it to DEBUG level so it will not be printed anymore (change has been submitted to be included in OH3.2).
However I do not understand why this should be related to the stopping of writing logs. Is there any other message/error near the last written log message?
Very strange! Can you post here your configuration for things/items that are involved it the rules that do not work anymore the next morning?
Hi Massi
Thanks for your interest.
I think I got some elements, itâs not due to the binding 
Indeed, very suprisingly, after any update of the my.items file - Yes, I still manage some manually, to keep a backup -, when I save the file, then the controls of my roller shutters (inc. when triggerd from rules) do not work anymore until I re-start Openhab server.
The point is that itâs the only binding not working anymore after an update ⊠
Need to further investigate.
(Iâm on 3.2.0.M4).
can you be more precise? what does not work exactly? are you able to send the shutters a UP or DOWN command?
at startup the binding needs to âre-synchronizeâ the state of all things (because they may have changed on the gateway while the binding was disconnected), so it will send a âstate requestâ for all things/channels, except for CEN/CEN+ which are not state channels but trigger channels (they do not have a state)
OK thanks⊠So far it seems to be some (?) MH202 scenarios with switches in the only if conditions that fail to work after OH restart. I was wondering if I disable the thing before reboot and reenable it after reboot maybe the binding will not try to synchronise? Could it be that the sync request overwhelms the MH202? I tried toggling the effected switches used in the MH202 âonly ifâ scenario conditions but it did not appear to work. Only rebooting the MH202 gets it all working again.
I would consider moving some MH202 scenarios to OH but I need the dry contacts to work and some are mission critical and I still view OH as developmental and more likely to fail. The MH202 maybe be dumb but it works reliably works except now for the OH interference.
M
No, I canât do anything, Up & down trigger does not work, no reaction.
By the way, here are my things & items configuration:
.things
Bridge openwebnet:zb_gateway:donglelegrand [serialPort="COM3"]
{
zb_automation voletsroulantthibault "ZigBee Automation Volets Thibault (WHERE=767876301#9)" [ where="767876301#9"]
zb_automation voletsroulantclement "ZigBee Automation Volets Clément (WHERE=767877401#9)" [ where="767877401#9"]
zb_automation voletsroulantparents "ZigBee Automation Volets Parents (WHERE=767878401#9)" [ where="767878401#9"]
zb_automation voletsroulantbureau "ZigBee Automation Volets Bureau (WHERE=767876801#9)" [ where="767876801#9"]
}
.items
Group gVolets "Volets Roulants" <rollershutter>
Rollershutter ChambreThibault_Shutter "Volets Chambre Thibault" <rollershutter> (gVolets,gGoogleHome) {ga="Blinds",channel="openwebnet:zb_automation:donglelegrand:voletsroulantthibault:shutter"}
Rollershutter ChambreClement_Shutter "Volets Chambre Clement" <rollershutter> (gVolets,gGoogleHome) {ga="Blinds",channel="openwebnet:zb_automation:donglelegrand:voletsroulantclement:shutter"}
Rollershutter ChambreParents_Shutter "Volets Chambre Parents" <rollershutter> (gVolets,gGoogleHome) {ga="Blinds",channel="openwebnet:zb_automation:donglelegrand:voletsroulantparents:shutter"}
Rollershutter ChambreBureau_Shutter "Volets Bureau" <rollershutter> (gVolets,gGoogleHome) {ga="Blinds",channel="openwebnet:zb_automation:donglelegrand:voletsroulantbureau:shutter"}
There is no error in the logs.
how do you send UP/DOWN commands ? via WebUI ? or other? Why there is no shutterRun parameter configured in your .things file ?
I do it via the MainUI.
Example in one room.
component: oh-rollershutter-item
config:
icon: oh:blinds
item: ChambreBureau_Shutter
title: Volets Bureau
vertical: false
I never parametered any shutterRun parameter, so default value used âAutoâ
Only âissueâ is that when I save the .items file (when improving on my OH3 with new items), I need to re-start Openhab to have it working again. Itâs not a big deal. When playing with my OH instance, I just need to not forget to re-start the server, otherwise, next morning, I need to use switches on the wall to open shutters, or I stay in the dark 
Massi has been busy
Do I just need the one kar file and latest snapshot?
Thanks Massi
@massi I will test this today/weekend
See info here:
Starting from OH 3.2.0.M5 you should be able to install it from Marketplace; dependencies should be auto-resolved.
But you should remove other versions.
No issues so far. All my dry contacts sensors are back in operation. No changes were needed to OH2 things, items or rules. Nice 