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?
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.
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.
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.
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.