How to implement USB-Serial connector as symbolic tty

peaeater · November 8, 2020, 10:35pm

After upgrading my openhabian and linux to

   Release = Raspbian GNU/Linux 10 (buster)
    Kernel = Linux 4.19.118-v7+
  Platform = Raspberry Pi 3 Model B Rev 1.2
    Uptime = 0 day(s). 1:3:19
 CPU Usage = 8.55% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
  CPU Load = 1m: 1.68, 5m: 1.71, 15m: 1.54
    Memory = Free: 0.03GB (3%), Used: 0.92GB (97%), Total: 0.95GB
      Swap = Free: 0.09GB (98%), Used: 0.00GB (2%), Total: 0.09GB
      Root = Free: 3.12GB (23%), Used: 10.41GB (77%), Total: 14.12GB
   Updates = 0 apt updates available.
  Sessions = 2 session(s)
 Processes = 109 running processes of 32768 maximum processes

                  openHAB 2.5.10-1 (Release Build)

I encountered that my modbus is not running anymore.

After adding an action to my /etc/udev/rules.d/99-usb-serial.rules

ACTION=="add",
ATTRS{idVendor}=="0403",
ATTRS{idProduct}=="6001",
RUN+="/sbin/modprobe ftdi_sio"
RUN+="/bin/sh -c 'echo 0403 6001 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"

SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A505T87R", SYMLINK+="ttyUSB_LG"

I got finaly my missing ttyUSB_LG

[23:25:27] pi@HAB:~$ ls -l /dev/ttyUSB*
lrwxrwxrwx 1 root root 15 Nov  8 22:13 /dev/ttyUSB_LG -> bus/usb/001/005

But I’m still not getting rid of the errors, which I have in the logger

2020-11-08 23:27:03.457 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 1/1 error: Could not get port identifier, maybe insufficient permissions. null. Connection SerialConnection@5ab493[portName=/dev/ttyUSB_LG,port=<null>]. Endpoint ModbusSerialSlaveEndpoint@337842[portName=/dev/ttyUSB_LG]

2020-11-08 23:27:03.461 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - re-connect reached max tries 1, throwing last error: Could not get port identifier, maybe insufficient permissions. null. Connection SerialConnection@5ab493[portName=/dev/ttyUSB_LG,port=<null>]. Endpoint ModbusSerialSlaveEndpoint@337842[portName=/dev/ttyUSB_LG]

2020-11-08 23:27:03.465 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - Error connecting connection SerialConnection@5ab493[portName=/dev/ttyUSB_LG,port=<null>] for endpoint ModbusSerialSlaveEndpoint@337842[portName=/dev/ttyUSB_LG]: Could not get port identifier, maybe insufficient permissions. null

2020-11-08 23:27:03.469 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Could not connect to endpoint ModbusSerialSlaveEndpoint@337842[portName=/dev/ttyUSB_LG] -- aborting request ModbusReadRequestBlueprint@694687[slaveId=3,functionCode=READ_COILS,start=0,length=1,maxTries=3] [operation ID b8149f0a-d927-4f49-8f44-be597b61af2d]

My things file look like

Things file

Bridge modbus:serial:lg3 [port="/dev/ttyUSB_LG", id=3, baud=9600, stopBits="1.0", parity="none", dataBits=8, encoding="rtu"] {
    
    Bridge poller Inputs      [start=2, length=1, refresh=1000, type="input"] {
      Thing data RoomTemp     [readValueType="int16",
                               readStart="2", 
                               readTransform="JS(divide10.js)",
                               updateUnchangedValuesEveryMillis=5000]
    }
    
    Bridge poller Coils       [start=0, length=1, refresh=1000, type="coil"] {
      Thing data Operation    [readValueType="bit",
                               readStart="0", 
                               readTransform="default",
                               writeValueType="",
                               writeStart="0",
                               writeType="coil",
                               writeTransform="default",
                               writeMultipleEvenWithSingleRegisterOrCoil=false,
                               updateUnchangedValuesEveryMillis=5000]
    }
    
    Bridge poller Holding     [start=0, length=2, refresh=1000, type="holding"] {
      Thing data Mode         [readStart="0", 
                               readValueType="int16",
                               readTransform="default",
                               writeStart="0",
                               writeValueType="int16",
                               writeType="holding",
                               writeTransform="default",
                               writeMultipleEvenWithSingleRegisterOrCoil=false,
                               updateUnchangedValuesEveryMillis=5000]
      
      Thing data SetPoint     [readStart="1", 
                               readValueType="int16",
                               readTransform="JS(divide10.js)",
                               writeStart="1",
                               writeValueType="int16",
                               writeType="holding",
                               writeTransform="JS(multiply10.js)",
                               writeMultipleEvenWithSingleRegisterOrCoil=false,
                               updateUnchangedValuesEveryMillis=5000]
   } 

    Bridge poller Fan         [start=14, length=1, refresh=1000, type="holding"] {
      Thing data Speed        [readStart="14", 
                               readValueType="int16",
                               readTransform="default",
                               writeStart="14",
                               writeValueType="int16",
                               writeType="holding",
                               writeTransform="default",
                               writeMultipleEvenWithSingleRegisterOrCoil=false,
                               updateUnchangedValuesEveryMillis=5000]
    }
}

Can anybody give me a hint what I am doing wrong. How can I check, that my USB-RS485 adapter is working, like it did before?

Bruce_Osborne · November 8, 2020, 10:42pm

I got finaly my missing ttyUSB_LG

[23:25:27] pi@HAB:~$ ls -l /dev/ttyUSB*
lrwxrwxrwx 1 root root 15 Nov 8 22:13 /dev/ttyUSB_LG → bus/usb/001/005

What us impirtant is the permissions & ownership of the actual device.
Try ls -l /dev/tty/bus/usb/001/005

peaeater · November 8, 2020, 10:52pm

It does not look good this was the first try

[23:51:15] pi@HAB:~$ ls -l /dev/tty/bus/usb/001/005
ls: cannot access '/dev/tty/bus/usb/001/005': Not a directory

This was my second try. I made ls directory by directory

[23:56:14] pi@HAB:~$ ls -l /dev/bus/usb/001/005
crw-rw-r-- 1 root tty 189, 4 Nov  8 22:13 /dev/bus/usb/001/005

The problem may be the missing “tty” between dev and bus in the second attempt

Bruce_Osborne · November 8, 2020, 11:06pm

Thay device can only be accessed by the root user and members of the tty group. OPenHAB usually runs as the openhab user that is a member of that group.
Perhaps the openHABian fix permissions menu option would help. @mstormi is our openHABian expert here.

peaeater · November 8, 2020, 11:12pm

I tried fix permisssions and I get

│ There was an error or interruption during the execution of:                  │
│   "10 | Apply Improvements"                                                  │
│                                                                              │
│ Please try again. If the error persists, please read                         │
│ /opt/openhabian/docs/openhabian-DEBUG.md or                                  │
│ https://github.com/openhab/openhabian/blob/master/docs/openhabian-DEBUG.md   │
│ how to proceed.                                                              │
│                                                                              │
│                                                                              │
│                                    <Ok>

In the bash I see the following entries

2020-11-09_00:08:16_CET [openHABian] Applying file permissions recommendations...
$ usermod --append --groups audio openhab

$ usermod --append --groups audio pi

$ usermod --append --groups bluetooth openhab

$ usermod --append --groups bluetooth pi

$ usermod --append --groups dialout openhab

$ usermod --append --groups dialout pi

$ usermod --append --groups gpio openhab

$ usermod --append --groups gpio pi

$ usermod --append --groups tty openhab

$ usermod --append --groups tty pi

$ usermod --append --groups openhab pi

$ chown openhab:openhab /srv /srv/README.txt /opt

$ chmod ugo+w /srv /srv/README.txt

$ chown --recursive openhab:openhab /etc/openhab2 /var/lib/openhab2 /var/log/openhab2 /usr/share/openhab2

$ chmod --recursive ug+wX /opt /etc/openhab2 /var/lib/openhab2 /var/log/openhab2 /usr/share/openhab2

$ chown --recursive pi:pi /home/pi

$ setfacl -R --remove-all /etc/openhab2 /var/lib/openhab2 /var/log/openhab2 /usr/share/openhab2
/opt/openhabian/functions/helpers.bash: line 25:  6273 Segmentation fault      "$@"
FAILED (reset file access)
2020-11-09_00:12:18_CET [openHABian] Checking for default openHABian username:password combination... OK
2020-11-09_00:12:18_CET [openHABian] We hope you got what you came for! See you again soon ;)

Now I go to bed

peaeater · November 9, 2020, 3:45pm

The problem

$ setfacl -R --remove-all /etc/openhab2 /var/lib/openhab2 /var/log/openhab2 /usr/share/openhab2
/opt/openhabian/functions/helpers.bash: line 25:  6273 Segmentation fault      "$@"
FAILED (reset file access)

may be an issue from an weared out usb stick. I backed it up with ddrescue. I shrinked it with pishrink and wrote it back to a brand new stick, which I am actual running one.

Everything so far ist working except the usb-Serial connector.

And the fix permission option is running so far only the above line seems not to work.

May be that some file I need is broken due to the weareout of the original stick. It should be possible to rewrite that file.

What can I do?

stefan.oh · November 9, 2020, 8:32pm

A “Segmentation fault” usually indicates that the running program tries to access memory that does not belong to the program itself. Basically there are 2 root causes:

The program is damaged, meaning the file containing the binary code might be corrupted. You can try to uninstall the package that contains the program and re-install it afterwards.
There is a bug in the program and data driven errors occur. E.g. a data situation that the programmer did not think of occurs and error handling for that is missing or is not correct. This can only be addressed with programming.

As you are writing about a weared out usb stick both situations are possible. Maybe it is best you start with a fresh installation and only try to re-use your configuration data if you don’t have a backup that is known to be “good”.

peaeater · November 9, 2020, 10:38pm

At the side of my actual RPi I already have a new RPi4 with allready fresh installed openhabian.

My intention is realy to switch over, I see 2 possibilities.

I get my actual system running again, and make a USB DiskDump to my new SSD drive
I try to copy the configuration data and all my influxdb Data (nearly 2 years) to the new installation.

At the moment I think the first point is for me easier to achive.

I think your idea of

is for the moment my preferred next step. Therefore I would have to know which package might be damaged. How can I find this out ?

If my system is running again I would first try to copy configuration and data (influxdb) to the new rpi and see how much effort this would cost (main problems I expect are permission, owner and group problems, when something is not working in linux it is one of these 3 issues.) If I’m not faced with major problems on that way I can use this as future backup strategy. (This would be also my preferred way because I would have a new installed system with my old data)

If this way takes to much time I would try the diskdump way. (My actual usb Stick has 64GB my SSD has 240GB) so that should work within one day. Afterwards I will have to try to find out an pratical backup way from RPi4 to my old RPi3, due to the fact that also my SSD may wearout sometime in future (I hope it will last longer then my usb stick)

Wolfgang_S · November 10, 2020, 6:52am

The command that seem to result in the segmentation fault seem to be setfactl.
You get the primary involved package by running:

dpkg -S `which setfacl`

That should result in acl ( at least on my system which is not Buster ).
As the problem also could be related to the shared libraries from a dependent package you need to run:

apt-cache depends acl

Here it shows: libacl1, libcx. x should be a number.
libc is a library that is related to every executable. I would assume that more programs would fail in case of a problem with this lib. The other one is specific for setfacl.

stefan.oh · November 10, 2020, 6:48pm

You face the risk that other files may be corrupt as well, without knowing about it. In addition to that you need to check whether your current Raspbian installation is suitable for running on a RasPi4.

I cannot say anything about your database data, e.g. if it can be copied over to a newly installed Pi4. For OH you can make a backup of all the configuration data and transfer that to another installation. Look for the “openhab-cli” command.