[OpenWebNet] Thermoregulation support in openHAB3 ready for testing

Hello community,

We are happy to announce of the BTicino (Legrand) / OpenWebNet binding for openHAB 3 with support for Thermoregulation (WHO=4).

Supported so far:

  • stand-alone thermostats (like LN4691)
  • sensors (like NT4577)
  • 3550 central unit

Not yet tested:

  • 4 zones central unit (like N4695)

The purpose of this community thread is to acquire your feedbacks in order to include all new Thermoregulation features, tested, in the next major release of OpenHAB (3.1).

Open / missing points:

  • [central unit] Read setPoint temperature and current mode
  • [central unit] Holiday activation command (all zones)
  • [central unit] Discovery

Documentation:

Thermo channels

Channel Type ID (channel ID) Applies to Thing Type IDs Item Type Description Read/Write Advanced
temperature bus_thermo_zone, bus_thermo_sensor Number:Temperature The zone currently sensed temperature R N
setpointTemperature bus_thermo_zone, bus_thermo_cu Number:Temperature The zone setpoint temperature R/W N
function bus_thermo_zone String The zone set thermo function: COOLING, HEATING or GENERIC (heating + cooling) R/W N
mode bus_thermo_zone String The zone set mode: MANUAL, PROTECTION, OFF R/W N
speedFanCoil bus_thermo_zone String The zone fancoil speed: AUTO, SPEED_1, SPEED_2, SPEED_3 R/W N
actuators bus_thermo_zone String The zone actuator(s) status: OFF, ON, OPENED, CLOSED , STOP, OFF_FAN_COIL, ON_SPEED_1, ON_SPEED_2, ON_SPEED_3, OFF_SPEED_1, OFF_SPEED_2, OFF_SPEED_3 R Y
heatingValves bus_thermo_zone String The zone heating valve(s) status: OFF, ON, OPENED, CLOSED , STOP, OFF_FAN_COIL, ON_SPEED_1, ON_SPEED_2, ON_SPEED_3, OFF_SPEED_1, OFF_SPEED_2, OFF_SPEED_3 R Y
conditioningValves bus_thermo_zone String The zone conditioning valve(s) status: OFF, ON, OPENED, CLOSED , STOP, OFF_FAN_COIL, ON_SPEED_1, ON_SPEED_2, ON_SPEED_3, OFF_SPEED_1, OFF_SPEED_2, OFF_SPEED_3 R Y
localOffset bus_thermo_zone String The zone local offset status: OFF, PROTECTION, MINUS_3, MINUS_2 , MINUS_1, NORMAL, PLUS_1, PLUS_2, PLUS_3 R Y
remoteControl bus_thermo_cu String The Central Unit Remote Control status: ENABLED, DISABLED R Y
batteryStatus bus_thermo_cu String The Central Unit Battery status: OK, KO R Y
modeCentralUnit bus_thermo_cu String The Central Unit set mode: MANUAL, OFF, PROTECTION, WEEKLY, SCENARIO R/W N
weeklyProgramCentralUnit bus_thermo_cu String The program number (1, 2, 3) when Central Unit mode is WEEKLY R/W N
scenarioProgramCentralUnit bus_thermo_cu String The program number (1, 2, … , 16) when Central Unit mode is SCENARIO R/W N

Download:

version date download link
3.1.0 ALPHA 1 31 May 2021 download
3.3.0 ALPHA 2 15 Jan 2022 download

Full Example

openwebnet.things:

BUS gateway and things configuration:

Bridge openwebnet:bus_gateway:mybridge "MyHOMEServer1" [ host="192.168.1.35", passwd="abcde", port=20000, discoveryByActivation=false ] {
      bus_thermo_cu              CU_3550           "99 zones central unit"    [ where="0" ]
      bus_thermo_zone            LR_thermostat     "Living Room Thermostat" [ where="2"]
      bus_thermo_sensor          EXT_tempsensor    "External Temperature"   [ where="500"]
}

openwebnet.items:

Example items linked to BUS devices:

Number:Temperature  iLR_thermostat_temp         "Temperature"                             (gLivingRoom)                                { channel="openwebnet:bus_thermo:mybridge:LR_thermostat:temperature" }
Number:Temperature  iLR_thermostat_set          "SetPoint Temperature"                    (gLivingRoom)                                { channel="openwebnet:bus_thermo:mybridge:LR_thermostat:setpointTemperature" }
String              iLR_thermostat_setFanSpeed  "FanSpeed"                                (gLivingRoom)                                { channel="openwebnet:bus_thermo:mybridge:LR_thermostat:speedFanCoil" }
String              iLR_thermostat_setMode      "Mode"                                    (gLivingRoom)                                { channel="openwebnet:bus_thermo:mybridge:LR_thermostat:mode" }
String              iLR_thermostat_setFunc      "Function"                                (gLivingRoom)                                { channel="openwebnet:bus_thermo:mybridge:LR_thermostat:function" }
Number:Temperature  iEXT_temp                   "Temperature [%.1f °C]"  <temperature>    (gExternal)                                  { channel="openwebnet:bus_thermo_sensor:mybridge:EXT_tempsensor:temperature" }

// 99 zones central unit 
Group   gCentralUnit                "Central Unit"                
Number:Temperature iCU_3550_manualset "Temperatura"       (gCentralUnit) { channel="openwebnet:bus_thermo_cu:mybridge:CU_3550:setpointTemperature", ga="thermostatTemperatureSetpoint" }
String iCU_3550_remote    "Remote Control"    (gCentralUnit) { channel="openwebnet:bus_thermo_cu:mybridge:CU_3550:remoteControl" }
String iCU_3550_battery   "Battery Status"    (gCentralUnit) { channel="openwebnet:bus_thermo_cu:mybridge:CU_3550:batteryStatus" }
String iCU_3550_mode      "Mode"              (gCentralUnit) { channel="openwebnet:bus_thermo_cu:mybridge:CU_3550:modeCentralUnit" }
String iCU_3550_wpn       "Weekly Program"    (gCentralUnit) { channel="openwebnet:bus_thermo_cu:mybridge:CU_3550:weeklyProgramCentralUnit" } 
String iCU_3550_spn       "Scenario Program" (gCentralUnit) { channel="openwebnet:bus_thermo_cu:mybridge:CU_3550:scenarioProgramCentralUnit" } 


openwebnet.sitemap

sitemap openwebnet label="OpenWebNet Binding Example Sitemap"
{
    Frame label="Thermoregulation"
    {
          Default   item=iLR_thermostat_temp        label="Temperature" icon="fire" valuecolor=[<20="red"] 
          Setpoint  item=iLR_thermostat_set         label="Setpoint [%.1f °C]" step=0.5 minValue=15 maxValue=30
          Selection item=iLR_thermostat_setFanSpeed label="Fan Speed" icon="fan" mappings=[AUTO="AUTO", SPEED_1="Low", SPEED_2="Medium", SPEED_3="High"]
          Switch    item=iLR_thermostat_setMode     label="Mode" icon="settings"
          Selection item=iLR_thermostat_setFunc     label="Function" icon="heating" mappings=[HEATING="Heating", COOLING="Cooling", GENERIC="Heating/Cooling"]
    }
}

Installation:

Copy the JAR file to your openHAB addons folder. On Linux and RaspberryPi it is under /usr/share/openhab/addons/

Prerequisites:

ALPHA 2 requires openHAB 3.3M0 or latest snapshot.

2 Likes

A suggested by @aconte80 , it would be useful if some expert users (@m4rk, @bastler , @enrico.mcc, others!!) with different installations (standalone, central unit 4 or 99 zones) could test the Thermo version of the binding on OH3, with DEBUG level logging:

from Karaf console:

  • log:set DEBUG org.openhab.binding.openwebnet
  • log:set DEBUG org.openwebnet4j

both log:set commands are important to log OWN commands exchanged between the binding and the OpenWebNet gateway.

and follow this test sequence (leave 20-30s between each step):

  1. discover thermostats and sensors (probes): they should appear as bus_thermostat and bus_temp_sensor and add them to OH3
  2. check room current temperature is read correctly on OH
  3. rise/lower set temp from one physical room thermostat, check set temp changes in OH
  4. change mode to MANUAL > PROTECTION > AUTO > OFF > MANUAL from physical room thermostat, check mode changes in OH
  5. rise/lower set temp from OH, check it changes on physical room thermostat
  6. change mode to MANUAL > PROTECTION > OFF > MANUAL from OH, check mode changes on physical room thermostat
  7. check actuator is activated when the heating is working (to reach set temp)
  8. repeat steps 3-7 with cooling function if your system supports it

Follow the steps in this order until something goes wrong, then extract the OH log and possibly insert a comment line before each step indicating which step number is it.

Send the log here or via PM. Always remember to use code fences.

It’s important to indicate which BTicino device you use (gateway, thermostat models) and the type of configuration (99 zones, 4 zones, standalone, only heating or heating+cooling)

Hi Massi,

Unfortunately I don’t have any thermal management device.

In general, I’m still on Openhab 2.5 so if I understood correctly I cannot install the new binding, right?

yes, the new binding is only for OH3

hi,
i use the 99 zone (3550) that is still not supported. my temp-sensors are HD4693 (probe without selector) can i do tests with this sensors?
if yes: i suppose i have to uninstall the openwebnet-binding before adding the *.jar file?

Yes the idea is to proceed “by difference” and adjust what is implemented now (which based on tests on a real environment) to other systems. Unfortunately official OWN specs are not precise enough to understand every case.

Yes: just uninstall the merged one (3.1M5) form the UI and then install this jar linked by Andrea, it’s in any case based on 3.1M5 so you do not miss any functionality from the milestone version.

let me share my very first impressions:

  • uninstalled the official binding (3.1.0m5) in ui
  • removed recently found things from inbox (mh200n, mh4893)
  • downloaded the testing-jar (org.openhab.binding.openwebnet-3.1.0-alpha.1.jar) and manually copied it from my windows-pc to raspi (with user openhab) to /usr/share/openhab/addons
  • immediately i see this error in the log:
2021-06-02 19:37:19.196 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.openwebnet-3.1.0-alpha.1.jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.openwebnet [288]

  Unresolved requirement: Import-Package: org.openhab.core.io.transport.serial

	at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]

	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]
  • entered karaf-console (openhab-cli console)
  • executed:
    feature:install openhab-transport-serial
  • an immediately the binding started, in the log all lights and shutters went “online”
  • executed in karaf:
log:set DEBUG org.openhab.binding.openwebnet
log:set DEBUG io.openwebnet
  • now opened “things” in ui and see that mh200n and mh4893 is already discovered again - nothing else
  • 30 minutes later i started a manual scan, then temperature sensors, some switches an a for me unknown device was found:
GENERIC Device (WHO=UNKNOWN, WHERE=0)
openwebnet:generic_device:bticino:0

the “single” temperature sensors were all found correct, but for example in living room i have four control circuits (14-1, 14-2, 14-3 and 14,4), here the discovery found only where=14 and where=114.
in the bathroom i have two control circuits (21-1 and 21-2), the discover only found where=21

  • i startet the scan again but didnt find any new things

  • i added one sensor to openhab: openwebnet:bus_thermostat (where=17)

  • took about five minutes until state went to “online”

  • linked an item for temperature - correct

  • linked an item for setpoint temperature - correct

  • lowering and rising of setpoint temp is correct

  • linked an item for thermo function:
    when select heating item state shows heating
    when select cooling item state shows cooling
    when select off item state shows generic

  • linked an item for mode function:
    when select off item state shows off
    when select protection item state shows protection
    when select holiday item state shows manual
    when select weekly item state shows manual

  • linked an item for set fan speed function:
    as i have no fan installed set fan speed is null

for the mode-item i miss the button auto - when i select manual in oh it switches to auto on my bticino-touchscreen

  • info: i do not have cooling installed and so cannot test it

first of all, thank you @bastler !

As you already said, the action to solve it is launching feature:install openhab-transport-serial from the karaf console.

I’ll check your logs and see what’s happening for the ‘generic’ device.

this is correct, the status will change only when something happen on the bus. I saw you’re using also the touchscreen: if after the discovery you go to the touchscreen (or mobile app) and change something (+0,5° to set temp for example) you’ll immediately see the status updated (online).

All other points you’ve highlighted sounds good to me.
Thank you again!

my pleasure!

… sorry for that, i was confused. this is correct, i mixed up sensors and actors:

  • in living room i use 2 sensors (14 and 114) with 4 actors
  • in bath i only use 1 sensor (21) with 2 actors

so to translate to openwebnet terminology, you have:

  • living room zone 14 with 2 actuators numbered 1 and 2
  • living room zone 114 with 2 actuators numbered 3 and 4
  • bathroom zone 21 with 2 actuators numbered 1 and 2

correct?

Can you confirm that in your BTicino system (without OH involved) you can read current temp and control setTemp & mode individually for the 3 zones but you cannot control each single actuator : they are activated whenever temp < setTemp.
Does this describe your system correctly?

actually zone 114 is not correct, 114 means “probe 1 of zone 14”
So you should have:

  • living room zone 14 with 1 thermostat (where=14) with 4 actuators numbered 1, 2, 3, 4 and 1 additional probe (sensor) numbered 1 (where=114)
  • bathroom zone 21 with 1 thermostat (where=21) and 2 actuators numbered 1 and 2

Can you confirm that in your BTicino system (without OH involved) you can read current temp from the 2 thermostats and from the 1 probe, and control setTemp & mode individually for the 2 zones (by using the thermostats) but you cannot control each single actuator : they are all activated together in the zone whenever temp < setTemp.

it would be useful if you provide a screenshot of your configuration from the MyHOME web server, for zones 14 and 21

sorry, my f454-webserver is quite empty, only use it as a gateway with no config.

yes that is correct! in living room the where=114 is an additional slave-sensor. all the actors in living are activated together whenever temp < settemp. and also both actors in bath are activated together whenever temp < settemp.

as i always do a file-based config, this was my things in the old binding, and this works again now:

    Thing bus_thermostat                EWoK_Heizung                "EWoK_Heizung"                  @ "Temperatur"  [ where="14" ]
    Thing bus_thermostat                EWoK_Heizung_Slave          "EWoK_Heizung_Slave"            @ "Temperatur"  [ where="114" ]
    Thing bus_thermostat                Bad_Heizung                 "Bad_Heizung"                   @ "Temperatur"  [ where="21" ]

my items for living-room now look like:

Group:Number:AVG iEWoK_HeizungAvg "Wohnen Ist-Temperatur[%.1f °C]" <temperature> (iG_Heizung)
Number:Temperature iEWoK_Heizung "Wohnen ist-Temp. Master[%.1f %unit%]" <temperature> (iEWoK_HeizungAvg) { channel="openwebnet:bus_thermostat:bticino:EWoK_Heizung:temperature" }
Number:Temperature iEWoK_Heizung_Slave "Wohnen ist-Temp. Slave[%.1f %unit%]" <temperature> (iEWoK_HeizungAvg) { channel="openwebnet:bus_thermostat:bticino:EWoK_Heizung_Slave:temperature" }

(in sitemap and rules i normally only use the average temp)

@bastler do you see the zone 14 slave probe (where=114) to be defined more correctly as a temperature_slave1 channel of the same EWoK_Heizung thing, or as it is now : a separate thing with its own temperature channel?

also another change we are discussing is to rename bus_thermostat to bus_thermo_zone: for example in your case you are definining zones and do not have any thermostat device (i.e. device able to control local temperature) in the rooms, so for me to name them thermostat things is not correct anymore.
What do you think?

indeed, when thinking about your suggestion it makes more sense to make a slave-channel. as i understand bticino system this kind of slaves are only used in big rooms with more than one temp-sensor to be able to calculate an average-temperature for the whole room. don´t know how this can be managed, maybe someone has more than one slave, will this be also possible?

perhaps ist already too long that i use the name bus_thermostat so i wouldnt mind. but of course, a thermostat is a device with some kind of control. i know bticino has other sensors what allow some kind of small control (i think it was plu/minus three degrees that where possible to regulate direct on the sensor) - for this devices the name would fit. other idea could be to call it just bus_temperature_sensor - no matter if it has a possibillity to regulate, main mission of the device is to deliver the actual temperature. the term bus_thermo_zone sounds for me more like an area. for example my living room is a zone that has two temperature_sensors and four heating_actors.

we are going in the direction of renaming bus_thermostat to bus_thermo_zone and leave the zone sensors as separate things (renamed bus_thermo_sensor): this makes configuration more flexible and general and adaptable to the 3 cases: standalone, central-99 and central-4.
The two things (bus_thermo_zone and bus_thermo_sensor) must be distinguished becuase they have different channels.
In your case for the living room you will have to configure 1 bus_thermo_zone thing with channels for the main temperature and the actuators, and 1 bus_thermo_sensor for the additional sensor. Basically like before, but with new names.

Hello here. I just changed binding from official to alpha from here on SCS with Myhome_UP and HomeServer1.

It is working and discovering my KG4441 and I can get all informations. Now I do some test because i’m also starting heat pump for cooling down home.

so this KG4441 is a new Living Now thermostat, but it is seen from the SCS BUS and from openwebnet?
Is it connected directly to the BUS or is it connected through the MyHOMEServer1 ?

Hi there. I just put the wrong code KG4441 is the one that is not connected to the bus, it’s used in car box just for emergency.
The ones that are connected to the bus are KG4691.

ok, added them to the list of tested thermostats.

Thermo has been merged on the official OH 3.1 binding version.
Compared to the old testing version, Thermo things and channels have been renamed:

  • bus_thermostatbus_thermo_zone
  • bus_temp_sensorbus_thermo_sensor

Refer to the official binding README for details on the new Thermo channels names.

For those who have 4-zone or 99-zone Central Units, try it and tell us what you are missing.