What I need is the ZWave binding version of this. Have you ever succeeded configuring this @chris? If so, could you, please, provide your bridge definition example?
No - I’ve never used or tested this. I also don’t use text files for configuration so can’t comment on this in general.
To me though, I suspect that rfxcom is not using the standard serial system here as they are specifying a host and port where if they were using the standard serial translation it would specify a serial port wouldn’t it?
Yes, but I was put off by the comment that “it still doesn’t work” followed by your comments that this functionality was removed from the binding—unless I got that wrong.
I think my statement that it was removed was wrong - I think it was relted to the serial discovery. Remember, this thread is nearly 3 years old now so there’s a lot of different stuff in here
The binding knows absolutely nothing about RFC2217.
As I said, all the magic happens in the serial abstraction layer - the binding is just passing the port etc through. As I understand it, that should be all that’s need - the idea of this is that bindings do not need to be modified in order to support different serial abstractions as the general serial abstraction does this.
I did some experimenting with socat and creating the port in different directories. The summary of that is that except for /dev locations I always get “Port does not exist” message unless I add a Java runtime option “-Dgnu.io.rxtx.SerialPorts=/somewhere/else/ttyUSB0” at which point the binding starts working. I cannot specify the URI-like location (rfc2217://xxxx) as that option, it seems. I wonder if that is the reason it gets rejected by the binding outright.
@chris, is there anyway that you could force gnu.io.rxtx to recognise the URI as a serial port? I know very little Java, I am afraid.
Sorry - as I think I said earlier I don’t know anything about the way RFC2217 is handled. rxtx is just the serial driver - probably there is another configuration for RFC2217.
I’d I’d suggest to do a search in the ESH repository for RFC2217 and have a read of the issues there.
For example -:
I raised that earlier though, and you said you’d read those mails so maybe you’ve already seen this. I’m sorry I can’t really help here as it’s not part of the binding and I don’t know anything about it.
Thanks, @chris, but it did not shed any new light. I am giving up on the OH2 upgrade for the week, glad that OH 1.8 is still so stable. I will have another look next weekend, hopefully someone else has more insight in the meantime, especially as also fighting the issue with ZWave serial dev lockfiles causing Java abort traps…
Hi Rafal i also tried with no luck. Gave up on it. 2.4 has been rock solid using MQTT to bridge to instances, no more Zwave issues and it just works so so well. 80 days rock solid.
I stand corrected by @chris that the functionality is present in the current ZWave binding, albeit no one has reported it as working, while there are 3 of us, @dastrix80, @vossivossi (who got a bit further that I and could see something in the logs) and I, at least, reporting it as not functioning.
We can see in the code that the ESH serial port abstraction classes are used, and not the NRJavaSerial, or any other library (directly).
So in theory, the ZWave binding should be able to use any serial abstraction that is implemented in the ESH (now OH) serial abstraction layer. I understood from the original PRs on ESH that this included RFC2217, but I have never personally tested this.
Thank you, again, @chris, for taking the time to patiently explain how things are. Would I be right in thinking, then, that when I specify “rfc2217://ip:port” as a port in your ZWave binding this is not handled using nrjavaserial. However, when I specify “/dev/something” it does get passed to nrjavaserial? I wonder what generates the “Port does not exist” error message string that I am seeing.
That would be my expectation. I would expect that the ESH abstraction does some sort of check on the “domain” of the port and decides where to handle this. However, again, I’ve never looked at this code so I can’t confirm this.
@chris, could you point me at the code file/folder that deals with this, and I will see if I can figure out anything? I am not familiar with the OH codebase, I am afraid, so any pointers will jump start me. Or is it just “org.eclipse.smarthome.io.transport.serial”?
Yes- if you look in the OH2.5 branch in the core then this should be the folder I think. As I’ve said, I’ve never personally looked at or for this code, so I’m not really able to help with any level of knowledge. Unfortunately I don’t really have the time to spend trying to work this out right at the moment.
I have tried recompiling openhab-core with the new nrjavaserial-5.0.0. I can see that rfc2217 URI in the ZWave binding port config is now behaving differently. It still does not work but it gives a different error. See this Github issue for more detail, please feel free to make any suggestions that could help move it forward.
@chris, in case you are not following the two threads on the nrjavaserial repo, I have a quick update. Indeed, the issue with the lack of RFC2217 support was in nrjavaserial. It was missing the logic that checks for the URI and it was never trying to instantiate rfc2217 serial port, ie. it was always treating it as a “real” port. This logic is now in place in the master branch, hopefully it will be in a release soon.
As for the issues @MrRusch and my system has in opening even regular ports under FreeBSD, this is still an open case. I am running out of time due to low Java skills (maven scares me), but I will try to help if I can.