New binding Resol VBUS

akashkumar · September 19, 2020, 8:55pm

Dear all,

I am trying to install this binding to get my Resol VBUS/USB Adapter running with Openhabian 2.5.5.1 on Raspi 4. However, I am having difficulty getting it running.

Is the USB adapter supported at all or only the LAN version?
I tried following the instructions at https://github.com/ramack/openhab2-addons/blob/master/addons/binding/org.openhab.binding.resol/doc/GETTING_STARTED.md. When using the IoT marketplace, I could install the Resol binding, but the thing discovery did not work. Does the discovery only work for LAN adapters? If yes, how can I configure/add the USB adapter. It said on the forum (https://github.com/ramack/openhab2-addons/tree/Resol_working/bundles/org.openhab.binding.resol), that no configuration file is required for this binding.
I tried adding the binding through the JAR file (https://github.com/ramack/openhab2-addons/tree/BETA-1/addons/binding/org.openhab.binding.resol/target) after removing the IoT binding, but that did not install the binding. Is this the most recent file? I couldn’t find the link on Github to a more updated JAR file.
Which is the best way to install the binding - using JAR file or IoT Marketplace?

Any help on this would be greatly appreciated!! Thanks a lot.

Kind regards,
Akash

ramack · September 20, 2020, 11:58am

I am sorry to say, but the USB-VBUS bridge is not supported and as the binding is using the resol-vbus-java library it seems virtually impossible to add support for USB devices in the binding but it should be put into the library.

@danielwippermann is there any chance for that in future? Or can you tell us something about the USB devices? - Would it be possible with some linux tricks to map the USB data stream to a socket simulating the VBUS-LAN network interface?

akashkumar · September 20, 2020, 1:44pm

Thanks a lot for the quick reply. But here it says that the USB adapter is also supported. It is for Openhab1 though, so not sure whether it would work now.

On a related note about linux tricks, I did find this webpage: https://github.com/tripplet/vbus-collector, where it says the data can be read from USB adapter. I am yet to fully try it out, but I did compile it and it is able to find the adapter at least. Will be able to test this week whether it also reads the data appropriately or not.

ramack · September 20, 2020, 2:23pm

Mh, the note you found is from a old vbus binding that was there in OH 1, the current OH2 binding is not related to it an written from scratch using the resol-vbus-java library. The main difference is, that the old one parsed the vbus packages completely on its own, while the new one uses the existing library, which enables “all” resol devices in a shot, while in the old style each package type required some development effort.

vbus-collectos is yet another tool to read vbus data. It might be possible to use but it will not fit to the approach I proposed by doing a usb-network bridge. You’d probably need to access the vbus data with MQTT or JSON (didn’t step into details about the tool).

akashkumar · September 20, 2020, 2:31pm

Thanks again. In that case, I will wait for @danielwippermann reply on whether it is feasible to create a network socket to stream USB data.

danielwippermann · September 26, 2020, 6:03am

Hi @ramack and @akashkumar!

The VBus/USB adapter and the built-in USB ports of some controllers just present themselves as serial ports to the operating system. We have successfully used Java libraries like https://github.com/Fazecast/jSerialComm to connect to those serial ports and receive VBus data that way.

But I decided against including serial port support into the library because then jSerialComm would be a required dependecy, adding quite some additional footprint for a use case that is not required for many people.

There are tools like “ser2net” that can give you access to serial ports over TCP but they don’t work with the “resol-vbus-java” library out of the box because the TCP connector in the library expects a textual handshake phase before getting access to the VBus data. And “ser2net” does not emulate that handshake, sending VBus data directly instead.

I have implemented such a serial-to-TCP converter in the past, but it is not part of any of my open-source projects. If you don’t mind running a separate application to give you that converter functionality I’ll search for that code, clean it up and publish it.

danielwippermann · September 26, 2020, 2:34pm

I found the code and published it here: https://github.com/danielwippermann/resol-vbus/tree/master/examples/serial-to-tcp

akashkumar · September 26, 2020, 2:51pm

That’s amazing!! Thanks so much. I will try it out and let you know.

I briefly read the Readme file. Does it mean, that once the service is running and accepting connections on the port mentioned there, I would be able to use the normal network binding to search for the LAN-based adapter? Or should I specify the local IP address and the port number in the config.js file somewhere?

danielwippermann · September 26, 2020, 3:00pm

The current implementation does not support being searched for. You would need to manually specify the IP. But if the service runs on the same PI your OpenHAB runs on, specifying “localhost” or “127.0.0.1” should be sufficient.

But implementing network discovery into the service sound like a great addition. I’ll see what I can come up with

akashkumar · September 26, 2020, 3:03pm

Thanks!
I meant the Resol binding which automatically searches for VBUS lan adapters? But if not, I can probably always describe a thing using a text file with an example somewhere.

danielwippermann · September 26, 2020, 4:06pm

I have updated the example to include the network discovery service used to find RESOL LAN-enabled devices. So if the bindings support scanning for such devices, the serial-to-tcp service will announce itself. But since I don’t know how the binding finds its devices this is a question that @ramack might be able to answer.

ramack · September 26, 2020, 5:31pm

Oh Daniel you are great! That sounds like a very cool extension! The resol binding uses the vbus-java library to search for bridge devices, so if the serial-to-tcp converter is detected it should automagically work. But is should be possible to add the bridge device in the binding also manually.

After the bridge is there, all devices on the vbus should be detected automatically as soon as they transmit data and then popup in the inbox. But for sure manual configuration is also possible.

ramack · September 26, 2020, 5:36pm

that is very reasonable and fitting well. What I could imagine as the cleanest solution would be to connect to the serial port with the libraries already included in openhab, so if you see a simple change in the vbus-java library in future to allow passing an already opened datastream for the vbus data that could go relatively easy.

But maybe I should not have written this, as I now have to fear you’ll do it in a few hours and I am expected to include the usage of it in the binding. - I really have to make the binding includable in the upstream OH repository before I add such things.

danielwippermann · September 26, 2020, 6:45pm

Haha, hold my beer…

ramack · September 26, 2020, 7:14pm

I’d love to! Tell me when you are anywhere near Stuttgart some time, then we can meet and have one together

danielwippermann · September 27, 2020, 6:21am

Thanks, I’ll keep that in mind But I assume you know, that “hold my beer” is normally just a joking expression

I have released version 0.5.0 of the VBus library to the Maven repo. If you ever feel the need to incorporate support for serial ports you find a new “StreamConnection” class in there. The example under “vbus-example/src/main/java/de/resol/vbus/example/serialport/Main.java” in the GitHub repo (I’m not allowed to paste a link here, grrrr) shows how to hook up that new class to a serial port to read out the controller’s changeset ID (= internal firmware version identifier).

akashkumar · September 29, 2020, 7:19pm

So guys, I finally managed to try it out today. The library installed like a charm and the service started running as well. However, the binding keeps hopping between ‘Online’ and ‘OFFLINE (COMMUNICATION_ERROR): TCP Connection problem’. First of all, some questions about the configuration:

Which serial number and the password should I set in the resol binding thing? I tried vbus for password as of now, according to the README. However, there is no password set from the serial-to-tcp main.js as far as I could see.
Which port number does serial-to-tcp really listen to? In the main.js file, there are two ports mentioned, 3000 and 7053. In the config.js, there is again a port 7053. However, when I try openhab:7053, it returns an error, but openhab:3000 does show the Tcp simulator parameters broadcast. This implies the service is listening for connections on port 3000?

Btw, I tried the library mentioned here: https://github.com/tripplet/vbus-collector. This did work, and gives the sensor readings.

Thanks a lot in advance as always!

danielwippermann · September 30, 2020, 6:58pm

The serial-to-tcp tool just accepts any password currently, so “vbus” should be fine.

The serial-to-tcp tool binds to three ports:

UDP port 7053 is used for the device discovery broadcast.

TCP port 3000 is used by a minimal web server that is queried during the device discovery phase to get information about the device itself. The minimal web server just replies with dummy information.

TCP port 7053 is used for VBus-over-TCP ( http://danielwippermann.github.io/resol-vbus/vbus-over-tcp.html) . Once the device is discovered, a connection to this port is opened, which uses a textual handshake protocol first before switching into VBus data forwarding mode. This connection is used to transfer live data from the controller into the binding.

I have updated the serial-to-tcp tool to contains additional debug output when a connection is rejected. Could you please pull the new version and try whether you see additional console output while you encounter the TCP connection problems?

Thanks in advance!
Daniel

akashkumar · October 1, 2020, 8:06pm

Thanks a lot for the nice explanation. I was thinking along the same lines but didn’t realise the UDP and TCP connection on the same 7053 port.

I pulled the file and ran it again. Here is the log file.

Opening serial port...
Opening TCP endpoint...
[ 'VBus 0: /dev/ttyACM0' ]
Starting discovery web service...
Starting discovery broadcast service...
Waiting for connections...
Rejecting connection for unknown channel NaN...
Rejecting connection for unknown channel NaN...
Rejecting connection for unknown channel NaN...

… Continues until stopped.

It seems something is wrong in the configuration. Below is my configuration file:

module.exports = {
    // A list of serial ports to connect to
    serialPorts: [{
        channel: 0,
        path: '/dev/ttyACM0',
        baudrate: 9600,
    }],

    // The TCP port on which the service is listening for incoming connections
    port: 7053,
};

Since I only have one channel, I should start numbering from 0, as I understand, right?

Thanks!

danielwippermann · October 2, 2020, 3:48am

Thanks for the debug output, that was insightful

... channel NaN... is an obvious bug. I have updated the example once more to fix this. Please pull the source again and give it a try.

Your configuration looks fine, the channel number should be good.