Release Notes > Version 8.2 Release Notes > ThingWorx Analytics 8.2.2 Release Notes
ThingWorx Analytics 8.2.2 Release Notes
The following enhancements and bug fixes were made in ThingWorx Analytics 8.2.2.
Enhancement Description
Reference #
ThingWorx Analytics Server: Security update
This release includes security enhancements.
Bug Fixes
Bug Fix Description
Reference #
Analytics Manager: Unable to view Analysis Providers in ThingWorx Platform 8.2.3
In the 8.2.3 release of ThingWorx Platform, a change to the list widget component of the Mashup Builder prevented Analysis Provider functionality from displaying correctly. This issue has been resolved.
Known Issues
Known Issue Description
Reference #
ThingWorx Analytics Server: Docker installation fails when using localhost URI for connection to ThingWorx
When ThingWorx server is installed on the local server, and localhost is entered for connection purposes during the ThingWorx Analytics Docker installation, the connection validates successfully but the ThingWorx Analytics Server Things are not created in ThingWorx. The Edge Microserver in the Docker container cannot accept localhost as the connection to ThingWorx. The following possible work arounds are available to resolve this issue:
Use a native standalone installer (either Windows or Linux) instead of the Docker installer. (preferred)
Uninstall and reinstall ThingWorx Analytics Server using the ThingWorx external IP address instead of localhost during ThingWorx Analytics Server Docker installation.
Update the and files with the correct ThingWorx address. Then restart the ThingWorx Analytics Server. For more detailed information about this option, see Article - CS273311.
ThingWorx Analytics Server: Two-at-a-time Signals request does not return MI for all field combinations
When running a request for Signals, and specifying maxAtATime = 2, Mutual Information (MI), in relation to the goal, is not returned for all field combinations as expected. Instead, individual (one-at-a-time) MI scores are returned for all fields and then are filtered down to the top 25% most relevant fields. Two-at-a-time signals are calculated only for those fields. There is currently no way to modify this filtering behavior.
Analytics Builder: Deleting a filter does not delete all jobs associated with it
When a dataset filter is deleted, all models, signals, profiles, and scoring jobs created using that filter should also be deleted. Currently, these items are not all being removed. New jobs cannot be initiated using the deleted filter, but if a user tries to retrain a model that was based on a deleted filter, the job will run against the entire dataset.
Analytics Builder: Retraining a time series model does not retain the default lookback window size
When a time series model is built using the default lookback window size of 0, the lookback size is not retained when the time series model is retrained. This issue can manifest itself in two scenarios:
In a time series model with one feature, and a lookback size of 0, a retraining job will fail. It will not be able to run time series training because the default lookback size is not retained, and it will not be able to run standard training because there is not enough data.
In a time series model with more than one feature, and a lookback size of 0, a retraining job will succeed, but only as a standard training model. It will not be able to run time series training because the default lookback size is not retained. However, it will have enough data to run standard training.
As a work around, rerun the training as a new model, using the same configuration as the original training job.
Only necessary if you want to retrain with the default lookback size of 0, which uses auto-windowing functionality.
Analytics Manager: Failure to deploy model by downloading file from a network URL for ThingPredictor
While creating an analysis model for ThingPredictor, if you specify a network location in the Model File URL field, ThingPredictor cannot download the file and deploy the model.
Analytics Manager: Deployment job status for docker deployer agent is shown as incorrect
When deployer agent deploys an agent on a machine, the corresponding job status is shown to be in the INPROCESS state. However, the deployment is completed.
Analytics Manager: An existing simulation event fails if it is triggered after server restart
Analysis agents must be restarted after a ThingWorx server restart. Without restart of the agent, any new simulation jobs will fail to execute.
Was this helpful?