OpenWebNet Binding (Beta)

The functionality (support for Dry Contact and IR interfaces) has been integrated in OH 3.2.0 release.

1 Like

Yep. Deleting the topic can cause problems if you upgrade openHAB for those who have the add-on installed (they have to delete it from userdata/marketplace).

The idea is that you could reuse this topic (edit the title/description and the “published” tag) to act as a “beta channel” whenever you have a new change waiting to be merged, so interested people can easily test it. When there is no pending PR you can unpublish the marketplace entry until there’s something new.

1 Like

3.3 beta 2 appears to have fixed the startup interference issues with MH202 scenarios ‘only if’ conditions.

I am not happy with the thermo support peroformance for the central 99zone thermo unit. I will report in the dedicated thread, but after spending sometime with the 3.3 beta 3 which I am now testing.

First start up errors with beta 3. Things are online/offline as expected even thermo zone 5 online despite messages below. Interestingly I normally use numbers for the thing id but the zone after zone 5 has ‘office’ as the id… maybe coincidence.

All things, items, rules seem to be behaving as normal so far.


2022-01-26 09:02:27.925 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Created a DiscoveryResult for gateway 'MH202' (UDN=pnp-scheduler-1_0-00:xxxxxxxxxxx)

2022-01-26 09:02:27.933 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Created a DiscoveryResult for gateway 'Touch Screen' (UDN=pnp-ts10-2_1-00:03:50:xxxxxxx)

2022-01-26 09:02:28.642 [INFO ] [rnal.handler.OpenWebNetBridgeHandler] - ---- CONNECTED to BUS gateway bridge 'openwebnet:bus_gateway:gateway' (xxxxxxxxx)

2022-01-26 09:02:28.688 [INFO ] [ery.OpenWebNetDeviceDiscoveryService] - newDiscoveryResult() WHERE=w:5#1, deviceType=SCS_THERMO_ZONE

2022-01-26 09:02:28.820 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key openwebnet:bus_thermo_zone:gateway:5 in ManagedThingProvider, because it does not exists.

2022-01-26 09:02:29.073 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler@26933022': null

java.lang.NullPointerException: null

	at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler.initialize(OpenWebNetThermoregulationHandler.java:83) ~[?:?]

	at jdk.internal.reflect.GeneratedMethodAccessor15550.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:829) [?:?]

2022-01-26 09:02:29.084 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'openwebnet:bus_thermo_sensor:gateway:500': null

java.lang.NullPointerException: null

	at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler.initialize(OpenWebNetThermoregulationHandler.java:83) ~[?:?]

	at jdk.internal.reflect.GeneratedMethodAccessor15550.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:829) [?:?]

2022-01-26 09:02:29.105 [WARN ] [rnal.handler.OpenWebNetBridgeHandler] - registering device with an existing ownId=4.500

2022-01-26 09:02:29.107 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler@26933022': null

java.lang.NullPointerException: null

	at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler.initialize(OpenWebNetThermoregulationHandler.java:83) ~[?:?]

	at jdk.internal.reflect.GeneratedMethodAccessor15550.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:829) [?:?]

2022-01-26 09:02:29.111 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'openwebnet:bus_thermo_sensor:gateway:500': null

java.lang.NullPointerException: null

	at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler.initialize(OpenWebNetThermoregulationHandler.java:83) ~[?:?]

	at jdk.internal.reflect.GeneratedMethodAccessor15550.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:829) [?:?]

2022-01-26 09:02:47.242 [WARN ] [rnal.handler.OpenWebNetBridgeHandler] - --- no handler for thing openwebnet:bus_thermo_zone:gateway:5

2022-01-26 09:03:17.173 [WARN ] [rnal.handler.OpenWebNetBridgeHandler] - --- --- CHECKED COMPLETED: ^^^NOT ALL THINGS ONLINE^^^ for bridge openwebnet:bus_gateway:gateway

OH 3.3.0M3 has been published .
For openwebnet it brings:

After updating to 3.3.0M3 I see what appears to be constant disconnections (the bridge goes constantly offline/online):

2022-04-10 14:42:25.142 [WARN ] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## openCommandConnection() returned exception (Could not open BUS-CMD connection to 192.168.1.11:20000 (IOException: Connection refused (Connection refused))) while opening NEW CMD connection

2022-04-10 14:42:25.145 [WARN ] [rnal.handler.OpenWebNetEnergyHandler] - subscribeToActivePowerChanges() Unable to refresh subscription to active power changes notifications for WHERE=w:51. Exception=IOException while sending frame *#18*51*#1200#1*10## or reading response: Cannot create NEW CMD connection to send message *#18*51*#1200#1*10##

2022-04-10 14:42:25.145 [WARN ] [rnal.handler.OpenWebNetEnergyHandler] - subscribeToActivePowerChanges() Unable to refresh subscription to active power changes notifications for WHERE=w:51. Exception=CMD is not connected

2022-04-10 14:53:44.400 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openwebnet:bus_gateway:MYHOMESERVER1_000350a46d47' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Disconnected from gateway.

2022-04-10 14:53:47.007 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openwebnet:bus_gateway:MYHOMESERVER1_000350a46d47' changed from OFFLINE (COMMUNICATION_ERROR): Disconnected from gateway. to ONLINE

mmm. that is really strange: the BTicino gateway seems to refuse connections.
I suggest you restart first the BTicino Gateway and then openHAB.
If it keeps disconnecting, you should set log level to DEBUG and send via PM the whole openhab log.

Not sure if I used the proper “button” for PM, in case you didn’t receive it please let me know

Version 3.3.0.beta5.aux is now published on the Marketplace.
This beta version includes initial support for AUX.

thank you for that new feature!

i could not find the beta in the marketplace (in the official there is the 3.3.0m3 and in the commuinty i only find the thermoregulation from aconte) - so i installed the *.kar manually.

sending aux command works fine, but not receiving of commands. for example i send an aux command to activate burglar alarm. the alarm central sends another aux back to confirm it is activated (so i recieve feedback in case the alarm could not be armed).

as long as no command was sent the item stays NULL

is there a reason why the item type is string? as the states can be ON and OFF it could be a switch (would be easier to manage in sitemap, at least for me)

Hi,
I am glad you enjoy the new aux capability!

I am aware of the issue. Unfortunatelly it is not possibile to get the state of an AUX command (you can only “send” AUX commands), that is why the item’s label remains NULL until a command is sent. Still, alarm commands can (only) have return messages from the bus. So a feature which retrieves the state of the command could be foreseen in the near future.

After several tests I finally realized that Aux things only work if they are set as String!

hi @Giovanni_Fabiani,
thank you for the clarification, so the beta works as expected.

receiving commands from the bus (that are sent from elsewhere, eg alarm central) would be a great enhancement making the aux feature work completely perfect.

that is strange: in my development environment I can find the binding via Marketplace, but I am on OH 3.3.0.SNAPSHOT. Probably Marketplace has still some issue.

handling of AUX commands originating from the BUS is still missing, I already pointed this out to @Giovanni_Fabiani in my GitHub code review. If I understand correctly this could be helpful to identify when another AUX system is activated my other mechanisms/scenarios. It is also needed to change the item value when a AUX command is sent from OH.
My suggestion is to clearly point this out in the binding README, add a new issue for this on GitHub and then leave it for a later addition/submission to the official repo.

actually from the official specs these are all possible values for AUX: ON, OFF, TOGGLE, STOP, UP, DOWN, ENABLED, DISABLED, RESET_GEN, RESET_BI, RESET_TRI. This is probably to support different type of devices using AUX.
So is correct to define the item Type for AUX channels to be String.
But so fare only ON/OFF AUX commands are supported.
@Giovanni_Fabiani again in this case is necessary to describe this limitation of the implementation in the README.

thank you for pointing that out, then of course only a type sting is possible.

did not know all these aux values, i use aux only for arming / disarming the burglar alarm. the reason why it is important (at least for me) to receive aux-commands is that the alarm central sends an aux back when armed / disarmed. this makes me able to know in oh if the command was successfull (eg if a window is open and i send aux to arm the central sends an aux back that arming was not possible). also it could be the alarm is armed / disarmed direct at the alarm central, so it sends the aux to the bus and oh receives that and can switch the item ON / OFF

Version 3.3.0.beta6.scenario-basic is now published on the Marketplace.
This beta version includes initial support for Basic Scenarios (WHO=0).

Hi all,
I’ve got an issue with the Beta binding : My MH200N sometimes become “UNINITIALIZED” and then no related items work anymore obviously.

There are two different cases when it happens :

  • Completely random moment, like today 10:00:10 am
  • Every time I add another binding

The only way I found to have it “ONLINE” again, is remove the beta binding, then install the beta binding again. All my config is in files so as soon as the re install is finished, all is back to normal.

I even made a rule to alert me when my MH200N becomes UNINITIALIZED

What can I provide to help troubleshoot that issue?
Do you have any suggestion for an easier fix in the meantime? :smiley:

hi,

sorry i cannot provide usefull informations. i have the f-454 webserver as gateway and dont realize any issues.
i also owhn a mh200n but it not configured in openhab. i used it earlier for my cenarios but since openhab it is even empty.

i dont use a beta binding, have installed the official version 3.3.0.m7. is there a reason why you still use a beta?

My heating would only work with the beta, so I stick to that.
I removed the beta and installed the official release just now… I’ll see how it goes :wink:

hi @hyzteric this is strange, as the beta published here at the top of this thread has only one improvement related to basic Scenario (WHO=0), all the rest is equivalent to the official version 3.3.0.Mx (which is about to become the 6-month release 3.3.0 in these days).