Embedded Applescripts and RFID Plugin

Posted on
Mon Jul 01, 2013 7:51 am
iautomate offline
User avatar
Posts: 7
Joined: Jan 31, 2013

Embedded Applescripts and RFID Plugin

The architecture of AppleScript requires Embedded scripts to be executed in the main thread of the Indigo application. When an embedded AppleScript executes, the Indigo Server stops processesing EVERYTHING else until the execution of the Applescript is completed.

With most serial interfaces such as X10, Insteon, Zwave, this delay might not result in any undesireable operation or symptoms other than a delay in operating a device.

With the RFID data stream however, timing is critical. With the RFID Plugin, Polling is real time, ALL of the time and the suspension of processing will have an adverse impact on polling and the resulting data. The Plugin is expecting responses from the reader even when no tags are preset at the RFID reader, If the RFID polling and access to the Indigo Database is interrupted, CRC errors or other errors can result.

To avoid this "stall" of Indigo, we recommend that AppleScript actions be executed as self contained external scripts, so that any pause created by an embedded script does not inhibit the plugin's access the Indigo Server's database.

Please see:

http://www.perceptiveautomation.com/wik ... pplescript
Last edited by iautomate on Wed Jul 03, 2013 3:50 pm, edited 3 times in total.
Reason: Because Sticky, included reference to accessing Indigo Database, for clarity

Posted on
Mon Jul 01, 2013 10:15 am
jay (support) offline
Site Admin
User avatar
Posts: 13250
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Embedded Applescripts and RFID Plugin

Hmmm. Since the plugin is running in it's own process, this really shouldn't be an issue, right? Particularly if your polling is done in a different thread from your plugin's main thread that updates the plugin states. The queueing between your threads should just fill up while the server is busy and then catch up once it's done...

Having said that, of course, external AppleScripts are almost always better than embedded scripts unless the script is just brain-dead simple (no talking to external apps, files, networks, shell scripts, etc.).

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Mon Jul 01, 2013 12:41 pm
matt (support) offline
Site Admin
User avatar
Posts: 17970
Joined: Jan 27, 2003
Location: Texas

Re: Embedded Applescripts and RFID Plugin

What might be occurring is that the plugin is making an Indigo Server request (looking up a device, refreshing a device, etc.) which requires Indigo Server main thread processing to return the result and thus can be blocked by an embedded AppleScript. Plugin commands to Indigo Server should just batch up and not block, but it is difficult for a plugin to know if a given command will require an just a command broadcast to Indigo Server (won't block) or a request to Indigo Server (can block). For example, off the top of my head I'm not sure if updating a device state requires any requests under-the-hood inside the plugin host when it executes.

But what Jay said is correct, I think if your plugin has the low-level hardware communication occur in its own thread and in that thread it just stuffs the results into a queue (no Indigo calls), then it should be able to maintain hardware communication regardless of what is occurring on the Indigo Server side.

Image

Posted on
Wed Jul 03, 2013 3:40 pm
iautomate offline
User avatar
Posts: 7
Joined: Jan 31, 2013

Re: Embedded Applescripts and RFID Plugin

matt (support) wrote:
What might be occurring is that the plugin is making an Indigo Server request (looking up a device, refreshing a device, etc.) which requires Indigo Server main thread processing to return the result and thus can be blocked by an embedded AppleScript.


The RFID plugin is very robust and data intensive. Even when there are no tag signals being detected at a reader, the RFID readers transmit "empty" tag packets indicating the reader is alive and the tag buffer is empty. This could be 8 bytes every 50ms. Aside from passing empty tag packets along to the serial port to indicate the buffer is empty, these empty tag packets also serve to indicate that communication with the reader is functioning properly.

Because the RFID Plugin is tracking the presence (and absence) of assets in near-real-time, we operate in a single thread that writes the Indigo database as tag data is available. When an embedded AppleScript ties up the Indigo Server, the plugin is not able to access the database when needed.

We had considered developing the plugin a multithreaded environment, but that too could cause delays, since the plugin would have an helper thread reading the data, and then handing it off to the main thread.

We are always looking at ways to improve the plugin in future releases and remain open to suggestions.

We do suggest that users of the RFID plugin avoid embedded Applescripts for best performance. The RFID plugin will run trouble free if embedded scripts are avoided.

Posted on
Wed Jul 03, 2013 4:22 pm
jay (support) offline
Site Admin
User avatar
Posts: 13250
Joined: Mar 19, 2008
Location: Austin, Texas

Re: Embedded Applescripts and RFID Plugin

I understand the time critical nature - however, threading the plugin, I believe, will solve a variety of issues. While it's interesting to know multiple times a second that the reader is present, I'm not sure that's interesting to the user. I don't know how much of the sub-second data is passed from the plugin to the server but if data is being updated more than a couple of times a second (which is probably overkill) then I'd suggest a heavy rethink about the plugin's architecture.

That would be my basic recommendation: minimize the amount of communication between the plugin and the server and buffer between the read thread and the main thread in the plugin so that anything that could cause the server to hang up for smallish periods of time doesn't significantly impact the plugin. If a tag is updated to be "in range" a second later than might be the case because the server was busy doing something else, I suspect that 99.9% of your users won't even notice.

Jay (Indigo Support)
Twitter | Facebook | LinkedIn

Posted on
Wed Jul 03, 2013 9:03 pm
pmonahan offline
User avatar
Posts: 28
Joined: Dec 19, 2006
Location: Atlanta

Re: Embedded Applescripts and RFID Plugin

jay (support) wrote:
I understand the time critical nature - however, threading the plugin, I believe, will solve a variety of issues. While it's interesting to know multiple times a second that the reader is present, I'm not sure that's interesting to the user. I don't know how much of the sub-second data is passed from the plugin to the server but if data is being updated more than a couple of times a second (which is probably overkill) then I'd suggest a heavy rethink about the plugin's architecture.

That would be my basic recommendation: minimize the amount of communication between the plugin and the server and buffer between the read thread and the main thread in the plugin so that anything that could cause the server to hang up for smallish periods of time doesn't significantly impact the plugin. If a tag is updated to be "in range" a second later than might be the case because the server was busy doing something else, I suspect that 99.9% of your users won't even notice.


I cannot go into too much more detail in a public forum about the protocol, however I can tell you that the buffer in the reader is very small and must be emptied of tag data many times per second in order to make room for any subsequent tag transmissions. The plugin is not simply determining if the reader is present, that is a secondary use of the empty tag packet which is primarily used for emptying the reader's buffer. If the buffer is not emptied, new tag data will overwrite the previous data and the tag data will be lost. This is especially critical when tags are at rest and transmitting at 15s intervals. In this example, if one tag packet is missed, 30 seconds will have elapsed between tag packets.

The design of the hardware (small buffer) is intentional and geared towards real time data collection and forces us as a developer to empty the tag buffer frequently to insure fresh, accurate data.

In our test environment we have had good results with as many as 135 active tags in the range of a reader and that is only possible because of the speed at which we retrieve the tag data from the reader, thus clearing the buffer many times per second.

Posted on
Thu Jul 04, 2013 12:00 am
matt (support) offline
Site Admin
User avatar
Posts: 17970
Joined: Jan 27, 2003
Location: Texas

Re: Embedded Applescripts and RFID Plugin

I understand that the buffer needs to be emptied promptly, but that is exactly why it should be in its own thread. It can queue the data it empties, which can then be processed in another (likely the main) thread. That will help ensure no data is lost even if the main thread has to block for a bit -- in this case waiting on Indigo Server to execute an embedded AppleScript. What would be the reason not to take this approach?

FYI, that is exactly what we do for X10, INSTEON, and Z-Wave data to make sure data is never missed. They aren't as timing sensitive, but we use dedicated threads for the incoming data regardless to make sure no data is ever missed.

Image

Posted on
Thu Jul 04, 2013 5:34 am
pmonahan offline
User avatar
Posts: 28
Joined: Dec 19, 2006
Location: Atlanta

Re: Embedded Applescripts and RFID Plugin

Hi Matt,

We are discussing multithreading as a development option in a future release of the plugin.

Presently we are referring users of the RFID plugin to Perceptive Automation's published guidance which recommends against the the use of Embedded Applescript, especially when "talking" to other applications. When that guidance is followed, the plugin runs without being affected by any stall that might occur with the Indigo Server because of an embedded script.

http://www.perceptiveautomation.com/wik ... pplescript

Thank you and Jay, this has been a helpful discussion.

Peter

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 0 guests