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
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):
discover thermostats and sensors (probes): they should appear as bus_thermostat and bus_temp_sensor and add them to OH3
check room current temperature is read correctly on OH
rise/lower set temp from one physical room thermostat, check set temp changes in OH
change mode to MANUAL > PROTECTION > AUTO > OFF > MANUAL from physical room thermostat, check mode changes in OH
rise/lower set temp from OH, check it changes on physical room thermostat
change mode to MANUAL > PROTECTION > OFF > MANUAL from OH, check mode changes on physical room thermostat
check actuator is activated when the heating is working (to reach set temp)
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,
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.
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]
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
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!
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:
@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.