With every version of Connhex you'll get:

  • a state-of-the art data collection infrastructure. Simply put, this is an entity responsible for receiving data and storing it efficiently into a database
  • every service included in Connhex Cloud
  • Connhex Control: Connhex's device management application. Think of it like an admin-level device management application for all the devices connected to Connhex: you can see what messages are coming from each device, send commands and configuration to devices
  • out of the box Grafana integration to create custom dashboards

Connhex AI and Connhex Edge licenses are billed separately instead.

Absolutely not.

Connhex has been designed to be the foundation for your product, with an emphasis on "your". Moreover, Connhex is not yet another white-label platform: if you're using one of those, you can probably customize the both the logo and the branding - but your most knowledgeable customers will still be able to tell what white-label platform you're using.

Needless to say, we are very careful in sharing information. Some of the companies using Connhex were gracious enough to provide a testimonial: this is, of course, optional. Every success story was shared with the customer involved before publication.

It really depends on your needs. A few examples:

  • if you plan to use Connhex to gather data and create dashboards, you can leverage Connhex's Grafana integration. Let Connhex do the heavy lifting for you - getting data from devices into a database - and build your own dashboards to visualize those data. A typical use case for this is the creation of internal dashboards to monitor company equipment
  • if you need to create a complex web application that includes more advanced logic than simply collecting and visualizing device data - think users management, handling user-devices associations, generating reports - you'll need to hire a software development team, typically a software house or a web agency. The advantage in using Connhex is two sided, the first being cutting down time to market, since developers be able to use all the additional services included in Connhex through API calls. The second one deals with demand and supply: there are many great companies that can develop beautiful apps, less of those know all the nitty-gritty details involved in getting data from intermittent sources and storing it efficiently. By choosing Connhex, you are expanding the pool of potential suppliers for the solution and lowering the total cost dramatically.
  • if you need to create a mobile app, all of the previous still applies with a single exception - you'll probably need to hire dedicated mobile developers instead of a standard web agency

These are just examples: if you're not sure whether your solution could benefit from leveraging Connhex or not contact us and we'll take a look at it together.

The main differences between the three versions are their features and performances. Broadly speaking about performances, there are two factors that scale the cost of a data collection infrastructure:

  • how much data is involved
  • what the required availability for the infrastructure is. For example, are you okay with the system being down for a few hours in a year or not?

Some Connhex versions are engineered to auto-scale as the data flow goes up, whereas others have been optimized to work with relatively low hardware resources.

Of course you can: just get in touch and we'll migrate all of your data. Downgrading is a bit trickier, since we have to figure out how to handle excess data - but that can be done too!

The short answers is: yes, but.

You can definitely piece together many open-source projects and implement the missing functionalities Connhex offers. You can also implement it yourself from scratch. However, besides the fact you'd be giving up on all the optimizations we spent years to achieve, there are a few things to consider:

  • open-source components are typically developed in isolation. While this is why open-source is great for lots of infrastructural stuff (we didn't write an MQTT broker from scratch, rest assured!), you can't build a great product by forcing together pieces that are not intended to work this way. This is another reason why, if you decide to go the in-house route, you'll need to write a lot of it yourself.
  • sad as this is, open-source funding is a hard problem in itself. You should also factor in the risk of the project you're using to be abandoned in the future
  • creating something is just a fraction of the work. The real deal is testing it, smoothing out edge cases and making sure it's production-grade
  • once you bring a project in-house, it immediately becomes both an asset and a liability. You should compare the benefits of building it yourself with the costs of monitoring, maintaining and updating it. Do you have a dedicated team or do you need to build one? What's your core business and where are you subtracting resources from?

Keep in mind the total cost of ownership: you'll need to code your solution, test it, validate it, monitor it, maintain it and support it. Look here for a detailed comparison between Connhex and custom projects.

We've shared our reflections here. In a nutshell, we will never open-source something if we can’t do it properly: right now we are still a small team, focused on serving our customers as best as we can. The overhead involved in managing and supporting an open-source project would be at the expense of the level of service we are currently providing.

Connectable is the general term we use to describe anything that can connect to Connhex (a bit of a tongue-twister, we know).

The difference between an edge and a device is actually very simple. An edge is a physical electronic device that is running Connhex Edge, whereas a device is a generally simpler object sending messages to Connhex and receiving commands from it. In short, you can think of edges as super-powerful devices that leverage Connhex Edge's functionalities.

You can read more here.

Like everything in software, it depends 😁. We wrote extensive documentation on this topic: you can find it here.