OpenWebNet-HA
[RFC] OpenWebNet-HA Roadmap & Priorities: Help us rank what matters and add what's missing! #248
Replies: 11 comments 21 replies
|
Hello, First of all, thanks for all the work you've done over the last few days (and thanks for the hundreds of email notifications 😄). I had a question: I saw on your repository that there is support for streaming music through the F441 matrix. Is this now possible with the current version? That's something I'm particularly interested in. And also have the possibility to change the sources… Similarly, I would like to know whether it is possible to use the F453AV to stream the doorbell video to Home Assistant (via an RTSP stream, for example). If music streaming is supported, would it also be possible to retrieve the doorbell audio in the same way? If I have some free time, and if nobody has already tested it, I can also test the current fork with the MyHomeServer and F453AV gateways (and maybe with an old MH200 as well). |
|
Hi @wave68runner, Thanks for the kind words (and apologies for the flood of notifications while the sprint was underway 😄)! Here is a detailed breakdown addressing your questions: 1. Music Streaming through the F441 Matrix & Source Selection
2. Doorbell Video & Audio with F453AV
3. Testing with MyHomeServer1, F453AV & MH200Testing on real hardware would be immensely appreciated!
If you give it a spin, you can use the built-in Lovelace Bus Monitor card ( Thanks again for offering to test! |
|
Hi @GreenGrassBlueOcean , Thank you for your feedback. I must say I am equally impressed by your knowledge of the MyHome hardware ecosystem. Some time ago, I worked in technical support for BTicino Belgium, and even I was not aware of some of the information you shared. I am particularly surprised to learn that the audio inputs are analog. I had always assumed that the audio signals were transmitted digitally across the system. I suppose that this also means the outputs of the F441 are analog as well. The reason I am asking is that several of my F502 and F503 amplifiers have become defective over time, and I have been looking for a replacement solution. Do you think it would be possible to replace them with a more "traditional" amplifier that accepts an analog audio input? Another question came to mind regarding the video door entry system. Would it be possible to replace the Classe 100 WiFi or Classe 300 WiFi indoor unit with an alternative solution capable of streaming the doorbell's audio and video directly to Home Assistant? My objective would be to integrate the door entry system natively into Home Assistant, allowing me to receive calls, view the video stream, and potentially manage door opening without relying on the official BTicino application. Have you ever come across a solution like this, or do you know whether the audio/video streams can be accessed directly on the MyHome SCS bus or through another interface? Any advice or experience you can share on this topic would be greatly appreciated. |
|
Hi! Re-seating the OpenWebNet protocol in OWNd as a separate library feels like foundational work that would absolutely need to happen before any other major change. I'm also wondering why is P7 needed ? |
this what is expected, but it does not work like this for all gateways and especially for general/area configurations. |
1. My Priority Ranking
2. What's Missing from My Setup
3. My Setup & Test Availability
|
1. My Priority Ranking
2. What's Missing from My Setupnothing 3. My Setup & Test Availability
|
|
Hi @mvalla , |
To develop the openwebnet4j library and the OpenWebNet binding for openHAB without necessarily working on the actual physical system, I developed an emulator (a very rudimentary one, truth be told) for OWN Gateways and BUS devices. It supports the OWN protocol over IP, authentication, and the behavior of various devices across different "WHO" categories—such as lighting and automation, thermostats, sensors, energy meters and so on. |
Hi @mvalla, What you described here caught our attention immediately—an emulator capable of statefully simulating gateways and BUS devices across different WHO categories is absolute gold! One of the steepest hurdles in developing, testing, and maintaining OpenWebNet integrations is that developers always need physical hardware and specific actuators wired up to test scenarios—especially complex setups like multi-zone HVAC (P4), CEN/CEN+ pushbuttons (P2), or high-device-density plants. If you are open to it, would you consider sharing or open-sourcing your Node.js emulator? A few thoughts on why this would be a huge leap forward:
No obligations whatsoever, of course—even sharing snippets of the state machines, device definition schemas, or the raw code repository would already be tremendously helpful. Thank you again for all the insight and for actively helping shape the roadmap! |
🗺️ RFC Synthesis & Semi-Final Roadmap UpdateHuge thanks to everyone who shared thoughts, priorities, and hardware setups (@anotherjulien, @mvalla, @daniedj, @wave68runner)! Based on your feedback, we have synthesized the consensus into our updated Project Roadmap (ROADMAP.md). 1. Key Takeaways & Community Consensus
2. Updated Milestone Progression
3. Final Call for CommentsWe consider this roadmap semi-final and plan to lock in the Phase 2 scope shortly so work on the standalone Please let us know if there are any final objections, timing considerations, or adjustments before we freeze Phase 2! |
📢 Roadmap Milestone Update: P1 (Decoupled Protocol Engine) & P5 (CI Trace Replay Fixtures) Achieved + Published Conformance MatrixFollowing community input on priority rankings from @mvalla, @anotherjulien, @wave68runner, and @daniedj, we are pleased to announce significant milestone completions on the roadmap, establishing a verifiable truth for OpenWebNet protocol conformance across the ecosystem: 🎯 Roadmap Progress: P1 & P5 Completed1. P1: Standalone Python Protocol Engine (Status: ACHIEVED)
2. P5: Real-World Gateway Trace Replay Fixtures in CI (Status: ACHIEVED)
📜 Published Verifiable Truth: Protocol Conformance MatrixTo move beyond hidden unit tests into documented, verifiable truth, we have published the authoritative OpenWebNet Protocol Conformance & Capability Matrix covering:
🛣️ Next Focus: Evolving Phase 2 PrioritiesWith P1 and P5 established and passing 100% in CI, we are focusing on the next ranked community items:
Active PRs (100% green CI):
|
🗺️ Official Roadmap Update: Consolidated Unified Beta v2.0.0b11 & Community RFC on Remaining ItemsWe are excited to share a major milestone update directly reflecting our published Project Roadmap (ROADMAP.md)! Thanks to intense community feedback from @mvalla, @anotherjulien, @fedem95, @xtimmy86x, @DinoMesina, @wave68runner, @daniedj, and @nicolacavallo84, the architectural milestones originally mapped across separate future phases have been consolidated, fully implemented, and validated with strict 100.0% test coverage in the v2.0.0b11 Unified Beta and companion engine OWNd 2.0.0-b6! gantt
title MyHOME Integration Status & Roadmap
dateFormat YYYY-MM-DD
section Delivered in v2.0.0b11
Phase 1 - Dual Async Transports, Core Features & Bus Monitor :done, 2026-08-01, 2026-09-01
Phase 2 - Standalone OWNd Library (P1) & CEN Triggers (P2) :done, 2026-09-01, 2026-09-11
Phase 2 - Native DIN Bus Timers (WHO 1) :done, 2026-09-01, 2026-09-11
Phase 3 - Central Unit 3550/4695 (P4) & Multi-Gateway (P6) :done, 2026-09-01, 2026-09-11
Phase 4 - Real-World Trace Replay CI Fixture Engine (P5) :done, 2026-09-01, 2026-09-11
DALI Tunable White & Native HSV Color :done, 2026-09-01, 2026-09-11
WHO 18 Energy Power/Meters & WHO 16 Audio Matrix Proxy :done, 2026-09-01, 2026-09-11
section Active Community Consultation
RFC - P7 Group Sync, P3 Cover Calibration, WHO 14/24/22 Scope :active, 2026-09-11, 2026-11-01
📦 What is Shipped & Operational Today in v2.0.0b11
🗳️ Active Community Consultation: How Should We Deal With the Last Remaining Items?With foundational architecture and primary subsystems delivered, our consultation focuses on the 5 remaining specialized items: 1. 💡 P7: Lighting Groups & General Sync (
|
💡 Community Consultation Update on P7 (Lighting Groups & General Sync) — Real-World Case Study: DALI Groups & F429G (Issue #300)We recently investigated Issue #300 submitted by @lyubomirtraykov, which provides a valuable real-world test case directly relevant to our P7 (Lighting Groups & General Sync) roadmap milestone. 🔍 The Real-World ScenarioIn this installation:
⚖️ Architectural Analysis & Trade-offsAs @mvalla pointed out earlier in this discussion:
Additionally, OpenWebNet provides no protocol command to discover group memberships (there is no way to query the gateway for which lights belong to Group Current Recommendation (Software-side):For the time being, we recommended using Home Assistant Native Light Groups (
🗳️ Feedback Wanted for Phase 4 (P7 Scope)As we prepare the scope for Phase 4, we’d love your input on how you want hardware groups (
Which approach (or hybrid) would work best in your home? Please share your thoughts! |
|
A third data point, from a MyHomeServer1. The setup, for context: a bus group configured in the gateway's own map, with a wall button that commands it; Home Assistant has the two member lights as ordinary entities and nothing at all for the group. It stays in sync anyway, because the members report their own state. Group Repeated four times in the same capture, always the same shape. So members are echoed here too — three gateway families, none silent yet. But the order is reversed: on @xtimmy86x's F454 the group frame comes first and the members follow within 65 ms; here the members come first and the group frame arrives about 0.9 s later. That matters for the fallback as described: "after a group or general frame, wait a short window; if individual status frames arrived, do nothing; otherwise sweep". On my plant nothing arrives after the group frame, so the window would expire empty and every group press would cost a redundant sweep. The rule needs to look backwards as well as forwards — something like "sweep only if no member status was seen in the second before or after the group frame" — and the window has to be at least a second wide, not tens of milliseconds. No membership map is needed for any of that, which I think is the useful part: the heuristic is about traffic, not about knowing who belongs to what. One more thing from the same capture, relevant to deriving a group's state from its members. Switching the two lights off individually, from their own wall buttons: No group frame at all: the group address is silent unless the group itself is commanded. So a declared group can never learn its state by listening to (Frames only, nothing from the plant beyond the bus addresses.) |
|
I ran another test on the same installation, this time capturing through a MyHomeServer1, using physical group The sequence was:
This supports the state rule I proposed: the group is ON when at least one declared member is ON, and OFF when all declared members are OFF. Full captured sequence — MyHomeServer1, group #4As in the other capture, individual control produces no group frame. With declared members, HA should therefore recalculate the group state whenever a member changes, independently of receiving anything addressed to There is one timing difference: here the individual states arrive both before and after each group frame—approximately 0.83–0.96 seconds before, then 0.13–0.20 seconds after. The diagnostic bundle reports 10 TX frames overall, which are not included in this excerpt, so I cannot yet attribute the repeated reports to spontaneous feedback alone. For the entity design, I think this reinforces the distinction:
In either case, commands still target the native bus group with a single frame. The absence of group frames during individual operation is exactly why the declared group should track its members. |
|
One caveat I should have stated up front: my capture comes from my own fork on OWNd 0.7.49, not from v2. It shouldn't matter for this question — we're measuring what the gateway emits, and the library only receives it — but it's worth saying, and it cuts the other way too: I checked the log for transmissions and there were none at all during the four presses, so what you see there is the gateway unprompted. Two things could explain the difference between our two MyHomeServer1 captures, and one of them you can check from the data you already have. Different software. Mine is that fork on 0.7.49; yours is v2 on 2.0.0b6. Same gateway model, different library and different integration, so "the gateway echoes twice" may not be a property of the gateway at all. Which is the second echo? You mention the bundle reports 10 TX frames. If any of them sits between the group frame and the member statuses that follow it 0.13–0.20 s later, then that second echo is a reply to something your side sent rather than the gateway speaking on its own — and my capture, with nothing transmitted at all, would be the unprompted behaviour. Could you post the TX frames with their timestamps? That settles it either way. Firmware is the other variable. Mine doesn't report one to Home Assistant at all, and the MyHomeServer1 has no local web interface to read it from, so I'd need the app for it; if yours reports one, that's worth comparing. Either way the design conclusion stands, and I'd say it gets stronger: if two setups on the same gateway model disagree about when members are echoed, no timing window is safe to depend on. With declared members, recompute the group's state whenever a member changes, independently of anything addressed to the group; the sweep stays the fallback for a plant that says nothing at all. |
|
my firmware is v2.87.13 |
|
Got it out of the bus in the end ( Which is where we'd already landed, now with the easy explanations gone: the echo pattern isn't a property of the model or of the firmware, so nothing should depend on its timing. Recompute a declared group's state from its members whenever one changes, and keep the sweep for a plant that stays silent. |
|
I have a draft of this ready and have opened it as a Draft PR for review: #376 This implementation follows the conclusion here—recomputing the declared group state from its members whenever one changes, while keeping the sweep as a fallback. |
[Architecture RFC] De-tangling Lifetimes: A Pragmatic Milestone for
|
| Target | Keep in Parent Module | Extract |
|---|---|---|
gateway.py |
Public facade (send, available, profile, close) |
gateway_identity.py (WHO=13, model precedence, repairs)gateway_sessions.py (event/command worker loops, reconnect) |
cover.py |
MyHOMECover public HA entity methods |
cover_motion.py (echo window, write tracking, position integration)cover_calibration.py (per-gateway lock hub, multi-stage run, trace buffer) |
__init__.py |
The four core lifecycle hooks | legacy_yaml.py (YAML loader, schema validation)migrate.py (unique_id and device registry migration) |
light.py and config_flow.py can remain as they are for now; they work reliably and do not have competing clocks causing friction.
We'd love your thoughts:
- Do you agree with this architectural direction and the extraction boundaries?
- Are you comfortable with scoping the first milestone to just these three files (
gateway.py,cover.py,__init__.py)?
🗺️ [Roadmap & Architecture RFC] The Bigger Picture: From De-tangling Lifetimes to the Road to Home Assistant CoreFollowing up on our earlier proposal (#18507640) about modularizing Refactoring monolithic modules is necessary, but where that code lands depends entirely on our ultimate destination. If we move session handling or address normalization into internal integration helpers when they actually belong in the client library, or if we extract This brings us to the elephant in the room that has hovered over the project from day one:
We want to put this question squarely on the map. This is not a decree or an instruction on how we will end up, but an open discussion starter to help us align our architectural roadmap with what the community actually values. The Reality Check: What Home Assistant Core Actually RequiresWith v2, we have built a phenomenal, high-performance integration. But if we benchmark ourselves against the official Home Assistant Core architectural standards (ADRs, Quality Scale, and core review culture), there is a stark reality: what makes an incredible HACS power-tool is often the opposite of what Core accepts. If upstream Core is our true North Star, four major structural bets come into focus: 1. Finish the library so the integration stops speaking OpenWebNet
2. Replace "Discover Everything" with a Hub Onboarding Model
3. Home Assistant is the UI (Stop shipping a second one)
4. Pragmatic Correctness over Self-Scored Metrics
What Do We Want? (The Upside of Core)
What Do We NOT Want? (The Red Lines & Trade-offs)
How Far Do We Want to Go? (Three Strategic Options)How do we balance these trade-offs? Here are three potential paths:
Connecting Back to the Code: How This Changes Our Next StepsIf we look back at the refactoring proposal in #18507640:
Over to You: Where Should We Set Our Sights?We’d love to hear from everyone—installers, power users, daily drivers, and developers:
Looking forward to your thoughts and perspectives! |
|
Thanks for opening this discussion. I agree that the destination can influence where some responsibilities should live, especially the boundary between OWNd and the Home Assistant integration. However, I think there is an earlier and more fundamental question we need to answer:
At the moment, Core inclusion seems to be treated as the highest possible destination and therefore as something the architecture should naturally converge towards. I am not convinced that this should be assumed. What would Core inclusion give us?There are real advantages:
However, MyHOME users are already dealing with a specialized, relatively old wired bus system. Many of them are installers or technically experienced users, so installing an integration through HACS is probably not the main obstacle they face. Core inclusion would also not mean that Home Assistant takes over maintenance of the integration. We would still need active code owners who understand OpenWebNet, maintain OWNd, respond to issues, review changes and adapt the integration as Home Assistant evolves. Before choosing Core as a strategic goal, I think we should identify what measurable benefit it would provide to the existing user base. What might we lose or have to split?Many of the features that make this project particularly useful are also the ones that may be difficult to include in Core:
These are not secondary extras. For many users and installers, they are a significant part of the value of this integration. There is therefore a risk that we spend a great deal of time producing an official but reduced integration, while the most useful advanced functionality still has to remain in HACS. Option B is more complicated than separating a JavaScript fileThe modular ecosystem is attractive in principle, but the Bus Monitor and Admin Panel are not standalone frontend components. They depend on backend functionality that:
If those backend APIs are not acceptable in a Core integration, moving only the JavaScript into We could then need three coordinated components:
That would introduce compatibility requirements and separate release cycles across all three components. For a team that is still stabilizing v2, OWNd and the new panel, this would be a substantial increase in maintenance complexity. Before selecting Option B, we would need a concrete technical design explaining where the backend used by the companion frontend would live. Some proposed Core requirements should also be verifiedA few points in the proposal appear to be architectural preferences or likely review concerns rather than strict Core requirements. Device onboardingA “Discovered / Pending / Ignored” workflow may be a good UX choice for MyHOME, especially to prevent unknown or incomplete bus frames from producing unwanted entities. However, automatic creation of entities for dynamically discovered devices is not inherently contrary to the Home Assistant Quality Scale. The documented dynamic-device rule actually expects newly connected devices to create their relevant entities automatically. The real problem to solve is not automatic creation itself, but uncontrolled creation from ambiguous frames, generic names and unreliable addressing. Discovery filters, ignored-address handling, disabled-by-default entities or a review workflow are all possible solutions, but the pending-device model should be evaluated as a MyHOME design decision rather than treated as a mandatory Core pattern. OWNd licensingPublishing a stable OWNd release is clearly necessary before any Core proposal, and a permissive license could make review and reuse simpler. However, I would avoid describing MIT or Apache-2.0 as an established legal requirement for every Home Assistant dependency without first confirming that with the Core maintainers. OWNd’s current LGPL licensing may require review, but its acceptability should be verified rather than assumed either way. YAML migration and registriesI agree that permanent runtime configuration through However, the complete MyHOME configuration should not simply be written into the device or entity registry. Those registries primarily store identities and metadata; they are not a general database for OpenWebNet addresses, device types and integration-specific behavior. A migration would more likely need to create structured config entries, possibly config subentries or another approved storage model, while preserving entity unique IDs, user-assigned names and areas in the registries. Raw services and diagnosticsA generic raw-frame action may well face objections related to safety, scope and user experience, but Home Assistant integrations can provide custom actions. Therefore, this should probably be described as something requiring discussion with Core reviewers, not as an automatic prohibition. Similarly, downloadable diagnostics and a live Bus Monitor solve different problems. Quality Scale and coverageFollowing the Home Assistant Quality Scale is useful whether or not we enter Core. High coverage, typing, correct config-entry lifecycles, diagnostics and good user-facing tests all improve the project. At the same time, an internally declared Quality Scale level is not equivalent to an official Core assessment. The official scale is reviewed upstream and looks at user experience and behavior as well as numerical coverage. Conversely, having 100% coverage is not a problem and should not be dismissed. It is simply not sufficient on its own to prove architectural quality. Tests should primarily protect real behavior—state changes, registry behavior, recovery, migration and user-facing flows—rather than exist only to satisfy a percentage. A possible fourth option: Core-compatible architecture, HACS-first deliveryI would propose an additional path:
This would mean:
This approach would avoid refactoring twice while also avoiding premature product and repository splits. A high-quality HACS integration is not an inferior outcome. We can use config entries, proper registries, repairs, diagnostics, extensive tests, strict typing and a clean standalone library without surrendering the flexibility that this particular protocol and its users require. My own view is therefore that Core inclusion should remain a possible future outcome, not the current North Star. Before changing the roadmap around it, I think we should answer these questions:
Until those questions have concrete answers, I would prioritize completing the panel, stabilizing v2 and OWNd, and solving the problems we are observing on real MyHOME installations. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Note
Roadmap & Delivery Status Update (September 2026):
The foundational architectural milestones originally planned across Phases 1, 2, 3, and 4 have been consolidated, fully delivered, and verified with 100% test coverage in the v2.0.0b11 Unified Beta and companion engine OWNd 2.0.0-b6!
👉 See the complete updated roadmap: Project Roadmap (ROADMAP.md)
👉 Read the detailed status update and RFC questions: Roadmap Update Comment #18405108
👉 Contribute bus traces: Discussion #291: Call for Testers & Trace Builders!
Context & The Leap Forward
Following the move to the
OpenWebNet-HAorganization on September 8, 2026, the integration underwent an intense sprint:AlarmControlPanelStateenums,via_device_idhierarchy, typed units of measurement,self.config_entryOptionsFlow stability, and SSDP discovery confirmation.WHAT=34/dim 6), and 4-digit zero-padded sensor addresses (normalize_where).<myhome-bus-card>enabling community testers to stream, filter, and export frame traces directly into GitHub issues.While this brings
OpenWebNet-HAup to modern Home Assistant standards, comparing our architecture with mature OpenWebNet implementations (notably Massimo Valla’s openwebnet4j and the openHAB OpenWebNet Binding) highlights key areas where our implementation needs to evolve into a resilient, production-grade protocol platform.Objective Gap Analysis: openHAB / openwebnet4j vs. OpenWebNet-HA (v2 Today)
Lighting.requestTurnOn("51")) published to Maven Central.custom_components/myhome/ownd/; duplicated in the new MCP server.device_trigger.pylacks address filtering; users rely on community YAML blueprints.shutterRun=AUTO) + hardware position via Dimension 10 (LN4672M2/67557).travel_timepercentage + state restore; auto-discovered covers remain dumb travel-time covers.bus_thermo_central_unitThing for master heating/cooling mode and 4-zone/99-zone central units (3550 / 4695).MyHOMEClimateentities only (#1–#99); no master Central Unit entity.#group) and general commands (WHERE=0) sync individual member entity states.Proposed Focus Areas (P1 – P7)
Move
owndout of the integration into a standalone, typedopenwebnetpackage on PyPI with strongly typed message models. Both Home Assistant and the MCP gateway server will import this single, tested library.Fix
device_trigger.pyto filter on scenario device address (object), and register physical wall panels as distinct devices in HA'sdevice_registrywith native UI triggers (Short Press, Long Press, Release) so external blueprints are optional.Dynamically promote discovered covers to advanced positioning when dimension 10 frames arrive from Legrand 67557 / F401 actuators, and add a calibration service to measure real physical run times.
Provide a dedicated Central Unit entity (
MyHOMEThermoCentralUnit) representing master controllers to switch heating/cooling seasonal modes and holiday programs from HA.Build a test harness using real bus captures recorded via
<myhome-bus-card>to ensure that hardware quirks never slip past CI again.Namespace all internal event dispatchers by gateway MAC/ID so installations with dual gateways (e.g. MH200N + F454) operate without cross-talk.
Reflect bus group commands and general commands (
WHERE=0) onto individual entity states in HA.We Need Your Input: Help Us Prioritize & Add What's Missing!
A roadmap is only as good as the community using it. We'd love to hear from everyone running MyHOME hardware:
Quick Reply Template
Feel free to copy and paste this template in your reply:
All reactions