Graphical design tool

[ES9830]

I have created several drawings illustrating the functionality of some components in my installation (see attachment).

This is quite a lot of manual work, and if you later make changes to the coding, you have to start over.

I would like to explore the possibility of automatically generating these schematics from the .vlp file into, for example, a .dwg (AutoCAD) format.

Can anyone tell me where I can find the description of the database structure of the .vlp file?

The ultimate goal would be to use a graphical design tool to generate Velbus code and then import it into the .vlp file.

Dreaming is allowed, and the best way to fail is simply not to try.

[PrzemoF]

On the output end - check graphviz. Autocad is proprietary, expensive and scripting it is not always easy. VelbusLink is not open source - not sure if there is a database file specification available. Would be great to be able to dump the info in some human readable format like yaml…

[MDAR]

Did you know that holding the top right hand corner of the latest glass panels for a few seconds puts them into cleaning mode?

---

I like yEd Works for layout

---

The entire memory dump is stored in raw form in the VLP files.

But what each part does isn’t public information.

You’ll also need to compare input devices to output devices, as only the reactions are stored in each module.

[Ggaljoen]

@ES9830

Can anyone tell me where I can find the description of the database structure of the .vlp file?

Each .vlp file is in XML, the best thing to look for is the < Module> info and further < Memory> section. For each module, the “Memory map” (at the end of each document) can be found here: Velbus Github -Link-
Be carefull to use the correct Build version mapping…

In VelbusLink “Advanced Mode” you can see the same info from a module in the Memory Debugger (Ctrl+M).

[ES9830]

I was able to open the .vlp file with an XML editor, but I can’t get any further.
I see the following data:
• Project settings
• Customer: name – address …
• Installer: name – address …
• Connection: Network host (IP address) …
• Modules: build – address – type – serial – locked – layer – terminator
• Caption – memory – snapshot

And that’s it.

The last two (memory and snapshot) are hexadecimal strings (probably machine code).
No information on channels nor action-codes

There’s nothing else in the file.

Anyone have an idea?

[ES9830]

It can’t be that I have to write a decompiler for every module, right?

[Ggaljoen]

@ES9830

The last two (memory and snapshot) are hexadecimal strings (probably machine code).
No information on channels nor action-codes

Did you bother to look at the memory map of a module you own (see my previous link)?

@ES9830

It can’t be that I have to write a decompiler for every module, right?

Unfortunately, something similar will be needed to get a handle on the actions and configuration of each module type.
It will be a big project (what you have in mind), but the good thing is that all the information is available!

[ES9830]

I think my story ends here.

Yes, I have looked at GITHUB. It describes all CAN messages per module in detail.

It is – for me – unthinkable to decompile the ‘compiler code.’

The .vlp file looks like an normal .xml file, but the elements “memory” and “snapshot” are in an internal Velbus format.

I have examined element “memory” in detail using a HEX viewer, and you can see readable text among the data (the labels you assigned to the elements), but what the other hexadecimal code represents, I have no idea. The CAN codes are probably stored there. However, for a simple 0103, you probably already need at least 10 CAN messages, both on the sending and receiving sides of both the switch and the relay.

Thank you to everyone who inspired me to try.

[ES9830]

[MDAR]

Have you tried programming a single action between two modules and comparing the XML?

And have you looked at the Log tab for activity between the same modules when the action is triggered?

[Ggaljoen]

@ES9830

I think my story ends here.

It is – for me – unthinkable to decompile the ‘compiler code.’

It’s best to start with a small chunk of data.

Perhaps you could start by ‘translating’ the VelbusLink 40 action codes from the VMB4RYLD (like 0103 etc) to the memory action list H’00’ - H’27’ (H stands for hex)?

You might be surprised how ‘readable’ it becomes once this initial barrier is overcome…

[PrzemoF]

@ES9830 S9830 I’d suggest contacting the Velbus team and asking if they are willing to share the specification. Signing NDA (Non Disclosure Ageement) is another option. I had created a linux driver based on internal specifications of a company - it was good for me and for that company You’re not trying to steal the idea, you are trying to make the system better. Maybe Velbus team can cooperate.

[ES9830]

Thank you for the tip. I have already sent them an email, but at the moment Velbus is not open to sharing certain information.

I am currently working on version 1.7 (already, haha) and hope to have a fairly complete navigation and documentation system ready soon.

Maybe I can convince them with that.

My version uses a mini installation designed to test everything.

The screen looks a bit like an XML editor.

• On the left side, there is a navigation panel with several tables:

• On the right side, is used to show the the real data

• The title page of this installation, containing all relevant information about the owners, the installer, the installation address, NetworkHost, NetworkPort, NetworkHostname, NetworkSsl, NetworkPassword, and NetworkRequireAuth.

• The primary navigation panel: This allows you to view all action codes sent to or from a module and also trace the path from the initial initiator (the switch) to the final destination (like a lamp or roller shutter). You can also retrieve a list showing where a specific action code is used throughout the system.

• The Velbus action code table: This table lists all action codes along with a hyperlink to the official documentation on the Velbus website.

• The module table: This table contains all details about the module, such as the hex address, build, and the commercial name under which the module is sold. An icon representing the module is also included (like a relay, dimmer, switch, NO module, IN module, etc.). These icons are used in other panels to visually indicate the module type.

I’m still facing an issue while building a working table from which the various databases can be loaded. I’m working on it, but it’s “a hell of a job.” Why? Because I can’t get the bitmapping of and right.

I can retrieve all essential information, but parameters for actions (like the duration of a timer) seem impossible to obtain.

[VEL524]

I most of the times use the memory debugger which you can activate behind advanced mode in VelbusLink for any technical issues, then you can just see which bytes are being changed and look them up more easily in the protocol manual. The parameters for the actions are in the memory map.

The XML contains the memory of the module (what’s in the module when you read them out) and snapshot of the module (what is going to be in the module when you write to them).

[PrzemoF]

It’s just a question, feel free to remove the post if you consider it “too far reaching”. Would it be legal to start preparing documentation based on reverse engineering? I.e. module XXX version YYY, position WWW of memory dump is feature ZZZ? I have in the back of my head that there is no open (or just native linux) version of VelbusLink and one day we might need that kind of module documentation.