I use SB for both my AD2USB Ademco alarm control as well as a Vaux matrix audio switch. The Vaux uses a Keyspan USA19h usb->serial port which has worked very well. Recently the Vaux, and not the AD2USB, has started generating a ton of extra files in the Vaux folder that I believe are duplicates of the settings file. From Feb 15 thru March 7 it accumulated over 500 of these. They must be somehow connected to use of the unit, as I was on vacation last week and many fewer were generated. I'd appreciate some help in sorting it out.

Attached is a screen shot of the file folder, as well as the script. I disabled several sections that didn't seem to contribute to my use, but perhaps I took out one too many. Thanks very much!

Code: Select all

-- Sample connection attachment script for Serial Bridge.
--
-- This script, if it is in the same folder as the Serial Bridge database settings
-- file (it is by default), will automatically be loaded and launched when Serial
-- Bridge is launched. It will be terminated and reloaded whenever any serial
-- port settings change for this connection, or if the Reload button is pressed.
--
-- MyProcessSerialData() below contains sample code you can modify to
-- wait for serial data, read serial data, send serial data, and log information
-- to the Serial Bridge log window.
--
-- The entry point into this file is startCommunication(). Although
-- documentation is provided below for both functions; you will probably
-- only need to modify MyProcessSerialData().
--
-- 2005-03-29 Original. (Matt Bendiksen)
-- 2005-04-01 Fixed event timeout bugs. (Matt Bendiksen)

-----------
--
on MyProcessSerialData(connectionName)
   tell application "Serial Bridge"
      -----------------------------------------------------------------------------
      (* "wait for data" will block our script until serial data become
             * available to read. Note it has optional argument to specify
             * the number of bytes to wait for ("to count") and the maximum
             * amount of time to wait in milliseconds until a timeout error is
             * thrown ("timeout after").
             *)
      wait for data from source connectionName to count 25
      
      (* Now that 25 bytes of data are available to read, we can extract out a single byte:
             *)

--Have commented out these next several lines.
      (*set singleByte to read byte from source connectionName
      log "one byte = " & (singleByte as integer) using type "Sample"
      
      (* or multiple bytes:
             *)
      set threeBytes to read byte list from source connectionName to count 3
      log "first byte = " & item 1 of threeBytes using type "Sample"
      log "second byte = " & item 2 of threeBytes using type "Sample"
      log "third byte = " & item 3 of threeBytes using type "Sample"
      
      (* or a string of 5 characters:
             *)
      set fiveCharString to read string from source connectionName to count 5
      log "five character string = " & fiveCharString using type "Sample"
      *)
      
--Thru here.

      (* or a string of all the available characters:
             *)
      set restOfString to read string from source connectionName
      --log "rest of string = " & restOfString using type "Sample"
      log "Vaux Output = " & restOfString using type "Sample"
      tell application "IndigoServer"
         if restOfString contains "!" then
            set value of variable "vauxResponse" to restOfString
         end if
      end tell
      
      (* The above read verbs all have an optional argument, "timeout after",
             * to specify how long to wait in milliseconds for the data if it is not
             * currently available. If no timeout argument is present, then a
             * timeout error will be immediately thrown if there is not enough
             * data present to fulfill the request.
             *)
      
      -----------------------------------------------------------------------------
      (* To send data use the "send to source" verb. You can either send
             * a single byte, multiple bytes as a list, or a string. To send a single byte:
             *)

--Have commented out several following lines.
      (*send to source connectionName byte 127
      
      (* or to send multiple bytes:
             *)
      send to source connectionName byte list {2, 4, 8, 16, 32, 64}
      
      (* or to send a character string:
             *)
      send to source connectionName string "hello world"
      *)
--thru here.[attachment=0]Serial Bridge Duplicate Settings.tiff[/attachment]

   end tell
end MyProcessSerialData

-----------
-- Serial Bridge will call the startCommunication() subroutine after it has opened
-- the serial port connection for this connection. It is only called after the serial
-- port connection has been opened, shortly after Serial Bridge launches or if
-- the user presses the Reload Script button.
--
-- The argument, connectionName, is a string used to identify this serial port
-- connection, and will always be the folder name in which this script (and
-- database settings file) resides. This value should be passed to all read, write,
-- and wait serial functions to identify which serial port connection the script is
-- using.
--
on startCommunication(connectionName)
   tell application "Serial Bridge"
      -- Loop forever: wait for data, read it, process it, and optionally send
      -- out serial data.
      --
      -- We do not want our script to return or exit since Serial Bridge
      -- only calls our script on launch (or when the Reload Script button
      -- is pressed).
      repeat while true
         try
            set maxTimeoutDelay to 8947848 -- 103.56 days (hex 0x00888888)
            with timeout of maxTimeoutDelay seconds
               my MyProcessSerialData(connectionName)
            end timeout
         on error number errNum
            (* Log timeout errors (-1712) but continue processing loop. Without
             * handling this error, the script would throw out of the repeat loop
             * and terminate if any of the script calls were to throw a timeout error.
             * Normally, if there was a timeout error thrown you would want
             * to continue processing your main loop in an attempt to get back
             * in syncronization with the hardware. By catching this error we
             * will do exactly this and continue to process our script repeat loop.
             *)
            if errNum is -1712 then
               log "timeout waiting for serial data" using type "Error"
            else if errNum is -1708 then
               log "AppleEvent not handled" using type "Error"
               return -- fatal error; exit script processing
            else if errNum is -128 then
               log "connection script aborted" using type "Error"
               return -- fatal error; exit script processing
            else
               log "error " & errNum & " inside MyProcessSerialData()" using type "Error"
               return -- maybe fatal error; exit script processing
            end if
         end try
      end repeat
   end tell
end startCommunication


What does the Event Log inside Serial Bridge show?

Those files are SB's attempt at auto-saving the settings file. It first saves them with a temporary name, then after that has completed it renames the file to the correct name. That rename may be failing, perhaps because of a file permission problem. So check the file permissions and owner on both the settings folder and the main settings file, and check the Event Log for any more detailed errors.

I checked permissions for the SB and Perceptive Automation folders. Both had the user and everyone permissions set to read-write. Nonetheless I had the PA folder permissions applied to all contained files.

Unfortunately that did not work and the files are still being generated. There is nothing in the SB event log folder to indicate what's going on.

Maybe I'll try deleting the settings files and start over in a different folder.

If that doesn't work, then check the system console for Serial Bridge errors and see if you have any Serial Bridge crash log files. Although it doesn't sound like it is crashing, or is it?

It's not crashing in normal use. However, one possibly suspect thing I have been doing is shutting down and restarting the Mini each night. In the shutdown process I've been issuing a "killall" command to SB as it sometimes would not want to quit with an applescript quit command. While I don't know how that would mess up the subsequent saving routines, I've turned off daily restart for now, quit SB normally and restarted it. We will see how it behaves if left undisturbed.

I still suffer from this issue. See: viewtopic.php?f=6&t=3334

HFTobeason wrote:I still suffer from this issue. See: viewtopic.php?f=6&t=3334

In the previous thread you said the problem stopped after relaunching SB. Do you have any idea what steps cause it to start again?

I have never been able to identify a precise sequence of events that result in the spewing of spurious settings files. Although I believe they only show up after a reboot of that machine. They don't show up - as far as I can tell - during "normal" operations. It seems to be something to do with an inelegant shutdown/relaunch of SB. The problem is relatively rare, and easily dealt with, so I just live with it.