🎉 MyHOME v2.0.0b13 Pre-Release: Field-Testing & Community Feedback Hub

[GreenGrassBlueOcean]

🎉 Welcome to MyHOME v2.0.0b13 (Pre-Release)

We are thrilled to announce that MyHOME v2.0.0b13 is now merged and ready for community field testing!

First and foremost, a massive and heartfelt thank you to everyone in our community and maintainer team:

• @anotherjulien for the foundational library, vision, and continuous support.
• @xtimmy86x, @Interstellar0verdrive, and @fedem95 for taking on co-ownership, establishing branch protection, rigorous reviews, architectural feedback, and keeping our repository safe, clean, and focused on real-world stability.
• @TheDarkWizard for meticulous testing, comprehensive logs, and identifying critical edge cases like the startup discovery NACK logging behavior.
• @gdluck for the fantastic HMAC hex/int string conversion refactor in OWNd that ships in this release.
• All community contributors who provided physical plant traces (MH201, MH200, F454, MyHomeServer1), golden corpus frames, and detailed issue reports.

This entire release would simply not have been possible without every single one of you. ❤️

---

🌟 What's in v2.0.0b13?

This pre-release consolidates weeks of intense architectural hardening, testing, and documentation:

1. 🚀 Powered by OWNd 2.0.0b8:
   • Bundles the new upstream OWNd 2.0.0b8 release with optimized HMAC authentication ($O(N)$ string generation) for modern Legrand gateways (MyHomeServer1, F454 with alphanumeric passwords).
2. 📖 Versioned Documentation Platform:
   • Complete multi-version documentation platform live at openwebnet-ha.github.io/MyHOME, including installation guides, upgrade instructions, architecture deep-dives, and known limitations.
3. 🛡️ 100% Green CI & Exhaustive Testing:
   • Over 1,720 automated unit and integration tests passing with 100% green checks across all 9 CI workflows (Python 3.11, 3.12, 3.13, 3.14).
   • Real-world trace replay fixtures directly validating real SCS bus traffic against Home Assistant state machines without needing physical hardware attached to CI runners.
4. 💎 Platinum Quality Scale Alignment:
   • Full compliance with Home Assistant Core Platinum architectural rules (100% strict mypy typing with 0 errors across all 30 modules, entry.runtime_data, non-blocking coroutines, comprehensive translations, and diagnostic platforms).
5. 🎛️ Feature & Subsystem Highlights:
   • CEN / CEN+ Device Triggers (WHO 15/25): First-class UI automation triggers for all 8 button actions with string-preserved addressing ("0001").
   • Heating Central Unit Master Mode (WHO 4): 3550 (#0) and 4695 (#0#1) central units with seasonal distribution.
   • Multi-Gateway Plant Isolation: Namespaced dispatchers preventing cross-talk across multi-gateway installations.
   • Lighting Groups & Debounced Resync (WHO 1): Group addressing with 250ms debounced echo window and cancellation.

---

🧪 How to Test & What We Need Feedback On

We encourage everyone running test plants or staging environments to update to v2.0.0b13 via HACS (enable Show beta versions).

Areas where we would love your feedback:

• Gateway Authentication: How does connection and reconnect perform on your gateway model (F454, F455, MyHomeServer1, MH200N, etc.)?
• Lighting & Covers: Responsiveness, debouncing, and state reporting.
• CEN / CEN+ Triggers: Building automations using the new native device triggers.
• Thermoregulation: Probes and central unit interactions.

Please share your logs, observations, and feedback directly in this discussion thread! If you hit a specific bug or unexpected error, feel free to open an issue referencing this discussion.

Thank you again to everyone for building the next generation of MyHOME together! 🚀

[marcob79]

how to get b13?
currently https://github.com/OpenWebNet-HA/MyHOME/releases/download/2.0.0b13/myhome.zip
returns 404

[GreenGrassBlueOcean]

Hi @marcob79,

The pre-release asset has just been published!

• Direct Download: myhome.zip
• HACS: You can also update directly within HACS (ensure Show beta versions is enabled, or click Redownload on the MyHOME integration card and select 2.0.0b13).

⚡ 1-Click Terminal Command (Terminal & SSH)

If you have the Terminal & SSH add-on installed (or connect via SSH), paste this one-liner directly into the terminal to download, extract, verify, and restart Home Assistant cleanly:

TAG="2.0.0b13"
mkdir -p /config/custom_components && cd /config/custom_components && \
wget -O myhome.zip "https://github.com/OpenWebNet-HA/MyHOME/releases/download/${TAG}/myhome.zip" && \
rm -rf myhome && \
unzip -q myhome.zip -d myhome && \
rm myhome.zip && \
grep '"version"' myhome/manifest.json && \
ha core restart

(This extracts directly into /config/custom_components/myhome/, verifies "version": "2.0.0b13", and restarts core).

Thanks for catching that so quickly, and looking forward to your feedback and logs!

[marcob79]

I'm sorry.
I was too anxious to try.
How calibrate travel time button is supposed to work? Is there any description somewhere?

[Interstellar0verdrive]

@marcob79 — it runs three full automatic passes: up, then down timed, then up timed, ending each pass on a "stopped" message from the bus. The times are saved into the integration's config options, under cover_travel_times (they also show in the diagnostics download).

A note on attribution: I reviewed and approved the underlying service in PR #349, in particular the 60 s cutoff guard — but I didn't write the button, this docs page, or this method. My calibration work is separate: a guided flow still in progress for the panel.

I tested this on my own system (MyHomeServer1, actuator at its factory 60 s limit). Automatic runs end at ~60 s every time, and the guard rejects them — 6 out of 6. Nothing shows on screen, since the button doesn't wait for the outcome; it only reaches the log. Following the current page ("press again" / Stop), I pressed Stop myself, and the procedure took those stops as end-of-run: it saved 5.7 s and 7.0 s for a shutter that takes about 14 s, matching my stops exactly. On actuators that don't report an end-stop, automatic measurement can't work — and following the current docs gets wrong values saved silently.

For what it's worth — from the official datasheets, not verified on hardware, so treat it as a guess: F411/2, F411/4 and F411U2 have a configurable timed stop (physical M configurator, or 1–60 s from MyHOME_Suite), so a run-time set equal to the real travel should make them measurable; F401 and the H4661M2/LN4661M2 family learn the real travel time themselves ("Push&Learn"), which is the case where the end stop on the bus should be genuine. A run that ends at ~60 s most likely means the timed stop was simply left at its default.

What I'd suggest:

• Docs (docs(covers): clarify automated travel time calibration sequence #411): say which actuators this works for and how to spot your case (~60 s run = not measurable); drop "press again" and "Stop to cancel" until stop-as-measurement is fixed; note the first run is always an opening move.
• Code: a stop from the integration, or received mid-run, should abort calibration, not close it as valid; the button should surface the result on screen; add a plausibility check across the three runs.
• This beta: consider disabling both buttons by default until fixed, keeping the service and manual time-setting available. Happy to open an issue with the full trace if useful.

@marcob79 — meanwhile: if your run lasts about 60 s, your actuator isn't measurable over the bus. Set the times by hand with myhome.set_cover_travel_time, stopwatch in hand — it overwrites whatever a previous attempt may have saved, and myhome.reset_cover_travel_time takes the cover back to its default if you'd rather start clean. And don't press Stop during calibration: the time would get saved.

[Interstellar0verdrive]

One more data point from this morning, following exactly the manual route below, on a 107 cm shutter:

1. Timed it with a stopwatch, arrow to arrow: 15.02 s down, 15.22 s up.
2. Saved those values:

   action: myhome.set_cover_travel_time
   target:
     entity_id: cover.cover_91
   data:
     travel_time_down: 15.02
     travel_time_up: 15.22

   and checked they were stored (cover_travel_times, source manual).
3. From fully open, cover.set_cover_position: 50 → it stopped with the bottom edge at 27 cm from the sill.
4. From fully closed, same command → it stopped at 37 cm.

In both cases the true midpoint is about 53 cm, and Home Assistant reported 50 % both times. The timing itself was exact — 7.55 s and 7.65 s of motion, half of each stored time to a few hundredths. Half the time is just not half the height on a roller shutter: coming down from the top the curtain runs fast on a full roll and is well past the middle at half time; going up from the bottom the first seconds go into gathering the slats and the curtain barely moves. That's a 26 cm error one way, 17 cm the other, and 10 cm between the two directions — with nothing in the interface to suggest anything is off. Worth knowing before anyone calibrates a whole plant this way.

[GreenGrassBlueOcean]

Hi @marcob79 — updated answer, now that @Interstellar0verdrive has tested this on hardware and the docs in #411 have been corrected against the code.

What the button does. Calibrate travel time on the cover's device page runs myhome.calibrate_cover: three automatic passes — up (to reach a known position), down (timed), up (timed). Each pass ends on the actuator's own stop frame. The two times are stored in the config entry (cover_travel_times) and show up as travel_time_down / travel_time_up on the cover. Nothing shows on screen while it runs — the button fires the action and does not wait — so watch the shutter, or the myhome_cover_calibration events.

Do not touch anything during the run. Not the button again, and not Stop — neither from the entity nor from the wall switch. A stop puts the same frame on the bus as the end stop, so the integration takes it as the end of the run and stores the partial time (Octavio measured exactly that). The only safe abort is myhome.stop_cover_calibration in Developer Tools → Actions.

Does it work for your actuator? Only if the actuator stops itself at the end stop. If a pass runs for ~60 s, the actuator is at its factory run-time limit and is not measurable over the bus; the integration refuses that result (visible in the log) and stores nothing. In that case set the times by hand — you don't need a stopwatch, every run is timed anyway: drive the shutter, press Stop the instant it reaches the end stop, read last_run_seconds in Developer Tools → States, do the same for the other direction and save both with myhome.set_cover_travel_time. myhome.reset_cover_travel_time takes the cover back to its default.

One thing I had overlooked: the card's Covers panel with the stopwatch and Stop & Save is not part of b13 — neither the UI nor the Lovelace card — so the docs no longer send you there. Attributes + actions is the route, and #411 adds a stock-card dashboard recipe for it.

The full write-up is the covers page in #411; it goes live on the docs site when that merges. Octavio's note below on roller shutters — half the time is not half the height — applies to any timed cover, calibrated or manual.

[marcob79]

So I couldn't rely on automatic calibration in my case.
I'll go on with travel_time configured in myhome.yaml

Is it suggested to move to UI configuration instead?

[GreenGrassBlueOcean]

Hi @marcob79 — staying with travel_time in myhome.yaml is 100% fine and fully supported.

The v2 backend continues to honor myhome.yaml travel times directly (marked with source yaml). There is no requirement or urgency to migrate to UI configuration right now, especially on actuators with factory 60 s cutoffs.

While you can use the UI route today via Developer Tools (myhome.set_cover_travel_time) or the stock Lovelace workbench card recipe in the documentation, a dedicated and much cleaner visual flow is currently in active development for the MyHOME administration panel (#374). Until that panel lands, keeping your existing and proven myhome.yaml setup is the recommended and easiest choice!