Some considerations and tips

Hello,

Recently I bought some Velbus modules in order to experiment Velbus system on PC, in fact the possibility of interaction with PC makes the Velbus system very attractive, making it possible to virtually do anything that passes by your creative mind, also as a whole I found Velbus system very flexible, adaptable, reliable and despite everything simple making it in a product of success.

At moment I’m sketching some .NET code for Velbus, and some ideas and questions began to arise.

1 - VMB4PD this control panel as anyone knows is very limited, after all you have only 2 lines of 16 characters, and off course if you try to do some real time custom menus through .NET code, quickly you will find some trouble because any simple menu certainly will hold more than 2 lines of 16 characters, given this the only alternative is trying to create some kind of scrolling text, however final result isn´t very satisfactory due to a slow display method, I believe is related with write memory data or Velbus bus speed.

2 – After some time studding Velbus packet I found that it´s allocated one byte to store all the Velbus commands, this means that there are only 255 available send and receive command interactions against ± 84 already taken.

3 – All Velbus Modules that deal with power drain Ex. “VMB1DM “, “VMB1RY “, “VMB4RY”, etc…, Should have some kind of feature “Power Load Monitor” something that reports how many power in Watts is being consumed in the exact moment. However to avoid bus congestion, this data should only be sent when a request is made or the value have changed for a certain percentage and an amount of time. Ex.5% for a second.
Ex. 1000W = Present power load
1000W*5% = 50W
if 1000W changed to 949W or 1051W and stayed changed for more than a second then send Power Value to Velbus bus.
Off course when I say 5% for a second is just an example, this values should be studied by Velbus engineers.
Nowadays this kind of feature “Power Load control” will help systems such as Velbus making sense, creating homes environmentally friendly and energy efficient .

4 – Another important feature is lighting related, today we see more LED lighting systems than ever especially ones where I believe that is the future, called RGB LEDs or Arrays of RGB LEDs, I have been investigating and is understandable such demand, because not only is light intensity controlled ”dimmable” but also spectrum color controlled “color controlled” , allied the fact that is energy efficient. There are a lots of systems “LED controllers or LED drivers” in the market based on DMX or RDM protocol that can handle such task, however none of them has the ability to be easily driven, integrated and computer controlled like in Velbus system, would be nice creating an RGB controller module similar to dimmer module but for LEDs control, with a dimming function and selectable output of 12V/24V ± 180/300W and independent color channel control R / G / B .

I hope my contribution would be very handy, helping Velbus System to grow and becoming a standard industry .

Greetings to all and good work.

Hello Ntiago,

I was suspected this but would to be sure :
Velbus module are limited to 255 on the same bus ? it should be enough for an individual home, no ?
What do you mind with +/- 84 ???

Thanks

Hello Golfy,

I think you did a little confusion, correct me if i’m wrong, i believe you mean, total number of possible modules in a single bus “Addressing Byte3”, if this is the case then yes, 255 modules in a single bus is the maximum limit, however I believe as you say to a normal individual home should handle the task i hope :wink:, what I mean is all available commands that operates velbus modules “Byte5”, I will describe in brief how the velbus packet is made:

255 Byte1 - Begin of Packet, “stx” 0F
255 Byte2 - Priority, FB = LOW, F8 = HI
255 Byte3 - Address, all available Module address’s from 00 to FF Hex = 0 to 255 Decimal
255 Byte4 - Data Size, From 00 to 08, size of data command sent or received, beginning on Command and itself included.
255 Byte5 - Command, all velbus commands “sent and receive” that tells to each Module what to do, From 00 to FF, some of them are specific, while others are common to all Modules Ex. FF = request node type .
255 Byte6 – Parameter1, Databyte1 holds fist part of data corresponding to command.
255 Byte7 – Parameter2, Databyte2 holds second part of data corresponding to command.
255 Byte8 – Parameter3, Databyte3 holds third part of data corresponding to command.
255 Byte9 – Parameter4, Databyte4 holds fourth part of data corresponding to command.
255 Byte10 – Parameter5, Databyte5 holds fifth part of data corresponding to command.
255 Byte11 – Parameter6, Databyte6 holds sixth part of data corresponding to command.
255 Byte12 – Parameter7, Databyte7 holds seventh part of data corresponding to command.
255 Byte13 – Parameter8, Databyte8 holds eighth part of data corresponding to command.
255 Byte14 –CRC8 or Cyclic Redundancy Checksum is used to control if a packet was received correctly, this value can hold From 00 to FF and corresponds to : 256 -Hex sum of (Byte1+ Byte2+ Byte3+ Byte4+ Byte5+ Byte6+ Byte7+ Byte8+ Byte9+ Byte10+ Byte11+ Byte12+ Byte13+ Byte15)
255 Byte15 – End of Packet, “etx” 04

Here is a list of all present available Commands already taken that i was referring +/-84:

All Present send and receive available Commands “Byte5”
Nr Address, And Function
1 00 switch status
2 01 switch relay off
3 02 switch relay on
4 03 start relay timer
5 04 blind off
6 05 blind up
7 06 blind down
8 07 set dimmer value
9 08 start dimmer timer
10 09 bus off
11 0A bus active
12 0B rs232 buffer full
13 0C rs232 buffer empty
14 0D start blink relay timer
15 0E interface status request
16 0F slider status
17 60 firmware update request
18 61 firmware info
19 62 enter firmware upgrade
20 63 abort firmware upgrade
21 64 exit firmware upgrade
22 65 firmware upgrade started
23 66 write firmware memory
24 67 firmware memory
25 68 firmware memory write confirmed
26 69 read firmware memory
27 C6 temperature settings part3
28 C7 statistics request
29 C8 statistics
30 C9 read memory block
31 CA write memory block
32 CB memory dump request
33 CC memory block
34 CD lcd line text part1
35 CE lcd line text part2
36 CF lcd line text part3
37 D0 lcd line text request
38 D1 enable timer channels
39 D2 reset backlight
40 D3 reset pushbutton backlight
41 D4 set pushbutton backlight
42 D5 backlight status request
43 D6 backlight
44 D7 real time clock request
45 D8 real time clock
46 D9 error count request
47 DA error count
48 DB temperature sensor comfort mode
49 DC temperature sensor day mode
50 DD temperature sensor night mode
51 DE temperature sensor safe mode
52 DF temperature sensor cooling mode
53 E0 temperature sensor heating mode
54 E1 temperature sensor lock
55 E2 temperature sensor unlock
56 E3 set default sleep timer
57 E4 temperature sensor set temperature
58 E5 temperature sensor temperature request
59 E6 temperature sensor temperature
60 E7 temperature sensor request settings
61 E8 temperature sensor settings part1
62 E9 temperature sensor settings part2
63 EA temperature sensor status
64 EB IR reciever status
65 EC blind switch status
66 ED input switch status
67 EE dimmer status
68 EF module name request
69 F0 module name part1
70 F1 module name part2
71 F2 module name part3
72 F3 set backlight
73 F4 update led status
74 F5 clear led
75 F6 set led
76 F7 slow blinking led
77 F8 fast blinking led
78 F9 very fast blinking led
79 FA module status request
80 FB relay switch status
81 FC write eeprom data
82 FD read eeprom data
83 FE eeprom data status
84 FF node type

The Velleman HQ is completely equipped with Velbus domotics (three story building with offices and a large warehouse), and we still haven’t used up all possible addresses. So any home would certainly not be able to occupy the entire address range.

It is true that the Velbus is limited to about 255 commands, but with the current range of modules i think we might just have used up less than half of that range.

Thus a BYTE type seems to be the best choice to reduce traffic and overhead as long as the ranges are sufficient.

The above list is rather outdated. What’s the best place to find the most up-to-date list?
Is there a github project on where to find a list of constants?

This link is a good resource, but not useful for developers to get the corresponding hex values.

I would love to see Velleman open sourcing the VelbusLink tool! :wink: Having an open API would be heaven! :stuck_out_tongue:

I think you’ll find that the Command list is still valid, as it is the basis of all Velbus actions.

Have you seen this post ?
https://forumtest.velbus.eu/t/official-github-repository/14828

Hi MDAR,

Thanks for the links, but I already checked them: the only option is to manually go through all of the module protocols and find a way to copy/paste them, because protected pdfs don’t allow copy/paste out of the box…

I found a few commands that are not in the above list, eg some used by the VMBELO:
COMMAND_MODULE_SUBTYPE: 0xB0,
COMMAND_VARIABLE_DIMMER_STATUS: 0xB8,
So there might be more …

For programmers it’s quite cumbersome to fully understand the packet commands for all modules. The only help we have are the basic explanations in the protocol pdfs and the VelbusLink packet logging.

Luckily I enjoy the process of reverse-engineering, but it’s a slooow process :wink:

Gert