Do you have discovery by activation set to true on the openwebnet bridge configuration? If yes i think this is normal behavior
I am using this jar org.openhab.binding.openwebnet-3.2.0-SNAPSHOT_cen_v3
For the Thermo valves they seem to need to be set as switch type and not string as stated in the docs
Is that correct?
Hi all, I recently switched to openHAB 3.2.0.M4 from 2.5 but I have some issue with Thermo WHO.
I have a 4/99 Zone central Unit and 4 local thermostates. In OH 2.5 I was using local thermo zone and everything was working fine: e.g. setting a target temp on a zone in sitemap was triggering manual mode and heating was turned on.
In OH 3 the 4 thermo zone detect current temp and previosly set target temp correctly but, I’m unable to turn on heating. Also setting mode to Manual won’t force heating to start.
Tried to set Stand-alone to true or false in the thermo zone thing but nothing changed. Autodisovery is not finding any Thermo Central Unit.
Any suggestion?
Thanks,
Marco
the thermo central unit is not included yet but the temperature sensors are already. so you can read the temps of the sensors but not regulate.
Thanks for the feedback.
This is intended or what?
Also the 2.5 binding was not supporting the central unit but I was able to regulare from the 4 zones.
Hi guys,
I’ve just published a preview release of the binding with support for central unit. It’s an alpha release, use at your own risk and feedbacks will be appreciated!
More details on openHAB Marketplace:
or on GitHUB:
just installed and tested, great!
for me it seems everything is working as expected: i can change the setpoint-temp now and the changes are also set in the termo-zone. if zone was in mode “automatic” it changes to “manual” as soon as i change the temp.
when i change back to mode “automatic” (actually not possible in openhab) the setpoint temp changes to the temp that is set for the automatic.
Thank you so much for your great work!!!
It seems to me that the binding is working as expected. I can change the setpoint temperatures in “Manual” mode and the binding and the thermo-zone are always aligned (checked with an F454 gateway). When I put a thermo-zone in “Auto” mode from OFF or Protection, the behavior is the one expected: the mode in the binding is changed to “Manual” and the corresponding setpoint temperature is set to the last one associated to the themo-zone (the one associated to the auto mode or manual mode, according to the last configuration of the themo-zone itself). This is the same behavior you can experience using an F454 gateway. The only two comments I have (but actually I don’t know if already covered by the current development, so in case please ignore them) are:
- Thermo-zone in Protection mode: the setpoint temperature in the binding is not updated to 7 degree (see following figures).
- Thermo-zone in Off mode: the setpoint temperature in the binding is not empty (see following figures).
In both cases the setpoint temperatures continue to point to the last setpoint temperature (manual or auto) associated to the thermo-zone (8 degree in the following figures, “Temp. Soppalco (M)” field).
Seen just now and sounds great… goint to make some test shortly and provide feedback.
Thanks Andrea
Made some testing, few feedbacks hereafter:
- As expeceted manual dependency install from Console to let the binding work (Transport and Upnp)
- Central Unit not supported warning shown in the logs:
newDiscoveryResult() deviceType=SCS_THERMO_CENTRAL_UNIT is not supported yet (WHERE=w:#0)
- If thermo is Off, setting of Zone Temp is correctly triggering the switch into Manual status, Function to Heating and Thermo is Turned On
- If thermo is already On, unfortunately setting of Zone status Off is not triggering Thermo switching to Off
Hi guys,
I’m currently using the official openwebnet binding but interested in the thermo central unit (99 zone) feature. Are there plans about merging this feature in the official binding? Thanks a lot
Hi @Brando, see this post: [OpenWebNet] Support for central units in thermoregulation
We’re working on it!
1 Like
Many thanks Andrea and Massi. I’ll keep checking the news on the community!
Updating heat set point to central unit works well for me too. (I got a 99 temp zone unit)
To help other as it was not straightfoward to me : you need to uninstall your bticino binding then upload the latest alpha jar from
to
/usr/share/openhab
I did restart the openhab service, I don’t know if it was needed though;
you should no longer need to do that because meahnwhile the thermo feature (only display temp without integration of 99 temp zone) is integrated in the official distribution binding (stable release 3.2.0)
Hi @bastler , that’s weird, because I juste reverted to the official binding and it does not work anymore.
I stopped the openhab service, removed the jar, started the service, installed the official binding through the web interface, I did not restart and all my items are back. But I cannot change the heat setpoint.
What could I do to troubleshoot that?
Hi guys,
I’ve just published an updated release of the binding for central unit (ALPHA-2)
As always, feedbacks will be appreciated!
More details on GitHUB:
1 Like
I get following error when it try’s to enable the auto discovered central unit,
may you can have a look.
Tested with openHAB 3.3.0 / Build #2694
2022-01-15 11:22:03.685 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler@d48976': null
java.lang.NullPointerException: null
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler.initialize(OpenWebNetThermoregulationHandler.java:99) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor67.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-15 11:22:03.689 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'openwebnet:bus_thermo_cu:Bticino_F454:0': null
java.lang.NullPointerException: null
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler.initialize(OpenWebNetThermoregulationHandler.java:99) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor67.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) [?:?]
yes, I know. Discovery is one of open points.
You should add CU manually as described in the readme.
Thanks for the hint, missed that, but may you add in the readme that also the bridge need to be defined textual otherwise it gives the same error as when it get discovered.