Protocol (memorymap) broken by new builds?

[lgor]

It seems like the memory protocol map of (at least) the VMBELO is broken in latest builds. In the past, memory maps were updated from time to time with new functionalities only by EXTENDING the memory map. This guaranteed backwards compatibility. (checking buildnr >= known_build_number assured the memory map layout upto the extensions).

Now however this simple but reliable update mechanism seems to be broken. By reverse engineering (I modified values with Velbuslink and looked at the position of the changes in the memorymap) I discovered that the memory is not extended but seems shifted from about address 0x029c (not sure about exact offset).

This causes following major problems:

• the protocol file of the VMBELO is NOT updated witch makes the (latest?) memory map undocumented
• backwards compatibilty is broken (checking buildnr >= xxx no longer works)
• it will be hard (impossible without frequent updates) to keep tools compatible with future firmware upgrades (no assumptions can be made about future memory layouts!)
• upgrading firmware’s will no longer be a brainless safe operation
• older (not updated tools) may even corrupt memory builds when writing memory (e.g. velbuslink synchronize)

I experienced this problem between builds 2012 and 2524 of the VMBELO. I have no idea if there are other builds in between or later. I also have no idea if other types are affected?

Can you please check this issue for the sake of maintenance and open source tool builds?

[EvAndy]

Ouch! Well spotted. This would presumably mean that use of new firmware with an older VelbusLink version would ‘break’ the module… programming it with the old VelbusLink would have crazy/upredictable results. Documentation being so very wrong as a result also not great.

I don’t have any VMBELO but I am very concerned if this may have happened to any other modules. I do not think it is reasonable to break compatability with old VelbusLink (unsupported features is OK, but breaking a working configuration just by “sync” is not). This is unnecessary and would surely be an oversight/mistake that will lead to trouble in future releases.

I would hope it is not too late for Velleman to update again only to a *compatible* memory map for VMBELO… and to be careful not to make this same mistake again or for other modules.

I think this is really important or things could get very messy. Compatibility in the management of updates in VelbusLink has surely been crucial to Velbus survival and longevity. They have done really well to support legacy modules and firmware updates all this time… I expect that requires quite a bit of work and I really appreciate that effort… I hope it continues.

[lgor]

I do agree compatibilty and openness to community has always been a strong and much appreciated point of Velbus and I am confident this will stay that way.

Being aware of the possible problem with memorymaps I guess upgrading VelbusLink to latest version BEFORE upgrading firmware, adding or syncing modules would make risc minimal.

My greatest concern is about other open source tools (especially velbus-aio) which might run in to trouble because of appearing new undocumented memory maps. Even when documented this would still pose important challenges and maintenance problems because it is hardly impossible to sync development and deployment cycles of both Velbus and any other open source tool.

[lgor]

Any comments from Velbus staff / development would be much appreciated.

Is this unintentional? new strategy? documentation? commitment to open source?

[MDAR]

There is a massive change in the range now that V2.0 is being delivered.

Documenting changes always takes a long time.

The R&D team are extremely busy ironing out the details, I’m sure the GitHub docs will be updated in the fullness of time.

[lgor]

I understand changes take time and I am not really concerned about some late documentation.

Rather, I am concerned about a broken upgrade philosophy with new builds for any module. Until now a build number was always considered as a contract that would stay valid for every newer build. This guaranteed any newer build would “just work” (new doc only required for new features).

Breaking this philosophy makes any assumptions about memory maps for new builds impossible (it isn’t even possible to detect if the map has changed). So any new build for any module will need a new rebuild for any tool using the memory map (like Velbus-AIO and home assistant).

The breaking of the old (and fine) upgrade design pattern in new builds seems to me like a design flaw … or maybe, hopefully, I got something wrong. That’s why I urge to get some comments from Velbus staff / development.

[VEL342]

Hi @lgor ,

Thanks for raising this concern — the feedback is absolutely valid and we understand why this creates uncertainty for community developers and tool maintainers.

There is indeed a significant architectural difference between the original VMBELO and the new VMBELO-x-20 series. The latter is not just an incremental update but a complete redesign of the glass panel electronics and firmware.
Because of this, the memory map of the VMBELO-x-20 is not an extension of the old one but a fully new layout, and should therefore be treated as a new product family, rather than a firmware evolution of the classic VMBELO.

We fully acknowledge that the protocol documentation for the VMBELO-x-20 is not yet complete online — this is work in progress, and we’ll make sure the updated protocol files are published.

That said, the core Velbus philosophy regarding backwards compatibility has not changed:

• Both VMBELO and VMBELO-x-20 modules can be used together in any installation.

• VelbusLink includes a “replace module” function that correctly maps the old VMBELO memory layout onto the VMBELO-x-20, ensuring safe migration.

• For future updates of the VMBELO-x-20, we will follow the long-standing Velbus practice of only extending the memory map for added features, not shifting or redefining existing fields.

So while the transition between VMBELO → VMBELO-x-20 is indeed a structural break (due to the hardware redesign), you can expect the familiar stability and forward-compatible behaviour going forward.

If anything remains unclear or if additional details could help tool maintainers, feel free to let us know — we appreciate the collaboration with the community.

[lgor]

At first: thanks for feedback and further commitment to community.

For clarity: I am not talking about the VMBELO-x-20 redesign. Although this new design poses some additional support work it doesn’t break compatibily. The VMBELE-x-20 is clearly marked by a new module type (0x52) and is therefore allowed to have a brand new memorymap without breaking anything.

The problem arises when the memorymap of an existing (classic ?) module changes. As a (modest) contributor / tester for Velbus-AIO I ran into compatibility issues between builds 2023 and 2524 of the classic VMBELO (module type 0x37). I guess this is unintentional but it stalls further development because there is no way to detect the memorymap changes except by hardcoded testing on (undocumented) build numbers. Also it’s unclear if this applies also to other “classic” module types.

Focused on upcomming new Home Assistant release, could you please comment on (unintended ?) break.

[lgor]

@VEL342 : Can you please confirm change of classic VMBELO memorymap (type 0x37)? If affirmative is there already a strategy for further updates (reverting to old memorymap, continuing with new map and freeze this map for all newer builds, …). Additional is this a VMBELO (0x37) only problem or are there other module types affected? Some more info would be very appreciated and would help al lot for preparing new community builds!

[VEL342]

Hi Igor, we are reviewing the changes that happened to the VMBELO memory map. It might be possible that they were affected due to a merge with the VMBELO-x-20 newer module, but we can’t confirm this yet. We will review if this change was accidental and can be reversed.

[VEL342]

Hi everyone (and @lgor ),
after reviewing this in detail together with the Velbus firmware engineering team, we want to provide a clear and comprehensive explanation of what happened with the VMBELO memory map changes.

Why the Memory Map Was Rewritten

As many of you know, Velbus normally avoids altering memory maps of existing modules because we fully understand how critical those stable structures are for DIY developers, integrators, and third-party tools.
However, the original memory map of the VMBELO series had reached architectural limits. It lacked both the address space and structural consistency required to support several new features that have recently been introduced—or are planned—in the VMBELO-x-20 line.

To address these constraints, the firmware team decided to consolidate the edgelit products under a single, unified memory map, aligned with the newer models. The alternative (maintaining two incompatible memory maps) would have created:

• substantial branching in the firmware,

• inconsistent behavior across modules,

• long-term difficulties for community tooling, and

• stability risks as the feature set grows.

A clean redesign ensures these modules remain viable and extendable over the long term.

Why We Aim for Functional Parity Between Old and New Modules

One of our core principles at Velbus is to make sure older modules don’t become “stuck” with limited capabilities. Whenever possible, we push new or improved behaviors from our latest modules back into the earlier generations—so end users benefit from newer features without needing to replace hardware.

To make this backwards-feature-compatibility possible, a high degree of alignment between memory maps is required. This is the main reason that the updated VMBELO map now mirrors the layout of the newer VMBELO-x-20 modules: it creates a unified structure that allows feature enhancements to flow to both old and new devices without fragmentation or behavioral mismatches.

The rewrite therefore wasn’t just a technical cleanup—it was a foundational step to ensure that older edgelit modules can keep benefiting from improvements developed in the newer series.

Why Communication Was Limited

We also want to acknowledge the communication aspect.
This change was implemented as part of a larger internal firmware consolidation and test-bench harmonization project. Because it was bundled with several other structural updates, the memory map rewrite didn’t surface as a standalone item in external release channels.

As a result, it didn’t get the visibility we normally aim for in community documentation and announcements. While no blame is on any individual or team, we recognize that this caused confusion for DIY developers and those maintaining custom integrations. We’re sorry for the inconvenience this created and appreciate your patience as we clarify the situation.

Compatibility With Velbuslink

It’s also important to clarify how this affects programming and configuration through Velbuslink.

1. Programming mixed modules (VMBELO + VMBELO-x-20) works without issues.
Velbuslink includes an internal translator layer that maps the older VMBELO memory structure to the newer unified format.
This ensures that in practical use:

• both generations can coexist in the same installation,

• programming them in a single project is fully supported,

• and Velbuslink handles the migration transparently.

This translation mechanism was added precisely to preserve compatibility for real-world systems and avoid breaking existing installations.

2. Newer firmware cannot be programmed with older Velbuslink versions.
Modules running firmware that uses the updated memory map require a Velbuslink version that understands this new layout.
Older Velbuslink releases do not have the translator layer and therefore cannot reliably program modules with the modified memory map.

This safeguard prevents misconfigurations and ensures that any module with the new map is always handled correctly.

What This Means Going Forward

The move to a unified memory map brings several long-term benefits:

• improved stability and predictable behavior across all edgelit modules,

• reduced fragmentation in firmware and documentation,

• a more maintainable platform for future features,

• and better alignment for community tools and automations.

In practical terms, this update lays the groundwork for consistent functionality across both older and newer edgelit devices.

Affected Modules

• VMBEL1

• VMBEL2

• VMBEL4

• VMBELPIR

• VMBELO

We sincerely appreciate the effort and expertise the community invests in supporting these modules. Your feedback is extremely valuable, and we’ll make sure changes of this scope get clearer communication moving forward.

[lgor]

@VEL342: Info much appreciated and nice to know this is a one time break . Still we need a way to recognize the break: can you communicate buildnumbers for affected modules. At the long term it would be nice to add this to the protocol doc files.

[VEL342]

Hi @lgor ,

VMBEL1, VMBEL2, VMBEL4 and VMBELPIR had the original memory map untill build 2221.
Build 2524 is similar to the -20 modules.

VMBELO had the original memory map untill build 2310. Build 2438 is similar to the -20 modules.

[lgor]

@VEL342

With the provided build info the fix was easy. However … it seems impossible to protect against any simular break in the future.

Tkanks!