Thank You for the quick reply. In fact, I suspected the Event loop to make some trouble, so I moved the &testSequence() execution into an own thread. And the data fed by &testSequence() into the pipe is read and processed by the FSM -- once the pipes are fed from the bash. I have also tried to put the &testSequence() asleep for 1s in its initialisation to make sure the Event loop is started when the pipes are fed: the outcome is negative.

I open the pipes in "+<" mode, and already suspected this could be an issue. But since opening the pipes in &testSequence() did not seem to work and I did not get any error or warning when writing to the pipe, I was not alarmed.

Based on Your input, I have now tried opening the pipes in "+>" mode in &testSequence again: it makes no difference. :-( It looks to me like if the Event::IO was not notified, when the pipe is fed from the same process. Could it be?

Code Example

sub initAppControl ()
{
   my $config = shift;
   $config->{deviceControlCallback} = \&addDeviceControlCB;

   # create and open control FIFO
   if ('' eq (-p "$config->{fifoControl}->{status}" ))
   {
      POSIX::mkfifo ("$config->{fifoControl}->{status}", 0700);
   }
   if ('' eq (-p "$config->{fifoControl}->{control}" ))
   {
      POSIX::mkfifo ("$config->{fifoControl}->{control}", 0700);
   } 
   # open pipes, set status pipe to "autoflush"
   open ($config->{fifo}->{appControl}->{control}, "+<", $config->{fif
+oControl}->{control}) || die "Could not open status pipe ($!)\n";
   open ($config->{fifo}->{appControl}->{status}, "+>", $config->{fifo
+Control}->{status}) || die "Could not open control pipe ($!)\n";
   $config->{fifo}->{appControl}->{status}->autoflush(1);
}

sub testSequence ()
{
   my $appControlFifo;
   my $deviceControlFifo; 
   if ('' eq (-p "$sm->{config}->{deviceControl}" ))
   {
      POSIX::mkfifo ("$sm->{config}->{deviceControl}", 0700);
   }
  # shorthands for pipe handles
   open ($appControlFifo, "+>", $sm->{config}->{fifoControl}->{control
+}) || die "Could not open status pipe for writing ($!)\n";
   open ($deviceControlFifo, "+>", $sm->{config}->{deviceControl}) || 
+die "Could not open device pipe for writing ($!)\n";
   $| = 1;
   $appControlFifo->autoflush(1);
   $deviceControlFifo->autoflush(1);
   # test sequence
   print $appControlFifo "connect to device\n"; # state transition: 01
+ -> 02, currently automatically set
   print $appControlFifo "connect to device\n"; # keep current state
   print $appControlFifo "connect to device\n"; # keep current state
   print $appControlFifo "disconnect device\n";
   print $deviceControlFifo "^MODE:1,1\n";      # state transition: 02
+ -> 03
   if ($sm->Instance() =~ "Statemachine::03")   # check if transition 
+succeeded (kind of ASSERT)
   {
      print "transition succeeded\n";
   }
   print $appControlFifo "connect to internet\n"; # state transition: 
+03 -> 04
   print $appControlFifo "internet connected\n"; # state transition: 0
+3 -> 04
}
[download]

Update: after explicitelly triggering the Event loop after each write to the pipes, things seem to work fine. I will make a more detailed check this evening.

sub testSequence ()
{
   my $appControlFifo;
   my $deviceControlFifo; 
   if ('' eq (-p "$sm->{config}->{deviceControl}" ))
   {
      POSIX::mkfifo ("$sm->{config}->{deviceControl}", 0700);
   }
  # shorthands for pipe handles
   open ($appControlFifo, "+>", $sm->{config}->{fifoControl}->{control
+}) || die "Could not open status pipe for writing ($!)\n";
   open ($deviceControlFifo, "+>", $sm->{config}->{deviceControl}) || 
+die "Could not open status pipe for writing ($!)\n";
   $| = 1;
   $appControlFifo->autoflush(1);
   $deviceControlFifo->autoflush(1);
   # test sequence
   print $appControlFifo "connect to device\n"; # state transition: 01
+ -> 02, currently automatically set
   Event::one_event();
   print $deviceControlFifo "^MODE:1,1\n";      # state transition: 02
+ -> 03
   Event::one_event();
   print "State Instance:>>> " . $sm->Instance() . "\n";
   if ($sm->Instance() =~ "Statemachine::03")   # check if transition 
+succeeded (kind of ASSERT)
   {
      print "transition succeeded\n";
   }
   print $appControlFifo "connect to internet\n"; # state transition: 
+03 -> 04
   Event::one_event();
   print $appControlFifo "internet connected\n"; # state transition: 0
+3 -> 04
   Event::one_event();
}
[download]

A named pipe (FIFO) is meant to be opened twice, once for reading only and once for writing only. Generally, the two ends of a named pipe are expected to be opened by different processes although it should still work if one process opens both.

At the least, you should fork at the beginning of testSequence and have the parent return immediately to the event loop. (You will have to handle synchronization for completing the test and reporting a result back to the parent separately; pipe is likely to be useful for this and I have used it in a number of Tk programs to handle slow background tasks in child processes without blocking the GUI thread.) This will effectively require another event-driven task in the parent to verify the state machine behavior as the child makes incremental progress reports, since the test driver and FSM will be in separate processes.

If you insist on your current approach, inserting recursive calls to the event loop to process the events you create in testSequence is exactly what you must do.