Open OevreFlataeker opened 3 years ago
It seems to work when I do it like this:
#!/bin/bash
cd ttybus
echo "Creating bus"
sudo ./tty_bus -d -s /tmp/ttyS0mux
echo "Attaching real device ttyAMA0"
sudo ./tty_attach -d -s /tmp/ttyS0mux /dev/ttyAMA0
echo "Attaching fake ttyAMAfake1 to bus"
sudo ./tty_fake -d -s /tmp/ttyS0mux /dev/ttyAMAfake1
echo "Now start fhem and wait until it is settled"
sleep 60
...
...
...
sudo ./tty_fake -d -s /tmp/ttyS0mux /dev/ttyAMAfake0
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 tty_fake
command and also one waiting for the tty_fake
device to be created after the tty_fake
command and it looks like this fixed my issue. Thank you.
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 tty_fake
should wait or check if the tty_bus
is ready/created and maybe wait until its fake tty is ready to use.
I am using something like this. This script was adapted from your script above.
In my case, I have a script for PART 1
, and another script for PART 2
that I can be launched multiple times creating different fake ttys and connecting to a different instance of an app or another app.
#!/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.
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?