[OpenWebNet/BTicino] BTicino MyHOME binding for openHAB

massi · January 12, 2024, 8:58am

I open this new thread for discussions and provide support concerning the OpenWebNet (BTicino/Legrand) Binding for openHAB.

This openHAB official binding integrates BTicino / Legrand MyHOME® systems using the OpenWebNet protocol (local network integration).

README, instructions and examples

Before asking a question here check the README doc for capabilities, configuration information and examples: README openHAB addons

Discussion on BTicino MyHOME system (hardware and configuration)

Thread for general discussions, information, links and help with BTicino/Legrand MyHOME system and devices and their configuration/tools

Reporting new issues/feature requests

After confirming a new issue/feature request for the binding here in the community, you can open a new issue on the openhab-addons repository on GitHub.

Support the project (OpenWebNet Java library)

To support the development of the OpenWebNet library (used by the binding) via donations or if you want to be involved in coding check the openwebnet4j library page

Beta version

When new features are under testing, a Beta version of the binding will be published on the openHAB marketplace

BTicino Smarther binding

To connect openHAB to the BTicino Smarther connected thermostat via Legrand cloud APIs check out the BTicinoSmarther Binding for openHAB (BTicino Smarther thermostats do not support the local OpenWebNet protocol)

m4rk · January 12, 2024, 10:51am

How is this different from the existing threads? Did I miss something?

edit …
The something I missed was the fact that the other thread was automatically closed!!

I will update the link in the general thread.

The general thread doesn’t have a closure threat that I can see. How is this changed?

Ciao Mark

massi · January 13, 2024, 9:16am

do not know: maybe different settings in the forum sw

mediterraneo · January 23, 2024, 4:04pm

Do you have any plan to support BTICINO HD4692FAN?

Thanks in advance

massi · January 26, 2024, 7:54am

It should be supported already as it’s a openwebnet enabled thermostat.
Did you try to add it to your configuration?

mediterraneo · January 29, 2024, 1:43pm

I had an initial try and it was not working but then I found an issue in my configuration.
I can confirm it works at least as measurement point for the temperature.

m4rk · January 30, 2024, 8:16pm

Is anyone using … dateTimeSynch=true … in the gateway thing?

I recently moved everything over to OH4.1. Time synchronisation worked briefly but not for long. Possibly due to me working on other bug fixes after the upgrade.

I have tried binding restart, RPi reboot and switching gateways from MH202 to Screen10 but nothing seems to get it working again

I am testing using the openweb net client and setting false times with commands that I just copied like:

#13**222202000000028012024##
and
#13*#22203000000003001*2024##

Docs >>>

Both MH202 and S10 are to slave. I also have a 99zone thermo unit with no option for master of slave. If I set the time on any of these units the others follow.

The client shows BUS time every 30sec. I think the source is the MH202… See bottom event in cleint below

The events *17 etc above the time events are caused by reloading the entry page shown below for the MH202

RPi time is correct.

openhabian@openhabian:~ $ date
Tue 30 Jan 2024 09:09:23 PM CET

Maybe these log events are clue ?

The last one in the list happened when I set the time on the S10!!

bastler · January 31, 2024, 7:26am

did you try to send a time to test via my open client?

if i send (a false time):

*#13**#22*08*22*07*001*03*31*01*2024##

all my touchscreens switch correct to 08:22 (the sent false time):
grafik

marchino · January 31, 2024, 10:38am

I’m using dateTimeSynch=true on a MH200N with OH 4.1 and everything seems to work fine. I had some trouble when I started using it, but after checking, I realized I was missing the Master configuration on a device.
Currently, I have MH200N, Touch Screen and Thermo set as Slave, and the Alarm Unit set as Master.

I’m not checking every day but the last change from “Standard/Daylight Saving Time”, after a while maybe few hours don’t know why, every device on Bus got the new time from OH plugin.

bastler · January 31, 2024, 11:03am

i am surprised this works? i thought the timesync only is able to sync salves. if your alarm unit still is a master i suppose it also will sync the time to your other devices.

so (not sure) but i thought if you use timesync feature then this is your master and all the other devices should be configured as slaves?

m4rk · January 31, 2024, 8:14pm

I am using openwebnet client. Where did you get open client from?

Yes, I sent a false time. In the past the binding would immediately correct it but not anymore.

So, you are not seeing the binding correct the time either?

I still can’t figure out why the inconsistent behaviour. Works , does not work. Maybe Massimo will comment or I get lucky with something

marchino · January 31, 2024, 8:16pm

To be sure, just made a double check:

Burglar Alarm is MASTER

Set wrong time from Touch Screen physical interface (which is SLAVE)
Touch, Thermo and Alarm got the new time for a while
After some seconds, all the devices got back to OH time from the plugin

m4rk · January 31, 2024, 8:45pm

If i send

*#13**#0*21*45*00*000##

to set a false time or

*#13**#22*21*45*00*001*03*31*01*2024##

to set a time and a date

the log shows for both cases

Unsupported DIM: #0 - frame *#13**#0*21*45*00*##

Unsuported DIM = dimension ?

but S10 shows time I sent as 21:45 as expected

edit… discovery

S10 as gateway is not working with the time synch feature. MH202 is OK

Now that I am running two clients simultaneously I can the screen 10 is missing some BUS events that the MH202 is receiving.

bastler · February 1, 2024, 6:42am

i do not use the timesync feature. i use a habapp rule to do it.

long time ago i tested some devices as gateways. i remember for example the mh4893 was not able to manage who=16 (sound system), and the mh200n was not able to manage who=6 (door entry system) - perhaps your screen 10 is not able to manage who=13?

maybe i am wrong but in my opinion this is not correct as you only have to have ONE master. what reason to use burglar alarm as master if you use time sync feature as master?

marchino · February 1, 2024, 10:01am

The binding is not functioning correctly as a Master because it only reacts and updates the date and time when a time update message is sent on the bus.

I set up my system last year and I might remember it wrong but when no master was set, no time update message was sent on the bus. Consequently, no corrections were made by the OH binding.

m4rk · February 2, 2024, 10:11am

Did the binding change how the SetpointTemperature works?

It used to show the final setpoint, after the local offset is applied ( CU target for the zone - local offset). Now it seems to show the central unit target and does not reflect the local offset… Docs seem to confirm this.

The local offset is however inconsistently applied.(CU target - offset) when the CU target changes but 15mins later it reverts back to showing the CU target without the offset!!!

Is that how it should be ?

When the CU changes the target (CU T1 to T2 to T3) then the offsets get reflected in the target temperature but only for a while, about 15mins after ramp to new temp the target does not include the local offset. This means those zones in protection mode (CU protection = 7C) show 7C on steping up the ramp but then finally show up as 20C; which is the CU T3 setting

Here shows the CU unit ramping from T1 18 to T2 19 and T3 20

The short duration excursions, blips, are me testing and changing the local offset…

The net result is my heatmap showing if rooms are on target is now useless because it only shows the eflect of the local offsest on the target temperaure for a short time after a CU target T change.

So, do I now need rules to correct for the local offset to in order to plot the final target temperature for a zone. Even then it will still jump around at the ramp steps

Or have I got something set wrong somewhere?

massi · February 2, 2024, 1:40pm

@m4rk my opinion is that SetpointTemperature and local offset never worked together since OH3.
They worked ok in OH 2 but there was an additional channel targetTemperature
.
I think what you are seeing in your graphs is related to this already identified issue:

github.com/openhab/openhab-addons

[openwebnet] Thermo : Update setpoint not working right when local offset is in use

opened 02:36PM - 03 Jan 24 UTC

hyzteric

bug

## Expected Behavior I have my office temperature set to 22°C with a local offs…et of +2°C, the resulting target temperature in the room is currently 24°C If I add 1°C, the setpointTemperature should switch to 23°C. The offset is still +2°C, so the resulting target temperature in the room would be 25°C ## Current Behavior I have my office temperature set to 22°C with a local offset of +2°C, the resulting target temperature in the room is currently 24°C If I send 23 to the setpointTemperature, the offset is added and the setpointTemperature becomes 25°C instead of 23°C, the resulting target temperature in the room is now 27°C instead of 25°C (or it isn't, see below...) ``` 2024-01-03 15:22:24.918 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'thermo_2_Bureau_setTemp' received command 23 2024-01-03 15:22:24.921 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'thermo_2_Bureau_setTemp' predicted to become 23 2024-01-03 15:22:24.926 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'thermo_2_Bureau_setTemp' changed from 22 °C to 23 °C 2024-01-03 15:22:25.141 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'thermo_2_Bureau_setTemp' changed from 23 °C to 25 °C ``` However, if I send a OWN frame to get the current temperature of that Thermo item, it shows the right value : ``` 2024-01-03 15:23:42.776 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'thermo_2_Bureau_setTemp' changed from 25 °C to 23 °C ``` So the correct value is actually sent to heating system, but a wrong value is stored internally by Openhab until a correct frame is actually received from the gateway, which is a MH200N in my case What's annoying in my case is that I have a widget with a +/- button that send a setPoint temperature of +1°C/-1°C that are useless with that issue because if I press "+" twice in my example, the temperature goes from 22°C to 28°C! (With 30°C displayed until a correct frames comes in) ## Your Environment * Version used: openHAB 4.1.0 Release build; Linux/6.1.51-v7+ (arm); * Environment name and version : Chrome 120, Java 17.0.9 * Operating System and version : Windows 11 * Bticino gateway : MH200N bticino.items: ``` [...] Group gBureauZone "Thermostat Bureau" {ga="Thermostat" [ modes="auto=GENERIC,heat=HEATING,cool=COOLING", roomHint="Bureau" ]} Number:Temperature thermo_2_Bureau_temp "Temperature [%.1f %unit%]" (gBureauZone) {ga="thermostatTemperatureAmbient", channel="openwebnet:bus_thermo_zone:MH200N_Gateway1:thermo_2_Bureau:temperature"} Number:Temperature thermo_2_Bureau_setTemp "Temperature cible" (gBureauZone) {ga="thermostatTemperatureSetpoint", channel="openwebnet:bus_thermo_zone:MH200N_Gateway1:thermo_2_Bureau:setpointTemperature"} String thermo_2_Bureau_mode "Mode" (gBureauZone) {channel="openwebnet:bus_thermo_zone:MH200N_Gateway1:thermo_2_Bureau:mode"} String thermo_2_Bureau_offset "Local offset" (gBureauZone) {channel="openwebnet:bus_thermo_zone:MH200N_Gateway1:thermo_2_Bureau:localOffset"} [...] ``` bticino.things: ``` Bridge openwebnet:bus_gateway:MH200N_Gateway1 "MyHOMEServer1" [ host="192.168.0.5", passwd="...", port=20000, discoveryByActivation=false] { bus_on_off_switch LedsFacade_Switch "Leds facade" [ where="12" ] bus_on_off_switch Buanderie_Switch "Buanderie" [ where="13" ] bus_on_off_switch WCRez_Switch "WC Rez" [ where="14" ] [...] bus_thermo_cu thermo_CentralUnit "99 zones central unit" [ where="0" ] bus_thermo_zone thermo_1_Living "Chauffage Living" [ where="1", standAlone=false] bus_thermo_zone thermo_2_Bureau "Chauffage Bureau" [ where="2", standAlone=false] [...] } ```

m4rk · February 2, 2024, 3:19pm

Maybe its related. I never had a problem with OH3. I only just changed to OH4.1 and I now see this issue and some others that I am monitoring… many unsupported DIM errors in log.

2024-02-02 08:36:53.193 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: #13 - frame *#1*98*#13*0*100*12*0##

2024-02-02 08:36:53.194 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*98*#13*0*100*12*0##` for thing openwebnet:bus_dimmer:gateway:98

2024-02-02 08:36:53.196 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: #4 - frame *#1*98*#4*100*12##

2024-02-02 08:36:53.197 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*98*#4*100*12##` for thing openwebnet:bus_dimmer:gateway:98

2024-02-02 08:36:53.229 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 13 - frame *#1*98*13*0*100**0##

2024-02-02 08:36:53.230 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*98*13*0*100**0##` for thing openwebnet:bus_dimmer:gateway:98

2024-02-02 08:36:53.240 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 4 - frame *#1*98*4*100*0##

2024-02-02 08:36:53.241 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*98*4*100*0##` for thing openwebnet:bus_dimmer:gateway:98

2024-02-02 08:36:53.282 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 4 - frame *#1*98*4*100*12##

2024-02-02 08:36:53.282 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*98*4*100*12##` for thing openwebnet:bus_dimmer:gateway:98

2024-02-02 08:36:53.284 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 13 - frame *#1*98*13*0*200*12*0##

2024-02-02 08:36:53.286 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*98*13*0*200*12*0##` for thing openwebnet:bus_dimmer:gateway:98

and this updateModeAndFunction warning soon after restart

2024-02-02 11:06:37.865 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'openwebnet.things'

2024-02-02 11:14:18.848 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Created a DiscoveryResult for gateway 'Touch Screen' (UDN=pnp-ts10-2_1-00:03:50:97:03:8C)

2024-02-02 11:14:20.777 [INFO ] [rnal.handler.OpenWebNetBridgeHandler] - ---- CONNECTED to BUS gateway bridge 'openwebnet:bus_gateway:gateway' (192.168.1.40:20000)

2024-02-02 11:14:37.163 [INFO ] [rg.openhab.core.model.script.Heating] - UtilityRoom_local_offset received update to MINUS_1

2024-02-02 11:14:41.848 [INFO ] [rg.openhab.core.model.script.Heating] - Gallery_local_offset received update to NORMAL

2024-02-02 11:14:43.250 [WARN ] [er.OpenWebNetThermoregulationHandler] - updateModeAndFunction() Could not parse Mode from: *4*1100*#0##

m4rk · February 16, 2024, 9:55am

I found the a cause of the DIM error messges in the log

When lights are activated by scenario in MH202 like below :

then I see these errors:

2024-02-15 17:40:27.605 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: #13 - frame *#1*91*#13*2*150*10*0##
2024-02-15 17:40:27.606 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*91*#13*2*150*10*0##` for thing openwebnet:bus_dimmer:gateway:91
2024-02-15 17:40:27.631 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 13 - frame *#1*91*13*2*100*0*0##
2024-02-15 17:40:27.631 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*91*13*2*100*0*0##` for thing openwebnet:bus_dimmer:gateway:91
2024-02-15 17:40:27.671 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 13 - frame *#1*91*13*2*150*10*0##
2024-02-15 17:40:27.671 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*91*13*2*150*10*0##` for thing openwebnet:bus_dimmer:gateway:91
2024-02-15 17:40:28.133 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: #13 - frame *#1*93*#13*2*140*10*0##
2024-02-15 17:40:28.134 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*93*#13*2*140*10*0##` for thing openwebnet:bus_dimmer:gateway:93
2024-02-15 17:40:28.147 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 13 - frame *#1*93*13*2*100*0*0##
2024-02-15 17:40:28.147 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*93*13*2*100*0*0##` for thing openwebnet:bus_dimmer:gateway:93
2024-02-15 17:40:28.197 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 13 - frame *#1*93*13*2*140*10*0##
2024-02-15 17:40:28.197 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*93*13*2*140*10*0##` for thing openwebnet:bus_dimmer:gateway:93
2024-02-15 17:40:28.534 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: #13 - frame *#1*95*#13*2*150*10*0##
2024-02-15 17:40:28.535 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*95*#13*2*150*10*0##` for thing openwebnet:bus_dimmer:gateway:95
2024-02-15 17:40:28.588 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 13 - frame *#1*95*13*2*100*0*0##
2024-02-15 17:40:28.589 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*95*13*2*100*0*0##` for thing openwebnet:bus_dimmer:gateway:95
2024-02-15 17:40:28.613 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 13 - frame *#1*95*13*2*150*10*0##
2024-02-15 17:40:28.613 [WARN ] [al.handler.OpenWebNetLightingHandler] - updateBrightness() Cannot handle message `*#1*95*13*2*150*10*0##` for thing openwebnet:bus_dimmer:gateway:95

Operating the lights from the wall switch does not cause the error.

bastler · February 16, 2024, 10:43am

i would imagine this is because from wall switch you just send ON of OFF, later you can dimm. but from your scenario you send a command to switch on to a defined dimm level in a defined amount of seconds.