MDAR
commented
3 years ago Can you please confirm than you are using binding Version - 2.5.4.202003281629 (or later) and at least openHAB2.5.x
"The VMBELO modules are configured by OpenHAB as 33"
The temperature sensor of Oled Panels is channel 33 in openHAB2 and Channel 9 for all modules that are NOT Oleds.
As shown here in PaperUI
The expected number of addresses for a complete VMBELO is infact 5: 1 for the module itself and the first 8 channels, 3 addresses for the next 24 channels and 1 address for the temperature controller.
This is correct and has been the case since the very first OLED panel. VMBGPO
When configuring the Thing in openHAB2, it only requires the correct Module Type and Base address, it will then populate the Thing according to the type profile (@cedricboon please correct me if I am wrong)
All Sub-Addresses that a module type requries are polled from the device, so unless you have changed them since adding the module to openHAB2, you should have the functionality of an entire glass panel, regardless of type.
The binding also queries the modules for channel names, which can help with identifying the channels you want to work with.
(the only condition is that while you can "not use" some of the sub addresses, you can not miss an allocation.
For example, Push buttons 1 to 24 can be used and you can miss push button 25-32, then use the thermostat, you can not use button1 to 16, miss 17-24, then use 25 to 32. They will function perfectly within Velbus, but openHAB2 will see them as buttons 1 to 25.)
Allow the user to enter different addresses for the different channel ranges
If you wish to do this, manually add a VMB8PBU and asign it the address you wish to reference,. This is not correct, but it does work.
As I'm working solely with the .items and .things files
This is not an ideal way to configure anything in openHAB2 any more.
Simply because there is too much room for error in the configuration of any Things. (Not just Velbus)
I would strongly advise you to allow PaperUI to create the Things from the Inbox (especially Velbus Things), then use Text based Items files, based on the Channels that the respective bindings create within each Thing.
For reference, I can confirm that the binding is working extremely well, and what you have reported is not anything I have seen during any of the testing.
I'm happy to share an example Items file that I have created that has every type of Item the whole Velbus range uses, along with Alexa and Google Metadata. This includes the 32 LED feedback channels of any OLED panel, should you wish to use them.
It can be found here --
and a ready made Velbus Bridge thing can be found here -- velbusbridge1.things
@cedricboon Please feel free to add these to your repository, or let me know how to so I can update it in the future.
fredericdepuydt
Expected Behavior
The VMBELO modules are configured by OpenHAB as 33 channel input modules, with only one address to access the module on the bus. The expected number of addresses for a complete VMBELO is infact 5: 1 for the module itself and the first 8 channels, 3 addresses for the next 24 channels and 1 address for the temperature controller.
Current Behavior
Only one address can be configured in OpenHAB, hence only the functionality of the first 8 channels works.
Possible Solution
Allow the user to enter different addresses for the different channel ranges
Environment
As I'm working solely with the .items and .things files a had to resort to the source code to determine the parameters which were required for the network bridge, oled panels, etc... I'm running the latest version of VelbusLink (10.2.4) and the latest firmware for the VMBELO modules (2012)
Note
I've added two images, one showing the configuration, and one showing the response given by the VMBELO module (Module type + Module subtype) on a scan request. As I'm not using the scan function but instead use the .things file, I'm unaware if you actually process the subtype packet to collect the additional addresses during the scan.