This section provides documentation on new features included in the 1.9 beta version as it is being developed. It is broken down by software version and provides the documentation required to use the new beta features. When 1.9 turns into a new release, the documentation below will be merged into the rest of the manual above.

To obtain beta software update packages, visit http://pathfinderpc.com/betaDownloadsCorePro.htm

Log Changes

This version adds a number of new log writer option checkboxes which may be enabled.

These new items allow generic emulator messages to be separately logged from Probel messages which tend to generate much more content.

Note that the auditing log entries will also include the source IP of the request as well as the name of the authenticated user. Also, AuditGet will generate much more data than AuditSet. If you are primarily concerned with tracking when users make changes AuditSet should be sufficient. For a comprehensive security audit logging configuration, some additional items should also be enabled including: AccessViolations, LoginFailures, and LoginSuccesses. Additionally, if Probel is used, enabling ProbelEmulatorsRouteChangeRequestReceived will track route change requests from Probel emulators.

Custom Log Messages

This version also adds the ability to generate your own log message subscriptions:

Clicking the new Add Custom button will open a dialog for generating your own log entry.

This dialog allows you to create a new log entry. The log entry is made up of a log entry name, and id which must be between 80001 and 99999, a severity, and a valid SapV2 subscription message. The subscription message allows you to define specific system changes that will generate this log message. This allows you to create a custom log entry to a specific device, panel, or specific properties which might not be exposed in the default options.

Once added it will be presented as a checked item under the new Custom group in the log items checkbox tree. Note that unchecking a custom item will delete it after selecting apply and so it will have to be recreated if you want to add it to the log writer again.

Logic Flow Hover Balloon Changes

This version adds the first 8 characters of the GUID that identifies a translator or combiner to the bottom of the hover balloon in the Logic Flows user interface. This makes it easier to equate the graphical element to the API and/or backup files.

Recursion Detection Disable

After double clicking on a translator in Logic Flows and clicking the Advanced link, you will now see an additional checkbox called Disable Recursion Detection. Turning this checkbox on will generate a warning for confirmation and then will bypass the recursion detection settings on that translator.

This option should rarely if ever be used. It is removing a protection. In most cases if your flow is being disabled due to the recursion detection system, it means there is flawed logic that is executing in a loop. Without the recursion detection such a loop could cause the CPU to spike to 100% and cause significant sluggishness or lockups. This is what recursion detection strives to prevent. However, in certain rare situations, many highspeed changes may be normal and not a sign of a loop. For example if the start point is a fader gain setting, moving the fader can cause lots of data which can create a false positive in the recursion detection. In these cases it is usually better to alter the detection settings to support the quantity of data you expect rather than to disable the detection. But in certain cases it may still be desirable to disable it completely for a translator and this option allows that.

Disabling recursion detection is only available in logic flows at this point in time. It is not available in the user panel generated flows or within SapPropertyRouter translations. See more on this subject below.

Sap Property Router Changes

Recursion detection within a SapProperty router has been modified such that it is disabled at the router level, but still happens at the source and destination level. This to prevent a problem where occasionally the router level translation was being disabled by recursion detection when large numbers of route changes were taking place at the same time (such as scene changes) or where many sources were receiving signal values at the same time. Instead recursion will be detected at the source or destination and passed through the central router level regardless of frequency. If you have values that are not transitioning through an active route in a SapProperty router, it is worth checking whether the source, destination, or router translation has been disabled by the recursion detector and if so adjust the recursion settings.

Restoring Backup Changes

This version adds some additional options when restoring a backup file to a PathfinderCore PRO system. After clicking the restore link on the backup file, the revised dialog will look like this:

By default, all options will be set to true. This means the backup file will be restored exactly as is. This will be the usual scenario and matches what restoring a backup file has accomplished previously. However, there are situations especially with systems integrators where it can be useful to bring a customer's configuration into your lab system without altering settings like security, make changes and then apply them back to the customer's system without changing some settings on the customer's system. These options help with that.

A good example is LDAP settings in the security section. If the customer is using LDAP as their login mechanism, working on the configuration away from the customer's LDAP servers will deny logins. So it can be useful to restore in both directions without affecting the security settings on either system.

The options are described below:

Restore Ips

Setting this option to false will cause the following settings to get skipped during the restore process leaving them as they are currently set on the system:

• Hosts

• Aoip and Office IP address settings

• Hostname

• DNS Settings

Restore Foating Ips

If this option is set to False, floating IPs will not be restored from the backup file and the existing floating IPs (if any) will be used.

Restore Security

Setting this option to False will skip restoring the files that are used by the Security section of the navigation bar. Additionally this will skip restoring other user specific settings. The items that will be skipped include:

• Custom User Menus

• User Password file

• User access rights database

• http/https settings

• SapV2 Raw and TLS settings

• Metering Internal/External Settings

• Ssh Settings

• Authentication settings

Restore Clustering

Setting this option to false will skip restoring the clustering data and clustering password. This can be useful if you need to design on a stand alone system, but restore to a clustered one. It is important to note that both nodes of the cluster need to be restored from the restore file.

Restore Email Settings

Setting this option to false will skip restoring the main email settings. This can be particularly useful to support so that if they load a customer's system without devices attached, it will not start trying to send failure state emails. It is also recommended to isolate the system so that it does not have access to the internet in that case.

Restore Time Settings

Setting this option to false will skip restoring the time zone and NTP settings leaving them as they are in the system instead of replacing these settings with the ones from the backup file.

Send route changes to disabled destination base ios

This version adds an option to Virtual Routers under the advanced button. Navigate to the virtual router details, click the points tab and then click the Advanced button.

By default if a base IO within a virtual router destination package is disabled, route changes are still sent to that base io if the virtual destination's source is changed. This is intentional. The use case described in the manual describes a situation where you wish to take an engine offline for maintenance and still want the routes for that Engine's base io to appear to work as long as the other base ios route successfully even though the device is offline. In that case it does not hurt to also send to the offline engine for the periods of time when it is online during the maintenance session. However, there may be times when you essentially want to fix the base io destination to a source and ignore other route change requests to it. In this case, disabling the base io and setting the "Send route changes to disabled destination base ios" option off may be appropriate. In that case when a new virtual source package is applied to the destination, base io sources that would normally be applied to that disabled base destination will be skipped. Then when the destination base io is reenabled, the current source base ios will either be sent or left in their current state depending on the Push current source (route) on base io enabled option.

Virtual Router Enabled/Disabled logic changes

In previous versions, disabling a base io in a virtual router destination package would conceptually remove the destination from the package for the period of time when it is disabled. This actually caused problems in situations where the destination package contained multiple ios from the same router. For example:

In the example above if each source from source A's package is routed to the corresponding destination in Destination B's package then the system would consider Source A to be routed to Destination B. Now if we disable the SapProperty10 base io the packages end up looking like:

So now Source A would only be considered routed to Destination B if SapProperty 1 were routed to SapProperty 11 instead of 10. Therefore if prior to disabling anything Source A was successfully routed to Destination B, if you disable the SapProperty 10 destination, the source assignment would switch to other. There is no route in the router that expects SapProperty 1 to be routed to SapProperty11 as a base io. This does not happen if the base ios are from different routers because the packages get organized by router type.

To fix this issue we no longer conceptually remove the base io when it is disabled. Instead we accept any route state as valid to that disabled destination (including None). This effectively allows the destination to show as routed no matter what base io source is routed to that disabled base io, while still allowing the proper alignment of other base ios in the package.

This creates the desired behavior, but it is a fundamental shift from how this feature worked previously so please report any issues you may encounter.

Note that the descriptions above refer to the logic that decides the current route state. When executing a route change with disabled destinations, a route is either sent to the disabled destination or not based on the "Send route changes to disabled destination base ios" option.

Use case examples

In the original example described in the manual, a source is duplicated in the source package and the destination package contains destinations from 2 different mix engines for redundancy. In this case if you want to take an engine out of service, disable the base io in the destination package for the engine and leave both checkboxes in the Advanced section enabled. This will attempt to send route changes to the disabled engine but accept that they may not be successful. Then when the engine is back online and you re-enable the base io, the current source base ios will get sent to the engine to bring it back to the correct value.

On the other hand if the intent is to create a patch around situation where you are basically temporarily assigning a different io to the base io but you want the logic to pretend the normal source is assigned, it is better to uncheck the "Send route changes to disabled destination base ios option". This will allow you to make route changes while leaving that base destination in a fixed state.

Future Changes

Currently, the system allows you to disable base points in the source package as well as the destination package, but that is rarely useful and so may be hidden or removed in a future version. If you find use cases for this ability, please report them so we can take them into consideration.

Additionally, because the virtual mixing router is based under the hood on a virtual router, the base io enable/disable features are currently exposed and exist in the virtual mixing router but may not work as expected. Again, we are not seeing much of a use case for this capability in Virtual Mixing routers. If you find use cases to the contrary, please let us know. Otherwise we will likely remove or hide those options in a future version.

Quasar Aux Return 1/2

This version adds support for the Quasar Aux returns. This requires Quasar software version 2.1.0 or later to work. Each of the two aux returns provides the following read/write properties which accept values of ON, OFF, or swap:

• ON_State: Whether the aux buss return in on or off

• Asg_PGM1: Whether the aux buss return is assigned to Program Buss 1

• Asg_PGM2: Whether the aux buss return is assigned to Program Buss 2

• Asg_PGM3: Whether the aux buss return is assigned to Program Buss 3

• Asg_PGM4: Whether the aux buss return is assigned to Program Buss 4

Lwch/Fach READY_State and Fader_State

This version adds the READY_State and Fader_State properties to the Lwch and Fach objects. These properties are read only on Element, Fusion, and Quasar consoles.

• READY_State: Whether the fader's ready state is off or on

• Fader_State: Whether the fader is up or down

Aes67 Multicast Range Addition

This version allows you to add a range of multicast aes67 addresses rather than having to add each one at a time. From the Axia Audio Router Points tab, select the Add Aes67 Source. Then for the Type, select Multicast. The Multicast IP field will now have a second field indicating the number of ios you wish to add:

By default x1 will be selected indicating only one new source will be added. This behaves the way previous versions do. Changing the x parameter to a larger number (say 255), will loop though that many ios incrementing the multicast ip and adding an underscore and number to the source name, adding them into the router.

Calendar Url option for calendar only display

For customers using the scheduling license, if you want to display a scheduling calendar without the rest of the Pathfinder header and navigation bar, this can now be accomplished by adding a parameter to the url. The parameter is nonavnohead and should be placed after the ? in the url followed by an ampersand. For example:

http://172.16.250.201/admin-timers-calendar.php?nonavnohead&calendarName=MyCalendar

This can also be used with the iframe widget in panels to embed the scheduling calendar into a panel. However, this should be considered a short term solution as in future releases we hope to add a scheduling calendar widget which will be more flexible.

Axia Gpio Destination CurrentChannelNumber

This version adds a CurrentChannelNumber property to Axia Gpio Destinations. This may be used to set or react to multicast livewire channel number assignments on gpio router destinations. It is important to note that if the destination is being used in snake mode (normal axia gpio routing), this value will be zero. Additionally using a channel number of 0 will clear the gpio routing in the same way as clearing it in the router would do. Also destinations that have a channel number will show a cleared route in the Axia Gpio router since that router works exclusively with snake mode. This can be used to more easily change the channel number associated with a gpio when multicast gpios are in use.

Virtual Router Base Io disabled property override

This version adds the ability to override the virtual router's advanced options in each base IO if necessary. Virtual Routers include two advanced options:

• Push current source (route) on base io enable - will push the current route state to disabled base ios when they become re-enabled.

• Send route changed to disabled destination base ios - will send route changes to disabled base ios if this option is enabled

These two options now also exist on each virtual router's destination base io. By default the parameters on each base IO will be set to Follow which means they will use the overall route advanced settings. But they can be overridden to create different behavior on individual base IOs. This is accomplished either via logic flows or via a new link in the UI. When editing a virtual destination, there is now an edit link for each destination:

Clicking the link will open a dialog where these options can be overridden. The new dialog also presents on option for toggling the base IO disabled state via the UI:

Overriding the router advanced option can be accomplished by changing either of the two options from Follow to the desired enabled or disabled setting. Remember these settings only affect the functionality when the base IO is disabled or returning from disabled to enabled.

As a refresher to the functionality, a disabled base IO will not be considered when evaluating whether a route is active. If the SendRouteToDisabledBaseIO option is enabled, route changes will still be sent to a disabled base IO. If it is disabled, then those changes will not be sent. If the PushRouteChangeOnEnabled option is enabled, the current route value will be sent to the base IO when it becomes re-enabled.

Example Use Case:

The customer has built a virtual router where each source and destination has multiple layers. A primary and backup audio IO, and a primary and backup metadata IO from a SapProperty signaling router. In this case they do not want a failure of the metadata layer to cause the route state to not be indicated to controlling automation. But they do want to be able to take one of the audio layers offline for maintenance or special situations (like EAS). In this case, the customer can set the router advanced options to:

• PushRouteChangeOnEnabled: Enabled

• SendRouteToDisabledBaseIo: Disabled

And on the individual destination base IO layers they set:

• Disabled: True

• PushRouteChangeOnEnabled: Enabled

• SendRouteToDisabledBaseIo: Enabled

In this example the metadata IOs are always disabled, but will still receive route changes. This means they will not be considered toward the success state of the audio route, but will be changed anyway. The audio layers are set to the default Follow so will follow the router settings. Therefore an audio layer can be disabled and switched away to something else, and route changes will not affect it, but it will get updated to the correct state when returned. It is important to note that for the PushRouteChangeOnEnabled to work and/or for routes to actually have a route state, at least one layer must be enabled. A SapProperty router can be used as an additional layer that is never disabled to maintain state if needed.

Audio Alarm disable

This version adds the ability to disable an audio alarm. In order for downstream logic to maintain its state, disabling an alarm involves fixing it to a specific state regardless of the underlying audio. Therefore the disable options are:

• Enabled: Alarm is enabled and works normally based on the audio changes.

• AudioPresent: The alarm state is fixed to the audio present state regardless of the underlying audio changes

• Silent: The alarm state is fixed to the silent state regardless of the underlying audio changes

• Clipping: The alarm state is fixed to the clipping state regardless of the underlying audio changes

In addition to manipulating these states using logic flows, the state is now represented in the audio alarms grid and may be manipulated by editing the alarm:

Clicking the edit link also now has an Enabled drop down in the alarm editor.

Scene logging

An additional section has been added to log writer editing for logging scene changes:

Each of the items in the scene section will log changes as described below:

• ActivateSceneRequested - logs when a scene activation is requested.

• ItemsAreActive - logs each scene item's active state.

• ItemsCurrentValue - logs changes to each scene item's current value.

• SceneIsActive - logs whether the entire scene is active

• SceneState - logs the scene state (Some, None, All, etc.)

Javascript updates

This version includes updates to all Javascript libraries for security and performance issues. These changes required some recrafting of the code on a number of the web pages. As a result this should be considered a major change. Please report any issues you encounter so we may address them promptly.

Clock Updates

This version adds additional features to analog and digital clocks in user panels. It adds the ability to select the clock source and time zone, as well as a number of styling properties for the analog clock when used in the classic style. Additionally digital clocks now have a time-format property for adjusting what is displayed. These changes are described in more detail below.

Clock-Source and Clock-Timezone

The Analog and Digital clocks in user panels now include a clock-source and clock timezone property under the style section:

The clock-source property allows you define whether the clock gets its time from Pathfinder or from the local PC clock. The time-zone property allows you to select a time zone and display the source time adjusted for the specified time zone. By default a new clock will have its clock-source set to Pathfinder and its clock-timezone set to source. Source is a special entry that displays the time as it is presented to the application with no adjustments.

Digital Clock time-format property

Digital clocks now have a time-format property for adjusting the presentation of the current day/time. Setting the format to default will display hours, minutes, and seconds the way it always has. The structure for formatting this display differently is based on Unicode date/field symbol options found here: https://www.unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table

For example:

Quasar style changes

All of the Quasar-specific style options have been moved to a single section under style/quasar in the property grid. Previously there were some located under the background section and some under the font/text section. It made more sense to put them all under a single quasar section under style.

Default / Classic style properties

This version adds a number of properties for styling an analog clock when the clockstyle property is set to classic.

These new properties under the default (classic in the future) heading only affect the clock when it's style is set to classic.

The clock on the left is the default clock. The clock on the right has the following property changes from default:

• min-sec-markers: true

• circle-border: false

• second-hand-color: #fc0303

• 24-hour-numbers: true

• 24-hour-numbers-color: #eb0017

LDAP Multiple Base DN Options

Sometimes it may be necessary when using LDAP authentication to query several different base domain name groups for a user. Note that it is preferable to find a base point that is common to both and issue one search instead of multiple, but in cases where this is necessary you can now specify multiple search paths by using the pipe character (|). For example:

The first option will only query the Users group. In the second case, the users group will be queried first and if no match is found, the Security Objects organizational unit will be queried.

Adding many base paths is not recommended as multiple queries can slow down the login process. Note that this pipe option only works for the X-Ldap-BaseDN field.

IP Address White Lists

This version adds the ability to white list ranges of IP Addresses. Attempts to access the system from the specified IP address will bypass the normal login process and use the user permissions assigned to the white list entry for permissions. While the choice to configure and use this option degrades security somewhat (IP addresses can be spoofed), it allows systems which may not usually have a keyboard attached to reconnect without requiring a login. To add a whitelist entry, click on the users tab and then click on the IP Address White List link.

Click the + icon to add a new whitelist entry or the return to Users link to exit the white list configuration page.

Calendar Resource Display

Version 1.9.12.91 adds a user panel control for displaying upcoming events from a calendar resource. This control requires a scheduling license.

To use drag a Calendar Resource Display control onto the user form. To make it function you need to use the resource property to select a resource from which to display events. When executing the control will show a configurable number of upcoming events where the top one is usually what is currently executing. The following styling properties are unique to this control:

Pulse and PulseValue Properties

The version adds two new properties to SapPropertyRouter sources and destinations. One is called Pulse and the other is called PulseValue. Both are write only properties. The Pulse property resubmits whatever the current value at the sap property source or destination through the router translations. For example, if the SapProperty source is assigned to a memory slot and the destination is the ToSend property of a device emulator, the current value from the memory slot at the source can be sent repeatedly by a timer if needed. The PulseValue replaces the current value at the property source or destination with whatever value you choose momentarily, and then immediately flips it back to the original value. This can be useful to retrigger logic and/or to resend commands through the sap property router.

Additional Gain Properties (InDb)

Gain in Axia equipment is sometimes expressed in a decimal format (-10.1), and sometimes in an integer format that still represents tenths of a dB (-101). For example the Fader_Gain property represents -10.1dB via the value -10.1. But VMixers and nodes represent -10.1dB as -101. This version tries to bring those together by adding an additional property for each property that expresses the gain in integral tenths to a decimal format. So for example the Vmixer IN object now has both a GAIN property and a GainInDb property. The GainInDb property essentially divides the native Gain by ten on Get and Sub and multiplies a set value by ten when sent to the equipment. This can be useful in situations where you want one gain to match and/or control another gain. For example if you wanted to make a physical fader on a console control a vmix fader you would use a logic flow like:

If you were to use the GAIN property on the output instead of the GainInDb property, the value conversion would be off by a factor of ten. If the property does not have a corresponding parallel, it means that the property is already expressed in a decimal format. If you find one where that is not the case, please report it so we can address it.

Numeric Memory Slots

This version changes the backing variables being used in Numeric Memory Slots from integers to decimal. This allows decimal values (like 10.1) to be used in the slot value, increment, decrement, and range properties.

Virtual Gpio Node Advertisement

Some devices such as the Infinity Dashboard can only discover Gpio devices which participate in Livewire advertisement. This version adds the ability to advertise Pathfinder's internal virtual Gpio node.

By default when you first try to enable this, the Advertise IP will be grayed out and unavailable. In an effort to make advertisement work properly in a clustered environment, this feature can only be enabled using a floating IP. Review the documentation on Floating IPs to add one to the system. Once a floating IP exists, it may be selected from the drop down list. You must click update for the changes to take effect. Please note that you should decide either to use a floating IP or to use None. This is not designed to be switched back and forth. This option also switches the IP address used for snake routing and updates existing snake routes in the router to use the floating IP. That update may take 10 or 15 seconds, and it may take a bit longer for the GPIO routes in the GPIO router to be fully updated with the change. You should pick the option that best suits your environment and stick to it.

Regarding Clustering

It is worth reviewing how the Virtual Gpio node has behaved historically in a cluster which is also how it still behaves if None is selected in the Advertise IP dropdown. If None is selected, the primary server will use it's Livewire IP address for all snake routing assignments. In the case where the primary fails, the secondary will execute a function that switches all snake routes that were on the primary to use the secondary's Livewire IP address.

On the other hand, if you select a floating IP via the advertisement option, PathfinderCore PRO will do a one time switch of all snake routes that are using the host Livewire IP address to instead use the floating IP. Failovers then do not need to make any additional changes as the IP address will float to the other server.

Using this feature, advertisement dependent systems such as Infinity Dashboard should be able to discover the PathfinderCore PRO Virtual Gpio node as if it was any other Livewire Gpio device.

RotateSource Property

This version adds a write-only RotateSource property to VirtualRouter Destinations and SapPropertyRouter Destinations. The property accepts a comma delineated list of source numbers. This can be used to rotate through a number of sources on a button push and/or to switch between two sources (for example a source and a cleared route) on each button press. For example:

In this example, the mousedown event of a button is used. And so each time the button is pressed (mousedown=true), the value 1,2,3 is sent to the destination's write-only RotateSource property. The logic that will take place under the hood is as follows:

• If the current source is none of the source numbers in the list (not 1, 2, or 3), then source 1 will be applied.

• If the source is currently source 1, then source 2 will be applied.

• If the source is currently source 2, then source 3 will be applied.

• If the source is currently source 3, then source 1 will be applied.

This can be useful for situations where you want to rotate thought multiple monitor channels. It can also be used when you want to switch between a route and a cleared route by using a value like: 2,0.

The RotateSource property is only applicable to VirtualRouter destinations and SapProperty router destinations.

Operating System

This version contains a complete update of the operating system including updates to the linux kernel, the system logging application, most of the underlying linux operating system packages, the web server, the shared web page application packages, and the framework under which the primary PathfinderCore PRO applications are compiled and executed. Please report any problems you might experience as this is a major update.

WebSocket ports

In previous versions of PathfinderCore PRO there was a separate web socket port for WebSocket communications between the webpages and SapV2 and the metering services. These are now all handled by the web server using port 80 (or port 443 if https is enabled).

First Start

You may encounter a cpu spike for the first couple of minutes on the first start after moving to this version. There is an encryption cypher that is used as a part of the TLS encryption that gets generated. This only occurs the first time you move to a version with these features. You should not enable https security options until this spike finishes. A future build may streamline this.

Security

This version introduces a new navigation bar item called Security. This section allows a system administer to manage SSL/TLS certificates, whether services are enabled and exposed to the outside world, whether their communications should be encrypted, as well as alternate authentication methods.

On Certificates

For customers wishing to encrypt browser and other communication traffic, the security section of Pathfinder Core PRO makes this possible. However, this encryption is based on certificates and a good understanding of certificate based encryption and the corresponding trust relationships are critical to making this work correctly. Throughout the security discussions below we will be discussing several different types of security certificates which may or may not be needed depending on which encryption options you choose to enable. These different types of certificates include:

• Self Signed Certificates: These are the default certificates created when enabling https. These present a public certificate to browsers attempting to connect to PathfinderCore PRO, and are used in the subsequent encryption of the traffic. However, since self signed certificates are not signed by a trusted authority, browsers will not by default trust the certificate and will therefore present a warning that you will have to click through in order to access the system's web pages. It is also possible to add a PathfinderCore PRO installation's self signed certificate to a browser's trust list, and that browser will from then on trust that PathfinderCore PRO installation.

• Publicly signed certificates: Pathfinder allows you to generate a certificate signing request which can be taken to a publicly trusted certificate authority such as Let's Encrypt to get a trusted certificate. This solves the browser warning issue. However, you can usually only get a publicly signed certificate if you are using public IP addresses. Therefore, if your PathfinderCore PRO is not accessible via a public DNS/IP address, then this option will not be available.

• Internally signed CA certificates: An option to the publicly signed certificate is to set up your own internal certificate authority. If you are in an Active Directory domain, you can add the certificate authority role to your Active Directory server. Then you can sign your certificates using the Microsoft CA and any computer in the network that trusts the Microsoft CA will also trust certificates signed by that CA. This allows you to use internal private IP addresses and DNS and still present certificates that the browsers in your network will trust.

• Root Certificates: These are certificates that Pathfinder trusts as authorities or just as trusted certificates. While the certificates above are presented to browsers trying to access PathfinderCore PRO, root certificates are used when Pathfinder tries to access other systems using encrypted traffic. For example, if PathfinderCore PRO tries to authenticate with an LDAP server using encrypted traffic, Pathfinder needs to trust the certificate presented by the LDAP server before the communication can take place. Also if encryption is added for clustering communications, all servers in the cluster must trust each other's public certificates. In the case of publicly signed certificates, PathfinderCore PRO includes the Mozilla public authorities. In the case of internal CAs, you need to add the public root certificate of that CA to Pathfinder's root CA list to trust certificates that CA signs. And lastly it is possible to simply add a self-signed certificate to the trusted list.

Much more will be presented in the sections below as we cover various encryption methods, but a good understanding of encryption and certificates is necessary to correctly enable and use some of these features. It is also important to note that certificates have a time limit built in, and so must be renewed periodically. The length of time a certificate is valid for depends on the certificate provider and the type of the certificate, but one to three years is usually the maximum. You can create much longer times with a self-signed certificate or by managing the options in a private certificate authority.

Web Server

The web server option allows you to switch between http and https. The https option will encrypt all traffic between the browser and PathfinderCore PRO. Enabling the https setting will forward any attempts to access the device using http to https instead.

https requires an ssl/tls certificate in order to function. By default there is an automatically generated self-signed certificate. Because self-signed certificates are not issued by a trusted authority, this means you will be presented with an insecure message from the browser.

Clicking on advanced and proceed link will let you get past the warning and allow access to the system while still using encryption for the data between the browser and PathfinderCore PRO. There are several alternatives for eliminating the browser warning. The first is to add the certificate as a trusted certificate to the browser on each system that needs to access that instance of PathfinderCore PRO. This may be simplified in an Active Directory domain by distributing it using a group policy. Alternatively, you can upload your own certificate into the system by clicking the manage certificates link.

Click on the Update link for the web server certificate.

This will display the current parameters of the certificate used for the web server. To generate a new one, click on the Request Cert button. This will present a view of the configuration file settings needed to generate a certificate request.

By default the settings will include the local IP addresses in the alt_names section. You will need to add any other DNS names or external IP addresses which will be used to access PathfinderCore PRO into the configuration. If you have been manipulating this data and wish to return it to a factory default setting, clicking the “Reset Csr Data To Default” to reset the data.

Click the Request Cert button in order to generate a signing request file based on these settings and PathfinderCore PRO’s private key.

After the request is generated you will be returned to the Current Certificate screen, but now the view Request and Fill Request buttons will be available. Click the View request to see the certificate request data that has been generated.

Copy this data into your certificate authority’s tools for generating a signed certificate.

Important notes for Microsoft CAs: If you are using an internal Microsoft certificate authority, each signing request requires an additional field which is not standard to most other signing requests. Specifically it requires you to define a template. To do this copy the certificate request into notepad, save it as a file like webserver.req and then move it to the Microsoft Server. Accessing the Pathfinder Core PRO web pages directly from the CA server may require installing a compatible browser on the server or loosening the browser restrictions to allow the web socket traffic. Or you can save the data using a windows 10 machine and move the files to and from the certificate server. Then open a command prompt on the Microsoft CA and type:

certreq -attrib "CertificateTemplate:WebServer"

This will launch Microsoft’s certificate signer using the WebServer template. The signer will ask you to select the certificate signing request file. It will then ask you to select the certificate authority to use for the signing.

Finally, it will then sign the file and ask you to store the signed certificate to a new file. For example you could save it as test.cer.

Whether you sign your request with a Microsoft Certificate Authority or some other CA, the final step is to click on the FillRequest button in PathfinderCore PRO, and paste the contents of the new certificate into the Signed Certificate Data field:

Clicking apply will then go through a process of validating and storing the certificate, restarting the web server and then returning to the security web page.

It is important to understand that using certificates signed by an authority other than an official public authority will still display as invalid in browsers unless that authority has been trusted on the corresponding machines. For example, if you sign the certificate using a Microsoft CA, it is assumed that you are also pushing the Microsoft root CA as a trusted root certificate to the client computers on your network.

The update web server certificate dialog also includes a Regen Self Signed button.

Clicking this button will issue a warning and then will remove any custom web server https certificate and generate a new self-signed certificate. Note that this will also generate a new private key for this certificate.

SapV2 Raw (9600)

This option defines whether the unencrypted SapV2 port 9600 is available externally or only within the box (internal). Since internally some inter-process communications use this, the port must be available internally. However, this option will prevent it from being accessed from outside the box.

SapV2 TLS (9602)

This option will enable a version of the SapV2 port that is encrypted using TLS encryption. The port will use the same certificate that is used by the https web server encryption. We can provide a tool we have created for interacting with the encrypted version of SapV2 in a similar way to how putty interacts with the unencrypted version. Please review the section below on security and clustering for details on how this setting affects clustering communications.

Metering (9501)

This option allows the metering to be exposed externally or internally. If it is exposed internally only, it will still work for any web browser user interfaces built in PathfinderCore PRO that display metering. This is because those interfaces connect to the web server which then connects internally to this port. This only needs to be exposed externally if you are using a third party application with the metering service.

SSH

This option allow you to turn on and off the ssh port. Typically this port is only used for support to get into the underlying operating system when troubleshooting a problem. Disabling this except when support needs it will tighten the security of the system somewhat by removing the open port.

Device Passwords

The device passwords option will retain the passwords used for logging in to devices, the email password, and the clustering password in symmetrically encrypted or unencrypted form in the server storage. It is important to understand that once the passwords have been encrypted, you cannot downgrade to an older version of the software that does not support this feature or restore a backup with the encrypted passwords to an older version of the software. If that is required you need to switch back to the decrypted form before downgrading. Changing this setting will kick off a function to encrypt and/or decrypt all instances of these passwords in the system.

Authentication

This option requires an optional External Authentication license. Beta testers may request a 90 day evaluation license for this feature. Once that license is installed on the system, this option will be available. It allows you to switch between using PathfinderCore PRO’s internal user list to authenticate users, and using an LDAP server to authenticate users. For example, enabling LDAP in an Active Directory server will allow you to use the users in your active directory domain as the login credentials to access PathfinderCore PRO. This allows a single point of user management rather than having to manage users in your Active Directory domain and your PathfinderCore PRO system.

It is critically important to understand how this feature works before trying to enable it or you may lock yourself out of the system. If that happens see the recovering from an authentication lockout section below.

After enabling LDAP, each login will send the username and password credentials to the LDAP server for authentication. If authentication is successful, Pathfinder will also request a list of the groups that the user is a member of. One of those groups must match a user security profile in PathfinderCore PRO for access to the system.

You can create a security profile in PathfinderCore PRO by adding a user with the name you will use for the group name in the LDAP server to Pathfinder. Then you configure that group's permissions in PathfinderCore PRO. While creating the user in Pathfinder you will have to add a password, but the password will not be used when in LDAP mode. For example, if your LDAP group name is PcpAdmin, then you need to create a PathfinderCore PRO user with the name PcpAdmin and configure the correct permissions for it. Then within Active Directory you can add users to the PcpAdmin group and when those users use their Active Directory user name and password to login to PathfinderCore PRO, they will have the rights of the PcpAdmin security user profile because they are a member of that group in Active Directory.

A user can pass correct credentials to LDAP, but not be a member of any group that is allowed to use PathfinderCore PRO and therefore be denied access. Therefore there are number of steps that should be taken before enabling LDAP authentication.

• Make sure that the url you will use for the LDAP server is resolvable by the DNS servers specified in PathfinderCore PRO. Usually for Active Directory, this means adding the Active Directory servers as DNS servers in the PathfinderCore PRO DNS section.

• Make sure you have created a group in the LDAP server that matches an Administrative user in PathfinderCore PRO.

  • For example, create a PcpAdmin user in PathfinderCore PRO that has Admin privileges and create a PcpAdmin group in an LDAP enabled Active Directory server. Warning: this is a case sensitive match.

• Make sure you have at least one user in the LDAP server assigned to the administrative group.

• If you are using Active Directory, make sure that LDAP is enabled on your Active Directory servers.

• If you wish the LDAP communications to be encrypted, you need to have a public certificate in the LDAP server or have an internal certificate authority and import the correct root certificate into PathfinderCore PRO so that PathfinderCore PRO will trust the internal CA's certificate. See more below on this.

If these steps are not taken it is likely that switching to LDAP will cause you to get locked out of the system.

To configure LDAP, use the Authentication drop down to display the LDAP configuration settings.

Enter the proper parameters for your LDAP server.

• X-Ldap-URL: comma delineated list of LDAP servers to try for authentication.

• X-Ldap_BaseDN: The point in the domain structure that will be used to search for users.

• X-Ldap-BindDN: The LDAP user that will be used to query the domain. It is highly recommended that this user have read only rights to the domain. It is the user that PathfinderCore PRO will use to access LDAP and authenticate other user credentials.

• X-Ldap-BindPass: The password for the BindDN user.

• X-Ldap-Starttls: Whether the LDAP communications should use TLS encryption which must be enabled on the LDAP server and have a proper certificate trust relationship configured.

The test button can be used to test your configuration options before applying them. Make sure you test before applying, as applying incorrect parameters can result in a lockout from the system. Generally we recommend getting LDAP working correctly without TLS encryption first, and then working through the TLS option. Clicking test will ask for a username and password which will then be passed to the LDAP authentication engine along with the entered parameters. A successful test means that the system was able to contact the LDAP server and use the bind paths and user to authenticate the user credentials supplied. It does not test for proper group membership. So a successful test can still result in a lockout if the authenticated user is not a member of a group that has a matching user profile in PathfinderCore PRO.

Once the test is working and you are sure that the users are a member of groups with matching security settings in the users section of PathfinderCore PRO, you can apply the changes. This will cause the system to present a new login screen which should then rely on LDAP user credentials for access to the system.

LDAP Urls

A comma delineated list may be used in the X-Ldap-URL section in order to try multiple LDAP servers. It is important to understand that the system will loop through the LDAP servers in order and attempt to bind to each one. If a bind is successful it will then try to authenticate a user. If the authentication fails, the system will not try the next server. The looping mechanism is only to achieve a successful bind. It is assumed that these are synchronized servers as far as the user data is concerned so a failed authentication on an active LDAP server equates to a failed authentication on all active LDAP servers. It is also important that each additional LDAP server connection that is tried adds delay to the authentication process. So it is preferable to make your most highly available server this first in the list.

LDAP and Starttls

If the Starttls option is set to true in the LDAP configuration, then the LDAP authentication engine will attempt to use a TLS encrypted path to access the LDAP server. In order for this to work, LDAPS (ssl/tls ldap) must be enabled in the LDAP server and a corresponding certificate must be in place. More importantly, the PathfinderCore PRO LDAP engine must trust the public certificate presented by the LDAP server. If your LDAP server has a publicly trusted certificate, this should happen naturally as PathfinderCore PRO includes the Mozilla trusted certificate root authorities. However, in many cases the LDAP server may be internal only and not have a trusted certificate. In this case it is recommended that the certificate be generated by an internal root authority and public certificate for that internal root be added to PathfinderCore PRO. For example, the following articles describe how to add a certificate authority role to an active directory server and set up a root certificate and LDAPS certificate in Active Directory.

https://pdhewaju.com.np/2016/04/08/installation-and-configuration-of-active-directory-certificate-services/

https://pdhewaju.com.np/2017/03/02/configuring-secure-ldap-connection-server-2016/

https://bl.ocks.org/magnetikonline/0ccdabfec58eb1929c997d22e7341e45

Once this is set up, you then need to export the public portion only of the root certificate and add it into PathfinderCore PRO. Click on the security nav bar link, click on the manage certificates link, and then use the add button (+) to add a new trusted root certificate.

Once the root certificate is added, any certificates the active directory server creates based on that root certificate will be trusted by PathfinderCore PRO. You can add additional root certificates or remove root certificates, but you cannot edit them. If editing is required, remove the old certificate and then add the new one.

Once the trust relationship is configured, you can enable TLS in the LDAP configuration and then use the test button again to verify it is configured correctly before applying the changes.

Troubleshooting the LDAP configuration

While trying to get LDAP working, it is often useful to get hints as to why the LDAP test might be failing. These hints can be obtained from the sai-ldap-auth log. Click on the logs nav bar link and then the system logs link to find that log. Remember that if the log is open in the browser you need to refresh it to see new messages.

Recovering From an Authentication Lockout

If you incorrectly configure authentication and get locked out of the box, the front panel menu system now includes a Reset Security option.

To access it, tap enter to get to the menus, and then system to find the reset security option. This menu option will reset https to http, set the authentication back to internal, and recreate the Admin user with the default password.

Browser Anomalies

Occasionally after switching from http to https or the authentication method, you may observe missing graphics. This is a one time occurrence after the change based on cached images with different http/https locations. It can be resolved by exiting all instances of the browser and then opening the browser and logging back in again. Since these parameters are usually set up once and then not changed, this should not then re-occur.

Security Settings and Clustering

Most of the settings within the security section will not automatically sync as they are changed across the cluster. However care needs to be taken that they are set the same on all nodes of the cluster. The reason the sync does not automatically happen is that usually there are certificates that are involved which will be different depending on the host and so must be instantiated first.

It is particularly important that the Device Passwords setting is the same across the cluster. If this setting is different on different nodes, the synchronization of new devices may not obtain the correct ability to login to devices.

It is also important to understand the ramifications of the SapV2 Raw and SapV2 TLS settings when it comes to clustering. Clustering uses the SapV2 protocol for cluster synchronization and so either the unencrypted or encrypted port for SapV2 must be available for clustering synchronization to work. Additionally if the node has the encrypted port enabled, then clustering will only attempt to use the encrypted port for clustering communications. It is highly recommended that you set up your desired security settings and certificates on both servers before setting up the cluster.

If TLS encryption is enabled, the clustering synchronization must be configured to trust the certificates of other members of the cluster. If you are generating certificates using a trusted authority, no further action should be necessary. If you are generating certificates using an internal CA, you need to add the CA's public root certificate to all servers in the cluster, and then the communications will be trusted. If you are using self signed certificated, joining Server B to Server A for the first time when creating a cluster with TLS encryption enabled for SapV2, the join will likely fail and produce a certificate trust dialog:

Clicking Trust will add the public certificate from the other node to the trusted certificate store. Then attempting the join again should work, and after the restart and sync, server B should show the correct clustering state. However, if you then go back and refresh server A’s clustering tab, you will see that the cert state column has a failed link on the A server:

Clicking on the failed link will present the certificate trust dialog again and allow you to trust the certificate from the B server. It should then connect properly. Both servers should now trust each other. This may not be necessary if you are using certificates signed by a publicly trusted authority.

LDAP Token Synchronization

LDAP login tokens are synchronized across the cluster including their removal for inactivity. This means that a successful login to one node in the cluster assumes a successful login to all nodes in the cluster. It is important to note that a redirect due to failure from one server to another is still likely to fail or request a new login. This is because the browser will not forward the cookie and or authentication data to a different ip address or DNS address for security reasons. If you login to both servers in the browser, it will then failover correctly, but that is not ideal and gets lost after all instances of the browser are shut down. To solve this problem, see Floating Ips below.

Floating Ips

This version adds a new feature called floating IPs. A floating IP is an additional IP address that you can add to the system which will only be present on one server or the other depending on which server is currently active in the cluster. The IP address will float to the other server if the first server dies. To create a floating IP, access the clustering tab:

Each floating IP must have a unique ID which must be a number between 1 and 255. It is critical to understand that floating Ips use VRRP (Virtual Router Redundancy Protocol) under the hood to manage who should own the IP. Therefore if you have routers in your network that also rely on VRRP, you need to pick id numbers (VRID) that do not coincide with the ones already in use. This synchronization data uses multicast IP address 224.0.0.18 and IP protocol number 112. To create a new floating IP, click the + icon.

Assign a unique id between 1 and 255 for the IP address which will be used for the VRRP id. Enter the floating ip address and select which network interface to use. The host priority list will change to the correct addresses for the cluster depending on the NIC you choose. It is very important that you choose a floating IP that is within the network range of the NIC you choose. In a future version we will add additional cross checking to enforce this rule. If you would prefer the normally used server to be the backup node in the cluster for this floating IP rather than the primary, you can switch the comma delineated order of the list or create the floating IP from the backup server which will cause it to be in the list first. In a future version we will also make this ordering more intuitive with a list where you can move the servers up and down in the order.

Click Apply to Add the IP address into the cluster.

This will now solve the failover login problems because you can point a browser at the floating IP/DNS, and the browser will properly resubmit authentication data/cookies after failing over since it is still the same IP address.

Https and Floating IPs

Floating IPs are a little more complicated with https and certificates. If you use self-signed certificates, PathfinderCore PRO currently is not including the floating IPs in the certificate. That will be changed in a future version but that means the self-signed certificate would be regenerated after adding or removing a floating IP to the system.

If you are generating your own certificates using a certificate authority, it is important that the certificate request includes all IP addresses (include the floating addresses) and DNS names you might want to use to access the system.

Https and Floating IPs and Failover

It is also important to understand how a user panel or other PathfinderCore PRO web page fails over using a floating IP. If the IP is currently owned by ServerA and ServerA fails, the IP will move to B. This will cause a loss of connection in the panel. The panel will then try to reconnect to the floating IP using the WebSocket only. If the WebSocket connection and authentication is successful, it will then refresh the entire panel web page. When using https, this will fail to work properly, if the computer does not trust the certificate on both servers. For example, if you open a browser and go to the first server and get a certificate warning that you have to click through in order to access the page, it is likely the failover to the other server will not work. What will happen is that the NIC icon in the right corner will remain red. If you use the Chrome DevTools(Ctrl-Shift-i) to inspect the webpage data, you will see certificate errors as the WebSocket tries to reconnect. Clicking the refresh icon on the browser will then present the certificate warning from the second server. Once you accept the certificate using the floating IP on the second server, then the panel will fail back and forth correctly. But if you close all instances of the browser that certificate acceptance is lost. The computer/browser has to trust the provided certificate if failover is going to work correctly using https.

Therefore it is highly recommended that if you are going to use https, that you also use certificates generate by a trusted authority and/or use an internal CA with proper trust relationships. If you are in an Active Directory domain, you can use the Domain Controllers as certificate authorities. This will work as long as you have the clients properly configured to trust the domain controllers as certificate authorities and sign your certificate using the domain controllers. Contact your IT department for more information. These issues do not exist if you use HTTP.

Property Groups

This version of PathfinderCore PRO adds a new feature called property groups. This feature allows you to group several properties together for redundancy or synchronization purposes. To add new property groups, visit the new Property Groups navigation bar link:

There are two types of property groups: RedundancyGroups and SynchronizationGroups.

Redundancy Groups

Redundancy groups are used for properties that should usually be in sync and are therefore redundant to protect against device failures. For example, you could wire up a device to the same GPI pins on two different xNodes. In normal situations both nodes would be tripped and Pathfinder would see two reasonably simultaneous closures. An "Or" logic flow could be created to trip off of whichever one came in. But without some complex logic there is the possibility of double processing of inbound signals. Property groups build intelligence into this using a combination of timing logic and (where possible) message ids to create a redundant path, but only process one of the two messages if both are received. An example diagram might look like:

In this situation the output of the PropertyGroup inherits the syntax of the input properties which is supplied to the logic flow editor. The property group handles the logic of understanding whether a new closure is the redundant closure to one on the opposing xNode, or if it is a new closure that needs to be processed. The PropertyGroup then only outputs unique signals. Then the logic flow can just work on the actual functionality that should occur without worrying about the redundancy aspect of the signals.

Creating a Redundancy Property Group

To create a Redundancy Property Group, click on the Property Groups link in the navigation bar.

Click the plus icon to add a new property group:

Give the property group a name and select Redundancy from the drop down. Case sensitivity determines whether values that are the same except for case should be considered equivalent. For example, in our gpio example, case sensitivity plays a role in whether H is the same as h. The pending interval is the amount of time that an event will stay in the pending state waiting for the recursive event from the other device before being removed. This does not pause the execution of the event, but if the duplicate event from the other device never comes, eventually we should stop waiting for it. If the duplicate event does come, then we clear the pending state but do not indicate the change since it has already been indicated.

Next we need to use the plus icon to add the GPI pin state property into the group. This will present a dialog where several properties can be configured:

The only property that is required is the signal property. The other two are used for very specific use cases where a group of properties are obtained at once and need to be evaluated only when the trigger property is set or when there is additional id information available that the system can use to identify unique events. In this case, set the Signal property to the GPI pin state property of xNode A by clicking the ellipsis button next to the signal property and selecting the Gpio pin. Leave the Id and Trigger properties blank. After selecting this pin state property click Apply, and the new property will be added to the group. Then repeat the procedure with the pin from xNode B. The result will look something like this:

We have basically defined that we expect to receive a pin closure from two different xNodes and to treat them as if they were one signal. The pending interval helps with the underlying logic to track unique cues versus redundantly received cues. Applying the changes to this property group will create the new group in the property groups list:

You will notice that this screen will also show the current value of the property and whether the property from each of the hosts is in sync or out of sync. Out of sync means signals have been received from one device that have not been received from the other.

Once this property group has been created, it can be used as the start point a logic flow by setting the start point to the GroupValue property of the property group.

This logic flow will turn a VMIX channel on and off based on a GPIO closure except that the GPIO closure is fed via redundant sources in case of an xNode outage.

This can be extended beyond GPIOs to any other property in the system. So for example you could set up redundant device emulator paths and pair the resulting watchers from both emulators into a property group.

The output of a property group could also be applied to a Sap Property router. The example below is grouping some device specific meta-data and sending that information into a Sap Property router for distribution to automation systems:

The group state property of the property group can also be used to track redundancy states that are broken by using a delay in a logic flow such that if the property group remains out of sync for more than a certain amount of time, an alarm is raised.

Synchronization Groups

Whereas a redundancy property groups pairs redundant incoming signals, a synchronization group attempts to keep groups of properties in sync. For example you could group to GPO pins together and whenever and one of the pins in the group changes, that same state would be pushed to all other pins in the groups. This could also be accomplished via a logic flow, but this option simplifies the logical combinations when you are trying to keep multiple properties in sync.

Creating a Synchronization Property Group

To create a Synchronization Property Group, click on the Property Groups link in the navigation bar, click the + icon, and select Synchronization from the type. Give the group a name.

Click the plus icon to add a property. In this case you will just get the property selector dialog.

Add the properties you want to synchronize to the group.

In the example above, changing any pin on this port will cause all of the pins to be changed to that state. Click Apply to apply the changes.

This example could also be extended beyond gpio pins. For example, it could be used to keep VMIX On/Off states in sync between mix engines. Also notice that the GroupState property can be used in a logic flow to alert an administrator about states that remain out of sync for a period of time using a delay in a logic flow.

Pathfinder log messages follow one of three different formats depending on the the log writer options selected and the type of message. If you choose UDP syslog as the log writer type, then the syslog structure is used. All other writer types use the standard log message structure. If the message type is one of the audit get or audit set message types the log message data is wrapped in an Audit log message structure.

Standard log message structure

By default log messages are composed of a timestamp, a message type id number, and a sap message:

<TimeStamp> <MessageTypeId> <sap message>

For example:

12-26-2023_11:45:00.001  6001  indi MemorySlots#0.MemorySlot#Time3 SlotValue=False

• Timestamp: Date and Time structured as: MM-dd-yyyy_HH:mm:ss.fff

• MessageTypeId: Each message item in the log writer editor checkboxes has an associated id number. So for example memory slot value changes have an id of 6001. This allows for easy filtering of specific message types.

• Message: Each message is a SapMessage comprised of an operator, object path, list of properties, and in some cases a list of system items. For more details on the structure of SapMessages see Appendix A of the Pathfinder manual.

Note: two spaces are used between the timestamp and the message type id and again between the message type id and the sap message data itself.

Audit log message structure

Audit log messages follow the same format as standard log messages except that the SapMessage wraps the original message with additional data:

01-03-2024_13:59:47.554  9012  indi AuditGet#[tcp://192.168.1.230:41202/] Direction=Incoming, Message="ClusterAdmin:get Devices#0 Ping<CR,LF>"
01-03-2024_13:59:49.230  9012  indi AuditGet#[tcp://192.168.1.230:9600/] Direction=Incoming, Message="<NoUser>:indi Devices#0 Ping=Pong<CR,LF>"

An audit log message will include an object path of AuditGet or AuditSet with a URL where the original audit message originated. Typically the url will begin with either tcp:// or ws:// for a tcp or websocket connection followed by the IP and Port. The Direction property indicates the direction of the message as incoming or outgoing. The message property itself will contain the user name used followed by a semi-colon and the original SapMessage. Outgoing messages may specify <NoUser> as the user since the outgoing message (especially if it is a change message) is not necessarily associated with a specific user. Carriage returns and line feeds in the original message are expressed as <CR,LF>.

Syslog message structure

When syslog is chosen for the log writer in Pathfinder, RFC 3164 format is used except that Pathfinder's time stamp portion of the message also includes the milliseconds.

<<severity>><timestamp> <localip> PFC: <MessageTypeId> <MessageObjectPath> <PropertyList>

<14>Jan 03 16:15:02.619 192.168.1.96 PFC: 6001 MemorySlots#0.MemorySlot#ttt SlotValue=B
<14>Jan 03 16:22:11.150 192.168.1.96 PFC: 9012 AuditGet#[ws://[::1]:56483/] Direction=Incoming Message="Admin:GET Devices#0 Ping<CR,LF>"

A syslog message is made up of a severity calculation followed by a date time stamp in the format: MMM dd HH:mm:ss.fff (normally RFS 3164 does not include the millisecond portion). Next comes a single space and the message portion which includes a tag (usually process name) and then the message data. We use PFC: for the tag for pathfinder core. The message itself is the object path and property list from the SapMessage as described in the standard and audit logging above. The operator and systems items from the SapMessage are not included when syslog options are selected.

SapProperty Router Changes

This version adds additional translators that may be used at either the Source and/or Destination level to add more specific customization to the value as it transitions through a Source to Destination route in a SapProperty Router. For example if the SapProperty router's sources were Gpios, and the destinations were rest API commands, the translation might look something like:

In this case we have made the translation as described in the manual for SapProperty routers. Every source to destination route in the router will use this same translation. But what if the rest API message required including an id (perhaps a Guid) for the original source? In that situation we need to change the translated message differently for each source the trigger originated on. To do this we have added an additional translation at the source and destination level. For example, instead of clicking on the translation button in the Sap Property main points tab, click edit on the source or destination in that tab.

A new Translation button now exists when editing an existing source or destination. The source must exist in the router before this button will exist. And there must be at least one source and destination in the router before it will be available. Clicking on that translation button will bring up the normal translation dialog and allow you to configure a source or destination specific translation list. The three translation points (Source, Router, and Destination) funnel into each other. For example:

In the first example we are defining the translation in the source and passing the output value from the source through to whatever destinations the source is routed to. This requires setting up a translation in each and every source in the router. This allows source specific data to be built into the output value.

The second example does the translation at the router level. This is how Sap Property routers have worked prior to this version and how existing routers will continue to work unless modified. The advantage of setting up the translation at the router level is that you can define it once and it applies to all sources and destinations. But that does not easily allow for modifying the translation differently per source or destination.

The third example passes the value from source through to the destinations which defines the translation to create the final output. This allows destination specific data to be included in the end result.

In the last example changes are made at each stage in a kind of pipeline. The source's "l" becomes "src1/l", and then that becomes the value of * in the router translation, and the output of that translation becomes the value for * in the Destination translation. This allows for translations to be changed at each stage of the process.

In most cases you will be choosing to do the translation at the Source, Router, or Destination level and leaving the other translations as *=*. But sometimes it can be useful to chain the translations together to build more complex output messages.

SapProperty Io Clear Value

When editing the translation on an IO, there is the same Destination Clear Value field as is present in the router translation. In the source, this field will have no effect and in fact should probably be hidden in future versions. In the destination, by default is will be set to <DefinedByRouter>. This means that the clear value when the destination is cleared will be defined by the router translation. This can be overridden to customize the clear value on a per destination basis if needed.

SapProperty Destination DestinationBeingSent Property

In order to improve the diagnosis of translations especially when chaining as described above, each SapProperty Destination now has a DestinationBeingSent property. This will momentarily spit out the final value change Sap message that gets sent via the destination each time a routed source value changes. So for example using the API on port 9600:

sub Routers#0.SapPropertyRouter#5 DestinationBeingSent $MAX_DEPTH=-1

This subscription will subscribe to any value changes being sent such that you can see the results of the translations.

Infinity Front Panel Remote Control Protocol Support

This version adds support for the Infinity front panel remote control protocol. This protocol allows PathfinderCore PRO to respond to and change properties of the Infinity intercom panels. It requires version 2.0 or later of the Infinity software. Because the ability to remote control an Infinity panel is not going to be necessary for most systems and/or only on select panels, support for the protocol must be manually enabled on a panel by panel basis. To enable support for the protocol, find the panel in the devices list. and click the edit link next to the web page link. If the edit link does not appear, you may need to remove and add the device again.

After clicking the edit link, you will be presented with an Infinity configuration dialog:

The lwrp enabled option is for future use. To enable the protocol, change the FrontPanel Rcp enabled option to True. Note that for this to work properly, you must be on 2.0 or later of the software in the Infinity panel. The FrontPanel Rcp Url link should be correct without changes. In the case where your Infinity panel is behind a proxy, this link can be modified. The FrontPanel Rcp protocol utilizes websockets via a url to communicate changes.

Once the protocol has been enabled on an Infinity panel with version 2.0 software or later, you should find additional items in the logic flow tree. Note that at this point in time the Infinity control protocol items only exist in the API tree.

Some of the properties that are available include:

Synchronization Master Property Group Type

This version adds an additional Property Group type called Synchronization Master.

Synchronization Group attempts to keep items in sync by using the last change to any item in the group. When one item is changed, the others are sent commands to change to the same value. In the case a device reboots and comes back in a state that is different from the group, the new state is the most recent and therefore would be used. However, this also means that a manual change on one item in the group will automatically get sent to all other items in the group.

Synchronization Master on the other hands has a property called MasterValue. Setting that MasterValue property to a certain value will send the value to all items in the group. In the case where one of the items in the group gets changed manually or via a reboot, there are two possibilities depending on the Allow Out Of Sync Parameter shown above. If allow out of sync is true, then the groups state will get set to "out of sync" and no other action will take place. In that case, you can build your own logic to decide what action should be taken. If the Allow Out Of Sync property is false, then a command will be sent to try to force the item back into synchronization. Any time an item in the group changes its value away from whatever is defined in MasterValue, an attempt will be made to force it back if the Allow Out Of Sync Property is false.

<NoChange>

The one exception to the rules above is if the MasterValue is set to <NoChange>. In that case, the items in the group can behave independently again until an actual value is set in the MasterValue again. The state will still show whether the items are in sync or out of sync, but this can be used to disable the enforcement of master value when necessary. It is important to note that the MasterValue is not retained between restarts of PathfinderCore PRO. By default when a SynchronizationMaster group is first started, the MasterValue will be set to <NoChange>. If you wish the value to be retained between restarts, this can be accomplished using a memory slot with the StartupState set to LastValue and a logic flow that hooks the memory slot to the MasterValue property. Then you can change the MasterValue property by changing the memory slot, and the value will get reset when PathfinderCore PRO restarts.

SapProperty Router Source and Destination Delays

This version adds a delay option to SapProperty Router Sources and Destinations. This allows you to delay the state changes if necessary. For example, if the source is a commercial break cue from a protocol translator or gpio, and you need to delay the signal to line up with audio or video, you can add the delay to the source or destination. To use this feature, edit the SapProperty source or destination by clicking the edit link:

Then click the translation button:

Within the translation editor for the source or destination you will now find a field where you can insert a delay in milliseconds.

In this case the message (SRC 1 is low) will get sent 3 seconds after the gpio pin goes low rather than immediately. If you add a delay to both the source and a destination, the effect will be cumulative.

Generic Device Emulator UDP Changes

In previous versions there was an issue with Generic emulators which could cause the emulator to stop transmitting data after a failed transmission attempt. This version fixes that issue and also clarifies configurations around send and receive with UDP in Generic Emulators.

There are several options for using UDP with generic emulators, and which one you choose will be defined by your use case.

• Only need to send UDP messages to a remote device:

  • Use a UDP client and leave the local port option set for zero.

  • Messages may be sent using the ToSend Property in Logic Flows and/or panels.

  • Note that configuring a watcher for this configuration is meaningless. The client is only configured to send messages and not set up to listen for any responses.

• Only need to receive UDP messages from remote devices:

  • Use a UDP listener and define the port on which to listen.

• Need to send and receive messages to/from a device

  • Use a UDP Client and define a local port to listen for return messages.

  • OR

  • Use a UDP Client with zero selected for the local port and a UDP listener for return messages.

This last situation could use a little bit of clarification. In general UDP is a single direction message with no guarantees on delivery. Therefore if you need bi-directional communication, you must define a port for the return messages. Using a UDP client you can define a listen port by using the local port option:

In this case we are sending messages to 192.168.1.223 on port 5001 and expecting messages to come back on port 5002. We could have also chosen 5001 for the return port as well which is perhaps more usual. The response port may be configured in the remote device or discovered since the local port will be transmitted as the source port of the message. Depending on the application, it may require defining a port to respond to, or it may use the source port from the message. However, you can only have one emulator listening on a single UDP port at a time. Therefore, in the situation where you have 3 remote devices and 3 emulators talking to them, but all of these devices are the same brand and expect to communicate to the same response port, then defining the local port redundantly in each emulator will not work. In that case, create a client with a local port of 0 for for each device to use for sending, and a UDP listener emulator to hear the responses from all of the devices.

Understanding your application is critical to configuring UDP communications correctly.