Hi Massi, thank you very much for your reply.
Can I install the binding you made for OH2.5 on OH3.3?
Without being able to return the single thermostat to AUTO, I do not find this binding useful. I try to explain myself: on the old binding I could not modify the control unit (but in the end the control unit does nothing but act as a chronothermostat for the zones that are set in automatic), but instead it was very useful to be able to manually put the zones I wanted to force (like I stay at home one day and I want to heat the tavern, here I put that probe in manual and when I stop using the tavern I put it back on automatic). I don’t know why only 3 states were put on the zones, when in reality the protocol foresees 4 (i.e. OFF, PROTECTION, MANUAL, NORMAL). Where NORMAL is intended as operation dictated by the control panel.
I add the thread on github, thank you very much and good evening!
no, the 2.5 version of the binding is not compatible with OH3
If I remember well this was mainly because this case was difficult to test in practice: in Andrea’s system there is no such configuration (all thermostats are independent)
Damn, so you advise me to stick with OH 2.5? If needed, I can test everything you need. I have a system with 120 light points, 16 shutters, 8 sound diffusion zones, alarm system with the old control unit, 15 heating zones, 2 of which with fan convectors, 3550 control unit, load control. I’ve been looking for a complete configuration for years, but I found the balance with your 2.5 because at least the thermoregulation works well. If you plan to add temperature control with the auto function on individual zones, try me as a beta tester 
since we cannot say if and when this feature will be added (it depends on other priorities and available volounteers developers) and since this feature is so important for you, I suggest to use OH2.5 until at least is available for testing.
No other user has asked this missing feature so far, if I am not wrong.
Remember to add the feature request to GitHub, so you will be able to track progress.
thanks Massi. can you tell me where to write on github? I searched but couldn’t find where to add the request. Can you post me the correct link?
Meanwhile, on OH2.5 I don’t understand why it’s been two weeks since the cloud sometimes sees my account offline (yet the seecret and UUID are correct). And today he is making strange gestures to me telling me that the map is not loaded or that it is not there, but if I enter the cloud from the web then I will find it. Do you know if there are ongoing problems on the iOS App?
I alreaedy did in my previous post above:
I have read on the community there have been some instability problems with the OH cloud. You can find some info for example in this thread.
Regarding the map: I cannot help as I do not use the iOS App.
Also let’s keep the discussion here about the openwebnet binding: for other issues use other threads in the community.
Hi,
I know that the auto function in thermo regulation doesn’t work but I have a problem also in normal mode.
If I set the item setpointTemperature the zone doesn’t start. Why?
With OH 2.5 it runs well.
P.S. I have a 99 zone central
Thanks
it’s necessary to have some logs using DEBUG level, from when you change the setpointTemperature
What is your thing configuration of the thermo zone?
Did you explicitly set the standAlone parameter to false (it defaults to true)? If you have a central unit, you need to set it to false.
like so:
Thing bus_thermo_zone LivingRoom_Thermostat “Living Room Thermostat” [where=“3”, standAlone=false]
at the end I added the feature request on github:
Thank you very much! I didn’t know where to start
For testing I’m always available, I’m still officially using version 2.5, but I already have a raspberry 4 running with the new release.
Have a good evening!
Thanks for the response.
I didn’t know needed set a parameter.
After set the parameter the problem remain yet.
The log show only this string:
@ins90 can you post here your Thing configuration?
(either from text file or -if you use only the UI- the thing configuration page in the UI)
@Ins90 can you change in the Configuration of yout thermo zone 1 Thing the OpenWebNet Address (where) parameter:
1#1 to → 1
this is the issue causing setpointTemperature not to work.
(There is an error in the Thing discovery, setting this parameter to a wrong valure. An issue has been opened to address this).
Not a negative post about an issue or something but something positive you guys might like that can be done with this great binding and because Thermo functions are in focus at the moment.
Grafana heat maps are a nice way to show at a glance a lot of data
eg
Below are my heating actuator states and the corresponding heat map for each of the thermo zones. The heat map shows how far from the target temperature each zone is. As you can see by the blue shaded zones the corresponding heating actuator is ON (black bar). The target temperature is the combined program/scenario temperature and the local offset. ie the target changes depending on the time of day.
To generate this type of chart you need a rule to convert the actuator string type to a number or switch type. I was thinking it might be an enhancement for the binding to have a channel that was the delta between the target and the measured temperature… Good idea?
Thanks massi, now everything works well! Finally
Good morning,
I am new to openHAB, having just installed it and integrated it with our BTicino automation system, mainly to control lights and shutters. So first, thanks to the developers here for the great work!
In my first tests I run into one issue: it seems the ON/OFF status of lights in openHAB is not updated when they are switched by general/area/group commands in BTicino.
I have created the things in openHAB from the automatic scan of the binding, and then created light items from the things. If I switch them individually it works, and I can also switch them from openHAB. However, if I use one of our general or area light switches to turn lights off, the status in openHAB is not updated.
Is this a known limitation of the binding, or am I doing something wrong?