The problem does seem to be in the Units. Here is an extract from the log when I change the setpoint temperature
2023-11-05 09:16:09.887 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'ThermoOffice_SetpointTemperature' received command 24
2023-11-05 09:16:09.890 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ThermoOffice_SetpointTemperature' predicted to become 24
2023-11-05 09:16:09.893 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ThermoOffice_SetpointTemperature' changed from 23 Ā°C to 24 Ā°C
The Setpoint receives the command 24 not 24 Ā°C. The predicted value is also 24 not 24 Ā°C. The state change event is correct however with 24 Ā°C. If this is the problem, how do I correct it?
If the problem is not with units of measure (see also @bastler suggestion), then the DEBUG level log is required.
The log you posted above is INFO and does not help.
See my link above on how to set log correctly for both the openwebnet binding and the openwebnet4j lib.
this line means the command to change temperature sent by the OpenWebNet binding is not accepted/understood by your gateway.
Can you send the Thing configuration? If itās configured using WebUI then go to the Thing settings, then copy what is in the Code tab
what is the model of the BTicino gateway to which OH is connected ?
can you confirm that your thermostats are in āstandaloneā mode, that means there is no 99-zone nor a 4-zone Thermo central unit in your BTicino system?
On reflection, this must be an issue relating to the changes from 3.2 to 4, probably the new Java engine. Since the hardware has not changed and it all worked before, I assume that OH is no longer sending the same string of commands. My system is running with OpenHabian on a raspberry pi4. If it would help, I could try re-installing 3.2 on my pc to see what commands are sent with that version.
What is needed is the Thing configuration for one of the 3 thermostats Things, better the one you already tested in the previous test.
What you pasted here is the bridge Thing (maybe delete and correct the message)
This part in fact has been updated from OH 3, so what I am suspecting is a wrong configurationā¦
The other thermostats are configured as 2#1 and 3#1. I think I remember that I had to change these from 1, 2 or 3 which were the default values by adding the #1 manually to each configuration for it to work under OH 3.3
I have tried deleting the Office Thermostat and re-installing it. The default configuration is now 1, but OH will no longer connect to it giving an UNKNOWN message.
The right configuration should be now (since OH 4) where=1 for Zone 1 for standalone thermostats.
Can you try it?
Deleting the Thing and re-discovery it should also work, but then you have to be sure the same Thing UID is used, otherwise the Item will not be connected anymore and you will have to link again the Item to the Thing channel.
I tried changing the 1#1 to 1 in the properties page, but the device went UNKNOWN when I saved it. Changing back to 1#1 left the device still UNKNOWN so I have lost all the data from the thermostat. I will start again tomorrow reinstalling the thermostats and copying the logs.
I have managed to get one of the thermostat setpoint functions working with just the configuration 2, rather than 2#1. Great. For your info, I have attached the log file section as it does seem to throw an exception when it first tries to send the command, but then seems to re-establish a connection which then works. Is this a problem or is it what you would expect?
Thanks for the help in getting things going again.
Great that the thermostat now works with the correct configuration.
In fact this was a required configuration change from OH 3.x to OH 4 in the case of standalone thermostats.
Re-establish of the command connection is perfectly normal since the binding closes the connection after a while if no command is sent.
Good evening everyone, my configuration is Raspberry 4, openhab 4.01 and MH201. I have about 80 switches and 10 zone probes; I also have the 3550 control panel with 99 zones. Iāve been using OH for 4 years now and have never had any major problems. there is one thing I canāt fix in my sitemaps graphics; if the zone probe has a local setting other than 0 the graph has a strange trend when the weekly program settings change.
The problem was that the Area/General messages of scenarios or physical devices did not update the status of OH elements. The previous beta version you shared solved this behaviour and OH was able to update itself and have the correct light status.
Group command was not optimised and although all lights could be switched on/off, the command was sent for each element.
If I change the configuration using bus_light_group thing and item, instead of sending a command for each element the Area/General message will be used. Is this correct? This thing should be the one to be covered by test?
correct, now if you send a ON command to a bus_light_group thing configured for an Area like in my Sample configuration, the command is sent only once to the BUS and the area thing/item is also updated correctly
ciao Massi.
The local probe in this case was -3; but this behavior also applies with +3,+2,+1,-2, -1 and protection/antifreeze.
The setpoint (impostata) changes as the time changes and is set on the control unit with TiThermo.
In my graph the problem is on the āThermo_Zone_WHERE5_Temperatura_impostataā.
Naturally it behaves this way with all similar items.
