[BTicino/OpenWebNet] New openHAB2 binding ready for testing

ok @fmalfatto if you set the log at DEBUG level and start a new discovery and copy here the log where the LN4890 is found (just search for “LN4890 ”, I will add it to the offical supported gateways so it can get discovered automatically.

Startup without defining the LN4890 in the things file:

+=== UPnP =========================================
| ID.UDN       : uuid:pnp-touchscreen-4_0-00:03:50:8F:24:74
| ID.MAX AGE : 500
| --------------
| MANUFACTURER : BTicino S.p.A. (http://www.bticino.it)
| MODEL        : LN4890 | Touch Screen Color | 4.0 (http://www.bticino.it)
| FRIENDLY NAME: Touch salone
| SERIAL #     : 00:03:50:8F:24:74
| BASE URL     : null
| UPC          : null
2021-06-21 16:53:38.237 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] -                               |- LN4890 (BTicino S.p.A.)
2021-06-21 16:53:38.245 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found BTicino device: not a OpenWebNet gateway or is not supported (UDN=pnp-touchscreen-4_0-00:03:50:8F:24:74)


After having defined this way
// Touch 3.5 LN4890
        Bridge openwebnet:bus_gateway:LN4890 [ host="", passwd="*******" ] {

Restarted OH :

2021-06-21 17:02:36.045 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - Initializing BUS gateway
2021-06-21 17:02:36.058 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - Creating new BUS gateway with config properties:, pwd=*********, discoveryByActivation=false
2021-06-21 17:02:36.111 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - Trying to connect gateway BUS_192.168.1.50:20000...
2021-06-21 17:02:36.435 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - bridge openwebnet:bus_gateway:LN4890 initialization completed
2021-06-21 17:02:36.440 [INFO ] [bnet.handler.OpenWebNetBridgeHandler] - ---- CONNECTED to BUS gateway bridge 'openwebnet:bus_gateway:LN4890' (
2021-06-21 17:02:36.446 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - updated property gw serialNumber: 00:03:50:8F:24:74
2021-06-21 17:02:36.450 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - updated property gw firmware version: 4.0.15
2021-06-21 17:02:36.462 [INFO ] [bnet.handler.OpenWebNetBridgeHandler] - properties updated for bridge 'openwebnet:bus_gateway:LN4890'
2021-06-21 17:02:36.975 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - Refreshing all devices for bridge openwebnet:bus_gateway:LN4890

I tested it, but I find only temperature and setpointTemperature. Missing heatingCoolingMode, activeMode, heating, cooling …
Did these items change name?

yes, some did, please look here at documentation to see the correct names:

Thank you very much, I missed that post!

Here is a jar which should solve the “flooding on reboot issue” (it does not contain Thermo part yet, as it’s based on 3.1M5). @Rob-VF , @bastler, and @aconte80: if you have time to test it , let me know if it solves the problem.

org.openhab.binding.openwebnet-3.1.0-SNAPSHOT_flooding.jar.pdf (184.6 KB)

Hi all,
As announced by Kai, OH 3.1 is out and it includes support for Thermo (WHO=4) on the official openwebnet binding. A big thanks to @aconte80 for the effort spent on the Thermo part!
Note that compared to the old testing version, Thermo things and channels have been renamed:

  • bus_thermostatbus_thermo_zone
  • bus_temp_sensorbus_thermo_sensor

Refer to the official binding README for details on the new Thermo channels names.
For now, only standalone mode (aka residential mode) has been tested thoughtfully with a real plant: for those who have 4-zone or 99-zone Central Units, try it and tell us what you are missing in this thread.

Next step for the binding will be support for CEN and CEN+: will open a dedicated thread for this shortly.


Ciao Massimo,

I tried to use the .jar extension only but I’m not able to use it, it is not recognized in openhabian.

Probably something is not working properly or I am doing something wrong.

Hello everybody, is there any news about the plan to include CEN/CEN+ support in the OH3 binding?

In the meanwhile, if this can help someone, I am using this code to enable double press detection. This way you have 3 options:

  • Long press
  • Single (short) press
  • Double (short) press

This works reliably if your double press is not too quick (e.g. more or less half a second between the first and the second press). If you double press too quickly, OH interprets it as a single press.

In my specific case:

  • Long press = All rollershutters UP
  • Single (short) press = All rollershutters STOP
  • Double (short) press = Activate a scenario (defined in a separate rule)

Here’s the code:

var Timer buttonTimerUp = null

rule "Traccia pulsante dummy generale Tapp SU (pressione prolungata) e dai il comando a gTapparelle"
		Item iDummy_CEN_Gen_Tapp_SU_rem changed to "RELEASED_EXT"

rule "Traccia pulsante dummy generale Tapp SU (pressione breve) e dai il comando a gTapparelle o accendi modalità estate (giorno)"
		Item iDummy_CEN_Gen_Tapp_SU_rem changed to "RELEASED"
		logInfo("bticino.rules", "button UP pressed")

		if (buttonTimerUp === null) {
			// start the timer
			logWarn("bticino.rules", "Timer Up started")
			buttonTimerUp = createTimer(now.plusSeconds(2)) [ |
				// if the timer expires
				logWarn("bticino.rules", "Timer Up expired")
				logInfo("bticino.rules", "--> Button UP SINGLE pressed")
				// reset the timer
				buttonTimerUp = null
		else {
			// within the timer window
			logInfo("bticino.rules", "--> Button UP DOUBLE pressed")
			// reset the timer
			buttonTimerUp = null

rule "Chiudi tapparelle modalità estate (giorno)"
		Item Chiudi_Tapparelle_Modalita_Estate_Giorno received command ON

Hope someone can find it useful!


Hallo. Thanks all for this beautiful binding. I have a question. How can I create an item with command 610*4000## to open the lock of an external gate? Thanks

Hi, from same week, i don’t can use the binding, becouse have this error:
'openwebnet:bus_gateway:mybridg' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR)
I have installed version 2.5.0.M2-2, and i have tied to unistall and reinstall, but it give me the same error. How i can solve?

Hello @massi,
first of all I’d like to thank you and all the contributors for the great work. I have been using your binding for the last couple years, with great satisfaction.

I just wanted to ask you if there is any update about CEN/CEN+ and if you can point me to the dedicated thread (once it will be opened). Of course if you find it useful I can test and report back, since I use CEN+ in my setup. Thank you!

Yes, me too. I stopped all my tweaking until that’s done and will remain oh 2.5 too, otherwise oh3 becomes a downgrade for me.

Since a few days I’m experiencing issues with the Openwebnet binding.
At some point, I start getting the “CMD is not connected” error.
Even if I cannot send commands, status messages keep working and I can see Items update whenever I turn on/off a light or move a shutter using pushbuttons.

I’ve been able to fix this behavior with a reboot (restarting openhab.service didn’t fix it), but this is the second time in 3 days that this happens, so I’m afraid it will happen again in a few days.

This is the “CMD is not connected” error I was getting before reboot

2021-07-25 15:02:58.372 [DEBUG] [.handler.OpenWebNetAutomationHandler] - Exception while sending request for command DOWN: CMD is not connected
org.openwebnet4j.communication.OWNException: CMD is not connected
        at org.openwebnet4j.communication.OpenConnector.sendCommandSynch(OpenConnector.java:115) ~[bundleFile:?]
        at org.openwebnet4j.OpenGateway.sendInternal(OpenGateway.java:175) ~[bundleFile:?]
        at org.openwebnet4j.OpenGateway.send(OpenGateway.java:155) ~[bundleFile:?]
        at org.openhab.binding.openwebnet.handler.OpenWebNetThingHandler.send(OpenWebNetThingHandler.java:173) ~[bundleFile:?]
        at org.openhab.binding.openwebnet.handler.OpenWebNetAutomationHandler.handleShutterCommand(OpenWebNetAutomationHandler.java:214) [bundleFile:?]
        at org.openhab.binding.openwebnet.handler.OpenWebNetAutomationHandler.handleChannelCommand(OpenWebNetAutomationHandler.java:183) [bundleFile:?]
        at org.openhab.binding.openwebnet.handler.OpenWebNetThingHandler.handleCommand(OpenWebNetThingHandler.java:136) [bundleFile:?]
        at jdk.internal.reflect.GeneratedMethodAccessor64.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
        at com.sun.proxy.$Proxy936.handleCommand(Unknown Source) [?:?]
        at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
        at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
        at jdk.internal.reflect.GeneratedMethodAccessor63.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        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) [?:?]

Before reboot, while checking systemctl status openhab.service, I was getting this warn, which was still there even after rebooting and was fixed by running systemctl daemon-reload:

The unit file, source configuration file or drop-ins of openhab.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Even after reboot, I keep getting a lot of these exceptions:

Jul 25 15:49:20 openhabian karaf[735]: Exception in thread "Thread-1191" java.lang.NullPointerException
Jul 25 15:49:20 openhabian karaf[735]:         at org.openhab.binding.openwebnet.handler.OpenWebNetEnergyHandler.handleMessage(OpenWebNetEnergyHandler.java:184)
Jul 25 15:49:20 openhabian karaf[735]:         at org.openhab.binding.openwebnet.handler.OpenWebNetBridgeHandler.onEventMessage(OpenWebNetBridgeHandler.java:437)
Jul 25 15:49:20 openhabian karaf[735]:         at org.openwebnet4j.OpenGateway.lambda$onMessage$4(OpenGateway.java:188)
Jul 25 15:49:20 openhabian karaf[735]:         at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
Jul 25 15:49:20 openhabian karaf[735]:         at org.openwebnet4j.OpenGateway$1.run(OpenGateway.java:274)
Jul 25 15:49:20 openhabian karaf[735]:         at java.base/java.lang.Thread.run(Thread.java:834)

I am running 3.1.0 on Openhabian (RPI4).

Please let me know if you need any other info to help debugging this error.


I think have the same problem…

If you have a spare rpi (3 is ok) you can temporarily solve using the remote binding, see here

Hi, Thanks.

Yes I was aware but to be honest I wanted to enjoy the summer and later when it gets dark and cold and the nights are long I will look at it again :slight_smile:

today it happened again.
This time I just stopped and started the openhab service, without rebooting the PI.
Since it seemed that the issue was somehow related to the energy handler, I have removed the Energy Meter related Things and it seems that I am not getting any more errors right now.
I’ll keep you posted.

I dont realize any issues, maybe because i do not use energy

@Rob-VF the flooding bug should be included in OH 3.2M1 which should be published in these days, after it’s published you can update directly from the official distribution/openhabian

@Gieffe70 welcome to the community!
For this command to be sent, a generic “send message” command should be added to the binding. Not started to work on it yet.