Managing Remote Hub Connections in Cambrionix Connect
One feature of Cambrionix is the ability to create a Cambrionix Connect account to connect to hubs remotely. This will allow you to view and manage all connected hubs, and any connected devices, on your network. Each host system can then be added to your organisation, and each user within that organisation can access and manage the connected hubs.
By creating a Cambrionix Connect account and using this feature, your organisation will be able to:
- Remotely manage any of your devices from across the room or the world, 24/7.
- Remotely Manage firmware updates across your whole fleet of devices.
- Monitor and control your Cambrionix products using a phone/tablet/computer.
To remotely access a hub, you must ensure the host API the hub is connected to has a digital certificate linked. You will also require a license if you wish to connect remotely.
You can obtain information on licenses from Cambrionix by contacting sales@cambrionix.com
For more information on connecting to hubs remotely, please read the Cambrionix Connect user manual, which can be downloaded from the below link.
https://downloads.cambrionix.com/documentation/en/Cambrionix-Connect-User-Manual.pdf
We would highly recommend you familiarise yourself with our API documentation (linked at the bottom), as that will explain everything in more detail. This is intended for a very quick overview.
Note that only a single certificate configuration is supported. We’re unable to support multiple certificates for remote access. If a password is supplied on the certificate, it is obfuscated for security.
- Without a certificate, and thereby no remote access to manage your devices, the API will natively only listen for connections on
localhost:43424. - With a certificate supplied, and the relevant private key supplied, the API will change to listen to
0.0.0.0:43424.
External connections (IE, not from localhost) will only be allowed if a valid SSL connection is made - HTTPS & WebSockets
Within the application, you’ll be supplying the file-location of the certificate and private key, so it’s important these aren’t stored in limited access folders, as it could prevent the application from retrieving them (IE, the User running the API from their machine needs access to the folder these are stored in). This is all tested when the set command is issued (explained in documentation) and should provide sufficient error messages in the event it doesn’t work.
It’s the User’s responsibility to supply a valid certificate that is suitable for their use. We are unable to provide support with signing unsigned certificates etc. - this will need to be managed through your certificate provider/authority.
Please review our API documentation for more information.