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:
- several enhancements & bugfixes for Thermo Central Unit support:
- added channel
function(HEATING/COOLING) - handle Thermo Central Unit monitoring messages (
AT_LEAST_ONE_PROBE_OFF,AT_LEAST_ONE_PROBE_ANTIFREEZE,AT_LEAST_ONE_PROBE_MANUAL,FAILURE_DISCOVERED) - [FIX] Thermo CU mode set to invalid scenario values Ā· Issue #12417
- [FIX] The Central Unit mode continues to switch to MANUAL Ā· Issue #12401
- added channel
- improved Thermo device refresh at startup
- updated openwebnet4j lib to 0.8.1 release
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.
- Configuration info can be found here.
Configuring Auxiliary
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).
- Configuration info can be found here.
Scenario channels
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? 
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 
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).
Hi @massi yes that is strange. But I just tried again and sure enough, when using the official version, I cannot change my heating set point.
Here is the log when I ask for 19Ā°C instead of 16Ā°C, the command is never send to the BTicino bus and it reverts to 16Ā°C :
2022-06-27 12:11:15.575 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'thermo_1_Living_setTemp' received command 19
2022-06-27 12:11:15.579 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'thermo_1_Living_setTemp' predicted to become 19
2022-06-27 12:11:15.598 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'thermo_1_Living_setTemp' changed from 16 Ā°C to 19 Ā°C
2022-06-27 12:11:19.505 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'thermo_1_Living_setTemp' changed from 19 Ā°C to 16 Ā°C
Also there is that just after, maybe it has to do with the issue :
2022-06-27 12:11:20.236 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item āthermo_1_Living_funcā changed from HEATING to GENERIC