Skip to content
  • There are no suggestions because the search field is empty.

Cogent DataHub Breaking Changes & Known Issues

Breaking Changes

OpenSSL 3.3 requires stronger certificate keys

DataHub v11 uses OpenSSL 3.3, a change from previous versions that use OpenSSL 1.1. OpenSSL 3 requires certificates to have stronger keys than in previous versions, so when DataHub v11 is acting as an SSL client it will reject connections to servers using weak certificates.

This is a breaking change. If you are using tunnelling, MQTT or web server functions in a DataHub application, you may need to re-generate the certificates for any DataHub installation being upgraded to v11 from an earlier version. If you intend to connect DataHub v11 to older versions, you may also need to upgrade the SSL certificates on the older versions.

The sample certificate, datahub.pem, that is installed with the DataHub installation has been changed in v11 to use a stronger key. This certificate is used for testing. It is not valid – it is self-signed, possibly expired and issued to an invalid DNS name. If you are using the test certificate in an older version of DataHub, you can copy datahub.pem from a v11 installation to the earlier DataHub installation to enable the connection.

If you have generated your own server certificates then you may not be affected by this change. Most certificate generators default to an acceptable key length and hashing algorithm. If your generated certificate is weak, you will need to generate a new one.

If the DataHub v11 tunneller rejects a certificate because its key is weak, you will see a message similar to this in the DataHub event log:

[2024-06-25 05:47:06.977] I: [TCP to TUN000 into domain]:  SSL Certificate failure: 66: depth 0: EE certificate key too weak:  /C=CA/ST=Ontario/L=Georgetown/O=Cogent Real-Time Systems Inc./ OU=Developers/CN=developers.cogentrts.com/emailAddress=support@cogent.ca

Look for the failure message, “EE certificate key too weak”.

If you cannot upgrade the certificate on a server for some reason, you can modify the configuration in the client to accept invalid certificates:

In the DataHub Tunnel/Mirror Slave SSL configuration, un-check the options “Reject invalid certificates” and “Reject host name mismatch”.

In the DataHub MQTT Client Authentication configuration, check the option “Accept invalid certificates”.

OPC UA connections are not affected by this change.

MQTT broker respects queue length setting

In DataHub V10, the MQTT broker would always send all QoS 0 retained messages in response to a subscription, regardless of the broker setting, “Maximum per-client message queue length”. In DataHub V11, the MQTT broker respects the queue length setting. This may result in unexpected loss of retained topic information when the client initially connects. To restore the behaviour of V10, set the DataHub broker’s “Maximum per-client message queue length” to zero, indicating no queue length limit. In that case, DataHub V11 will use its own smart queue management based on the recipient’s data ingestion rate. The default queue length in DataHub V11 is now zero.

DataHub v9 software (and later) does not support Windows XP and Server 2003

DataHub V9 requires .NET 4.6.1, which is only available on Windows 7 and later. Windows XP and Server 2003 are not supported.

Changes to OPC-UA certificate handling

DataHub v9 changes the way DataHub deals with OPC-UA certificates by removing a dependency on the windows machine certificate store that was stopping DataHub from registering with the LDS if the user permissions did not permit reading that store. We are not aware of any side-effects from this.

64-bit DataHub software needs 64-bit OPCEnum service

If you are upgrading to the 64-bit DataHub software, you may find that you cannot configure connections to OPC DA servers. This requires a 64-bit version of OPC Core Components. Most OPC server products will install OPC Core Components (containing OPCEnum) when they are installed. They typically install a 32-bit version. The 32-bit version only supports 32-bit clients and servers.

The 64-bit version of DataHub software attempts to install a 64-bit version of the OPC Core Components that will support any combination of 32 and 64-bit clients and servers. The installation may not succeed if the installer already sees a 32-bit version installed. You can ensure that the 64-bit version gets installed by using the Windows Programs and Features interface to delete all installed copies of OPC Core Components, and then re-install DataHub.

Bit-depth for in-process OPC servers must match DataHub bit-depth

In-process OPC servers are typically 32-bit, so you need to use the 32-bit DataHub software to connect to them. If you have a 64-bit in-process OPC server, then you must use the 64-bit DataHub software.

Bit-depth for ODBC drivers must match DataHub bit-depth

The 64-bit DataHub v9 software uses 64-bit ODBC drivers. All existing DSNs will fail to load. You need to create the DSNs as 64-bit instead of 32-bit. To open the 64-bit DSN editor, you can choose “Open DSN Administrator” from the DataHub database action configuration dialog.

Changes to DataHub Web Server folders

The DataHub Web server document root, default certificate file and log folders have all changed. The tunnel/Mirror default certificate file has changed. When the DataHub instance starts, it looks for a configuration that was default for version 8 and automatically adjusts that to reasonable values for version 9.

Binary tunnel connections between DataHub software v9 and earlier versions not supported

Binary connections between v9 and v9 will succeed, but not those between v9 and v8, v7, or v6.4. When tunnelling between DataHub software v9 and earlier versions you must use the default (non-binary) text connections. Non v9-to-v9 binary connections may appear to succeed but no data values are delivered. The DataHub Event Log may contain error messages depending on the direction of the connection. This is made necessary by a change in the timestamp representation from 32 to 64 bits. Text connections (non-binary) are compatible between v7, v8 and v9.

DataHub v9 (and later) start up parameter now on by default

In DataHub software version 9 and later, the installer now sets the default value of “Allow only one running instance” to TRUE.

Old Web Server demo pages removed in DataHub software v9 (and later)

The demonstration pages for the built-in web server have been removed in DataHub software v9 and later. The special URLs supporting AJAX and streaming AJAX application have been removed. The AJAX paths (/points and /ajax) are unauthenticated and represent a potential information leak. Streaming AJAX is no longer a useful technology.

Specifically, the following paths no longer exist:

/points

/ajax

/stream

/socketIn

/socket

For web applications that need to interact with DataHub you have 2 options:

use a WebSocket connection

create your own ASP page to generate custom JSON or XML content that your web application can poll.

Scripts need to be moved after upgrade to DataHub software v9 or later

After upgrading to DataHub version 9 or later, the scripting tab may refer to scripts in the C:\Program Files (x86)\… folder. These scripts should be moved to another folder. We recommend creating a folder within the DataHub configuration folder and moving them there, typically:

C:\Users\<Windows Login>\AppData\Roaming\Cogent DataHub\scripts

where <Windows Login> is the user name you used to log in to Windows.

Known Issues

Moving back to Cogent DataHub™ software v10 (or earlier) after installing v11

If you install DataHub software v11 on your system and then decide you want to move back to an earlier version, you must uninstall the DataHub v11 software and then install the previous version. Failure to do so results in unexpected behavior. Installers for DataHub software v9.0.11 (and later) will do this automatically for you.

If you run into trouble, re-run the DataHub v11 installer and then uninstall it before installing the earlier version.

Media control does not function in Desktop WebView

The Media control does not function reliably in Desktop WebView. It may or may not play a video that works in Silverlight. We are aware of the issue and will try to improve it in a future version.

New security groups may need to be reset in DataHub software v9 and later versions

DataHub software v9 includes two new security groups (Admin and RemoteConfig), which help with configuring new user access credentials. After upgrading to v9 (or later versions), you may not see these new user groups in the Configure Permissions window. To add these new groups, you can close the Configure Permissions window and click on the ‘Reset Default Users and Groups’ button.

No WebSocket support in Windows 7

Microsoft does not support WebSockets in Windows 7. So when using Remote Config, Desktop WebView or the DataHub for Microsoft Excel Add-in, you will need to configure a TCP connection to the DataHub instance, rather than the default WebSocket connection.

Upgrade from DataHub v7 while running as a service

If you are running DataHub software v7 as a Windows service and you plan to upgrade to DataHub software v8 or later, then you should follow these steps.

Stop the DataHub service in the Service Manager program;
Perform the upgrade to later version;
Run the DataHub software as a Windows service again from the Service Manager program.


Running DataHub software as a service in Windows 10, Server 2016 and later versions

We use a program called the Service Manager to help you run the DataHub software as a Windows service. With Windows 10 and Server 2016 and later, Microsoft have removed keyboard and mouse support from the service console 0. Although you can still use the Service Manager to run DataHub software as a service, you can no longer use the service console to change the DataHub configuration.

DataHub software v9 introduces the Remote Configuration feature which makes it easy to configure and work with the DataHub instance while it is running as a Windows service. Using the Remote Configuration feature also allows you to configure a DataHub instance running on a remote network computer.

To make changes to DataHub instance v7 or v8 (in Windows 10/Server 2016 and later), you must do the following:

Stop the DataHub service in the Service Manager program;
Run the DataHub software as a normal Windows user and save the configuration changes;
Close down the DataHub instance; and
Run the DataHub software as a service again from the Service Manager program.


Windows XP support for LDS

If you install the DataHub software in Windows XP with Service Pack 2, then the DataHub instance will run but the UA Server will not be able to register with the Local Discovery Server. The work-around for this problem is to simply copy the DataHub UA server Endpoint URL and paste it into the UA client configuration.

Failed authentication causes a disconnection

In version 7, the authentication mechanism follows an escalation process, where the connection initially has anonymous permissions, then upgrades to TCP permissions, then to Mirror permissions. If the user then authenticates then the connection upgrades to the permissions of the user. If the user authentication fails, the connection remains open and the permission for that connection remains at the permissions for Mirror.

In version 8, the same escalation process occurs. However if the user attempts to authenticate and the authentication fails, the connection is immediately disconnected instead of remaining open with the permissions of Mirror.

Data model not always transmitted

Version 8 no longer sends the data model over a tunnel during initialization when the user selects “Get all values from the master”. In version 7 the slave would send its model even when it knew that it was not authoritative on the data set. This could cause a slave to mangle the model on the master, even though the master is supposed to be correct.