Feature - Support for VMB1TS module

[MDAR]

Hi

How are you getting on with this?

Myself and bouwkarolinemaarten have tried adding a VB1TS using your development version and we are both seeing this error - UNINITIALIZED - HANDLER_INITIALIZING_ERROR

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

I've got OH2 V2.4 and I think bouwkarolinemaarten is running V2.5

[bouwkarolinemaarten]

[bouwkarolinemaarten]

Dear Cedric, Not sure if it helps, but I noticed in openhab log some events from the VMB1TS module. (ref picture above). Happy to assist with debugging if this can help you. Note, currently running OH2 V2.4 with the development velbus binding “2.5.0.201908142035” Special thanks for all the great development so far !

[MDAR]

Hi

I've upgraded to OH2.5 and I'm still seeing UNINITIALIZED - HANDLER_INITIALIZING_ERROR when adding a VMB1TS.

I've rolled back to the last 4 development versions of your binding, but still the same each time.

I was sure that I'd seen the VMB1TS working in a previous version, maybe I imagined it??

Does this series of log entries help ?

2020-01-06 21:09:51.810 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to 'en_GB'.
2020-01-06 21:10:01.497 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.178.27:8080
2020-01-06 21:10:01.505 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.178.27:8443
2020-01-06 21:10:03.475 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2020-01-06 21:10:03.514 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2020-01-06 21:11:15.931 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.velbus.internal.handler.VelbusVMB1TSHandler@fe4436': null
java.lang.NullPointerException: null
    at org.openhab.binding.velbus.internal.handler.VelbusSensorWithAlarmClockHandler.initialize(VelbusSensorWithAlarmClockHandler.java:115) ~[?:?]
    at org.openhab.binding.velbus.internal.handler.VelbusTemperatureSensorHandler.initialize(VelbusTemperatureSensorHandler.java:52) ~[?:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
    at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
    at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
    at java.lang.Thread.run(Thread.java:748) [?:?]
2020-01-06 21:11:15.968 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'velbus:vmb1ts:06ee97c1:01': null
java.lang.NullPointerException: null
    at org.openhab.binding.velbus.internal.handler.VelbusSensorWithAlarmClockHandler.initialize(VelbusSensorWithAlarmClockHandler.java:115) ~[?:?]
    at org.openhab.binding.velbus.internal.handler.VelbusTemperatureSensorHandler.initialize(VelbusTemperatureSensorHandler.java:52) ~[?:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
    at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
    at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
    at java.lang.Thread.run(Thread.java:748) [?:?]
g.velbus.internal.handler.VelbusTemperatureSensorHandler.initialize(VelbusTemperatureSensorHandler.java:52) ~[?:?]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]

[cedricboon]

Hi, yes, that helps, I'll try to get you a new build tomorrow.

[MDAR]

Wow!!!

Thanks.

I don't need it, but it looks like a few others would be very grateful.

Feel free to connect to port 6006 if you want to try anything.

Best wishes,

Stuart

[cedricboon]

Hi,

Can you try the following version? https://we.tl/t-ZQZrPYaY48

It should solve the " UNINITIALIZED - HANDLER_INITIALIZING_ERROR" on the vmb1ts and add the temperature channel.

Regards, Cédric

[MDAR]

Hi Cédric

You've worked your magic yet again :smile:

The (only) VMB1TS I have appears to be working perfectly :smile:

I'll make a noise about your fabulous work and wait for the inevitable questions.... :wink:

Thanks,

Stuart

[bouwkarolinemaarten]

Dear team, Thank you very much for this fix/integration of the 1TS modules ! Highly appreciated.

Best wishes for 2020 and keep up the good work.

Kind Regards, Maarten

[MDAR]

Hi, yes, that helps, I'll try to get you a new build tomorrow.

Hi

This was posted on the Velbus forum

Join 2h Hi, My vmb1ts thermostats are working in openhab, but since the update it looks I a have problems with the connection with velbuslink and openahab at the same time, I’m loosing modules or it takes very long time to detect them in velbuslink and in openhab. Is somebody have the same?

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

I'll explore this more on Monday.

I've got a fresh ODroid C2 setup that will eliminate any other issues.

[JohanSpijker]

Another problem I have: my dsl rules are not working anymore when I start velserv. (The button "pressed" is not detected any more).

when
Channel 'velbus:vmb8pb:f06bdf10:22:input#CH5' triggered LONG_PRESSED then { sendCommand('velbus_vmb4ryno_f06bdf10_51_CH1','ON') sendCommand('velbus_vmb4ryno_f06bdf10_52_CH1','ON') sendCommand('SonosConnectZone1_MediaControl','PLAY') } end

When I stop Velserv, they start working.

Greetings, Join (aka join)

[MDAR]

Hi

my dsl rules are not working anymore when I start velserv.

Do you mean "all" your rules, or just those connected with Velbus?

And if your Velbus rules work when VelServ isn't running, that assumes you're using a Velbus Serial Bridge.

So the obvious conclusion is..

VelServ is taking exclusive control of the Velbus USB interface, just as it should.

Which is being odd, considering that the port should have been exclusively held by the Velbus Serial Bridge in openHAB2.

So..

Can you explain in detail what steps you're taking ?

(Ideally in a different thread, as this is for the VMB1TS)

Cheers,

Stuart

[MDAR]

Hi Cedric

I've put the VMB1TS version of your binding onto a new machine this morning and performed a scan.

Binding Version No - 2.5.1.202001072138

These are the only results

velbus:vmb1ts (Address 01)
VMB1TS

01

visibility_off
delete
velbus:vmbel2 (Address E0)
VMBEL2

E0

visibility_off
delete
velbus:vmbelo (Address E2)
VMBELO

E2

visibility_off
delete
velbus:vmbgp2 (Address 1F)
VMBGP2

1F

There are a couple of Relays missing, as well as the VMB4AN, a VMBDMI-R, some VMB4DC

I'll try the next version and let you know.

As a side note, I stopped and restarted VelServ and this version of the binding didn't re-connect.

I have to disable the Network Bridge and re-enable it.

[MDAR]

Again..

Something is different.

Binding version 2.5.1.202001110742 found everything straight away :-)

Within seconds :smile:

I'll put it into the zip on my website :smile:

velbus:vmb1ts (Address 01)
VMB1TS

01

visibility_off
delete
velbus:vmb2ble (Address 61)
VMB2BLE

61

visibility_off
delete
velbus:vmb4an (Address F1)
VMB4AN

F1

visibility_off
delete
velbus:vmb4ryno (Address 72)
VMB4RYNO

72

visibility_off
delete
velbus:vmb4ryno (Address 74)
VMB4RYNO

74

visibility_off
delete
velbus:vmb8pbu (Address A0)
VMB8PBU

A0

visibility_off
delete
velbus:vmbdmir (Address D1)
VMBDMI-R

D1

visibility_off
delete
velbus:vmbel2 (Address E0)
VMBEL2

E0

visibility_off
delete
velbus:vmbelo (Address E2)
VMBELO

E2

visibility_off
delete
velbus:vmbgp2 (Address 1F)
VMBGP2

1F

visibility_off
delete
velbus:vmbgp4 (Address 34)
VMBGP4

34

N.B.

When I went back to the SSH Terminal, this error was showing in the Karaf Console window

I had disabled and re-enabled the Velbus Network bridge, so that it used the new version of the binding (after using bundle:restart)

Exception in thread "Thread-72" java.lang.ArrayIndexOutOfBoundsException: 41                                                       
    at org.openhab.binding.velbus.internal.VelbusModule.setChannelName(VelbusModule.java:121)
    at org.openhab.binding.velbus.internal.discovery.VelbusThingDiscoveryService.handleChannelNameCommand(VelbusThingDiscoveryService.java:331)
    at org.openhab.binding.velbus.internal.discovery.VelbusThingDiscoveryService.onPacketReceived(VelbusThingDiscoveryService.java:88)
    at org.openhab.binding.velbus.internal.handler.VelbusBridgeHandler.readPacket(VelbusBridgeHandler.java:172)
    at org.openhab.binding.velbus.internal.handler.VelbusBridgeHandler.readPackets(VelbusBridgeHandler.java:183)
    at org.openhab.binding.velbus.internal.handler.VelbusNetworkBridgeHandler.lambda$0(VelbusNetworkBridgeHandler.java:52)
    at java.lang.Thread.run(Thread.java:748)

[JohanSpijker]

Hi mdar, Can you let me know when you uploaded this working version 2.5.1.20200111074, or is there still a bug ?

[MDAR]

Hi mdar, Can you let me know when you uploaded this working version 2.5.1.20200111074, or is there still a bug ?

Hi Johan

As long as you are happy that this version is fresh from Cedric's wizzard workshop and may need more reviewing - testing...

He has uploaded it to WeTranfer - https://we.tl/t-d6hhpfvHyx

This link should still be vaild.

I'm heading up to my office now, when I get there I'll put this new jar file into the dev.zip on my website

Cheers

Stuart :smile:

[JohanSpijker]

Hi mdar, Thank you very much for your help ! You know I’m really new in openhab / programming etc. I use always your manual and the PI download directly from you site, but can you tell me how I can put cedrics binding on my PI ? Johan

[MDAR]

Give me a few minutes and I'll upload the zip file to make life easy.

Just double check that the Karaf console hasn't got more than one loaded

[MDAR]

There you are Johan

That should be uploaded now

just use the same script to pull it down and put it in the correct place.

wget http://www.mdar.co.uk/dl/openhab/update-velbus-jar-dev.sh
sh update-velbus-jar-dev.sh

But do remember to check the Karaf console.

and maybe restart the Velbus Network Bridge in paperUI / configuration / Things (Click on the clock icon... why a clock???? who knows)

as per these instructions -

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

[JohanSpijker]

Mdar, I still have problems, sometimes 4, sometimes 10 items our found. When I restart the binding, another 5 are found. but it is not stable. I have 30 modules, did you test it with more then 10 modules? Velbuslink works via velserv. Is there a way I can test with a previous version of the binding. When I go back to 2.5 I don't have the network bridge option.

[MDAR]

Curious.

When I'm back in the office tomorrow, I'll use this version and connect to my home, there are certainly more modules there.

As for previous versions, you can try the current one by using the normal script

wget http://www.mdar.co.uk/dl/openhab/update-velbus-jar.sh

[cedricboon]

I'll take a look at the "Exception in thread "Thread-72" java.lang.ArrayIndexOutOfBoundsException: 41" message, maybe it's causing the discovery to stop.

[MDAR]

What happens if you keep the PaperUI inbox open, and perform a Scan in VelbusLink

Do more modules show up?

[MDAR]

I'll take a look at the "Exception in thread "Thread-72" java.lang.ArrayIndexOutOfBoundsException: 41" message, maybe it's causing the discovery to stop.

I'm glad that makes sense to you, it just looks like a collection of random words to me

Feel free to remotely connect to my home / model if you want to

[JohanSpijker]

Do more modules show up?

No, only 2 modules are found :( No more then 2, even when I let velbuslink scan.

Another thing: now a item is named something like this: velbus:vmb4dc:c8960b0f:30:CH1 before the update it was more logical like this: VelbusVmb4rynoAddress51_Bad

[cedricboon]

Can you give this version a try? https://we.tl/t-HjfXGAkoIf

I think there is still something wrong with the discovery of channel names, but it should at least rediscover all modules again.

[JohanSpijker]

Its better, but not ok, the binding detected the first scan 14 modules, but after 4 scan it found only 24 from the 30 modules. this is the correct version ?

[MDAR]

My results were brilliant.

Only one scan for each network and everything was discovered.

I did have an artifact of the previous version still in the Karaf console that needed removing first.

Just for reference,

I'm testing this on an ODroid C2, running DietPi.

With nothing added from the fresh image other than OpenJDK1.8, NodeRed, VelServ 1.6, Samba & openHAB2.5.1-0

[MDAR]

Its better, but not ok, the binding detected the first scan 14 modules, but after 4 scan it found only 24 from the 30 modules. this is the correct version ?

That's Cédric's most recent version (IE tonight)

[MDAR]

Just a thought.

In OpenRemote, we had to really slow down the scan to capture all modules (there is a big problem with OpenRemote 2.x)

In the end, a (long) delay was added between address queries.

I'm still not sure if the problem was with the SBC hardware, Java1.8 or OpenRemote 2.x

(I haven't touched it for nearly 18 months)

[JohanSpijker]

But with the serial (usb) connection we have no problems, and I think with the version from 3 weeks ago (before the vmb1Ts was added) it was also ok. Can you send me this version again, so I can test again.

[MDAR]

Hi

Just to confirm.

2 x Velbus Network bridges installed on an Odroid C2, DietPi, with OH2.5.1-2 (fresh setup on Jan 12th 2020)

1 x Velserv locally - 127.0.0.1:6000 1 x Velserv across the LAN (on a Odoird XU4, with OH2.5.1-2, fully populated and operational)

VelbsuLink confirms 54 Modules online, on two networks (11 on demo rig & 43 on Home network)

2 modules from Demo rig previously added to OH2

In less than 50 seconds, remaining 52 modules found

Paper UI Inbox 2 Network scan less than 1 minute.pdf

@JohanSpijker Can you confirm your exact hardware setup please?

[JohanSpijker]

This evening I'm gonna setup a fresh system on a PI. The modules I have: I use the openhab image for raspeberry pi that can be found on openhab.org

1 x Velserv locally - 127.0.0.1:6000

[MDAR]

Excellent.

Good luck.

( I didn't know that there is a SnapShot of V3, I might have to give that a try.....)

[JohanSpijker]

Update: On my "new test" system and on my "production" system I can find all modules, when I scan (disable/enable velbus bridge thing) a few times. BUT my rules are not working because an incoming button press is not detected :( (nothing in the log) I use this rule: rule "verhoog volume Sonos Badkamer"

when
Channel 'velbus:vmb8pbu:f06bdf10:28:input#CH2' triggered PRESSED then var Number v_adjustvolume = SonosConnectZone1_Volume.state as DecimalType { v_adjustvolume = v_adjustvolume + 1 sendCommand(SonosConnectZone1_Volume, v_adjustvolume) } end

with the serial bridge i have no problems, but I can't use nodered then.

[MDAR]

because an incoming button press is not detected :( (nothing in the log)

Hi

I saw this error recently too.

I suspect it is because something hasn't completed in openHAB yet.

Just disable the module in question / or all of them.

Then en-enable.

That did the trick for me.

As per my comment here -

https://github.com/cedricboon/openhab2-addons/issues/17

As you've got a Sonos volume rule there and you're talking about NodeRed, you might be interested in this Flow I created for a client.

https://community.openhab.org/t/node-red-as-alternative-rule-engine/29509/216

[JohanSpijker]

Just disable the module in question / or all of them. Then en-enable.

Ok this helped for me also, thank you for the tip. At the moment I have all my modules working + vlserv + dsl-rules+ nodered on the same PI.

Is there a reason, that when you search for your modules, the names of the founded items are never the same ? for example: in velbus_vmb4ryno_7459a6fc_51_CH3 7459a6fc is changed to a random "ID"

[MDAR]

Is there a reason, that when you search for your modules, the names of the founded items are never the same ? for example: in velbus_vmb4ryno_7459a6fc_51_CH3 7459a6fc is changed to a random "ID"

Do you mean that the Velbus Network Bridge ID is 'new' on this New installation of openHAB2?

(I assume you're comparing this new installation to your previous one)

[JohanSpijker]

So when you delete a velbus module (and bridge) and you do a fresh scan the "ID" of the "new" ITEM is changed. (I know normally you do not do this but this was for testing different versions of the binding.) Then you have to edit all the rules, the "habpanel items" has to be changed, etc....

[MDAR]

So when you delete a velbus module (and bridge) and you do a fresh scan the "ID" of the "new" ITEM is changed.

Hi

This is quickly turning into an openHAB2 support session :wink:

It's my understanding that what you're seeing is this..

velbus_vmb4ryno_7459a6fc_51_CH3

Where...

Velbus is the binding

vmb4ryno is the Thing type

7459a6fc is the Unique ID for the Bridge to the Thing

51 is the base address of the Thing

CH3 is the attribute of the Thing

So it you wanted an identical ID, you can / should dictate the ID number when your create(d) the Velbus Bridge.

From then on, scanning and adding Things would have given the new(ly added) Things the same details as your previous setup.

As for how you name your Items and use those in HabPanel, that's a totally independent issue. Meaning your Item names are (or at least can be) completely independent of the Thing name. (Assuming you're NOT using "Simple Linking", which I discovered very quickly isn't such a great idea, especially when it comes to editing the Items later)

The only errata to that is obviously Channel Triggers in rules / NodeRed, where you look directly at the Thing, not the Items.

Does that help?