Skip to content

Profinity 2.3.3 release notes

Profinity 2.3.3 is the build of Profinity 2.3 that you install to move a Profinity 2.2 system to 2.3. It checks settings and profile files when they load, skips a rule, collection, or derived tag that holds an unknown key, and stores a custom side menu in one shape. Follow Upgrade from Profinity 2.2 for the upgrade procedure, and refer to Profinity 2.3 breaking changes for what changed from 2.2.

Configuration files

Settings files

config.yaml and security.yaml stop Profinity at start-up when the file is empty or unreadable, names an unset environment variable, or holds a key that 2.3 does not define. The removed 2.2 keys in config.yaml, listed in Profinity 2.3 breaking changes, are the exception, and Profinity ignores them. Profinity leaves the file unchanged and shows a message that names the file and the reason, and When a configuration file is invalid describes what to do.

Loading security.yaml and restarting Profinity keep the saved settings, so the session length, the sign-in method, and the password rules stay as they were saved. The tag history limits on the Tags tab, including Max Total Points (All Tags), also stay as you set them.

Profiles

Profinity reads a profile from profile.yaml in its profile folder, and a folder appears as a profile when it holds that file. A key at the top level of profile.yaml that Profinity does not define stops that profile loading. Profinity then creates a default profile, makes it the active profile, and writes the reason to the log, and the invalid file stays unchanged. Refer to When a configuration file is invalid for what to do.

Profinity ignores these top-level keys, so a profile that holds them still loads:

  • attachments
  • canId
  • comment
  • componentMenuLayout
  • componentsMenuLayout
  • defaultDashboardFilename
  • name
  • readOnly
  • remote
  • useCustomComponentMenu

A profile takes its name from its folder. The check covers the top level of the profile, so the components and profileDevices sections are outside it.

Uploads and imports

Profinity checks an uploaded dashboard before it replaces the current file, and refuses one that would not load, so the current dashboard stays in place. A profile pack whose profile.yaml is invalid is refused, and Profinity removes the files it extracted from that pack. When a valid upload replaces a dashboard, rules file, or collections file, Profinity keeps the replaced file as <file>.bak, replacing any earlier .bak copy.

Rules, alerts, and derived tags

A rule, collection, or derived tag with a key that Profinity does not define is skipped, and the file stays unchanged when it loads. A rule action with a value of the wrong kind, such as a list where a parameter belongs, skips that rule only, and the other rules in the file still load. The log and the editors name each skipped item, and the editors mark it Invalid and keep SAVE disabled until every item is valid, as described in When a configuration file is invalid.

If active_alerts.yaml is damaged or empty, Profinity rebuilds the current alert state from the daily alert files, and acknowledged and silenced alerts keep that state.

A derived tag that reads a component property, which is a value the component supplies when it is asked, follows that property's current value, because Profinity reads the property each time the derived tag is read. A derived tag that also reads an ordinary tag still updates when that tag changes, as described in Derived tags.

Unreadable tags

A rule holds its current alert state while its tag is unreadable, so an active alert stays active through a short device dropout. A rule that alerts on a lost reading, such as !tag.HasValue, needs onUnreadable: evaluate to trip, so add the line to each rule whose expression or clear expression tests HasValue or Quality. In rules.yaml, such a rule looks like this:

- rule:
    id: temperature_sensor_lost
    expression: "!tag.HasValue"
    onUnreadable: evaluate

onUnreadable takes hold, the default, or evaluate, and any other value skips that rule. When rules load, the log warns about each rule that tests for a missing reading and lacks the line. In the rules editor, the same setting is When the tag is unreadable, set to Evaluate the rule, as described in Rule settings.

Dashboards, themes, editors, and the rules API

Opening a dashboard leaves its file unchanged. Earlier 2.3 builds rewrote the file on open when it needed normalising, and turned an absolute tag path inside the dashboard's own component into a relative path. 2.3.3 keeps the file and its paths as written, so an absolute tag path such as /Solar/Total stays absolute. A dashboard still in the 2.2 format opens with an error panel titled "This dashboard no longer matches the schema". In that panel, a user whose role can modify dashboards can select Reset from Template. Copy the dashboard's YAML first, as the Troubleshooting guide describes, because the reset replaces the dashboard with its template and discards every customisation. If the replaced dashboard loads, Profinity keeps it as <file>.bak, which replaces any earlier .bak copy, and the next save of the dashboard replaces it again. A dashboard that does not load is replaced with no copy.

A dotted tag address such as Component.Message.Signal is rejected, as described in Profinity 2.3 breaking changes, and Tag tree paths and dashboard binds shows the slash path forms.

A theme can set app.title to an empty value, and the sign-in page then shows the logo with no title text, as described in Themes and branding.

The rules, collections, derived tags, menu layout, and dashboard editors disable SAVE when there is nothing to save or an item is marked Invalid, and they say which of those applies. The permission message appears only for a role that cannot save. A component setting that is outside its allowed range is marked when its dialog opens.

The rules API returns every rule action as an object with an action name, including an action that the file writes as a bare name, so a client reads each action name from the action field.

The side menu is the menu section of profile.yaml, and the YAML tab in the Menu Layout editor shows that same list. Profinity 2.3 ignores the custom side menu keys a 2.2 profile holds, such as componentMenuLayout and useCustomComponentMenu, so arrange the menu again in the editor. When Profinity cannot read or validate the menu section, it shows every component in its default group, writes one message to the log, and leaves the profile file unchanged. The Menu Layout editor shows the reasons, and, after you change the layout, selecting SAVE there writes the menu section and leaves the rest of the profile as it is.

Licensing

Features that were available without limit in 2.2 depend on the edition in 2.3, as listed in Profinity 2.3 breaking changes. Have a licence file from Prohelion ready before you upgrade, which you can request through the Prohelion contact page, and apply it on the License page, as described in Apply a licence.

A server installation whose licence is missing, expired, or invalid runs in restricted mode until a valid licence is applied. A user with the Security administration permission is taken to the License page, which shows a banner with the reason, and can still read the logs. Every other user sees a Licence required view.

Profinity checks the licence at the expiry date, and at least once an hour, so an expiry takes effect as soon as the date passes. When the expiry removes Profinity AI, the Server features, scripting, or custom plugins, Profinity restarts to apply the change.

Service accounts

A service account signs in with its API token instead of a password, as described in Service accounts. A password sign-in for a service account shows "This is a service account and cannot log in with a password." Profinity refuses to make the last administrator a service account, so at least one administrator who is not a service account always remains.

Docker, samples, and CAN adapters

Scripting is available in the Docker image for each supported processor, as described in Install Profinity with Docker. If scripting cannot start, Profinity keeps running with scripting off for that session and writes the reason to the log. The scripting setting in config.yaml stays as it is, and the next start tries again.

On a new installation, Profinity adds the sample content described in Artefacts directory, and an upgrade keeps your existing files as they are.

The PCAN and PCAN FD CAN bus adapters need the Peak driver on Windows, which provides the PCANBasic library. Install the latest Peak drivers from the Peak System website first.