Problem reading from one serial device with two apps #11
Comments
|
It seems to work when I do it like this: During the "sleep 60" I need to start the app and when she has done all the initializing it seems to be safe to attach the 2nd fake serial port to the bus and connect a second app, but when the 2nd port is attached to early the app on port 1 fails to initialize. Whether this is a bug and should be fixed in "app nr. 1" I can't say but I'd like to have your opinion on WHY this is happening. Is "the fake serial port 2" maybe sending something when connecting which irritates the physical serial device? |
|
I also have problems when I put all the tty_bus, tty_attach, tty_fake, tty_fake commands in a single script, but they work when I do it on the command line by hand. I've moved to a different focus for a while, but next time I get back to this I will look at it more and see if adding delays helps my situation, too. |
|
@OevreFlataeker thanks, your comment fixed my issue. I put a wait command until the tty_mux is created before of the |
|
Would be great if there's an official fix - shouldn't be hard to do? Maybe I'll have a look at it when I got a couple of spare hours |
|
Sure, I think I am using something like this. This script was adapted from your script above. In my case, I have a script for #!/bin/bash
# ================================
# PART 1
the_real_dev="/dev/ttyAMA0"
my_tty_busmux="/tmp/ttyS0mux"
my_fake_tty_1="/dev/ttyAMAfake1"
my_fake_tty_2="/dev/ttyAMAfake0"
# ================================
# PART 2
echo "Creating bus"
sudo tty_bus -d -s ${my_tty_busmux}
echo "Attaching real device ttyAMA0 to the Bus Mux"
sudo tty_attach -d -s ${my_tty_busmux} ${the_real_dev}
# Wait for tty_mux to be ready
echo -n "Waiting for tty_mux ${my_tty_busmux}"
until [[ -S ${my_tty_busmux} ]]; do sleep 0.1; done
# ================================
# PART 3
echo "Attaching a fake tty to the bus mux"
sudo tty_fake -d -s ${my_tty_busmux} ${my_fake_tty_1}
# Wait for pty
echo "Waiting for tty_fake ${my_fake_tty_1}"
until [[ -c ${my_fake_tty_1} ]]; do sleep 0.1; done
echo "You can now use the ${my_fake_tty_1}"
# ================================
echo "Attaching another fake tty to the bus mux"
sudo tty_fake -d -s ${my_tty_busmux} ${my_fake_tty_2}
# Wait for pty
echo "Waiting for tty_fake ${my_fake_tty_2}"
until [[ -c ${my_fake_tty_2} ]]; do sleep 0.1; done
echo "You can now use the ${my_fake_tty_2}" |
|
I am starting to think my solution doesn't fix this issue. |
|
Same here... it works for quite some time but then neither of the two clients can any longer properly read from the tty :-( It's a pity, would be such a neat solution. Did anyone have any success with alternative approaches, e.g. socat? |
I would like to use your tool to read from one physical serial device with two apps and both of them seing the same data read. One of those apps will also write to the port, the other won't.
I've set everything up according to your use case example 1, however when I start the app which will be writing and direct it to fake device nr 1 I get lots of communication errors in the log:
Basically the physical device has a very simple CLI and sends and receives plain text data ending with \r\n - but something in the ttybus seems to annoy it. I've started every component without the daemon option to potentially see any issue but there is no output in any of the tty_* tools apart from tty_bus.
The whole thing is about a "CUL" device receiving 868 MHz data, parsing it and returning it to an app as a plaintext string. It is used with a home automation system called fhem (fhem.org). The physical device is the CUL SCC from busware.de
Any idea what could be the problem?
The text was updated successfully, but these errors were encountered: