I wonder if that was the same problem with the old binding crashing the mh102
No, the refresh status after reboot was added last month and only to OH3
Yes, you can donate just to say thanks or, like others did already, to express your interest to new features/next steps for the openwebnet part and support them.
See here: openwebnet4j | A Java library for the Open Web Net protocol
Another way to also attract new developers is to open a new request through an issue here, and then put a bounty on it here: https://www.bountysource.com/teams/openhab.
I never used this Bountysource so I do not know how it works in practice.
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.DESC URL : http://192.168.1.50:49152/
| 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="192.168.1.50", 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: 192.168.1.50:20000, 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' (192.168.1.50:20000)
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_thermostat→bus_thermo_zone -
bus_temp_sensor→bus_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.
4 Likes
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"
when
Item iDummy_CEN_Gen_Tapp_SU_rem changed to "RELEASED_EXT"
then
gTapparelle.sendCommand(UP)
end
rule "Traccia pulsante dummy generale Tapp SU (pressione breve) e dai il comando a gTapparelle o accendi modalità estate (giorno)"
when
Item iDummy_CEN_Gen_Tapp_SU_rem changed to "RELEASED"
then
logInfo("bticino.rules", "button UP pressed")
if (buttonTimerUp === null) {
gTapparelle.sendCommand(STOP)
// 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")
Chiudi_Tapparelle_Modalita_Estate_Giorno.sendCommand(ON)
// reset the timer
buttonTimerUp.cancel
buttonTimerUp = null
}
end
rule "Chiudi tapparelle modalità estate (giorno)"
when
Item Chiudi_Tapparelle_Modalita_Estate_Giorno received command ON
then
iCucina_tapp1.sendCommand(0)
iCucina_tapp2.sendCommand(80)
...
...
end
Hope someone can find it useful!
3 Likes
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.
Hello,
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.
Thanks
I think have the same problem…
@m4rk
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 
Hello,
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.