-
Notifications
You must be signed in to change notification settings - Fork 12
Migration from Broker 1.0 to 3.1.x
The migration from Broker 1.0 version to the newer 3.1.x version will break old installations. This is happening because the broker has been split in many decoupled packages to provide better development flexibility.
It comes at the cost of 1) being harder to join into the project to help with a specific part when it is a feature that impacts the whole project and 2) causing headaches in migrating from version 1.0 to 3.1.x.
This page addresses the breaking changes that occur in the migration of a project from 1.0 to 3.1.x
If you are using MQTT Broker 1.0 in production, don't upgrade the following packages:
- OpenSerializer >= 1.1.0
- DataManipulation >= 1.2.3
- Any MQTT Packages other than the broker (that includes Control Packets, Connection, Client)
Migrating from 1.0 to 3.1.1 will be a breaking change, at the benefit of having a more extendable framework for your application.
- First, determine if you need both Client and Server functionality. They are now separate packages. You can choose to install one, or the other, or both.
- Then, open VI Package Manager and install the client or the server (or both) along with all its dependencies.
- Open your project: There might be breaking changes that need to be corrected. You'll see it right away with a pop up dialog that searches for some dependencies on disk. Most of the changes should be relinking issues. This is because the namespacing of a few classes has changed.
Serializer classes used to be called... Serializer.lvclass. This was too generic to be sustainable in the long run. Many developers would have had conflicts if the MQTT library were to become popular. I changed it to OpenSerializer.lvlib:Serializer.lvclass. The Marshalling and Unmarshalling methods will need to be relinked to heir new location: <vi.lib>\LabVIEW Open Source Project\OpenSerializer
MQTT_Base class used to be in the Broker library. Now it is on its own. It is very likely that public methods will not have relinked properly. It you are asked to search for them, they are located at this new path: <vi.lib>\LabVIEW Open Source Project\MQTT Connection\MQTT_Base\Base Class
Very likely to need relinking are the methods:
- Decode Publish Package.vi
- Decode Publish Package (Raw).vi
- Subscribe.vi
- Unsubscribe.vi
- Subscribe (SingleTopic).vi
- Unsubscribe (SingleTopic).vi
- Start.vi
- Stop.vi
MQTT_Client class used to be in the Broker library. Now it is on its own. It is very likely that public methods will not have relinked properly. It you are asked to search for them, they are located at this new path: <vi.lib>\LabVIEW Open Source Project\MQTT Client
Very likely to need relinking are the methods:
- Create MQTT Client.vi
- Connect to Server.vi
- isConnected.vi
There will also be a breaking change where the Connection URL is not an input of the Connect method anymore, but rather injected through a Connection Configuration temrinal in the "Create MQTT Client.vi" input terminal
With every client or server, there is now an input terminal in the creator methods that allow you to specify a type of connection. The configuration of that connection is a method of any of the connection extension classes:
<vi.lib>\LabVIEW Open Source Project\MQTT LocalQueue Connection <vi.lib>\LabVIEW Open Source Project\MQTT TCP Connection <vi.lib>\LabVIEW Open Source Project\MQTT Websockets Connection <vi.lib>\LabVIEW Open Source Project\MQTT Secured TCP Connection
These connection extensions are their own projects. Install them separately from the VIPM Application.
You'll need to add a Connection at the input of the create method.