Pathfinder Core PRO’s event system is called Logic Flows, and it enables information visualization so that you can see how things work within your system.
Click the Logic Flows link in the navigation bar to open the Logic Flows user interface.
Each Logic Flow can be thought of as an event. More specifically, a Logic Flow is a set of property translations. During an event, we convert an input property value to an output property value.
There are four components that may be used to design a Logic Flow:
Using these tools, you can visually build Logic Flows to accomplish just about any task you want.
When you first look at the Logic Flows screen you will see an organizational panel on the right called Views. Think of Views as folders in your computer’s file system - organizational containers into which you can place Flows, allowing you to keep all Flows related to a certain subject in the same place.
Important Note: Clicking the Views tab allows the panel to slide in and out.
To create a new View:
- 1.Check an existing View (this will become the parent View).
- 2.Click the Add (plus) button in the Views panel.
- 1.Type a Name for the new View and click OK.
Like your computer folder structure, you can nest Views as deep as you like. While you can add Flows to the master LogicFlows View (your “Root” folder), this is not recommended as LogicFlows is the one View that you cannot completely delete. Instead, devise a View naming strategy and create additional Views underneath LogicFlows to store your Flows.
Important Note: Each View is limited to 100 Flows.
There are two special Views called HardwareMaps and _panels. These Views are created by the system and used to manage the mapping of software buttons to hardware controls and bindings in HTML5 user panels. This is described in the chapter on HTML5 panels, but it is important to understand that these Views are managed by the system and should not be deleted.
With a View selected:
Important Note: You cannot select multiple Views for copy and paste operations, though if you select a View with child Views, those child Views are included in the copy operation. All pasted Logic Flows will be in a disabled state whether the operation started as a cut or a copy.
It is assumed that after completing a copy and paste you will want to modify the Start and End Points of the Flow to reproduce behavior using different End Points.
View, copy, and paste operations are completed by the Pathfinder Core PRO appliance rather than by the browser and so they do not require an Apply.
Under the hood, the browser sets a write-only CopyTo property on the copied View folder object via a SapV2 Set message. The value used in the set message is the path to which the View should be copied. The Pathfinder Core PRO Logic Flow engine then handles the data cloning.
To delete a View:
- Select the View
- Click the X button in the Views panel
- The system will ask for confirmation; all Logic Flows and descendent Views of the View selected for deletion will be deleted as well
From left to right, the Toolbar controls are:
Toolbar controls will be enabled or disabled depending on whether the control is currently valid. For example, the Cut icon will not be enabled if you do not have a Flow selected that can be cut.
Understanding how these tools are used will be easier if we walk through creating a Flow.
- 1.Click the Logic Flows checkbox then click the Plus icon in the Views panel
- Type a name for the new View and click OK
- You can select "multiple Views" to view the Flows from multiple Views together on the same screen; in order to create new Flows, you must select a single View since the system has to know into which View to place the new Flow; click the newly created View’s checkbox to select the new View; click the root Logic Flows View to uncheck its checkbox so only your new View is selected
- Once a single View is selected, the Add button (plus) in the main control panel for Logic Flows will switch from its disabled grey state to green; click the Add button to create a new Flow consisting of a Start Point, a Translator, and an End Point
Important Note: This Flow is in black and gray indicating that these are pending changes that have not been submitted to the system yet. So far, they only live in your local browser.
All Flows must have at least one Start Point, one Translator, and one End Point, which is the simplest Flow you can creat. However, we have not yet set parameters to define what this Flow will do. You can define the options for each block in this Flow by double-clicking on the block, though double-clicking on the Translator itself will not do anything until the Start Point and End Point are defined. The reason for this will be explained shortly.
Double-click on the Start Point block; its background will turn orange on the first click to indicate that it is selected.
The second click opens the property selector dialog. This dialog is used to select a property in the system that the new Flow will monitor for changes.
Use the arrows to expand and navigate into the objects in the system until you find the object and property you want to select. Properties will have a green dot next to them as opposed to the expansion arrow.
You can either click the property you want to monitor and then click Select, or just double-click the property to select it.
In this example, we are selecting the PinState property of GPI#1, Pin#1 on the Fusion device at 192.168.2.62. Notice that as you select properties in this dialog, a description of the property will usually appear underneath the tree window providing more detail about the property’s purpose.
Important Note: The property selector dialog has a simple list and an API list. The API list is only recommended for advanced users and so will not be discussed until later in the documentation.
Important Note: Hovering over the Start Point that has been assigned a property will cause a pop-up hover box to appear with more detailed information about the selected property.
- Double-click on the End Point block and repeat the procedure to select the End Point or property we want this Flow to change; in this example, we are going to pick an LCD button, but you could also pick a GPO in order to make the GPO state follow the GPI state
At this point, the Flow looks something like:
Important Note: The list of available properties differs depending on whether you are editing a Start Point or an End Point. This is because the system is intelligent enough to know if a property is read only, read write, or write only. Properties that are read only may not be used as an End Point (something you want to change). The system will only display properties that make sense for the type of block you are editing.
- With configured Start and End Points, you can edit the translation table by double-clicking the ListTranslator block
The dialog that opens allows you to enter a list of translations you want to execute as part of this Logic Flow. The other buttons on the translation list screen can be used to move translation definitions up and down in the list, insert new ones, and remove them.
- Select the top translation point (*=*) to enable the drop-down boxes below; the left drop-down has Low and High as options, and the right drop-down has a list of indicator states; for this example, select Low in the left drop-down and On in the right drop-down
- Click Add to add another translation to the list
- For this example, select High in the left drop-down and Off in the right drop-down
You cannot edit the translation block until the Start and End Point properties are configured because the system will filter the list of possible options depending on the property selected. For example, in this case, Low and High were available options on the left, and indicator states were available on the right. If the Start Point had been the CurrentSource property of a destination, the right drop-down would present a list of available router sources.
- Your Flow should now look something like this:
What we have just defined is that if the Start Point (GPI) is Low, then we are going to set the LCD Button indicator on the button to On. If the GPI is High, then we are going to set the LCD button indicator to Off. We are essentially defining a list of rules as to what the End Point value should be depending on the Start Point property value.
When creating translation items, the asterisk serves as a special wildcard that will be evaluated as “any” value. For example, we could have made the second entry in this translation list *=OFF.
Since the list is analyzed in order, this would mean that if the GPI is Low, then the indicator should be turned On. If the GPI is anything else other than Low, then the indicator should be turned OFF. In this case, using * or explicitly defining the High are equivalent because the GPI only has two possible states.
Where the * comes in useful is in situations where there are multiple options on the Start Point side. For example, if the Start Point was the current source routed to a destination, we could build the translation such that if a specific source is selected the indicator would be On, and then use the * to say if there is any other source routed, turn it Off.
Order is important. If you were to move *=Off to the top of the list, the indicator would always be Off because the first item in the list says if anything, then Off, and the system would never analyze any of the other items in the list.
Generally, a * should almost always appear at the end of a list of translations as a catchall. If there is a * on the right-hand side of the translation it means to pass the value from the left on unchanged. So *=* would pass anything from the Start Point to the End Point (or next step in the Flow) unchanged.
For those of you familiar with programming languages, this list works very much like a select case or switch statement. When the Start Point property changes, the value is analyzed in order through this list until a match is found and then the correct value is applied to the End Point or next step in the Flow. If no match is found, the End Point is not changed.
- Once you are finished, click Done. The Flow will now look something like this:
- This Flow is not active yet, and the black and gray states are showing us that this Flow has not been committed to Pathfinder Core PRO; in the top toolbar, the flashing Apply button indicates changes are pending; click Apply to commit the changes to Pathfinder Core PRO
The Flow will now change colors to indicate that it is a live and active Flow:
The Flow diagram does not simply show the design of the Logic Flows in your system. It also shows the live up-to-the-second state of each of the Flows. Using the Flow example created above, if we trip the source GPI to Low, we will see the diagram change to:
And if we switch it to High, it will change to:
Within the top of the translation box, we see the currently active translation state in text and a color change depending on that state. These dynamic changes indicating the state of the Flow makes for much easier monitoring and troubleshooting.
Note: These colors come from a file that may be edited in an advanced web page if necessary.
Translation points are one-to-one only. In other words, we are translating one value from a property to another value on another property. Combiners, on the other hand, allow us to pass values to multiple End Points and make logical decisions based on more than one Start Point.
- To add a Combiner, click a Translator in an existing Flow to enable the Combiner tool in the toolbar; click the tool to insert a Combiner into the Flow
Using the Flow we created in the example above, it will look like this:
Combiners can perform many useful functions, but each Combiner type both require a minimum number of inputs and are limited to a maximum number of inputs.
As you attempt to change Combiner types, you will only see options that meet these restrictions. For example, with the single input in our sample Logic Flow, we are restricted to NOT, PASSTHRU, and DELAY Combiner types:
- We can access the other Combiner types by adding the requisite number of inputs by clicking on the Combiner to select it; notice that both the Start Point and End Point tools then become available
- Click on the Start Point tool to add a second input to our Flow
By adding a second input, you will notice the Combiner switches to AND.
With two inputs, we can perform other Combiner operations, including: AND, OR, NAND, NOR, XOR, XNOR, EQUALITY, and RELAY.
In this case, since the default AND Combiner is a logic gate, the translation types entering and exiting the Combiner are automatically switched to True/False. By assigning a second GPI pin to the second Start Point…
…we can change this event so that two buttons must be held simultaneously for the End Point change to happen. This Flow will light the indicator light on the button only if both GPI 1 and 2 are Low.
- As it is, this Flow is not very useful, but if we were to change the End Point to be a route destination, it becomes more interesting; to do so, double-click on the End Point and instead of a GPIO, expand the Routers section and select the CurrentSourcePath property of one of the router destinations
Your Flow should now look something like this:
- Edit the translation which is after the Combiner and change the translation so that True= one of the sources in the right-hand drop-down of the translation dialog; remove the False translation as we do not want to do anything if the buttons are released, and you end up with:
This essentially means a user must hold two GPIO buttons down simultaneously and then source SRC 4 will be routed to destination DST 2. This is a common scenario where we don’t want an accidentally bumped button to change the air chain routing.
Logical Combiners include AND, OR, NAND, NOR, XOR, XNOR, and NOT. All of these except NOT accept multiple inputs which must be translated to True or False on the input side. NOT only accepts a single input. In each case, the translation that feeds the input of these Combiners should be converted to a True or False like we did in the example above.
The output of the Translator then becomes either True or False based on the truth table associated with the logical type selected.
The PASSTHRU Combiner allows only one input but can pass the value from the Start Point translation to as many output Translators as you like, allowing you to change multiple output properties based on a single input property.
The RELAY Combiner allows you to define one Start Point property that will translate to a True or False. If it evaluates to True, the value from the second Start Point is passed through the Combiner to any translations on the output of the Combiner.
The diagram within the combination displays which Start Point translation is acting as the trigger and which is acting as the PASSTHRU:
This will achieve the same functionality as our previous example but in a different way. GPI 1 must be Low in order for changes taking place on GPI 2 to pass thru. If it is Low then changes from GPI 2 will be passed to the output translation which converts the Low to a route change.
The EQUALITY Combiner takes multiple inputs and will result in an output value of True or False depending on whether all input values match.
The EQUALITY Combiner also has a Case Insensitive checkbox which defines whether comparisons are done in a case sensitive or insensitive way:
This Combiner can be used in situations where the primary concern is whether the property states are equivalent or not.
The DELAY Combiner takes a single input and introduces delay directly into the Logic Flow. It works like a PASSTHRU Combiner in that it takes the input value and passes it through to the output but only after a configured number of milliseconds. There are also some additional parameters that can affect how this Combiner functions:
DELAY Combiners can be used in many situations where you need to introduce some delay into a Logic Flow. Previously this required using an interval timer. Therefore, there will be many situations where an interval timer is no longer necessary to accomplish the task as the delay can be built directly into the Flow. This also reduces licensing requirements as the DELAY Combiner does not require an intermediary timer End Point.
Interval timers are still useful in situations where a single delay needs to be stopped, started, reset, or manipulated by different Flows.
In this example, the EQUALITY Combiner outputs True or False depending on whether two silence alarms are in the same state. This can be useful if two audio channels should have the same audio. Silence is expected in certain situations, but we are trying to make sure that if audio is present on one, it is present on both and if it is silent on one then it is silent on both. True or False is translated into a message of AudioMatches or AudioDiffers. A delay is introduced to expunge short variations of alarm states and only pass on definitive states. This is one example of how the DELAY and EQUALITY Combiners might be used.
In many cases you may want the DELAY to pass a value through after the delay but then reset the output for the next change. For example, if we want a Flow that requires a user to hold a button down for a length of time before making a change, the Flow might look something like:
Our goal with this Flow is the following:
- If the button is pressed, start a 5 second timer
- If the button is released cancel the timer
- If the button is held for 5 seconds make the route change
The DELAY Combiner has an input value and an output value. Changes only get passed to the output Translator when the Combiner’s output value changes. And the delay is only analyzed for countdown when the Combiner’s input value changes. For this example, we would set the DELAY Combiner parameters as follows:
- If the user presses the button, the input value gets set to True based on the inbound translation:
- The timer starts counting
- If the user releases the button before the timer elapses, the input value of the Combiner gets set to False. Since this matches the cancel value, the delay timer stops counting
- If the user does not release the button for 5 seconds, then the True value gets passed to the Combiner output which is being monitored by the output Translator:
- A route change is made
- Since the Clear Value and Clear Output after countdown completes options are set, the output value of the Combiner is then set to False again so it is ready for the next button press
- When the user releases the button, the Combiner input is set to False but since that is the Cancel field no change to the Combiner output is made
Without the Clear Value and Clear Output after countdown completes options, the output of the Combiner would remain True and so the next press would not change the output and therefore would not trigger another route.
If we cleared the Cancel value and did not use the Clear options, releasing the button would pass False to the output but 5 seconds after the button was released. It is important to note that a Cancel value if set will cancel the countdown, but the Cancel value does not get passed through.
These parameters will allow you to produce differing effects using the DELAY Combiner depending on the required goal.
By adding Combiners and Translators you can make any individual Flow as deep as you need it to be.
This example is not created to do anything specific; it is just shown to illustrate that you can theoretically continue to add Translators and Combiners as needed to get the logical job done. Translators and Combiners must alternate. You cannot have a Combiner next to a Combiner or a Translator next to a Translator, but the user interface helps with that by only enabling the controls you can use depending on which logic block you currently have selected.
Another relevant example is EAS. This is a pretty common EAS Flow that we see customers make:
Important Note: if you are going to use a Flow like this, it is critically important that you also turn on the Skip startup state request and wait for next change option. See the Advanced Options section on this option.
Without enabling this option, a restart of the system will request the current GPI state which is High and will therefore toggle the Previous route. In many cases this will route “nothing” to the air chain because no previous state exists yet.
However, even with that option enabled this Flow may produce unforeseen results. For example, what happens if the GPI goes Low and someone manually changes the route before it goes High again? At that point EAS is now the previous source when it does go High. This can be solved by using a slightly more complex Flow and Previous:
In this example, a route to Previous will only happen if the GPI is High and we are currently on the EAS source. This will function in a much more reliable manner.
While these examples have been EAS related the same rules apply to other uses of previous. More importantly, if you can avoid the use of Previous and design the Flows to be more specific, the outcome will also be more reliably specific.
If you select the End Point of a Flow, you will notice that the right Translator control in the control panel is available and not disabled. This is what is referred to as "extending a Flow". You can create a second Flow whose Start Point is the same as the End Point of the previous Flow.
If we go back to this example Flow:
Click on the End Point and then click the End Point control in the tool bar.
Our Flow now looks something like this:
In this case, the second Flow is joined to the first Flow because the Start and End properties are the same. Likewise, if we had added a second Flow using the + button and then set the Start Point to the DST 2 destination’s CurrentSourcePath, after we applied the change, the system would detect that the Flows should be joined and join them.
In this example we could now set the indicator of a button at the End Point of the second Flow:
What we have designed is a Flow where if you hold GPI buttons 1 and 2 down, PC4 source will be routed to PC4 destination. And if PC 4 source is routed to PC4 destination then LCD button 1’s indicator will be turned on. If anything else is routed to that destination then the Indicator will be off.
The system is intelligent enough to recognize when Flows should be joined into a single logical entity.
Cut, Copy, and Paste are standard tools and require little explanation. You can select a Flow by clicking in the area surrounding a Flow at which point the cut and copy icons become available. "Cut" will remove the Flow from the View and place it on the clipboard while "copy" will just make a copy of it on the clipboard. Once a Flow exists on the clipboard it can be pasted back into the current View or any other View.
The system does make some assumptions regarding pasting. If you copy a Flow and paste it back into the same View, the system assumes you are trying to duplicate the functionality with a new set of End Points. It will clear the outer Start and End Points of the pasted Flow so you can select new ones.
It is important to reiterate that none of the changes involved in a cut/copy/paste operation ever become a reality on the system until you click the Apply button, and that clicking the Cancel button will return to the last known applied state.
Each Flow can be assigned a title. If you double-click in the whitespace surrounding a Flow, the system will ask you for a title for the Flow. Click Apply to apply the title. Flows that have titles will display the titling text underneath the Flow.
Titling is a very important habit to form as it makes it much easier to glance at a Logic Flow View and understand the states of the Flows and which Flows are performing which functions. Additionally, it is useful as an organizational tool as Flows with titles will be displayed alphabetically within the View. Otherwise the Flow order within the View is somewhat arbitrary.
Translators, Combiners, and entire Flows may be enabled or disabled. Select the Translator, Combiner, or entire Flow (by clicking in the whitespace within the Flow), and then use the disable/enable button on the control panel.
This change is the only one that takes place immediately within Pathfinder Core PRO Logic Flows without the need to click Apply. The object will become greyed out and that particular object will no longer function, stopping the Logic Flow at that point. For example:
If you trigger the GPIs, their states will change within the attached Translators, but the End Point in the first half of the Flow will not change because the Combiner is disabled. This is a useful tool if you are testing logic up to a point but do not want the End Point (which might be an air chain change) to change. It is also useful if you want to temporarily disable a Flow during testing or troubleshooting.
If your system is clustered and you are Viewing Logic Flows on the secondary system, you may see a lighter gray form of disabling:
Also with clustering the upper right corner will show an Event System state:
In this case you are being shown that the final output will not actually execute on this server because the other server is currently in control of the event system. On that server, you will see:
And in the right corner:
Important Note: The event system is never actually turned off in Pathfinder Core PRO. When a Logic Flow needs to make a change to an End Point, it first checks to see if it has the lowest IP address of the currently active and online servers in the cluster. If so then it executes the action. If not, then it does not.
The Event System True or False will be hidden on systems that are not in a cluster because in that case the Logic Flow End Points will not be disabled by the clustering system.
You may notice when editing the Start or End Point of a Flow that if you select an object in the property selection tree (arrow icon) instead of a property (green dot icon), you will get a warning message that looks like:
Object translations are a slightly more advanced subject and should be used with caution (hence the warning), but they can also be extremely powerful. Object translations will most likely be used in situations where you want to mirror several different property states across a couple of objects. We could create a Translator Logic Flow where the Start Point is a VMIX sub mixer on Engine 1 and the End Point is a different VMIX sub mixer on a different engine:
This Translator looks slightly different in that the Start and End Points only have two pieces of information rather than the usual three.
If we do not alter the translation pattern from the default *=*, every change to every property of every sub-object under the sub mixer 1 will get mirrored to the equivalent object and property under sub mixer 2. For example, if sub mixer 1, channel 1 gets turned On, then sub mixer 2, channel 1 would also be turned On. If sub mixer 1, channel 3 has its TimeDown property changed, then sub mixer 2, channel 3 will also get its TimeDown property changed. This allows us to mirror an object’s settings.
When you edit the translation list and select an object translation, there are additional drop‑downs that allow us to specify the object’s properties as well as its values. For example, we could change the translation pattern from *=* to:
In this case, we are specifying that we only want this translation to operate on State properties. If sub mixer 1, channel 4’s State property gets turned on, so would sub mixer 2, channel 4’s state property. Other properties would not be affected.
Or, we could apply values such as:
This allows us to invert the states on the second sub mixer. Now when sub mixer 1, channel 5’s State property gets turned on, sub mixer 2 channel 5’s State property gets turned off and vice versa.
Another useful way to use Object Translators is when you want to set multiple properties on an object. For example:
In this case the Start Point is a normal property but the End Point is an object selection. If we click on the translation properties we can make the configuration look like this:
In this case, we are setting two different properties on the button each time the GPIO pin state changes High or Low. This can simplify the Flows and greatly reduce the licensing counts used when there are many button states that need to be set.
Object translation is extremely powerful in situations where you want to match multiple properties across two similar objects or multiple properties on a single object.
It is common to need a button to latch, where each press of the button will toggle something back and forth. Using the kind of logic shown above to accomplish this can get complicated because the state becomes a condition which is also an action. For example, many novice Pathfinder Core PRO users may try to create a Flow that looks like this:
Warning: Do not use this Flow. This is an example of what NOT to do!
The goal of this Flow is that each time a GPI goes Low, the user wants to toggle the on state of the fader back and forth between on and off.
The user has tried to create a Flow where if the GPI is Low and the button is on, it turns off, and if the GPI is Low and the button is off, then it turns on. The problem is that this creates a loop that lasts as long as the GPI is Low.
Setting the GPI to Low changes the state of the console channel which in turn causes the second half of the Flow to change it again and so on until the GPI is returned to High. This leads to interesting and convoluted loops resulting from trying to solve what on the surface appears to be a simple problem. To avoid this scenario, we have crafted two much simpler approaches to latching in Pathfinder Core PRO.
Many of the properties that have two states (On/Off, Low/High, etc.) also have a value that you can set called Swap. For example:
In this case, each time the button is pressed, the button state will be swapped (On to Off or Off to On).
If a Swap value is available, it is always preferable to other options.
To achieve similar behaviors for properties that do not have the Swap value, you can use the Latching Memory Slot. While basic memory slots can be created using the Logic Flows property tree as a shortcut, there are additional types that can only be created from the memory slots page as outlined in the Memory Slots chapter.
To create latching functionality, go to the memory slots link in the Navigation Bar and add a new memory slot using the plus icon. In the resulting dialog, switch the memory slot type to “Latching Memory Slot”. Provide a name for the slot and click Apply to create the slot.
The Latching memory slot can only have a value of True or False. For example, in Logic Flows we could now add a Flow such that whenever a button is pressed on the console, the Translator sets the trigger property to True:
It also has a property called "Trigger" which is write-only and cannot be read. Whenever you apply a True value to it, it automatically switches the SlotValue property of the memory slot from True or False to the opposite state. This simple Logic Flow will cause the latching memory slot to switch its value back and forth every time button 10 is pressed.
Next, we can create a second Logic Flow that defines what we want to happen depending on whether the Latching memory slot is True or False. For example:
Now the button will cause the latching memory slot to switch back and forth between True and False. If the slot’s value is True source sa_server_05, it will be routed to Destination sa_server_04. If the slot value is False, then whatever the previous source contains will be routed back to Destination sa_server_04.
It is important to reiterate that Swap is preferable where it is available. For example:
In this case, the Trigger property causes the latching memory slot to Swap between True and False each time the GPI goes Low, and then that True or False is translated to the on/off state of the fader. Engaging the GPIO repeatedly will cause the fader to turn on and off. The problem with this Flow is that the fader can also be turned on and off with the actual console button which causes the latching memory slot to get out of sync with the fader state. This could be solved with a third Flow if we allowed you to force the state of the memory slot each time the fader state changed, but this requires numerous Flows and the creation of a memory slot for every instance of this functionality. This approach feels too complicated to accomplish what should be a simple task.
The Swap value makes this much simpler and is all that is needed to solve this problem:
Each time the GPI goes Low, a value of Swap is sent to the fader. The device manager picks up this request, checks to see whether the fader is currently on or off, and sends the opposite state as a command to the equipment. The problem with the earlier Flows is that the Flow logic had to encapsulate all viable options of the existing state and specifically request what state to move to accordingly. The Swap property removes that complexity from the Flow logic and allows the system to handle it for you.
It is important to note that the Swap value is an action and so will only appear in the translation options for an End Point. It has no meaning for a Start Point because placed there, there it is not an actual state accordingly will not appear in the options on a Start Point. The user interface will present the option only where it is available. For example:
Important Note: Axia LCD buttons and user button indicators represent a special case in that they have more than two options including On, Off, Flash, Wink, and a variety of other flashing states. However, we chose to add a Swap value to this property because On and Off are the states that are most often used. If a button indicator is Off and the Swap value is sent, it will turn the indicator on. If it is in any other state when the Swap value is sent, the indicator will be turned off.
Detected devices identified as Infinity products have a SendToRestAPI property which can be used by Logic Flows to address the Infinity Rest API. The format of the commands addressed to this property should be as follows:
Operator Path Value
PUT /api/s/main/audio/speakerMute True
Note that Gets have not yet been implemented as we do not want to encourage polling logic. It is also important to know whether or not the value being sent needs to be wrapped in quotes.
Contact Telos support for details on properties that may be manipulated using the Infinity Rest API.
Dialing and status items are exposed in the Logic Flows simple tree under the Z/Ip One branch.
When viewing a Start Point there are several options:
It is important to understand the difference between Call#0 > State and ConnectionState. Call#0 > State lists all possible connection statuses including multiple options for Idle and options for how the connection was established. ConnectionState offers only Idle, Connecting, and Connected options making it suitable for situations where logic needs to be fired based on the connection being active or disconnected.
The ConnectedTo property will contain the phone book entry matching the one selected in the Call Connect property allowing you to display the current call connection phonebook entry name.
Important Note: In addition to these properties, the API tree contains a much larger set of properties matching those from the Z/Ip One Lwcp API. Consult the Z/Ip One documentation for details on these other properties.
When selecting an End Point in the Simple tree, the Z/Ip One branch includes several properties for any Z/Ip One in the system:
Connect and Drop can be used to establish and drop connections. After selecting the Connect property as a Logic Flow End Point, the translation list will display the list of entries in the Z/Ip One phone book. Currently, only phone book entries may be used for dialing:
Important Note: In general, the Codec settings will not be used as an End Point since those settings are normally stored within the call phone book entries.
There is also a special phonebook entry that only lives in Pathfinder Core PRO called None which, when dialed, will behave the same as the Drop item.
This Flow will dial the Z/Ip One every time Fader 1 is turned on and drop the call every time it is turned off.
The iPort branch in the simple tree exposes the Encoder and Decoder Enable and Disable options. We have limited those options to the simple tree as most other properties related to the iPort MPEG side of the configuration are considered advanced and are not normally dynamically adjusted.
Most of the other settings found on the Configuration pages of the iPort are available via the API.
Some additional explanation is needed regarding the VX and its control protocol. This protocol allows Pathfinder Core PRO logic flows and user panel controls to monitor and change Vx calls in a studio. Control points such as lines, studios, call states, comments, and call actions are available to be used by Pathfinder Core PRO via this protocol.
It is important to understand that when you connect to a VX engine on the control port, you have to select which studio to interact with. As a result, if you want to monitor multiple VX engine studios in Pathfinder Core PRO at the same time, a separate TCP connection is required for each studio. Rather than enabling this by default when many customers may not need this functionality, we decided to allow the administrator to enable the studios they wish PathfinderCore PRO to interact with and leave the others disconnected. This conserves resources.
To begin using the VX Control protocol, go to the Logic Flows tab and select a logic flow view. Add a flow and double click on the end point. Within the tree you will see a new branch called VxEngine Call Control.
Clicking on the [Add Studio] branch will bring up a dialog where you can select which studios you want Pathfinder Core PRO to use and monitor.
Select the VxEngine whose studios you wish to enable from the drop down and then enable the check boxes for the studios you wish to have available. You need to click apply for each engine whose studios you enable or disable. If you have changed the Lwcp password in the VxEngine, you need to supply the correct password in this dialog as well. If you change the password after adding the studios into PathfinderCore PRO, come back to this dialog, deselect the studios and apply and then reselect them using the new password and apply again. This is not a dialog that is specific to this instance of logic flow editing. You are adding or removing that studio support from the system and so it is generally a one-time change, and does require some cpu resources while adding or removing the studio. We decided to place this dialog within logic flow because that will be where customers will most frequently be interacting with the VX Control protocol data points.
Once added, the studio and property items will then be available in logic flows under the specified engine:
Warning: If you add new studios to an engine, you need to collapse and re-expand the engine branch to see the new studio. Also if you uncheck (remove) a studio, you may need to refresh the logic flows web page before it is removed from the property tree. Removing (unchecking) a studio removes it from Pathfinder’s control and monitoring entirely which may affect any other flows that use that studio.
As an example as to how this might be used, you could cause a gpio to light an indicator whenever a given line rings. To accomplish this, you would create a flow where the start point is the line’s callstate property and the endpoint is a gpio.
The flow would look like:
For the translation you would create something like:
Additional flows could be added to trip other gpio pins for different lines.
It is important to note that the properties will differ significantly depending on whether you are selecting a start or end point. There are numerous properties that are “read only” or “write only” and so will only display in either the start or end point editing. Selecting a property in the logic flows tree will also display a brief description as to what the property does.
You can also use these properties in user panels. So for example, you could use a label object and bind the label’s background color to the line call state and the textContent to the caller_id field. A button could then be used to answer and drop the calls. One of our support engineers crafted the following using the html 5 user panel designer during our initial testing.
This uses a large label where the call state is bound to the background color, and smaller transparent labels on top of that are bound to the caller_id, comment, and time properties. An image was also overlaid that swaps between multiple images to represent call state. Finally, additional buttons were added for the additional call actions such as seize, drop, hold, etc. Using these items you can develop a user interface to your liking that works with the vx phone system. This also allows you to create a user interface that mixes console fader control, call control, and other user interface items to achieve your specific needs.
Below find a list of the commonly used properties. Additional properties may be available that are not included in this list, so review the logic flow tree and property descriptions within the tree. Items in this table that are marked as true only in the syntax are write only actions where setting the property to true is a momentary state that triggers the action.