[OpenWebNet] Thermoregulation support in openHAB3 ready for testing

strange, i also use the 3550 (99 zone central). for me the channel actuator works

my things:

bus_thermo_zone               Buero_Heizung               "Buero_Heizung"                 @ "Temperatur"  [ where="17", standAlone=false ]

and this are my items i use:

Number:Temperature iBuero_Heizung "Büro Ist-Temperatur[%.1f %unit%]" <temperature> (iG_Heizung) { channel="openwebnet:bus_thermo_zone:bticino:Buero_Heizung:temperature" }
Number:Temperature iBuero_Heizung_Set "Soll-Temperatur[%.1f %unit%]" <heating> { channel="openwebnet:bus_thermo_zone:bticino:Buero_Heizung:setpointTemperature" }
String iBuero_Heizung_Mode "Modus" <settings> { channel="openwebnet:bus_thermo_zone:bticino:Buero_Heizung:mode" }
String iBuero_Heizung_Aktor "Heizung heizt![]" <radiator> { channel="openwebnet:bus_thermo_zone:bticino:Buero_Heizung:actuators" }

the actuator is configured as follows

Its working as I can hear it switching a few seconds after changing the thermostat setting

OH3 Items for setpoint , temperature and mode all work as expected. Mode is manual, protection, off… didn’t see automatic when at the 0 degree room offset

for me the actor config looks quite different (in myhome suite):
grafik

and module1 for example:
grafik

i dont use sensors with a wheel for offset, i use 4693 (probe without selector)

when you change the mode from to auto then the channel mode becomes PROGRAM that was confusing for me but i thik this is wanted because in auto mode it runs 1 of the three programms that you can configure in the central - but maybe ther is a little bug, often when i change to auto the binding immediately changes back to manual, if i try more often then it works.

Thanks a lot for your work! I’m testing the 3.3.0-ALPHA-2 version. Currently, it seems to me that the binding works as expected with MANUAL, OFF, PROTECTION, and SCENARIO (I still have to test the WEEKLY one). I few comments regarding those modes:

  • The Central Unit mode continues to switch to MANUAL. For instance, If I change it to PROTECTION, all the setpoint temperatures are correctly set but the Central Unit mode immediately changes back to MANUAL. This happens also if the Central Unit mode is changed outside OH, for instance using the F454 WebUI. Also in this case the Central Unit mode in OH changes to the new value (for instance OFF or PROTECTION) and then back to MANUAL.
  • With MANUAL mode it seems to me that the Central Unit setpoint temperature is set (i.e. written) correctly. Nonetheless, I experienced some issues when reading. If the Central Unit setpoint temperature is modified outside OH (for instance through the F454 WebUI), the new value is correctly reported as a target by each thermostat in OH but not by the Central Unit setpoint temperature.

Got it working.

It used work with heating valves but now its actuators. Also, initially when testing I had actuator missing the s at the end. I changed it but it also needed to toggle the setting to get it updated.

Next problem is how to Grafana to plot OFF, ON as 1, 0. This also used to work without me doing anything but then it was defined as switch. Now its a string.

i dont use persisted string items so i cannot test, perhaps this might still work:

I thought about this some more. The actuator can only be OFF or ON so why is it a string or why isn’t a switch available?

Tried that and it didn’t work. Previoulsy mode worked when it was switch type. With string type then I am going to need to use some messy rules and conversions… not nice really compared to before

as you can see in the docu both channels actuators and heatingvalves can have several states (no matter if you and me dont need that), not only ON and OFF - so i suppose with a switch this would not be possible to manage.

I saw that but the hardware can only be ON or OFF and thats all I see in my case even with string type. The type used to be switch and that worked very well, so it can be done? I don’t know if the other string states are useful?

OH3 RPi4 3550 99 zone central unit
org.openhab.binding.openwebnet-3.3.0.M1.beta3.bootsynch-thermocu

I have some issues with this

  • Mode doesn’t update and remains as manual
  • Manual temperature is always null
  • Scenario/Weekly program doesn’t update
  • The local override isn’t being taken into account for the setpoint value. It does update with local offsets after a binding restart but not with, or least inconsistently, with weekly program setpoint changes
  • As the weekly program changes set points I see an intermediate value. Not sure if this a problem of the binding or my Grafana chart I use to track setpoints

Battery and remote status work as expected. Current temperaure is OK and seems to be updated every 15mins.

As said before I would prefer the actuator channel to be switch type. My actuator can only be ON or OFF and it used to be easy to plot it with Influx/Grafana as it will automatically plot on/off as 1/0

The bootsync part is a big improvement for me. The MH202 now doesn’t get upset on binding restarts.

i suggest you open new issues here possibly detailing for each case the test you do, what happens on the binding and the relevant debug log messages, for example you can take the first two bullets and explain exactly the test steps you do and the results on the binding/thermostat + log messages.

my opinion is that current actuators channel must remain String and support all the possibile values defined in the OWN specs that could be used in other installations/setups.
One possibile improvement is to define another new Switch ON/OFF channel (calling it heating) that collapses the other possibile values to just ON/OFF.

1 Like

Thanks Massi,

The issues with the setpoint values that I saw only happen as the binding restarts or I edit the items file. If I leave it alone it behaves as expected.

I had also thought of translating the string to ON/OFF to a proxy item using rules but it would be much nicer if there was an additinal ON/OFF channel for actuators, etc.

Tip:…Grafana heat maps are very good at showing the whole house status in one chart. Influx automatically translates ON/OFF as 1/0. I use heatmaps for monitoring lighting and heating. If Grafana math is used to scale the 1 to 100 then the heatmap also works great with dimmers(0-100) on the same chart. I guess it woould work with blinds too but havent tried so far.

Hi all,
please let me announce a cumulative update that will be release within next-coming OpenHAB official release.

Changelog (all stuffs are related to the integration with the central unit):

Please have a look to the official README for further details.

2 Likes

thank you for this enhancement! i just installed it and did a short test. some remarks from my side:

  • in the documentation (1. post here) some channels are labeled not quite correct (modeCentralUnit is mode, weeklyProgramCentralUnit is weeklyProgram and scenarioProgramCentralUnit is scenarioProgram)

  • the channel weeklyProgram in my enviroment shows 1970-01-01T00:00:01.000+0000 (at startup when mode is set to weekly) i thought it should show 1, 2 or 3 ?

  • the channel failureDiscovered stays NULL - is this expected as long as no failure is discovered?

Hi @bastler

  1. Thanks for letting me know
  2. It should be either the value setted in the central (if weekly or scenario mode is setted) or undef , for sure not a timestamp
  3. If there isn’t an error it should be false not null

I’ll fix them all, thank you for your feedback

thank you very much @aconte80

one more thing i would like to tell:
the channels atLeastOneProbeOff, atLeastOneProbeManual and atLeastOneProbeProtection are all OFF after a reboot, even when for example some probes are OFF (so channel atLeastOneProbeOff should start ON).
then, when i set for example one probe in PROTECTION the channel atLeastOneProbeProtection switches correct to ON - but it stays ON forever, even if i switch back. this behaviour is the same with all three channels.

Hi @bastler
I’ve just double-checked all points that you’ve raised.

Are you using the official binding 3.3M3 or the preview one? Because these issues are solved in the official binding (just checked).

For example, inside the latest readme OpenWebNet (BTicino/Legrand) - Bindings | openHAB weeklyProgramCentralUnit was already changed to weeklyProgram

hi @aconte80,

i am on 3.3.0.M3 - milestone build and use the official binding, checked in caraf:

291 │ Active │  80 │ 3.3.0.M3               │ openHAB Add-ons :: Bundles :: OpenWebNet (BTicino/Legrand) Binding

ich checked again and confirm having this issues

  • channel weeklyProgram in my enviroment shows 1970-01-01T00:00:01.000+0000
  • channel failureDiscovered stays NULL
  • channels atLeastOneProbeOff, atLeastOneProbeManual and atLeastOneProbeProtectionstay ON forever as soon as they switch to ON never switch back to OFF

regarding the documantation with the old descriptions i meant the documentantion here in this topic at first position.

I updated to 3.3 M3, Previous issues now gone but see some new issues?
Non of the channels are writable. I cannot change the mode setting via sitemap button. The item states do now reflect the 3550 mode. But if I change from manual to weekly program the manual set temperature changes from the setpoint previous manual 20 to 11.5C. No idea where the 11.5 value comes from?
Initial state after creating items:

  • failureDiscovered is OFF
  • atLeastOneProbeOff has state ON but does not update
  • atLeastOneProbeProtection has state ON but does not update
  • atLeastOneProbeManual remains null unitl manual set for a zone on the 3550 unit

I can change the states using the sitemap switch eg set all to OFF Then when setting Protection on one thermostat >> Protection changes to ON, setting to OFF >>> protection stays ON and ‘OFF’ switch became ON and both stay there until I change them on the site map. Likewise manual mode setting on one probe via the 355o cause the manual mode switch to become ON but it does not return to OFF. So, for me its the same behaviour as Stefan saw.

Changing local settings on thermostat shows nothing in the log (min logging) Using site map switches causes these warnings in the log:

2022-04-22 10:48:27.492 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID atLeastOneProbeOff

2022-04-22 10:48:28.656 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID atLeastOneProbeProtection

2022-04-22 10:48:44.040 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID atLeastOneProbeOff

2022-04-22 10:48:45.004 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID atLeastOneProbeOff

2022-04-22 10:48:45.863 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID atLeastOneProbeManual

2022-04-22 10:48:46.516 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID atLeastOneProbeManual

2022-04-22 10:48:47.647 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID atLeastOneProbeProtection

2022-04-22 10:48:48.370 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID atLeastOneProbeProtection

2022-04-22 10:48:49.205 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID failureDiscovered

2022-04-22 10:48:50.016 [WARN ] [er.OpenWebNetThermoregulationHandler] - handleChannelCommand() Unsupported ChannelUID failureDiscovered

.items

Group gCentralUnit                              "Central Unit"     
    String CU3550_mode                          "Mode"                                          <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:mode"}
    String CU3550_function                      "Function"                                      <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:function"}                
    Number:Temperature CU3550_ManualSetpoint    "Manual setpoint temperature"                   <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:setpointTemperature"}
    String CU3550_remote                        "Remote Control"                                <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:remoteControl"}
    String CU3550_battery                       "Battery Status"                                <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:batteryStatus"}
    Number CU3550_wpn                           "Weekly Program"                                <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:weeklyProgram"} 
    Number CU3550_spn                           "Scenario Program"                              <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:scenarioProgram"} 

    Switch atLeastOneProbeOff 	                "A probe is OFF"                                <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:atLeastOneProbeOff"} 
    Switch atLeastOneProbeProtection 	        "A probe is in frost protection"                <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:atLeastOneProbeProtection"} 	
    Switch atLeastOneProbeManual 	            "A probe is in manual mode"                     <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:atLeastOneProbeManual"}
    Switch failureDiscovered 	                "Failure"                                       <temperature>       (gCentralUnit)                          {channel="openwebnet:bus_thermo_cu:gateway:3550:failureDiscovered"} 	

.thing

Thing bus_thermo_cu 3550 "Heating control" [ where="0" ]
    Thing bus_thermo_zone 1 "West bathroom heating zone" [ where="1", standAlone="false" ] 
    Thing bus_thermo_zone 2 "West bedroom heating zone" [ where="2", standAlone="false" ] 
    Thing bus_thermo_zone 3 "East bedroom heating zone" [ where="3", standAlone="false" ] 
    Thing bus_thermo_zone 4 "East bathroom heating zone" [ where="4", standAlone="false" ] 
    Thing bus_thermo_zone 5 "Lounge heating zone" [ where="5", standAlone="false" ] 
    Thing bus_thermo_zone office "Office heating zone" [ where="6", standAlone="false" ]
    Thing bus_thermo_zone 7 "Dining room heating zone" [ where="7", standAlone="false" ] 
    Thing bus_thermo_zone 8 "Guest bathroom heating zone" [ where="8", standAlone="false" ] 
    Thing bus_thermo_zone 9 "Home cinema heating zone" [ where="9", standAlone="false" ] 
    Thing bus_thermo_zone 10 "South bedroom heating zone" [ where="10", standAlone="false" ] 
    Thing bus_thermo_zone 11 "Gallery heating zone" [ where="11", standAlone="false" ] 
    Thing bus_thermo_zone 12 "Utility room heating zone" [ where="12", standAlone="false" ] 


.sitemap … if you want the buttons to have a nice name

Switch item=CU3550_wpn label="Weekly pgm []" mappings=[1="Work", 2="Home", 3="Spring"]

P.s. What does the 'advanced’column signify in the documentation table for thermo?