VermoHub device model

In the world of IoT, standardization is the key to scalability. When designing VermoHub, we drew inspiration from the best practices of the Matter standard, creating a flexible and hierarchical device model. Our goal? To create a bridge between physical hardware and digital abstraction that is both readable and functionally powerful.

VermoHub model architecture

The model structure is based on three key levels:

• Node: A virtual representation of the device functioning within the software layer. A single physical controller (VermoBoard) can support multiple virtual nodes, allowing for flexible management of hardware resources.
• Endpoint: These are logical components of a node corresponding to specific devices or subsystems. Examples of an Endpoint include “Lighting”, “Pump Drive”, or “Temperature Sensor”. Each Endpoint is an independent logical entity.
• Cluster: The lowest level of the hierarchy, defining specific functionalities within a given Endpoint. Clusters group attributes and commands, such as control (“On/Off”), parameter configuration, or telemetry streams (“Data”).

This approach allows us to precisely map physical reality onto a digital model while maintaining the order known from leading IoT standards.

Connection to reality: controller software and behavior definition

What distinguishes the VermoHub model is its tight integration with the running software on the physical VermoBoard module. The parameters of each Endpoint contain a direct reference to software blocks running on the device. In the VermoHub model, Cluster parameters are not just static variables—they are rules defining the dynamics of the entire system:

• Flow logic and direction: Distinction between control (data directed to the device) and telemetry (data received from the device).
• Action Triggering: Definition of whether an executive function should be triggered reactively (upon receiving a message “from outside” or in response to a change in a monitored sensor value) or deterministically (based on the device’s internal schedule).
• Digital Twin Synchronization: Automation of output data transmission schedules, ensuring the freshness of the machine’s digital representation in the cloud (via cron standard or in response to value changes).
• Reliability: The TTL (Time-To-Live) parameter manages critical behaviors in case of connectivity loss. It defines the validity period of a command in the VermoHub queue, preventing the execution of outdated or unsafe commands once the connection is restored.
• Flexibility: An architecture open to defining arbitrary, custom parameters, allowing full adaptation of the platform to specific implementation requirements (e.g., alarm definitions).

Security

Robust architecture requires solid security foundations. All communication between the device and VermoHub is secured by x.509 certificates based on our own Public Key Infrastructure (PKI). Furthermore, VermoHub provides full support for remote updates (OTA - Over-The-Air Update). We can independently update the device model definition itself, the software communicating with the model, and its entire firmware.