Yes that is correct . when I choose the address it doesn’t work, when I choose to fill in the address myself it works 
I had a look at this, but as as far as I know there is no command to get the module name. Velbuslink probably stores the name you give to a module in the project file (.vlp), so that data is not available on the bus.
Of course it would already help to always get the names of the channels (as I do with the button node) but that requires knowledge of the nr of channels of each module, and therefore we first need that JSON file! 
But, as I’m typing this, I see that @Stef_Coene just posted a very promising update! 
1 Like
The module names and even more labels can be stored in the device memory.
Exactly: line 2151
https://github.com/StefCoene/moduleprotocol/blob/master/out/protocol.json#L2151
A lot new stuff to discover/implement, co-operation serves more FUN.
Congrats guys for the efforts made over and over again!
3 Likes
Regarding the module name, indeed, you have to query the memory. And for some older modules you can not change the module name.
I had some issues with different addresses for different builds. For most of the modules there is only 1 possible memory address combination. That’s were the MemoryMatch is used for.
I could also skip this part and only support the last build, that was also an option.
In my scripts, I take the address range and store all of them in a list. When I need the module name, I query the addresses one by one.
My ‘listener’ has the same list of addresses and when the module answer, it parses the message and stores the character in the correct place. When the last address is received, it saves the module name.
Stef
3 Likes
To be honest I’m overwhelmed by the splendid work @Stef_Coene did 
This means there’s no excuse anymore to get my hands dirty and implement that JSON file! 
2 Likes
If you’re looking for text strings to test with, I created these for use within openHAB2.
1 Like
I want to fix this, but I can not replicate it - both work om my relay module 
Can you have a look at the VelbusLink logger what command is sent in both scenarios?
Tx!
I agree with the logic you explained here but I did not succeed changing those ambient colors 
Is this command overruled by another settings somehow?
Can you confirm it’s working on your setup?
Yes I can confirm, just tested this code:
[
{
"id": "dff627b9.b51c08",
"type": "velbus-send-raw-bytes",
"z": "e143c9bc.3a1eb8",
"name": "Send Raw Bytes",
"connector": "2a1a837f.ef12bc",
"dataBytes": "",
"dataBytesType": "PAYLOAD",
"address": 0,
"addressType": "MSG",
"priority": "251",
"rtr": 0,
"x": 840,
"y": 640,
"wires": []
},
{
"id": "c77b684.d3bb598",
"type": "trigger",
"z": "e143c9bc.3a1eb8",
"op1": "1",
"op2": "0",
"op1type": "str",
"op2type": "str",
"duration": "-1",
"extend": false,
"units": "s",
"reset": "",
"bytopic": "all",
"name": "",
"x": 140,
"y": 640,
"wires": [
[]
]
},
{
"id": "f1666b2.98f5f98",
"type": "random",
"z": "e143c9bc.3a1eb8",
"name": "random 2-30",
"low": "2",
"high": "30",
"inte": "true",
"property": "random",
"x": 450,
"y": 640,
"wires": [
[
"40f9a309.bbf99c"
]
]
},
{
"id": "40f9a309.bbf99c",
"type": "function",
"z": "e143c9bc.3a1eb8",
"name": "format 0xD4 for 0x81",
"func": "msg.random += 0x60;\nmsg.payload = \"0xD4 0x01 0x0F 0x\" + msg.random.toString(16);\nmsg.address = \"0x81\";\nreturn msg;",
"outputs": 1,
"noerr": 0,
"x": 640,
"y": 640,
"wires": [
[
"dff627b9.b51c08",
"df67f7bd.267778"
]
]
},
{
"id": "df67f7bd.267778",
"type": "debug",
"z": "e143c9bc.3a1eb8",
"name": "",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "false",
"x": 830,
"y": 600,
"wires": []
},
{
"id": "3b4ad771.20c788",
"type": "inject",
"z": "e143c9bc.3a1eb8",
"name": "",
"topic": "",
"payload": "",
"payloadType": "str",
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"x": 350,
"y": 600,
"wires": [
[
"f1666b2.98f5f98"
]
]
},
{
"id": "2a1a837f.ef12bc",
"type": "velbus-connector",
"z": "",
"ip": "192.168.1.xxx",
"port": "yyyy"
}
]
Can you import this nodes and check?
Change velbus-connector ip/port and your edge address (mine 0x81) in function node code.
Alright! It was still not working until I saw that the address was not set right: same issue as you had: once I fill in the address manually, it dit work!
So now I have a test case to find that bug!
1 Like
Here’s another release of node-red-contrib-velbus v0.2.09!
Mostly bugfixes this time:
- Bugfix: Some modules had a wrong nr of relays (thanks to MDAR)
- Bugfix: The first gen. glass panels had no temp sensor (thanks to MDAR)
- Bugfix: The relay node had no icon in specific circumstances
- Bugfix: Address was empty when data bytes were parsed from payload (thanks to jorampic)
- Enhancement: More descriptive default names (but no module names yet, MDAR
)
2 Likes
Thanks @jorampic, but in the meantime I could fix the bug. There’s a new release 0.2.09 
At least, I hope you did not see this error in the latest version anymore? 
1 Like
Error is fix Well done GertSt 
2 Likes
Hi
I’m trying to select anything other than channel 1 on a VMB4DC and it’s not playing nicely.
I guess you are using the Dimmer node? I’ve implemented the commands for the VMBDMI, as these are the dimmers I have. I checked the docs and indeed, the VMB4DC has some changes in the protocol 
Another reason to implement @Stef_Coene’s protocol JSON! 
1 Like
I have tried to play with the Dimmer node a bit more and can’t get any joy with a DMI-R or 4DC.
(the channel selection doesn’t seem to want to play ball, but even a DMI-R doesn’t want to play)
Would you like to connect remotely and experiment with either?
I guess it will only work with the older DMI… The DMI-R has a slightly different way of dimming.
So I first have to add those commands and then it would be helpful to test them out remotely.
Thanks for the offer to test remotely - I’ll let you know when I have a something ready!
1 Like
Hey Gert
How are you getting on?
Are you keeping yourself amused ?
Can I put two suggestions forward for your Node-RED nodes?
-
Can you add the Thermostat “button” events to the Button node?
IE.
Button 1 of a thermostat base address is Heater
Button 2 is Cooler
Button 3 is Pump
Button 4 is Boost (I think that’s the order)
Buttons 5 to 8 are the threshold alarms
(By just allowing the manual entry of the thermostat [sub] address {Address used for the thermostat, not the glass panel}) -
A minor tweak, can you set the default bridge address to
127.0.0.1, instead ofraspberrypi.local
Many thanks,
Stuart