msg.payload = channel/s as HEX, so multiply channels can be triggered
If no Topic, use the command as set in the Send Raw Bytes node
If a Topic exists as a single Hex value, use that as the Command
(Although I do like how you’ve got it accepting a name string, so maybe that for clarity?)
Having the command from the topic and/or having the databytes from the payload for sure will make the node easier to use for dynamic input. I also like the Mustache input as it is quite readable once you are familiar using it. But there’s a learning curve…
So you got me thinking
Bottom line: it should be easier to use! Usability is key here!
Here is a new mock-up on how a screen might look like:
I don’t have a separate Command and Data Bytes input anymore, but I merged them:
If you Choose “All data byte from payload”, all will be picked up from the payload. Easy.
“Command from Topic + other data from Payload”: no extra info needed I guess?
“Manual input”: all data bytes should be filled in manually
All other options are in fact the commands (=1st data byte) and the other data bytes should be filled in by the user.
Here’s a view on how it looks with different options selected:
Sorry, I made a mistake in the dependencies of version 0.2.6.
So I just pushed an update 0.2.7 to fix this.
If you have difficulties upgrading using the Palette Manager, due to the error in 0.2.6, I recommend to remove the module manually using the command line:
$ cd ./.node-red (or another path where you installed node-red)
$ npm uninstall node-red-contrib-velbus
Now you can install the latest version again by using the Palette Manager or using command line $ npm install node-red-contrib-velbus
As an edge use case example for your nodes, I tried to set the Ambient edge light colours of a VMBEL2 yesterday by using Command 0xD4 (which appears twice in the protocol document)
Nothing I tried in VelbusLink or your NodeRed nodes worked.
When I used the Module configuration in VelbusLink to set the edge lights, I saw in the log that the memory map was being directly addressed, with no reference to a 0xD4 command.
The Data Bytes format was easy enough to follow, so maybe this is an example of how a table of commands would be useful, or a specific node for this type of command.
I tried it myself, both using the Send raw bytes node as from within Velbuslink (using the Send a Packet window), but it did not work here either.
The required databytes should have a specific binary combination and the documentation is not too clear to me. So I probably feed it with the wrong bits
An example from Velbus would be helpful here …
Code for upper button ambient color: 0xD4 0x01 0x02 0x6y
should be for fix light with highest priority 0bx11yyyyy, x=1 is for blink and y are color bits
Looking at error prone binary data like this, it would be so cool to have a user-friendly interface to rule all those commands!
That’s why we need a well structured, detailed JSON file! At least, that would be the first small step
I’m getting a little confused… (maybe I’m hungry?)
Reading this (Page 23), it looks like I need to send
Command = 0xD4
To module address = 0xE2
To apply to background lights = 0x01
To apply to all 4 side = 0x0F
To apply Colour pallet no 28 to background without blinking = 0x1C
We now have a dimmer and a relay node.
Easy to set or get the brightness of a dimmer or to switch a relay on or off.
I’m using it to write dimmer and relay states to InfluxDB and visualizing it with Grafana.
Set it up on a Pi and an hour later you have some nice usage logs of all your Velbus relays and dimmers.