In windows, I was able to solve this issue by adding an environment variable (JAVA_TOOL_OPTIONS = -Dfile.encoding=ISO-8859-1)
How to do it in OpenHabian?
you would be able to add JAVA options this way but could you please explain your use case and why this is needed?
All the same as here
Tell me please the correct syntax for adding a new option, if I already have a record:
This should do the trick:
You can check if the option is in place like shown in this screenshot.
Thank you… But not work…
ps aux --sort=start_time | grep -v grep | grep AMA0 root 556 0.0 0.1 5480 1968 ? Ss+ 18:49 0:00 /sbin/agetty --keep-baud 115200 38400 9600 ttyAMA0 vt102 openhab 879 54.3 14.9 439060 148920 ? Sl 18:50 2:44 /usr/bin/java -Dopenhab.home=/usr/share/openhab2 -Dopenhab.conf=/etc/openhab2 -Dopenhab.runtime=/usr/share/openhab2/runtime -Dopenhab.userdata=/var/lib/openhab2 -Dopenhab.logdir=/var/log/openhab2 -Dfelix.cm.dir=/var/lib/openhab2/config -Dorg.osgi.service.http.port=8080 -Dorg.osgi.service.http.port.secure=8443 -Djava.awt.headless=true -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0:/dev/ttyAMA0 -Dfile.encoding=ISO-8859-1 -Djava.endorsed.dirs=/usr/lib/jvm/zulu-embedded-8-armhf/jre/lib/endorsed:/usr/lib/jvm/zulu-embedded-8-armhf/lib/endorsed:/usr/share/openhab2/runtime/lib/endorsed -Djava.ext.dirs=/usr/lib/jvm/zulu-embedded-8-armhf/jre/lib/ext:/usr/lib/jvm/zulu-embedded-8-armhf/lib/ext:/usr/share/openhab2/runtime/lib/ext -Dkaraf.instances=/usr/share/openhab2/runtime/instances -Dkaraf.home=/usr/share/openhab2/runtime -Dkaraf.base=/var/lib/openhab2 -Dkaraf.data=/var/lib/openhab2 -Dkaraf.etc=/var/lib/openhab2/etc -Dkaraf.restart.jvm.supported=true -Djava.io.tmpdir=/var/lib/openhab2/tmp -Djava.util.logging.config.file=/var/lib/openhab2/etc/java.util.logging.properties -Dkaraf.startLocalConsole=false -Dkaraf.startRemoteShell=true -classpath /usr/share/openhab2/runtime/lib/boot/org.apache.karaf.diagnostic.boot-4.0.8.jar:/usr/share/openhab2/runtime/lib/boot/org.apache.karaf.jaas.boot-4.0.8.jar:/usr/share/openhab2/runtime/lib/boot/org.apache.karaf.main-4.0.8.jar:/usr/share/openhab2/runtime/lib/boot/org.osgi.core-6.0.0.jar org.apache.karaf.main.Main
But no serial exchange. In the log i can see this only:
2017-03-16 17:28:00.021 [ItemCommandEvent ] - Item 'Pulsar' received command &A▒/▒ 2017-03-16 18:52:11.581 [ItemCommandEvent ] - Item 'Pulsar' received command &A▒/▒ 2017-03-16 18:52:11.582 [ItemCommandEvent ] - Item 'Pulsar' received command &A▒/▒ 2017-03-16 18:52:11.618 [ItemStateChangedEvent ] - Pulsar changed from NULL to &A▒/▒ 2017-03-16 18:53:00.035 [ItemCommandEvent ] - Item 'Pulsar' received command &A▒/▒ 2017-03-16 18:54:00.023 [ItemCommandEvent ] - Item 'Pulsar' received command &A▒/▒ 2017-03-16 18:55:00.024 [ItemCommandEvent ] - Item 'Pulsar' received command &A▒/▒ 2017-03-16 18:56:00.041 [ItemCommandEvent ] - Item 'Pulsar' received command &A▒/▒ 2017-03-16 18:57:00.029 [ItemCommandEvent ] - Item 'Pulsar' received command &A▒/▒ 2017-03-16 18:58:00.029 [ItemCommandEvent ] - Item 'Pulsar' received command &A▒/▒
And no answer… In the windows with same code:
Serial_string changed from &Pлn›t›эBAПt to & AП/Ц
this is serial device reply.
Hey, that’s too bad! I’m not sure how I could further help you. I’ve got no experiences with the serial binding and this looks rather complicated to give a quick solution. Did you check the forum for similar threads? The serial binding is probably also used with linux/raspbian systems, openHABian is nothing special in that sense.
Another option I can think of: If you know of an external serial tool that’s working as expected, you might want to call it from within openHAB with the exec binding. This way you can avoid the serial binding. Might not be the most elegant solution but at it’s a solution…
The problem is solved. It turned out that this is a software-hardware problem. After several days of struggle for the normal operation of the device, I looked into the configuration of the virtual COM port of the usb-rs485 converter. And I found there a small checkbox. It was called RS-485. We need to go deeper…
I turned off this checkbox. And the converter in Windows stopped working correctly. The converter chip is called Exar XR21B1411.
In one Russian forum, I found a solution. This is a program that changes some registers of the converter for its correct operation in Linux.
It runs from the Windows command line:
OTPMongo -c COMn -f XR21B1411.xml
“n” is the COM port number of the converter in the device manager.
Please pay attention, we are talking about the chip Exar XR21B1411. If you have another chip, then it’s better to google it. Everything you do, you do at your own risk.
A few moments … And it works! Both in Windows and Linux!
I ask you to excuse me all the participants of this topic. And I thank the responders.
Great you got it working!!