Velbus Multiple funtion switch

Setup, Configuration and Use Beginners
1

Hi, I have realised the connection between OpenHAB and Velbus. I works great but i have some problems. In Velbus i have 2 switches with dubble funtions. A short press will switch on lamp A and a 2 second press on the same switch will put lamp B on. When i make the connection in openHAB and switch lamp B on, lamp A will also switch on. How can i this avoid and realise the correct bindings.

How can I simulate a PULSE. To open the garage door in Velbus i only need to send a pulse and the door will go up, sending another pulse and the door will close (or stop). In openHAB i only find a SWITCH that youself need to open and close. I like to have a toggle switch (i comme back to the previous possition when you release it).

Thanks

Heman

2

You can use the expire binding for this:

Switch MySwitch { expire="1s, command=OFF" }

Everytime the switch is turned ON it will go OFF after 1s

1 Like
3

Hi

It’s great to hear that you’re using Velbus with OpenHab2.

To really help you, I would like to know how your Velbus buttons are configured.

For example…

Have you set multiple virtual buttons to your panels?

Or have you got some clever logic going on?

I guess what I’m asking is…

What are you trying to achieve and what are you trying to avoid?

If you’re saying that you DO want Lamp A & B to come on together, you could create a Group Switch in OpenHab2. (With configuration of your choice)

In your UI you then have …

Lamp A
Lamp B
Grouped Lamps A&B

I have done this with multiple dimmer channels to give a room UI…

Dimmer 1 - Slider
Dimmer 2 - Slider
Dimmer 3 - Slider
Etc

All Dimmer Channels - Slider (shown as an average, if dimmers have been set at different levels)

4

This is how i set it up, but it will not do what expected, the switch will stay in the ON position.

afbeelding.png
afbeelding.png777×169 8.24 KB

5

Thanks, but lamp A may NOT switch on when lamp B is ON.

6

Hi
I’m not entirely sure I understand what you want to achieve.

IF…

Lamp A must NEVER be on when Lamp B is on…

You could always add an action in VelbusLink, use a ‘Force Off, when initiator is closed’ (Action 0807) from Lamp B (Initiator) to Lamp A (Subject)

Action 0807 Definition EN

Action 0807 Definition NL

Action 0807 Definition FR

If you have a different use case in mind, could you re-phrase your question so I can get a clearer picture of what you want to achieve.

Best wishes,

Stuart

7

Stuart,

thanks for the reply

This i my problem:

In my gardenhouse, i have two ledstrips inside and 2 outside (add them later) . They may never switch on at the same time because the power of the driver is just enough for 2 strips. So i have only 2 switches, but in Velbus it’s not a problem because 1 switch can have up to 4 actions (press < 1sec, 1 sec press, 2sec Press, 3sec press).

(left switch put on ledstrip1, right switch put ledstrip2 on, an press on switch1 for moren dan 2 sec switch the 2 outside strips on)

When i make the connection now in openHab and is switch on the inside strips automaticaly the outside will light on and the driver will go in save mode.

When i switch on just the outside the there no problem.

8

I see now :smile:

I have something similar in my garden house too (also a power issue within my house for a mirror, but that is another story)

This does sound very strange.

Especially as you have it working perfectly in Velbus / VelbusLink.

Action 0807 would over-ride anything else you do, until a bigger power supply is available (because who wouldn’t want every light on??)

But that does not resolve why 2 relays are coming on when only the inside is switched in OpenHab2.

(I assume you have 2 seperate relays controlling these lights)

Can you look at the relay channels in VelbusLink to see that BOTH relays are switched on by OpenHab2 when only the inside is required.

@cedricboon is this anything you have seen before?

It is possible to add a rule in OpenHab2 to switch off Relay 1 as soon as relay 2 is on, but the in-rush to relay 2 lights would probably put your PSU into protect / safe mode anyway.

But that is just a work around and not a fix or an explanation why both relays are coming on.

9

It’s not clear to me what happens on the Velbus side. If you press the button, does it send “A” to OpenHAB immediately, or after 1 second? Or does it wait for 2 seconds to see if you wanted “B” before sending anything? Or nothing happens until you release the button?

10

Arrrr well… Yes, but no…

Velbus is a self contained protocol, where devices place status updates onto its bus, for other modules to react to.

The basics are…

A button is pressed - device sends a packet saying “device ID, Button number, status” in this case is “PRESSED”
A button is held - device sends a packet saying “device ID, Button number, status” in this case is “LONG_PRESS”
A button is released - device sends a packet saying “device ID, Button number, status” in this case is “RELEASED”

A module that is programmed to respond to an event will activate, also putting a status update on the bus device sends a packet saying “device ID, Channel number, status” in this case is “ON”

However…

The glass panels can do SO much more than just be a Single / Double / Quad button device.

Herman could have programmed a two button panel with multiple button actions.

For example…

1 quick pressed of button 1 will send packets stating that Button 1 has been pressed & released.
But a 2nd press of that same button will send packets saying that a virtual button has been pressed and released. (Thus causing a different set of events)
3rd press of that same button will send packets saying that a 2nd virtual button has been pressed and released.

Or…

Buttons can be put into DUAL mode.
Meaning that a short press of a button will send packets saying that the button has been pressed and released
A LONG press of that same button will send packets saying that a virtual / second button has been pressed and released (but not send a status packet about the primary / physical button)

Alternatively…

He could have programmed a relay to respond to LONG_PRESS packets only, which would mean a button must be pressed & held before an output module responds.

Lamp A responds to Pressed
Lamp B responds to Long_Pressed

However, none of that infomation accounts for why it works within the confines of Velbus, but directly switching the state of the output channel from OpenHab2 (in this case a relay) causes 2 relays to react. (This is not behaviour I have seen before)

OpenHab2 merely instructs to perform an action.

In this case I am assuming that Herman has created a number of OpenHab2 Switches to directly control the output relays.

(The feedback LEDs on the Velbus panels will show the new state of their linked outputs, regardless of how their state was changed)

FYI @cedricboon has added trigger channels so that OpenHab2 rules can respond to the 3 button states.

11

Hi,

My problem is solved, i had a typing error in the bindings in openHAB.

1 Like
12

Hello

I’m really glad that you’ve found the issue and it was something easy to solve.

How is the rest of your Velbus & OpenHab2 configuration coming together?

Just a thought…

Are you using the version of the Velbus binding from the public repository or do you use Cédric’s cutting edge version?

Best wishes,

Stuart

13

I use the binding from "Cedric Boon.

All is working fine in just a couple off day’s. I used even some self created icons.

The only problem i have till now, when i disconnect the USB cable between the Raspberry and Velbus VMBRSUSB I have some work before everyting is working again because the connection /dev/ttyACM0 is not the same. But it’s still in “test”, so soon, i will put a separate VMB1USB only for the connection between Velbus and Raspberry.

The next thing to learn now are the rules to make the system nicer and fine tune the system.

Herman

14

Hi Herman

Well, yes, that would be an issue.

I would strongly suggest running something like VelServ between your USB connection and OpenHab2.

(I haven’t unplugged a USB cable for months / years)

VelServ creates a TCP port on the host machine, so multiple clients can connect to your Velbus network.

VelbusLink & OpenHab2… And others :wink:

All you need to do in OpenHab2 is add a Velbus Network Bridge, then edit each Thing so that it uses the network bridge.
(A restart will get it all back up and running)

VelServ post on Velbus forum

Link between OpenHab2 and Velbus

https://forum.velbus.eu/t/velbus-software/3041/12

I’ve been using Jerome’s VelServ for a couple of years without any issues.

I have a zipped up copy of VelServ 1.5 if you want it. You’ll just need to compile it for your Raspberry Pi. (Really easy how to instructions are in the zip file)

As for rules and find tuning, have you seen the post on the Velbus forum that simply says…

(Something like)…

Since installing OpenHab2 alongside my Velbus, I haven’t pressed a button in months.

https://forum.velbus.eu/t/velbus-binding-for-openhab/14992/123

FYI…

If you don’t have the option of a Velbus Network Bridge, you don’t have the latest version of the binding :slight_smile:

Quote from Velbus Forum post

The new program also combines the two previous programs (client/server) and acts as deamon. It has verbose modes, just the more “-v”'s you place in the comment line, the more you get (till six times).

source can be downloaded at the following link: leachy.homeip.net/velbus/velserv.c
compiles with: gcc -o velserv velserv.c -lpthread

Usage: velserv -csfvhV] -d DEVICE] -a ADDRESS] -p PORT]
-s --server act as server only, gateway will be disabled
when in server mode, the address is always 127.0.0.1
-c --client act as client only, server wil be disabled
-d --device INTERFACE device where the Velbus interface is connected to
default device is: /dev/ttyACM0
-a --address HOST IP address or hostname where to connect to as client
default is 127.0.0.1
-p --port PORT port where to connect
default is 3788
-f --foreground do not run in background
-v --verbose verbose operation, repeat for debugging output
1 general debug, 2-3 com to socket debug, 4-6 server socket debug
-h --help print this help and exit
-V --version print version information and exit