VMBELO - Send raw bytes function

[fredericdepuydt]

Hi,

I'd like to control the feedback leds of my VMBELO, but also be able to change the colors on the fly based on a specific rule. I've reverse engineered the communication between the VMBELO and the VelbusLink software while setting a specific feedback color for a specific channel.

Changing the feedback led color during operation would require a Write Memory Block (CA) command to be sent to the VMBELO. So the first question that arrises: is this bad practice?

This CA command for example sets the colors of CH1 - 4 to "16:Blue" (0x1F) for the Continuous mode (0x30): Write Memory Block(CA) Raw bytes: 05 30 1F 1F 1F 1F

I'm willing to dive into the code to add this functionality myself, but I'd like to discuss this idea here first.

How I would approach this: 1) I'd need to create a function that allows to send the Write Memory Block command with an array of raw bytes as content. 2) The command should be callable from a rules file (probably using the Thing, as it doesn't apply to a specific channel) If these two steps work, the hard work is done. 3) Then I could create a wrapper for the command that takes a channel and color as input 4) Additionally the function can wait for the response of the VMBELO to check whether the color is actually applied correctly

How would I go about step 1 and 2? Can a Thing function be called from within a rule? Would love to hear your thoughts.

For those questionning my reasons for willing to implement this: I'd like to be able to set specific colors on the VMBELO based on specific events. I could use channels from multiple pages but most of the time the VMBELO will be in screensaver mode, in that case only the feedback of the Startup Page (CH1-4 for me) can be shown, limiting me to a single color per led.

EDIT: An alternative way of achieving this, is by using the 1806 command "Set continious feedback color", but as I want OpenHAB to be the initiator I don't see a possibility to call/reach this function. Unless again I can manually sent a raw command that fakes the initiator?

Kind regards, Frederic Depuydt

[StefCoene]

Hi,

The protocol files for all velbus modules are pulicly available: https://github.com/velbus/moduleprotocol

You don't need to write to memory to set the color. I don't recommend doing so. It's possible that new firmware revisions have other memory maps and writing to the wrong memory address may brick your module!

Setting the color is tricky. You first have to define the color in a palette. And then specify which palette should by applied to a certain edge. The relevant command is for both COMMAND_SET_PB_BACKLIGHT (0xD4) But depending ont he nummber of COMMAND_SET_PB_BACKLIGHT (0xD4) and databytes it's for defining the palette or setting the background.

I was able to do this in my scripts: https://github.com/StefCoene/velserver

Relevant code can be found in https://github.com/StefCoene/velserver/blob/master/lib/Velbus/Velbus.pm Search for 'edge_color' and 'edge_lit'

Stef

On 2020-08-14 17:21, Frederic Depuydt wrote:

Hi,

I'd like to control the feedback leds of my VMBELO, but also be able to change the colors on the fly based on a specific rule. I've reverse engineered the communication between the VMBELO and the VelbusLink software while setting a specific feedback color for a specific channel.

Changing the feedback led color during operation would require a Write Memory Block (CA) command to be sent to the VMBELO. So the first question that arrises: is this bad practice?

This CA command for example sets the colors of CH1 - 4 to "16:Blue" (0x1F) for the Continuous mode (0x30): Write Memory Block(CA) Raw bytes: 05 30 1F 1F 1F 1F

I'm willing to dive into the code to add this functionality myself, but I'd like to discuss this idea here first.

How I would approach this:

1. I'd need to create a function that allows to send the Write Memory Block command with an array of raw bytes as content.
2. The command should be callable from a rules file (probably using the Thing, as it doesn't apply to a specific channel) If these two steps work, the hard work is done.
3. Then I could create a wrapper for the command that takes a channel and color as input
4. Additionally the function can wait for the response of the VMBELO to check whether the color is actually applied correctly

How would I go about step 1 and 2? Can a Thing function be called from within a rule? Would love to hear your thoughts.

For those questionning my reasons for willing to implement this: I'd like to be able to set specific colors on the VMBELO based on specific events. I could use channels from multiple pages but most of the time the VMBELO will be in screensaver mode, in that case only the feedback of the Startup Page (CH1-4 for me) can be shown, limiting me to a single color per led.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cedricboon/openhab2-addons/issues/30, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCM6OLAEGPA47BGPOHIJTDSAVI63ANCNFSM4P7TIZGQ.

[fredericdepuydt]

Hi,

I wasn't aware the complete protocol was publicly available. Makes things a lot easier! The COMMAND_SET_PB_BACKLIGHT (0xD4) would indeed be the way to go here, I had a quick look in this repo but assume this function is not yet implemented. (Looking at the VelbusBindingConstants.java file)

public static final byte COMMAND_READ_MEMORY_BLOCK = (byte) 0xC9;
public static final byte COMMAND_MEMORY_DATA_BLOCK = (byte) 0xCC;
public static final byte COMMAND_SET_REALTIME_CLOCK = (byte) 0xD8;
public static final byte COMMAND_SWITCH_TO_COMFORT_MODE = (byte) 0xDB; 

I also notice that Cedric has declared all the command constants independently of the module. Is it safe to assume that the velbus command value is unique and never used twice with different functionality depending on the module?

The implementation of the 0xD4 command is small work, the part I don't know how to tackle still remains: how would I trigger this function/command call from within an OpenHAB rule?

Kind regards, Frederic Depuydt

[StefCoene]

Hi,

If you want a more parsable format for all protocol files, take a look at my site: https://qos.docum.org/velserver/

The info is based on the protocol files. The code to parse the protocol files can be found here: https://github.com/StefCoene/moduleprotocol

If you want to have a list of modules that uses message D4: https://qos.docum.org/velserver/?action=MessageDetail&Message=D4

Stef

On 2020-08-15 10:33, Frederic Depuydt wrote:

Hi,

I wasn't aware the complete protocol was publicly available. Makes things a lot easier! The COMMAND_SET_PB_BACKLIGHT (0xD4) would indeed be the way to go here, I had a quick look in this repo but assume this function is not yet implemented. (Looking at the VelbusBindingConstants.java https://github.com/cedricboon/openhab2-addons/blob/2.5.x/bundles/org.openhab.binding.velbus/src/main/java/org/openhab/binding/velbus/internal/VelbusBindingConstants.java file)

|public static final byte COMMAND_READ_MEMORY_BLOCK = (byte) 0xC9; public static final byte COMMAND_MEMORY_DATA_BLOCK = (byte) 0xCC; public static final byte COMMAND_SET_REALTIME_CLOCK = (byte) 0xD8; public static final byte COMMAND_SWITCH_TO_COMFORT_MODE = (byte) 0xDB;|

I also notice that Cedric has declared all the command constants independently of the module. Is it safe to assume that the velbus command value is unique and never used twice with different functionality depending on the module?

The implementation of the 0xD4 command is small work, my issue remains: how would I trigger this function/command call from within an OpenHAB rule?

Kind regards, Frederic Depuydt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cedricboon/openhab2-addons/issues/30#issuecomment-674368592, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCM6OLC7YUNF25HLKX7LJTSAZB4RANCNFSM4P7TIZGQ.

[MDAR]

If you want to experiment with commands, before diving into the code of the binding, as Stef suggests, you could use his scripts, or there is the Node-RED Velbus nodes that can be used to set all kinds of features.

https://flows.nodered.org/node/node-red-contrib-velbus

The implementation of the 0xD4 command is small work, the part I don't know how to tackle still remains: how would I trigger this function/command call from within an OpenHAB rule?

If you are suggesting adding functionality to the binding, then my guess would be you'd need to add a Channel to a Thing. So that a rule can send a command to the linked Item, much the same way that Heating modes or feedback LEDs etc are read & set.

This is something we've spoken about previously, but there wasn't much inspiration to do anything with it.

It would certainly be a nice addition, I'm happy to help you test anything, but please keep in mind that my specialty is in physical system design and installation, rather than the software.