Skip to content
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

[velbus] Add new functionality PRESSED and LONG PRESSED #10664

Merged
merged 12 commits into from
May 29, 2021
Merged

[velbus] Add new functionality PRESSED and LONG PRESSED #10664

merged 12 commits into from
May 29, 2021

Conversation

Rosen01
Copy link
Contributor

@Rosen01 Rosen01 commented May 9, 2021

New functionnality :
Add the the possibility to simulate the PRESSED and LONG PRESSED message of an input.

Module supported with button simulation :
VMB1RYS (button : CH6)
VMB6IN (buttons : CH1 ... CH6)
VMB2PBN, VMB6PBN, VMB7IN, VMB8IR, VMB8PB, VMB8PBU, VMBEL1, VMBEL2, VMBEL4, VMBGP1, VMBGP1-2, VMBGP2, VMBGP2-2, VMBGP4, VMBGP4-2, VMBGP4PIR, VMBGP4PIR-2 (buttons : CH1 ... CH8)
VMBELO, VMBGPOD, VMBGPOD-2 (buttons : CH1 ... CH32)

Fix bug :
The channels names were not correctly assigned to the thing properties. The last channel had the default name, not the one retrieved from the module.

Signed-off-by: Daniel Rosengarten github@praetorians.be

Rosen01 and others added 3 commits May 9, 2021 22:29
New functionnality :
Add the the possibility to simulate the PRESSED and LONG PRESSED message of an input.

Module supported with button simulation :
VMB1RYS (button : CH6)
VMB6IN (buttons : CH1 ... CH6)
VMB2PBN, VMB6PBN, VMB7IN, VMB8IR, VMB8PB, VMB8PBU, VMBEL1, VMBEL2, VMBEL4, VMBGP1, VMBGP1-2, VMBGP2, VMBGP2-2, VMBGP4, VMBGP4-2, VMBGP4PIR, VMBGP4PIR-2 (buttons : CH1 ... CH8)
VMBELO, VMBGPOD, VMBGPOD-2 (buttons : CH1 ... CH32)

Fix bug :

The channels names were not correctly assigned to the thing properties. The last channel had the default name, not the one retrieved from the module.

Signed-off-by: Daniel Rosengarten <github@praetorians.be>
@fwolter
Copy link
Member

fwolter commented May 19, 2021

@cedricboon Can you take a look?

Copy link
Contributor

@cedricboon cedricboon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Rosen01, thank you for the enhancements!
I've reviewed the code and made a few suggestions.
The most important one is probably of the usage of Thread.sleep in a few places, which I would replace by the use of the scheduler.

bundles/org.openhab.binding.velbus/README.md Outdated Show resolved Hide resolved
bundles/org.openhab.binding.velbus/README.md Outdated Show resolved Hide resolved
bundles/org.openhab.binding.velbus/README.md Outdated Show resolved Hide resolved
try {
packet.Pressed();
velbusBridgeHandler.sendPacket(packet.getBytes());
Thread.sleep(20);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you are allowed to let the thread sleep here.
But you could use the scheduler, like here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I d'idn't check this part of your code, the 20 ms delay is useless then. I've remove this from my code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're absolutely right. I didn't thought of that when reviewing the code :-)

if (stringTypeCommand.equals(LONG_PRESSED)) {
packet.LongPressed();
velbusBridgeHandler.sendPacket(packet.getBytes());
Thread.sleep(20);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you are allowed to let the thread sleep here.
But you could use the scheduler, like here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I d'idn't check this part of your code, the 20 ms delay is useless then. I've remove this from my code.

try {
packet.Pressed();
velbusBridgeHandler.sendPacket(packet.getBytes());
Thread.sleep(20);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you are allowed to let the thread sleep here.
But you could use the scheduler, like here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I d'idn't check this part of your code, the 20 ms delay is useless then. I've remove this from my code.

if (stringTypeCommand.equals(LONG_PRESSED)) {
packet.LongPressed();
velbusBridgeHandler.sendPacket(packet.getBytes());
Thread.sleep(20);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you are allowed to let the thread sleep here.
But you could use the scheduler, like here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I d'idn't check this part of your code, the 20 ms delay is useless then. I've remove this from my code.


packet.Released();
velbusBridgeHandler.sendPacket(packet.getBytes());
} catch (InterruptedException e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This empty catch clause will probably become obsolete if you use the scheduler instead of a Thread.sleep.

Copy link
Contributor Author

@Rosen01 Rosen01 May 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've remove this from my code.


packet.Released();
velbusBridgeHandler.sendPacket(packet.getBytes());
} catch (InterruptedException e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This empty catch clause will probably become obsolete if you use the scheduler instead of a Thread.sleep.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've remove this from my code.

Rosen01 and others added 5 commits May 24, 2021 22:05
Co-authored-by: cedricboon <cedric.boon@hotmail.com>
Signed-off-by: Daniel Rosengarten <github@praetorians.be>
Co-authored-by: cedricboon <cedric.boon@hotmail.com>
Signed-off-by: Daniel Rosengarten <github@praetorians.be>
Co-authored-by: cedricboon <cedric.boon@hotmail.com>
Signed-off-by: Daniel Rosengarten <github@praetorians.be>
Remove uneeded  Thread.sleep in code.
Trigger the events PRESSED, LONG_PRESSED, RELEASED on the linked trigger channel when using the button simulation.

Signed-off-by: Daniel Rosengarten <github@praetorians.be>
Copy link
Contributor

@cedricboon cedricboon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Rosen01 and others added 2 commits May 26, 2021 22:53
Redundant superinterface DiscoveryService for the type VelbusThingDiscoveryService, already defined by AbstractDiscoveryService.

Signed-off-by: Daniel Rosengarten <github@praetorians.be>
Copy link
Member

@kaikreuzer kaikreuzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@kaikreuzer kaikreuzer added the enhancement An enhancement or new feature for an existing add-on label May 29, 2021
@kaikreuzer kaikreuzer changed the title [velbus] Add new functionality PRESSED and LONG PRESSED and fix bug [velbus] Add new functionality PRESSED and LONG PRESSED May 29, 2021
@kaikreuzer kaikreuzer merged commit 4ad6eda into openhab:main May 29, 2021
@kaikreuzer kaikreuzer added this to the 3.1 milestone May 29, 2021
computergeek1507 pushed a commit to computergeek1507/openhab-addons that referenced this pull request Jul 13, 2021
* [velbus] Add new functionality PRESSED and LONG PRESSED and fix bug

New functionality:
Add the the possibility to simulate the PRESSED and LONG PRESSED message of an input.

Module supported with button simulation :
VMB1RYS (button : CH6)
VMB6IN (buttons : CH1 ... CH6)
VMB2PBN, VMB6PBN, VMB7IN, VMB8IR, VMB8PB, VMB8PBU, VMBEL1, VMBEL2, VMBEL4, VMBGP1, VMBGP1-2, VMBGP2, VMBGP2-2, VMBGP4, VMBGP4-2, VMBGP4PIR, VMBGP4PIR-2 (buttons : CH1 ... CH8)
VMBELO, VMBGPOD, VMBGPOD-2 (buttons : CH1 ... CH32)

Fix bug:
The channels names were not correctly assigned to the thing properties. The last channel had the default name, not the one retrieved from the module.

Also-by: cedricboon <cedric.boon@hotmail.com>
Signed-off-by: Daniel Rosengarten <github@praetorians.be>
frederictobiasc pushed a commit to frederictobiasc/openhab-addons that referenced this pull request Oct 26, 2021
* [velbus] Add new functionality PRESSED and LONG PRESSED and fix bug

New functionality:
Add the the possibility to simulate the PRESSED and LONG PRESSED message of an input.

Module supported with button simulation :
VMB1RYS (button : CH6)
VMB6IN (buttons : CH1 ... CH6)
VMB2PBN, VMB6PBN, VMB7IN, VMB8IR, VMB8PB, VMB8PBU, VMBEL1, VMBEL2, VMBEL4, VMBGP1, VMBGP1-2, VMBGP2, VMBGP2-2, VMBGP4, VMBGP4-2, VMBGP4PIR, VMBGP4PIR-2 (buttons : CH1 ... CH8)
VMBELO, VMBGPOD, VMBGPOD-2 (buttons : CH1 ... CH32)

Fix bug:
The channels names were not correctly assigned to the thing properties. The last channel had the default name, not the one retrieved from the module.

Also-by: cedricboon <cedric.boon@hotmail.com>
Signed-off-by: Daniel Rosengarten <github@praetorians.be>
@MDAR
Copy link

MDAR commented Nov 5, 2021

Thanks @Rosen01
That's actually a really great addition that a few people have been asking for.

one "tiny" detail, is there any way you can get the channels to show the live state of the button, or return to null or "released" after a while?

I have been suggesting people do this, but I know that is a hack.

{channel="velbus:vmb7in:VelbusNetworkBridge:0A:button#CH1", expire="1s,state=RELEASED"}

thinkingstone pushed a commit to thinkingstone/openhab-addons that referenced this pull request Nov 7, 2021
* [velbus] Add new functionality PRESSED and LONG PRESSED and fix bug

New functionality:
Add the the possibility to simulate the PRESSED and LONG PRESSED message of an input.

Module supported with button simulation :
VMB1RYS (button : CH6)
VMB6IN (buttons : CH1 ... CH6)
VMB2PBN, VMB6PBN, VMB7IN, VMB8IR, VMB8PB, VMB8PBU, VMBEL1, VMBEL2, VMBEL4, VMBGP1, VMBGP1-2, VMBGP2, VMBGP2-2, VMBGP4, VMBGP4-2, VMBGP4PIR, VMBGP4PIR-2 (buttons : CH1 ... CH8)
VMBELO, VMBGPOD, VMBGPOD-2 (buttons : CH1 ... CH32)

Fix bug:
The channels names were not correctly assigned to the thing properties. The last channel had the default name, not the one retrieved from the module.

Also-by: cedricboon <cedric.boon@hotmail.com>
Signed-off-by: Daniel Rosengarten <github@praetorians.be>
@Rosen01
Copy link
Contributor Author

Rosen01 commented Nov 10, 2021

Thanks @Rosen01 That's actually a really great addition that a few people have been asking for.

one "tiny" detail, is there any way you can get the channels to show the live state of the button, or return to null or "released" after a while?

I have been suggesting people do this, but I know that is a hack.

{channel="velbus:vmb7in:VelbusNetworkBridge:0A:button#CH1", expire="1s,state=RELEASED"}

The messages PRESSED/LONG_PRESSED and RELEASED are sent in less than 1 sec, it won't show up in the interface.
Why not use the "mapping" option like in the .sitemap example ? Which creat a push button.

@bouwkarolinemaarten
Copy link

Hi @Rosen01 and @cedricboon ... Just checking if org.openhab.binding.velbus-3.1.0.2105092215-SNAPSHOT.jar is the latest and greatest available Velbus .jar file for OpenHAB 3.2.0 - Release Build (running in docker).

Unfortunately broke my own rule (never touch a working setup), hence facing below errors when trying to load the file. Next to the fact I like the great new feature of "long pressed" (as I use this trigger to execute rules as "hidden button"), the current official Velbus release in OpenHAB is no longer supporting the channel triggers from vmbmeteo (CH1->CH8)
example trigger rule:
Channel "velbus:vmbmeteo:179718b801:c3b7b9fbb2:input#CH5" triggered PRESSED // Dusk Alarm

This was working perfectly in org.openhab.binding.velbus-2.5.10-20201017.033442-19.jar but I think it skipped the lease/rebuild for openhab 3 unfortunately. (unless maybe included in the .jar releases on github)

I tried to run the 2.5 version unsuccessfully (logically), but also didn't get the release from Rosen01 to work...
Possibly my fault, initially because missing serial binding - normally not needed, but now receiving errors on requirement: Import-Package: javax.measure.

Can you help me please as my knowledge is limited to put the .jar files in addons folder ;-)

Running version:
openhab> bundle:list | grep Velbus
240 │ Active │ 80 │ 3.2.0 │ openHAB Add-ons :: Bundles :: Velbus Binding
openhab> system:version
4.3.4

Log details with custom .jar files:
22:23:54.349 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/openhab/addons/org.openhab.binding.velbus-2.5.10-20201017.033442-19.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.velbus [260]
Unresolved requirement: Import-Package: org.eclipse.smarthome.config.core

    at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.2]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.2]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.7.2]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.2]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.2]

12:23:48.235 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.velbus [261]
Unresolved requirement: Import-Package: org.openhab.core.io.transport.serial

    at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1849) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1842) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1785) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1747) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1669) ~[org.eclipse.osgi-3.16.300.jar:?]

12:23:48.235 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.velbus [261]
Unresolved requirement: Import-Package: org.openhab.core.io.transport.serial

14:37:06.010 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/openhab/addons/org.openhab.binding.velbus-3.1.0.2105092215-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.velbus [261]
Unresolved requirement: Import-Package: javax.measure; version="[1.0.0,2.0.0)"

    at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.16.300.jar:?]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.2]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.2]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.7.2]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.7.2]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.2]
    at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.2]

@MDAR
Copy link

MDAR commented Feb 12, 2022

@bouwkarolinemaarten

Good morning

If it makes you feel any better, I broke that golden rule yesterday too...
Right in front of a client just as we were about to sign off the installation.

I don't know what I've done wrong, but I just can't get Chromium to start on this machine.

Oh well, I'll just re-flash the card and load the backup configuration.

Regarding your issue, I'm no expert in these matters, looking at your log file, it would seem that you haven't installed the serial binding.

12:23:48.235 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.velbus [261]
Unresolved requirement: Import-Package: org.openhab.core.io.transport.serial

@Rosen01
Copy link
Contributor Author

Rosen01 commented Feb 12, 2022

Hi @bouwkarolinemaarten,

You cannot use a package for OpenHAB 2.5 with OpenHAB 3.x.
The Velbus package for OpenHAB 3.1 is not compatible with OpenHAB 3.2 too.

I just look in the code in the repository and the trigger on channels CH1 -> CH8 is still implemented for the VMBMETEO in the official 3.2 release.
I don't have this module on my system, I won't be able to test it.

But I'm a littlebit surprised by the identifier of your module. velbus:vmbmeteo:179718b801:c3b7b9fbb2
Normally, it shoud be somthing like this velbus:vmbmeteo:179718b801:xx where xx is the module address.
Have you tried to remove the module and do a scan to recreate it?

You can check in the OpenHAB event logs if the the channel is triggered :
tail -f /var/log/openhab/events.log (CTRL-C to stop the live view of the log)
If the channel is triggered, the information will be in the log.
I looked in Velbuslink app, and it's not possible to manually operate the channels on this module.
You will need to change the values in the configuration of the module to force the trigger, or manually spin the sensor.
If the information is displayed in the logs, there is probably something wrong with the rule implemented in OpenHAB 3.2.

@bouwkarolinemaarten
Copy link

Hi both,

Thx for the feedback and sorry we are going off-topic on this topic. I will use the official 3.2 release for my purpose.

As per request, I recreated the module. Remark, the "scan" only give back a few modules, hence needed to manually add the module providing the address ... which might explain the naming.
As you see all is recognized fine and wind & temperature values are coming in as ItemStateChangedEvents.
I think the challenge is that the ChannelTriggeredEvent are missing for the vmbmeteo module.
It's fine for the 1TS (temperature sensor), but even after "forcing" channel triggers by playing with frost alarm, nothing was captured in the logs (for CH1)

note: there is a workaround by just trigger alarms in openhab using the wind & temperature readouts ... hence non-blocking for me. If no quick win, just let me know.

---Recreated the module vmbmeteo---
19:43:05.038 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'velbus:vmbmeteo:179718b801:c3b7b9fbb2' changed from ONLINE to REMOVING
19:43:05.052 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'velbus:vmbmeteo:179718b801:c3b7b9fbb2' changed from REMOVING to REMOVED
19:43:05.062 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'velbus:vmbmeteo:179718b801:c3b7b9fbb2' changed from REMOVED to UNINITIALIZED
19:43:05.087 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'velbus:vmbmeteo:179718b801:c3b7b9fbb2' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
19:43:58.400 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'velbus:vmbmeteo:179718b801:d6063d9c89' changed from UNINITIALIZED to INITIALIZING
19:43:58.422 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'velbus:vmbmeteo:179718b801:d6063d9c89' changed from INITIALIZING to ONLINE

---initiating ---
19:46:50.433 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOClockAlarmClockAlarm1Enabled' changed from NULL to OFF
19:46:50.442 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOClockAlarmClockAlarm1Type' changed from NULL to GLOBAL
19:46:50.447 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOClockAlarmClockAlarm2Enabled' changed from NULL to OFF
19:46:50.457 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOClockAlarmClockAlarm2Type' changed from NULL to GLOBAL
19:46:50.479 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOClockAlarmClockAlarm1WakeupHour' changed from NULL to 9
19:46:50.486 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOClockAlarmClockAlarm1WakeupMinute' changed from NULL to 0
19:46:50.494 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOClockAlarmClockAlarm1BedtimeHour' changed from NULL to 22

---ItemStateChangedEvents----
tail -f events.log
2022-02-12 19:47:25.883 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH13' changed from 0 km/h to 3 km/h
2022-02-12 19:48:25.654 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH13' changed from 3 km/h to 0 km/h
2022-02-12 19:49:25.425 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH13' changed from 0 km/h to 8 km/h
2022-02-12 19:50:25.189 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH13' changed from 8 km/h to 0 km/h
2022-02-12 19:51:27.591 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH13' changed from 0 km/h to 1 km/h
2022-02-12 19:52:27.359 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH13' changed from 1 km/h to 0 km/h
2022-02-12 19:54:08.772 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH13' changed from 0 km/h to 1 km/h
2022-02-12 19:55:08.530 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH13' changed from 1 km/h to 0 km/h
2022-02-12 19:58:58.728 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH10' changed from 4.0625 °C to 3.8125 °C
2022-02-12 20:01:42.446 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOWeatherStationCH13' changed from 0 km/h to 1 km/h
2022-02-12 20:02:28.668 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOClockAlarmClockAlarm1Type' changed from GLOBAL to LOCAL
2022-02-12 20:02:28.673 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEOClockAlarmClockAlarm2Type' changed from GLOBAL to LOCAL

--- ChannelTriggeredEvent (for 1TS) ----
2022-02-12 20:00:33.874 [INFO ] [openhab.event.ChannelTriggeredEvent ] - velbus:vmb1ts:179718b801:f2760da854:input#CH3 triggered RELEASED

We aren't at openhab rule level yet, but this is the test rule to capture the channel event
rule "METEO - Frost Alarm "
when
Channel "velbus:vmbmeteo:179718b801:d6063d9c89:weatherStation#CH01" triggered PRESSED
then
logWarn("test", "forst alarm received-hello world")
WS_AlarmFrost_MeteoCH1.sendCommand("ON")
end

@bouwkarolinemaarten
Copy link

hi @Rosen01

--- SOLVED ---
Update: I was intrigued with your remark of the "naming" and the expectation of seeing the module address.
hence "forced" the name of the module to 9A (module address) upon recreating the Thing and all of a sudden/magic ;-) here are the expected triggers ;-)

velbus:vmbmeteo:179718b801:9A:input#CH1 triggered PRESSED
velbus:vmbmeteo:179718b801:9A:input#CH1 triggered RELEASED

Thanks a lot for the golden tip !

Lessons learned: I'm thinking to make my things also text based (.things) instead of creation through UI.
(and will rename all modules to the address, as I might miss other triggers ;-) potentially)

21:22:48.259 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH10OutdoorTemp' changed from 3.3125 °C to 3.0625 °C
21:23:39.962 [INFO ] [openhab.event.ChannelTriggeredEvent ] - velbus:vmbmeteo:179718b801:9A:input#CH1 triggered RELEASED
21:23:42.288 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH10OutdoorTemp' changed from 3.0625 °C to 3 °C
21:23:46.355 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH13Windspeed' changed from 0 km/h to 3 km/h
21:23:47.290 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH10OutdoorTemp' changed from 3 °C to 3.0625 °C
21:23:55.368 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH13Windspeed' changed from 3 km/h to 8 km/h
21:23:59.362 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH13Windspeed' changed from 8 km/h to 3 km/h
21:24:03.370 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH13Windspeed' changed from 3 km/h to 0 km/h
21:24:07.366 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH13Windspeed' changed from 0 km/h to 1 km/h
21:24:09.310 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH10OutdoorTemp' changed from 3.0625 °C to 3.3125 °C
21:24:11.379 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH13Windspeed' changed from 1 km/h to 0 km/h
21:24:14.306 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH10OutdoorTemp' changed from 3.3125 °C to 3.0625 °C
21:24:23.315 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH10OutdoorTemp' changed from 3.0625 °C to 3.3125 °C
21:24:27.314 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH10OutdoorTemp' changed from 3.3125 °C to 3.0625 °C
21:24:47.505 [INFO ] [openhab.event.ChannelTriggeredEvent ] - velbus:vmbmeteo:179718b801:9A:input#CH1 triggered PRESSED
21:24:50.327 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'VMBMETEO_CH10OutdoorTemp' changed from 3.0625 °C to 3.25 °C

marcfischerboschio pushed a commit to bosch-io/openhab-addons that referenced this pull request May 5, 2022
* [velbus] Add new functionality PRESSED and LONG PRESSED and fix bug

New functionality:
Add the the possibility to simulate the PRESSED and LONG PRESSED message of an input.

Module supported with button simulation :
VMB1RYS (button : CH6)
VMB6IN (buttons : CH1 ... CH6)
VMB2PBN, VMB6PBN, VMB7IN, VMB8IR, VMB8PB, VMB8PBU, VMBEL1, VMBEL2, VMBEL4, VMBGP1, VMBGP1-2, VMBGP2, VMBGP2-2, VMBGP4, VMBGP4-2, VMBGP4PIR, VMBGP4PIR-2 (buttons : CH1 ... CH8)
VMBELO, VMBGPOD, VMBGPOD-2 (buttons : CH1 ... CH32)

Fix bug:
The channels names were not correctly assigned to the thing properties. The last channel had the default name, not the one retrieved from the module.

Also-by: cedricboon <cedric.boon@hotmail.com>
Signed-off-by: Daniel Rosengarten <github@praetorians.be>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature for an existing add-on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants