Hi m4rk,
Good to hear from you and I hope all is well at your end.
I agree it is a delicate balance and the need to avoid putting all the eggs in one basket.
While I have quite a bit of scenarios linking different items (in addition to the Bticino ones), the issue now is the discovered items themselves are no longer working.
I’ve been trying to figure out how to circumvent it, but to date no luck.
If I strike Gold will update back 
Hi,
All good. Thanks for asking.
I am still adding more stuff to openHAB. Latest project was the SolarEdge PV data. Alexa now announces when my house is running totally on solar power and no import from the grid.
PV gear is new to me and while I was checking on my electricity use I became aware that I have an unusually high background consumption compared to others. About 400w is continuously burning! This appears to be my BTicino BUS system stuff 
Does this sound right? I have nearly fully used the BUS addresses >> all lights, some sockets and all blinds, contact sensors and other stuff, plus video door entry.
Swings and roundabouts I suppose. The BUS main job is to control my blinds to maximise solar heating through my large south facing windows, and avoid over heating.
Over Xmas I updated to openHAB 4.3.1 - Release Build and MyHomeSuite to 3.5.29. It went OK. No new issues that I could see. The old logging niggles remained with the MH202 as gateway.
So far, I haven’t disappeared and still check in here from time to time, as well as having thread notifications set.
1 Like
Hello again,
I wanted to share my findings after manually attempting to change the MyHomeServer1 (MHS1).
I installed my MyHome_Suite connected to MHS1, did a scan, and imported the needed automation.
I then looked for all items with Area (A) set to 0. The first observation is that all items with A=0 and from P=11 to 15 are working fine in OH3.4 and are being read as 0011, for example (interesting at it means it is a code issue in my view, and that’s the only way to get around it). Items from 1 to 9 are read as 01 to 09, where the issue is arising. I tried on OH setup to change the 09 configuration to 009 and to 0009. This did not fix the problem.
I listed down all the addresses and found an empty range. I then attempted to change the A=0 from 9, for example and sent the configuration.
Indeed, the configuration was sent, as the light was no longer functioning from the switch. I attempted to configure the actuator again (linking the switch to the actuator) from Home+Project, and while the setup went through, the link was still broken between the switch and the actuator, and I managed to roll back safely.
After a few days, I attempted a bolder move. From Home+Control, delinked the switch from the actuator (freed it up) and then set up the new address to the actuator, and here literally, the sh*t hit the fan, so to speak.
From my MyHome_Suite, I got a configuration error. From Home+Control, the actuator gave an error that it had been manually configured and could not be set up. I tried to roll back with no luck.
I did a few scans on Home+Control, which made things worse as MHS1 decided to link a random switch to the actuator. After 4 hours, I got things working again by disconnecting the actuator, scanning, deleting the conflicting items, connecting the actuator again, scanning, and reconfiguring.
In summary, it is clear as we know that MHS1 assigns the addresses, and automatically assigned addresses don’t go with manually configured ones.
Interestingly enough, when it finally worked, the actuator returned to the same address, A=0 P=9, and A=0 P=10, so it’s not random.
Now, back to square one, on OH beyond 4.1.1 from MHS1, I am losing access to A=0 P=1 to P=10; only a code can fix it.
Any other ideas? Anyone?
@espresso I may help to solve the problem you rise, but unfortunately I can dedicate much less time now to the binding then in the past.
The binding is quite complete, and in a stable state now.
Many users with the right configuration can use it regularly without problems, also using the latest openHAB releases.
Have you filled an issue on GitHub?
If no please do : summarise clearly the problem, your configuration and the expected solution.
Provide DEBUG level logs if useful to show the problem.
What I still do not understand is why you cannot simply re-configure your devices to use the right A-PL addresses instead of using the not allowed configuration (according to documentation), A=0 is used to indicate “all areas”, and A=1 to indicate Area 1.
So an address with WHERE
=01 (A=0 and PL=1) is a wrong configuration.
It should be WHERE=0001 instead.
I understand that MyHOMEServer1 accepts the wrong configuration, but why you cannot just change it to a correct one?
Have you gone through the server / installation documentation carefully ?
Is there maybe some physical addressing that’s takes priority over the “virtual” configuration you are tying to send form server/H+P app?
I cannot help with your own BUS configuration…
An extreme solution would be to add to the binding a configuration parameter that relaxes the check on wrong addresses (like it was in previous versions), but is would strongly avoid this because would be a tricky and custom change in the binding just accomodate wrong BUS addresses configurations present only in some of the user system at home
Ciao Massi!
I’m one of those users but, probably one of the latest changes (don’t remember if after OH or OpenWebNet addon version update) some issue arised with heating (don’t know if also on other things). Although I can turn on/off heating, status on Central Unit and Zones is not updated. Don’t know if the other issues reported here in previous messages have the same source.
I’ve a PI 4 with OH 4.3.2 and a MH200N Gway.
As always, I’m available for testing/providing logs if needed.
Marco
Hello @massi,
First, thank you for your reply, support, and suggestions on resolving the issues.
I have good news! I managed my MyHomeServer1 (MHS1) work with the latest binding. I will try and detail to help others apply for the others with the same issue when moving beyond OH.4.1.1 and OpenWebNet’s latest binding.
After Massi’s reply, it was profoundly bugging me to find out why, while the documentation clearly states that A=0 should we WHERE=00, where is this set, and why it cannot be changed on MHS1?
I have been trying for more than three weeks, with lots of trial and error (lots of frustration and lots of heartbeats lost), to trigger a change of address until I struck gold.
The first time I tried was via MyHome_Suit (though if you read further, this is not needed), with the following steps (I was attempting to change A=0 P=9 to A=7 P=9 with the whole A=7 being unused):
- Updated switches to read A=7 linked to the actuator
- Send Config for the switch
- Update actuator from A=0 to A=7
- Send Config
- Diagnose the actuator (make sure it passes)
-
- Make sure lights work physically
- Go to my home control
- While the switch worked physically, I could not get it to work with my Control app, so I said the only solution was to delete it and see if that helped.
- Remove the actuator from all scenes (painful, I know)
- Delete Fully the Items (this is the primary action to ensure a new address gets assigned)
- Add the item back to the room/location (i.e., you have to set up a new item and link the actuator to the switch)
- Add the actuator to the scenes you deleted in point 9
- Go now to the Control app and add the light if needed
Interestingly enough, while I initially set the WHERE=79, it ended up with WHERE=21 (don’t ask me why (other than the fact that it was available); I reason that MHS1 decides the available address, with no option to force).
So, for the remaining eight items, I took a shortcut
- Go to my home+control app
- Remove the actuator from all scenes
- Delete Fully the Items (this is the primary action to ensure a new address gets assigned)
- Add the item back to the room (i.e., you have to set up a new item and link the actuator to the switch)
- Add the actuator to the scenes you deleted in point 2
- Go now to the Control app and add the light if needed
I did it one by one and not a bulk to be able to keep track if something fails (I did it over 2 days)
Interestingly, two items got new addresses, WHERE=10 (A=1 and P=0) and WHERE=20 (A=2 and P=0), which the new binding on OH4.3 did not like (this is a key issue with my MHS1 2-digit addresses). I witnessed the same behavior with the A=0 from P=1 to P=9 before and detailed in the abovementioned discussions.
Luckily, repeating the steps of deleting and adding gave new addresses that the binding liked, and they worked.
In summary, in MHS1, accessing the BUS or changing anything on it is impossible (not that I have figured it out yet, at least).
I noticed that anything with two digits in the address, for example, A=0 and P=2, will be broadcast on the MHS1 bus as Where=02 (does not work). On the other hand, A=0 and P=11 will be WHERE=0011 (works like a charm). In my view, this differentiation is the root cause of the issues with MHS1. For example, there is no way to enforce WHERE=02 to be sent on the bus as WHERE=0002.
Massi, I believe it would be good if you noted the above behavior of the 2-digit address on MHS1 for the future.
I am running the latest MHS1 firmware 2.84.09. I am now on OH4.3.2 and have been running smoothly for 24 hours.
I hope the above helps.
Thank you again @massi
Cheers,
Espresso
Hello Marcho,
I just noticed on OH.4.3.2 that the temperature setpoint is not being read. If I update the temperature setpoint physically, OH does not reflect it. Interestingly, if I send a rule to update the setpoint, it gets updated on OH but with no impact.
I have checked this on OH4.1.1, and it works on that version.
I have rules that used to work for the temperature control that are no longer working (I’m not sure if it’s due to the playing around I had done before on MHS1 or the fact that during that time, I got a firmware update, and that changed the behavior).
Nevertheless, there is a difference between OH4.1.1’s ability to read the setpoint and its no longer working on OH.4.3.1.
I don’t know if the whole configuration in the Model needs updating. I tried a few combinations, but they didn’t make a difference.
Here I am from OH changing the setpoint (but nothing is getting reflected except in OH)
18:21.5 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler handleCommand() (command=13.5 °C - channel=openwebnet:bus_thermo_zone:MYHOMESERVER1_000350a4baef:7:setpointTemperature)
18:22.8 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler handleCommand() (command=13 °C - channel=openwebnet:bus_thermo_zone:MYHOMESERVER1_000350a4baef:7:setpointTemperature)
18:22.9 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler handleCommand() (command=12.5 °C - channel=openwebnet:bus_thermo_zone:MYHOMESERVER1_000350a4baef:7:setpointTemperature)
18:48.1 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler handleCommand() (command=13 °C - channel=openwebnet:bus_thermo_zone:MYHOMESERVER1_000350a4baef:7:setpointTemperature)
18:49.3 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler handleCommand() (command=13.5 °C - channel=openwebnet:bus_thermo_zone:MYHOMESERVER1_000350a4baef:7:setpointTemperature)
18:51.2 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler handleCommand() (command=14 °C - channel=openwebnet:bus_thermo_zone:MYHOMESERVER1_000350a4baef:7:setpointTemperature)
There is no error being sent or handled.
Now below I changed the setpoint from the thermo controller
Blockquote
19:16.0 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler @@@@ Thermo.handleMessage():*#4*7*0*0167##{THERMOREGULATION-TEMPERATURE,w:7,dimValues=[0167]}
19:34.2 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler @@@@ Thermo.handleMessage():*#4*7*12*0145*3##{THERMOREGULATION-COMPLETE_PROBE_STATUS,w:7,dimValues=[0145, 3]}
19:34.2 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler @@@@ Thermo.handleMessage():*4*0*7##{THERMOREGULATION-CONDITIONING,w:7}
20:11.1 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler @@@@ Thermo.handleMessage():*#4*5*0*0188##{THERMOREGULATION-TEMPERATURE,w:5,dimValues=[0188]}
20:11.3 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler @@@@ Thermo.handleMessage():*#4*8*0*0167##{THERMOREGULATION-TEMPERATURE,w:8,dimValues=[0167]}
OH reads but the it does not get reflected on the setpoint item.
I ran a script to turn on specific items automatically
|20:43.1|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler|handleCommand() (command=COOLING - channel=openwebnet:bus_thermo_zone:MYHOMESERVER1_000350a4baef:7:function)|
|—|—|—|—|
|20:43.2|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler|handleCommand() (command=MANUAL - channel=openwebnet:bus_thermo_zone:MYHOMESERVER1_000350a4baef:7:mode)|
|20:43.3|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler|@@@@ Thermo.handleMessage():*4*202*7##{THERMOREGULATION-COOLING-PROTECTION,w:7}|
|20:43.5|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler|@@@@ Thermo.handleMessage():*#4*7*12*0350*3##{THERMOREGULATION-COMPLETE_PROBE_STATUS,w:7,dimValues=[0350, 3]}|
|20:43.6|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler|@@@@ Thermo.handleMessage():*4*202*7##{THERMOREGULATION-COOLING-PROTECTION,w:7}|
|20:43.6|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler|@@@@ Thermo.handleMessage():*#4*7*0*0168##{THERMOREGULATION-TEMPERATURE,w:7,dimValues=[0168]}|
|20:43.9|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler|handleCommand() (command=14 °C - channel=openwebnet:bus_thermo_zone:MYHOMESERVER1_000350a4baef:7:setpointTemperature)|
|20:46.1|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler|@@@@ Thermo.handleMessage():*#4*7#2*#20*0##{THERMOREGULATION-ACTUATOR_STATUS (writing),w:7#2,dimValues=[0]}|
|20:46.4|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler|@@@@ Thermo.handleMessage():*#4*7#2*20*0##{THERMOREGULATION-ACTUATOR_STATUS,w:7#2,dimValues=[0]}|
It ran but now as setpoint item does not get updated the script is no longer working.
I hope this helps.
Thoughts
I suggest to read carefully the configuration help for the binding as some changes have been introduced in the 4.3 release for the Thermo part.
I suggest to re-configure from scratch the Thermo items/things.
If the problem persists , pleas open an issue on GitHub
Thank you @massi,
You were spot on. I looked at the documentation and noticed that in the actual Thermostat thing, the setting “Stand-alone” was being set to false (that is, to use the central unit) whenever I did a scan on the OpenWebNet binding.
I can’t weigh if this was the previous behavior. I ran this setup for 5 years and was upgrading without much intervention.
Recently, due to A=0 addresses on the MHS1 playing funny, I ran a few scans while deleting and testing items.
Nevertheless, I took note to set it up (change it to Stand-alone) whenever I do a scan again (which, in theory, shouldn’t be the case in the foreseeable future).
Thank you for your help and the help of the others.
Cheers,
Espresso
Thanks, this solved also my issue with thermo 
Marco
@espresso
Would be very useful if you set log level to DEBUG for the binding and library (see here how) and run a new scan , so I can look why the thermostat is discovered as connected to Central Unit instead of stand-alone
Hello @massi ,
Technically, there is a central Unit on the MHS1, though it is not used in my case.
The MHS1 is configured via an app called Home+Project.
The user application is called Home+Control (uses netatmo protocol).
The scheduling for actions and Temperature happen in Home+Control (not native to Home+Project).
Home+Control needs an internet connection to work, and on Saturday, February 8, there was an issue with Bticino’s cloud service.
I haven’t been able to restore my connection yet!
Luckily, I use openhab to control others; I would have been completely locked out.
I will be raising a bug on 4.3.2 with Openwebnet whereby the temperature (setpoint) is not being regularly updated or made available online.
Another is when rescanning OpenWebNet; it overwrites the configured setup (meaning if the thermostat is set to standalone, it is overwritten to the central unit if it detects one).
I would need to restore my connection first and will work on providing the needed details.
Thank you
Espresso
Can you give more details, please?
What did you do, and what was solved?
Are you getting the thermostat reading updated?
Hi Espresso,
I have the Thermo Central Unit and with the latest release I had to change the ‘where’ from ‘0’ to ‘#0’. This seemed to solve the issue with the Central Unit and zones not being aligned on status. However, last week the misalignment was still present, so I must do more testing…
2 Likes
I found it is also possible to run the older 4.1.3 version of the addon with openhab 4.4 if you do not need access to the new functionality; details here: [OpenWebNet/BTicino] Problems sind OH 4.2 - #19 by mavnn
Obviously this isn’t a “fix”, but it does at least allow people with a MHS1 to continue using the latest version of openhab for everything else while the problem is addressed.
Anyone tried upgrading to OH5? Any issues? I plan to do a clean install over Xmas break. RPi OS is currently 32bit and OH5 needs 64bit OS.
I see the following two persistent errors for OH 4.3.1
1 >>>>
2025-12-14 15:58:55.157 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported WHAT=1000#15 for frame *1*1000#15*99##
2025-12-14 15:58:55.159 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported WHAT=1000#15 for frame *1*1000#15*99##
2025-12-14 15:58:55.469 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported WHAT=1000#15 for frame *1*1000#15*0114##
2025-12-14 15:58:55.470 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported WHAT=1000#15 for frame *1*1000#15*0114##
Caused by MH202 scenario with these actions
2 >>>> After network rebooted or MH202 rebooted.
[WARN ] [rg.openhab.core.model.script.Network] - <<<<<< OpenWebNet error: Exception while sending set DateTime command >>>>>>
The only fix so far I found is to reboot the RPi.
Gone for OH5 or still present ???
Moved to OH5 last month, didn’t check the logs every day but everything seems to work smoothly.
During next days, I’ll check logs to see if the above errors are there.
1 Like
i suppose massimo would complain that you just see “warnings” no “errors”
i am openhab 5.0.3 since about two weeks. i see the same warnings in the log as before:
2025-12-15 16:46:59.376 [WARN ] [openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 4 - frame *#1*45#4#01*4*100*1##
and the problem i still have is when a timed light command was sent the switch in the main ui stays “on” although the light is off at the end of the timer (not sure but i think this is related to the warning above, it says a dimmer-100 is level 0 → off).
1 Like
<<<<<< OpenWebNet error: Exception while sending set DateTime command
To see the above error I suppose you need to have set dateTimeSynch=true in the openwebnet bridge setting as well as have a break in the network connection to the MH202. On reconnection the error then appears very frequently filling my log.
The time sync worked nicely at the recent switch back to GMT 
i do not use this setting, so it is default = false. i have gateway and all touchscreens set as slave and send the time with a habapp rule to the bus once an hour, so the time is always correct on all devices even when it changes between summer and winter.
1 Like