[OpenWebNet/BTicino] BTicino MyHOME binding for openHAB

perhaps try this:

  • start myhome suite an select “new home”

  • in the next window insert at top right your gateway data (ip-address, and password, port normally always is 20000) and click “connect”. the red dot must become green

  • click “bus scanner” and then “manual”

  • select “devices” and click “start scan”

  • you will then have to press the eg light-button of a light you want the address, it takes short time and then the (actor or dali) device should be found and listed in the right window. click the line and drag it to the middle window. then on the right window switch from “bus scanner” to “configuration” - then on the right window you see the actor with its modules, there you can see (and change) the adresses.

  • if you want to store a changed address select the device in the middle, with a right-click you can select “send configuration” to write it back to the device

Tip: You can save the scan results as a .plant file.

Then if you want to update something or just want to review the list you can open the .plant file instead of repeating the scanning. I have separate plant files for devices, MH202 scenarios and Screen10 setup. Devices show as green when the config has been sent successfully.

We should move this dsciussion to the general thread as it is not binding specific

Hi @CrazyPaw,

I see bastler replied to you.

If you were having the same issue I had with MHS1 using unwanted addresses, I recommend you avoid changing the address via myhomesuit, as it didn’t work for me and caused issues.

Have read on this one

It has the step-by-step to force MyHomeServer1 to choose another address.

I hope this helps.

Let me know if you need more information

Espresso

Has anyone seen this error ?

checkDateTimeDiff: Exception while sending set DateTime command: CMD is not connected

Time slaves do not update.

I have time sync enabled. It occurs after a router reboot (eg power cut) and is fixed by enabling and disabling the binding. I have now created a rule to do that.

I also noticed that the same error occurs when sending a command, using actions, to send an openwebnet frame to set the time slaves. eg *#13**#22*hr*min*sec*000*28*14*04*year##

I guess something gets disconnected in the binding and is not reconnected when everything is back up.

FYI >>>>

Also, I finally found the source of my time zone error when using the time sync option. Maybe it helps someone with this feature

linux timedatectl command response >>>>>

Local time: Sat 2026-08-15 09:25:44 CEST
Universal time: Sat 2026-08-15 07:25:44 UTC
RTC time: n/a
Time zone: Europe/Vienna (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Correct, and openHAB settings also looked to be correct

But >>>>>

sudo nano /etc/default/openhab

This line was wrong >>>>>

EXTRA_JAVA_OPTS="-XX:-TieredCompilation -XX:TieredStopAtLevel=1 -XX:+ExitOnOutOfMemoryError -Dxtext.qn.interning=true -Duser.timezone=Europe/Vienna"

The line was set to London even though openhab GUI and RPi all showed correct time settings. I am in Austria!

I do not see this error, but this is because I do not have dateTimeSynch enabled. I have a python rule to set correct date and time and all bticino devices run in slave mode. This works for me.

It should work and it would be good if this binding feature was reliable for people who want life to be simple. A power cut stopped some scenarios running because the time of day was wrong when everything was back up. My MH202 scenario controller and Screen 10 are both set to be time slaves.

I have written a rule to display the BUS time and NTP time on my sitemap with a sitemap button to sync them on demand. I just need to write the part that automatically checks if there is a difference in time between BUS and openHAB, but first I wanted to monitor what circumstances causes the binding time sync option to fail.

How often does your python script check and sync the time and what allowed time difference is reasonable?

Indeed the feature should work if its implemented.

I already use my own code since a long time and it works how I like it: Always seven seconds after each full hour I send the date/time OWN. This ensures even after clock change (summer - winter) I always have the correct time on all my bticino screens and never have to care about it.

Hi Mark
What probably is happening is that in case of router restart (=no connectivity to the gateway), the time synch command fails to be sent to the gateway and this blocks the binding.
This should be solved as it makes useless the time synch feature.

Can you create a new issue in GitHub?

As always, is important to add to the issue the specific log section (activate DEBUG mode first both for binding and OWN lib).

During upload of a new MH202 config I notice these frames in the openHAB log. They are all for the Gateway WHO 13

Does anyone know if any correspond to a reboot request?

edit… Since they are repeated in the sequence I doubt these are reboot request but DIM 41 is unique and used twice but slightly different

It would be good to be able to force a reboot remotely


14:29:14.423 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 40 - frame *#13**40*4*0##
14:29:14.467 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 23 - frame *#13**23*2*6*32##
14:29:14.577 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 24 - frame *#13**24*##
14:29:15.054 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 40 - frame *#13**40*4*0##
14:29:15.098 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 23 - frame *#13**23*2*6*32##
14:29:15.207 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 24 - frame *#13**24*##
14:29:15.270 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 41#4 - frame *#13**41#4*1*4*1*4098##
14:29:34.729 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 40 - frame *#13**40*4*0##
14:29:34.779 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 23 - frame *#13**23*2*6*32##
14:29:34.828 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 24 - frame *#13**24*##
14:29:34.891 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 41#2 - frame *#13**41#2*1*1*0*0##
14:29:37.988 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 40 - frame *#13**40*4*0##
14:29:38.038 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 23 - frame *#13**23*2*6*32##
14:29:38.095 [WARN ] [.openwebnet4j.message.BaseOpenMessage] - Unsupported DIM: 24 - frame *#13**24*##

Sorry for letting this die and now resurrecting it again. But do you mean there’s a way to read the bus and make something of it?

Hi, Yes.

When my class 300 video door bell is used the binding sees frames but is not configured to recognise them

Bit how do you read the Bus?

The openhab binding connects to openwebnet bus via the the configured bus gateway thing. The binding reports in the logs when there are unsupported bus frames (who). Or if you really want to see all bus activity you could use the openwebnet client.

I meant physically. How did you ‘tap’ into the wired BUS?

Via ethernet cable and IP address in the gateway. I have MH202 scenario conreoller and Screen10 touch screen panel amd either can act as a gateways; there are others too. Both have an IP address to which I can configure the openwebnet gateway thing to use. BUS frames are via the 24v power cables to connected devices. So, the BUS power supply links them all.

Do you have BTicino BUS system?

I know practically nothing about our setup. It was already there when we bought the house.

But since we’ve got two of those classe 100 devices, I can only assume there’s a BUS somewhere, including in the fuse box.

I’d be interested to see what could get retrieved from it, but wouldn’t know how to take the first step: get the BUS to some kind of connector and in a device.

You need a gateway with an ethernet connection.

Maybe this thread helps learn and there some links to more material. Also, it is where we talk about more general stuff rather than openHAB binding specific topics >>>

Funny, the very last post on the thread I linked to was >>>>