[OpenWebNet] Thermoregulation support in openHAB3 ready for testing

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?

Try changing the states via the sitemap switch and then see how they respond.

sorry for the delay, i was out some days.
the channel mode seems to work, i can change it via sitemap and the central accepts that. all other issues are as i already wrote.

Did you see any differences in my config files? Mode and weekly program always immediately revert to what is set on the central unit ignoring any site map button pressing

in things my central is similar to yours. what is a little strange for me ist that your thermo-zone-items are just numbers, only “office” has a name, the other items are 1-10.
here my things (with cu and one zone to shorten it):

bus_thermo_cu                 Zentrale_3550               "Heizungszentrale"              @ "Temperatur"  [ where="0" ]
bus_thermo_zone               EGFlur_Heizung              "EGFlur_Heizung"                @ "Temperatur"  [ where="10", standAlone=false ]

and here are my items for the cu:

String iZentrale_3550_Remote "Fernbedienung" { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:remoteControl" }
String iZentrale_3550_Battery "Batterie Status" <battery> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:batteryStatus" }
String iZentrale_3550_ThermoFunc "Arbeitsweise[MAP(de.map):%s]" <settings> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:function" }
Switch iZentrale_3550_1ProbeOff "Mind 1 Heizkreis 'AUS'" <info> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:atLeastOneProbeOff" }
Switch iZentrale_3550_1ProbeMan "Mind 1 Heizkreis 'MAN'" <info> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:atLeastOneProbeManual" }
Switch iZentrale_3550_1ProbeProt "Mind 1 Heizkreis 'FROST'" <info> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:atLeastOneProbeProtection" }
String iZentrale_3550_Failure "Fehler: [%s]" <error> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:failureDiscovered" }
String iZentrale_3550_Mode "Mode[]" <settings> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:mode" }
Number:Temperature iZentrale_3550_ManualSet "Temperatur Global" <temperature> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:setpointTemperature" }
Number iZentrale_3550_WP "Programm[]" <calendar> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:weeklyProgram" }
Number iZentrale_3550_CenPrg "Secnario Prg-Nr" <settings> { channel="openwebnet:bus_thermo_cu:bticino:Zentrale_3550:scenarioProgram" }

i had confgured the weeklyprogram as string before, that was the reason it did not work for me, now correct configured as number and now it works. when i change channel mode to weekly then i can change the channel weeklyprogram from 1 to 3 - and the central accepts that and stays in this program.

maybe you are not in the correct mode? see how i configured my sitemap to prevent changing the weeklyprogramm when not in correct mode:

Switch item=iZentrale_3550_Mode mappings=[OFF="aus", MANUAL="man", PROTECTION="Frost.", WEEKLY="Prog."] labelcolor=[OFF="blue", WEEKLY="green"]
Setpoint item=iZentrale_3550_ManualSet minValue=5 maxValue=30.0 step=0.5 visibility=[iZentrale_3550_Mode=="MANUAL"]
Switch item=iZentrale_3550_WP mappings=[1="Std.", 2="Urlaub", 3="Frost."] visibility=[iZentrale_3550_Mode==WEEKLY]
Setpoint item=iZentrale_3550_CenPrg minValue=1 maxValue=16 visibility=[iZentrale_3550_Mode=="SCENARIO"]
1 Like