-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VMBELO - Send raw bytes function #30
Comments
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
<#30>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABCM6OLAEGPA47BGPOHIJTDSAVI63ANCNFSM4P7TIZGQ>.
|
Hi, I wasn't aware the complete protocol was publicly available. Makes things a lot easier!
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, |
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
<#30 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABCM6OLC7YUNF25HLKX7LJTSAZB4RANCNFSM4P7TIZGQ>.
|
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
If you are suggesting adding functionality to the binding, then my guess would be you'd need to add a Channel to a Thing. 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. |
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:
If these two steps work, the hard work is done.
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
The text was updated successfully, but these errors were encountered: