hello
I have a F422.
I have a Legrand home screen who pilote the bulgar alarm => arm & disarm & zone by zone.
Ok, with my Solution (Sdomotica) you can arm totally, arm mixed zone , disarm, and use Home Assistant alarm panel. If need you more info please send me PM.
Bye
Sandro
If you are interested I made a fork of MyHome by anotherjulien, you can find it here
that is great, there is another fork as well GitHub - GreenGrassBlueOcean/MyHOME: MyHOME integration for Home-Assistant · GitHub
any chance it can be combined so burden being spread? not sure which one to pick and for now the original is working so I would want to avoid change something that works. can one install yours and keep the current from anotherjulien?
great work.
I guess you cannot install my integration keeping the original one. I suggest you to make a HA backup and try it.
Hello, nice to read this! do you plan on integrate Thermo? i have a BT3550 central station and thermostats in every room HC4691 and HC4441
Same question for Contact intereface like F428.
just tried to add you integration but i get the following message Repository ‘mantovanellimatteo/myhome’ exists in the store.
try to search “MyHOME (Modernized)” into HACS
maybe do you have the anotherjulien integration installed?
Hi again, i’m using Yalm config file to configurate, but it shows no entities, what am i doing wrong? Tried de where only config like in the old pluging and the who-where. nog difference.
location: /homeassistant/myhome.yaml
myhome_gateway:
mac: 'my_mac'
light:
Cuisine:
where: '21'
name: Plan de travail
dimmable: False
Rideau:
where: '23'
name: Led rideau2
dimmable: False
Dining_room:
who: "2"
where: "4"
name: "Dining room"
dimmable: true
Boules_mur_poolhouse:
who: "9"
where: '12'
name: Boules Mur Poolhouse
dimmable: false
Crepusculaire:
who: "0"
where: '2'
name: Crepusculaire
dimmable: false
Poolcover:
who: "10"
where: '13'
name: Poolcover
dimmable: false
@jp_colin Are you sure your myhome.yaml is not in /config/myhome.yaml? That’s the default location for the original MyHome integration (anotherjulien). Chances are your file may be there…
strange, if i put this location in the configuration of hte gateway: /config/myhome.yaml
I don’t get an error, but it does take the light form the myhome.yaml into account.
Also i have my installation with virtual configuration so my devices go from who: 0 to 10 and where 0 to 15.
But the documention say 11 to 99
Hello @mantovanelli.matteo,
I am experiencing a specific issue with a couple of devices in my MyHome setup (configured manually via myhome.yaml because auto-discovery failed to recognize all devices).
Overall, the integration works exceptionally well: the official BTicino Home Control app functions without issues, all changes made via the app are perfectly reflected in Home Assistant (which updates passively by listening to bus events), and commands sent from Home Assistant work for all entities, except for light_14 and zone_10, which only work partially:
light_14(dimmer): turns on and dims correctly, but fails to turn off.zone_10(climate): allows temperature adjustments, but fails to change the HVAC mode.
The issue seems to be related to the fact that these two specific devices emit very complex extended status frames (and it remains unclear why these specific devices generate such formats compared to other standard devices in the system), which the integration treats as Unsupported message type.
Below are the details and actual captured logs:
- Climate (Zone 10)
- Behavior: All other thermostats work perfectly. Zone 10 instead outputs extended status frames that are not interpreted, preventing the HVAC state from updating.
- Log:
2026-08-16 16:46:22.377 DEBUG (MainThread) [custom_components.myhome] [F454 gateway - 192.168.x.xx] Message received:*#1004*10*11*110111111111101101101101##
2026-08-16 16:46:22.377 INFO (MainThread) [custom_components.myhome] [F454 gateway - 192.168.x.xx] Unsupported message type:*#1004*10*11*110111111111101101101101##
- Lights (Dimmer - Where 14)
- Behavior: All other standard lights and switches operate flawlessly. The dimmer on WHERE 14 instead replies with a complex extended feedback frame.
- Log:
2026-08-16 [DEBUG] (MainThread) [custom_components.myhome] [F454 gateway - 192.168.x.xx] Message received:*#1001*14*11*111110111111111101100111##
2026-08-16 [INFO] (MainThread) [custom_components.myhome] [F454 gateway - 192.168.x.xx] Unsupported message type:*#1001*14*11*111110111111111101100111##
Request / Suggestion
Would it be possible to add parsing support for these specific extended frames (*#1004 for zone 10 and *#1001 for dimmer 14)?
If you need more information please ask me!
Thank you very much in advance for your support!
Thank you very much for the detailed report and for providing the exact raw logs. They were extremely helpful in identifying the root cause!
The frames you are seeing (*#1001 for the dimmer and *#1004 for the climate zone) are specific diagnostic/extended frames in the OpenWebNet protocol (where 1000 + WHO indicates a diagnostic dimension). The long binary-like string (e.g. 111110111111111101100111) is an extended hardware state bitmask.
Unfortunately, our underlying protocol parser dependency (OWNd) does not currently have native support for parsing these specific diagnostic WHO categories. Because of this, it falls back to returning the raw string, which the integration then flags as an Unsupported message type. Since Home Assistant never receives the parsed status update confirming the state change, the entity visually bounces back to its previous state (causing the de-sync you are experiencing with the dimmer and the HVAC mode).
I have just published v0.4.2 which introduces a solid workaround for this exact scenario.
Instead of waiting for an upstream update to the OWNd library, the integration now actively intercepts these specific *#1001* and *#1004* raw diagnostic strings at the gateway listener level. When it detects one, it immediately extracts the device address (e.g., WHERE 14 or 10) and forces a standard status poll (e.g., *#1*14##) to the gateway.
The gateway will then reply with a standard status frame (which OWNd fully supports), perfectly forcing Home Assistant to stay in sync with the hardware without throwing any unsupported message errors!
Please update the integration to v0.4.2 via HACS and let me know if this fully resolves the issue for your dimmer and thermostat!
Hello @mantovanelli.matteo,
Thanks again for your work! Quick update: thermostat 10 has issues even directly from the official app, so I’m focusing only on light 14 for now.
When toggling light 14, commands from Home Assistant fail because the gateway receives an unsupported complex status message, whereas operating it via the app triggers this extended frame:
File “/config/custom_components/myhome/gateway.py”, line 537, in sending_loop
2026-08-17 08:38:10.519 INFO (MainThread) [custom_components.myhome] [F454 gateway - 192.168.88.34] Message *1*0*14## was successfully sent.
2026-08-17 09:16:11.192 DEBUG (MainThread) [custom_components.myhome] [F454 gateway - 192.168.88.34] Message received: *#1001*14*11*111110111111111101100111##
2026-08-17 09:16:11.192 INFO (MainThread) [custom_components.myhome] [F454 gateway - 192.168.88.34] Unsupported message type: *#1001*14*11*111110111111111101100111##
I have already tested both version 4.6 and version 4.2 with the same outcome. Any thoughts on how to parse this? Thank you!
Hi! Thanks for bringing this up and providing the exact log trace—it was incredibly helpful for debugging!
It turns out you hit an interesting edge case that completely bypassed the interception fix introduced in version v0.4.2. Previously, the integration was designed to intercept these diagnostic extended frames (*#1001* for lights) by assuming the underlying parser library (OWNd) would completely fail to parse them and just return the raw string. However, looking closely at the OWNd regex engine, it actually does successfully parse that specific frame format, but it wraps it in a generic OWNEvent python object rather than a raw string. Because it was parsed as an object, it skipped the raw string interception logic entirely and trickled down the event loop until it hit the “Unsupported message type” fallback you saw in the logs.
I have just released version v0.4.9, which updates the interception logic to correctly handle these parsed OWNEvent objects for diagnostic frames (both 1001 and 1004), extracting the address and immediately querying the gateway for the standard status.
Could you please update to v0.4.9 via HACS and test if light 14 works correctly now? Let me know how it goes!
Hi Matteo, thank you for your quick answers!
I tried the latest updated version, but unfortunately, it goes into a continuous loop and now even the other lights have stopped working.
I rolled back to previous version
You can find a complete log here:
It contains other data as well, but I preferred to provide as much information as possible!
Thank you again and feel free to ask anything you need!
Blockquote
strange, if i put this location in the configuration of hte gateway: /config/myhome.yaml
I don’t get an error, but it does take the light form the myhome.yaml into account.
Also i have my installation with virtual configuration so my devices go from who: 0 to 10 and where 0 to 15.
But the documention say 11 to 99
Blockquote
@mantovanelli.matteo
Could you look into this and help me please?
Thank you