21 | Eclipse Kanto™ is a modular IoT edge software that enables devices for
22 | IoT with all essentials like cloud connectivity, digital twins, local communication, container management,
23 | and software updates - all configurable and remotely manageable by an IoT cloud ecosystem of choice.
24 |
25 | {{< /home-about >}}
26 |
27 |
28 | {{< home-component-list color="100" height="auto" title="Benefits">}}
29 |
30 | {{% home-component icon="icons/lightweight.svg" title="Lightweight" color="kanto-feature" url="about/#features" url_text="Read more" %}}
31 | Run Eclipse Kanto on various constrained edge devices with ranging hardware capabilities to scale hardware and enable a seamlessly integrated and harmonized IoT edge landscape.
32 | {{% /home-component %}}
33 |
34 | {{% home-component icon="icons/containerized.svg" title="Containerized" color="kanto-feature" url="about/#lightweight-container-management" url_text="Read more" %}}
35 | Develop edge applications by using most fit-for-purpose languages, reliably deploy and manage them as containers leveraging cloud-native technology at the edge.
36 | {{% /home-component %}}
37 |
38 | {{% home-component icon="icons/connected.svg" title="Connected" color="kanto-feature" url="about/#cloud-connectivity" url_text="Read more" %}}
39 | Connect devices to most fit-for-purpose IoT cloud ecosystems to manage devices and device data remotely with minimum customization and prototype quickly.
40 | {{% /home-component %}}
41 |
42 | {{% home-component icon="icons/flexible.svg" title="Flexible" color="kanto-feature" url="about/#flexible-deployment" url_text="Read more" %}}
43 | Choose and combine Eclipse Kanto's reusable, configurable and interoperable building blocks to bring the right IoT edge capabilities depending on the hardware and use case.
44 | {{% /home-component %}}
45 |
46 | {{< /home-component-list >}}
47 |
--------------------------------------------------------------------------------
/web/site/content/about/_index.html:
--------------------------------------------------------------------------------
1 | ---
2 | title: "About"
3 | linkTitle: "About"
4 | menu:
5 | main:
6 | weight: 2
7 | description: >
8 | About Eclipse Kanto features.
9 | aliases: ["/about/"]
10 | ---
11 |
12 | {{< blocks/cover title="About Eclipse Kanto" image_anchor="top" height="min" color="kanto-primary">}}
13 |
motivation | overview | features
14 | {{< /blocks/cover >}}
15 |
16 |
17 | {{% include file="about/motivation.md" title="Motivation" ref="motivation" %}}
18 | {{% include file="about/overview.md" title="Overview" ref="overview" %}}
19 | {{% include file="about/features.md" title="Features" ref="features" %}}
20 |
21 |
--------------------------------------------------------------------------------
/web/site/content/about/features.md:
--------------------------------------------------------------------------------
1 | ### Cloud connectivity
2 |
3 | {{% alert color="primary" %}}
4 | Connect devices to the Bosch IoT Suite cloud services, powered by Eclipse Hono™:
5 |
6 | * Basic and certificate-based device authentication
7 | * Auto-registration of edge devices using certificates
8 | * Device telemetry data and operations handling
9 | * Configurable connectivity recovery mechanisms
10 | * Messages-based synchronization on connectivity recovered
11 |
12 | {{% /alert %}}
13 |
14 |
15 |
16 | ### Digital twins
17 |
18 | {{% alert color="secondary" %}}
19 | Represent connected edge devices and semantically model their capabilities, powered by Eclipse Ditto™ and Eclipse Vorto™:
20 |
21 | * Device state, data and operations handling via Eclipse Ditto™ digital twins
22 | * Ready-to-use pre-defined Eclipse Vorto™ semantic models for all Eclipse Kanto features
23 | * Out-of-the box support for existing and customized device capability modelled via Eclipse Vorto
24 |
25 | {{% /alert %}}
26 |
27 |
28 |
29 | ### Local communication
30 |
31 | {{% alert color="primary" %}}
32 | Develop loosely coupled event-driven applications that exchange messages over Eclipse Mosquitto™ as a local MQTT broker:
33 |
34 | * MQTT broker access control via local basic authentication support
35 | * Мessages forwarding between applications running on the edge device and to the cloud
36 | * Access and manage connected IoT devices, IoT device data and services in cloud and at the edge via Eclipse Ditto protocol
37 |
38 | {{% /alert %}}
39 |
40 |
41 |
42 | ### Lightweight container management
43 |
44 | {{% alert color="secondary" %}}
45 | Pluggable container management optimized for edge use cases to enable a secured, isolated and reliable
46 | deployment mechanism and runtime for edge applications:
47 |
48 | * Lightweight management layer that integrates with a container technology of choice - containerd, podman, Docker, LXC and more
49 | * Uniform API for containers lifecycle, state, networking, host resources access and usage management
50 | * Pluggable architecture enabling transparent container management components exchange and customizations on different levels
51 | * Remote deployment and management of containers via Eclipse Ditto digital twins and Eclipse Vorto models
52 | * Working with private and public secured container image registries
53 |
54 | {{% /alert %}}
55 |
56 |
57 |
58 | ### Flexible software updates
59 |
60 | {{% alert color="primary" %}}
61 | Deploy and manage various software artifacts at the edge by using open and generic software update model, powered by Eclipse Vorto and Eclipse hawkBit™:
62 |
63 | * Extensible and configurable software download and installation flows to enable update of any software
64 | * Ready-to-use script-based software updates to easily implement specific download and install operations, progress tracking, artifact
65 | validation, on start up resume and more
66 |
67 | {{% /alert %}}
68 |
69 |
70 |
71 | ### Flexible file uploads
72 |
73 | {{% alert color="secondary" %}}
74 | Upload files like logs, configurations, diagnostics, backups and more using backend storage of choice:
75 |
76 | * Ready-to-use integrations with Azure Cloud Storage and AWS S3 buckets
77 | * Configuration for periodic uploads or explicitly trigger file upload from the device and more
78 |
79 | {{% /alert %}}
80 |
81 |
82 |
83 | ### Flexible deployment
84 |
85 | {{% alert color="primary" %}}
86 | Choose and combine configurable building blocks deployable on wide range of edge platforms:
87 |
88 | * Specifically optimized for constrained devices to offer compact footprint and optimal utilization of resources
89 | * Configurable features to allow additional resources allocation fine tuning
90 | * Ready-to-use builds for Linux ARM, Linux ARM64, Linux x86_64
91 | * Integrated with open hardware platforms like Raspberry Pi
92 |
93 | {{% /alert %}}
94 |
--------------------------------------------------------------------------------
/web/site/content/about/motivation.md:
--------------------------------------------------------------------------------
1 | We are living in an era of digitization, in which companies are reshaping their operations and innovating their business models by offering next generation connected products and digital services. Machines, consumer goods and vehicles are transforming into complex connected IoT devices with advanced software features, collecting and reacting on user insights and data in real-time in secure and safe way.
2 |
3 | Edge computing is shifting from hardware to software focusing on intelligent devices, edge platforms, edge applications and services. New connected products continuously increase in complexity to benefit AIoT – be it built into the products or empowering the production lines. Building the products of the future such as connected vehicles and in vehicle cross-domain applications, connected appliances, smart buildings and connected manufacturing is becoming more and more complex and companies are losing time and money to build the common technologies by themselves, sometimes even lacking the right skills and expertise.
4 |
5 | We bring our knowledge and 20+ years of IoT and edge experience in the open source to enable true collaboration, technology co-development and co-innovation! We address the sheer complexity of edge software and hardware via open technology and ecosystem approach ensuring freedom of choice with vendor-neutral, independent jointly-developed software that goes at the heart of manufactured devices.
6 |
--------------------------------------------------------------------------------
/web/site/content/about/overview.md:
--------------------------------------------------------------------------------
1 | Eclipse Kanto™ is a modular IoT edge software that enables devices for IoT with all essentials like cloud connectivity, digital twins, local communication, container management, and software updates - all configurable and remotely manageable by an IoT cloud ecosystem of choice.
2 |
3 |
4 | Eclipse Kanto makes it possible to deploy intelligence on the device so companies can get more value from diverse edge assets, process and act on IoT data right on the device and manage devices from the cloud. Device manufacturers can add new revenue streams with connected products and ensure agile development for hardware and software.
5 |
6 |
7 | Using Eclipse Kanto, technology teams take advantage of configurable and reusable building blocks to connect the unconnected or build the edge applications for the next generation connected products and services.
8 |
9 |
10 | Eclipse Kanto is specifically optimized for complex IoT devices facing limited hardware resources, (near) real-time requirements, diverse device software, heterogeneous data sources and the ability to operate without connection. This makes it a perfect technology for emerging paradigms such as software-defined vehicles, connected machines and connected manufacturing, smart appliances, smart buildings and more.
11 |
--------------------------------------------------------------------------------
/web/site/content/community/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Community"
3 | linkTitle: "Community"
4 | type: community
5 | menu:
6 | main:
7 | weight: 4
8 | ---
9 |
--------------------------------------------------------------------------------
/web/site/content/docs/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | linkTitle: "Documentation"
3 | type: docs
4 | menu:
5 | main:
6 | weight: 3
7 | ---
8 |
9 |
--------------------------------------------------------------------------------
/web/site/content/docs/concepts/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Concepts"
3 | type: docs
4 | weight: 3
5 | description: >
6 | Explore key essentials of Eclipse Kanto.
7 | ---
--------------------------------------------------------------------------------
/web/site/content/docs/concepts/aws-connector.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "AWS Connector"
3 | type: docs
4 | description: >
5 | Empower the edge device with a remote connectivity.
6 | weight: 1
7 | ---
8 |
9 | AWS Connector enables the remote connectivity to an AWS IoT cloud ecosystem. It provides the following use cases:
10 |
11 | * **Enriched remote connection**
12 | * **Optimized** - to pass the messages via a single underlying connection
13 | * **Secured** - to protect the edge identity and data via TLS with basic and certificate-based authentication
14 | * **Maintained** - with a reconnect exponential backoff algorithm
15 | * **Synchronized** - on a connectivity recovering via a message buffering
16 | * **Application protection** - AWS Connector is the only one component with a remote connectivity i.e. all local applications are protected from exposure to the public network
17 | * **Offline mode** - local applications don't need to care about the status of the remote connection, they can stay fully operable in offline mode
18 | * **Device Shadow** - messages sent to the [Twin Channel](https://eclipse.dev/ditto/protocol-twinlive.html#twin) are converted to messages more suitable for [AWS Device Shadow](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-document.html) service and sent to it.
19 |
20 | 
21 |
22 | ### How it works
23 |
24 | The AWS Connector plays a key role in two communication aspects - local and remote.
25 |
26 | #### Cloud connectivity
27 |
28 | To initiate its connection, the edge has to be manually or automatically provisioned. The result of this operation is different parameters and identifiers. Currently, AWS Connector supports MQTT transport as a connection-oriented and requiring less resources in comparison to AMQP. Once established, the connection is used as a channel to pass the edge telemetry and event messages. The IoT cloud can control the edge via commands and responses.
29 |
30 | In case of a connection interruption, the AWS Connector will switch to offline mode. The message buffer mechanism will be activated to ensure that there is no data loss. Reconnect exponential backoff algorithm will be started to guarantee that no excessive load will be generated to the IoT cloud. All local applications are not affected and can continue to operate as normal. Once the remote connection is restored, all buffered messages will be sent and the edge will be fully restored to online mode.
31 |
32 | #### Local communication
33 |
34 | Ensuring that local applications are loosely coupled, Eclipse Hono™ MQTT definitions are in use. The event-driven local messages exchange is done via a MQTT message broker - Eclipse Mosquitto™. The AWS Connector takes the responsibility to forward these messages to the IoT cloud and vice versa.
35 |
36 | Monitoring of the remote connection status is also enabled locally as well, along with details like the last known state of the connection, timestamp and a predefined connect/disconnect reason.
37 |
--------------------------------------------------------------------------------
/web/site/content/docs/concepts/container-management.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Container management"
3 | type: docs
4 | description: >
5 | Empower the edge device for containerized applications.
6 | weight: 2
7 | ---
8 |
9 | Container management enables a lightweight standard runtime which is capable to run containerized applications with all advantages of the technology: isolation, portability and efficiency. The deployment and management are available both locally and remotely via an IoT cloud ecosystem of choice. The following use cases are provided:
10 |
11 | * **Standardized approach** - with OCI (Open Container Initiative) compliant container images and runtime
12 | * **Lightweight runtime** - with a default integration of {{% refn "https://containerd.io/" %}}`containerd`{{% /refn %}} and a possibility for another container technology of choice like podman, LXC and more
13 | * **Isolation** - with a default isolation from other containerized applications and the host system
14 | * **Portability** - with an option to run one and the same containerized application on different platforms
15 | * **Pluggable architecture** - with extension points on different levels
16 |
17 | 
18 |
19 | ### How it works
20 |
21 | A container image packs the application executable along with all its needed dependencies into a single artifact that can be built by a tooling of choice.
22 | The built image is made available for usage by being pushed to a container image registry where the runtime can refer it to.
23 |
24 | To create a new container instance, the container management uses such an image reference and a configuration for it to produce a fully functional container.
25 | The container lifecycle (start, update, stop, remove) and environment (memory constraints, restart policy, etc.) are also handled by the runtime.
26 | The container management continuously ensures the applications availability via state awareness and restart policies, provides monitoring via flexible logging and fine-grained resources management.
27 | All of that is achieved on top of an underlying runtime of choice ({{% refn "https://containerd.io/" %}}`containerd`{{% /refn %}} by default) that takes care of the low-level isolation mechanisms.
28 |
--------------------------------------------------------------------------------
/web/site/content/docs/concepts/file-upload.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "File upload"
3 | type: docs
4 | description: >
5 | Empower the edge device to upload files to various storage providers.
6 | weight: 7
7 | ---
8 |
9 | File upload enables sending of files to a backend storage of choice. It can be used both locally and remotely via a desired IoT cloud ecosystem. The following use cases are provided:
10 |
11 | * **Storage diversity** - with ready to use integrations with Azure Blob Storage, Amazon S3 and standard HTTP upload
12 | * **Automatic uploads** - with periodically triggered uploads at a specified interval in a given time frame
13 | * **Data integrity** - with an option to calculate and send the integrity check required information
14 | * **Operation monitoring** - with a status reporting of the upload operation
15 |
16 | 
17 |
18 | ### How it works
19 |
20 | It's not always possible to inline all the data into exchanged messages. For example, large log files or large diagnostic files cannot be sent as a telemetry message. In such scenarios, file upload can assist enabling massive amount of data to be stored to the backend storage.
21 |
22 | There are different triggers which can initiate the upload operation: periodic or explicit. Once initiated, the request will be sent to the IoT cloud for confirmation or cancellation transferred back to the edge. If starting is confirmed, the files
23 | to upload will be selected according to the specified configuration, their integrity check information can be calculated and the transfer of the binary content will begin. A status report is announced on each step of the upload process
24 | enabling its transparent monitoring.
25 |
26 | ### What's next
27 |
28 | [How to upload files]({{< relref "upload-files" >}})
--------------------------------------------------------------------------------
/web/site/content/docs/concepts/local-digital-twins.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Local digital twins"
3 | type: docs
4 | description: >
5 | Empower the edge device with local digital twins for more advanced offline scenarios.
6 | weight: 6
7 | ---
8 |
9 | Local digital twins enables the digital twin state on a local level even in offline scenarios. It provides the following use cases:
10 |
11 | * **Mirrors the applications**
12 | * **Persistency** - digital twins are stored locally
13 | * **Cloud connectivity** - provide connectivity to the cloud (similar to [Suite connector]({{< relref "suite-connector" >}}))
14 | * **Offline scenarios** - local applications stay fully operable as if the connection with the cloud is not interrupted
15 | **Synchronization** - when connection to the cloud is established the last known digital twin state is synchronized
16 |
17 | 
18 |
19 | ### How it works
20 |
21 | Similar to the [Suite connector]({{< relref "suite-connector" >}}) service the **local digital twins** service needs to establish a connection to the cloud. To do this this the edge has to be manually or automatically provisioned. This connection is then used as a channel to pass the edge telemetry and event messages. Once a connection is established the device can be operated via commands.
22 |
23 | To ensure that the digital twin state is available on a local level even in offline mode (no matter of the connection state) the **local digital twins** service persist all changes locally. Such capabilities were implemented to support offline scenarios and advanced edge computing involving synchronization with the cloud after disruptions or outages. The synchronization mechanisms were also designed in a way to significantly reduce data traffic, and efficiently prevent data loss due to long-lasting disruptions.
24 |
25 | Upon reconnection, the **local digital twins** will notify the cloud of any changes during the offline mode and synchronize the digital twins state.
26 |
27 | The synchronization works in both directions:
28 | * Cloud -> Local digital twins - desired properties are updated if such changes are requested from the cloud.
29 | * Local digital twins -> Cloud - local digital twins state is sent to the cloud (e.g. all current features, their reported properties values, and any removed features while there was no connection).
30 |
31 | ### What's next
32 |
33 | [How to receive offline the structure of your edge device.]({{< relref "../how-to-guides/offline-edge-device" >}})
--------------------------------------------------------------------------------
/web/site/content/docs/concepts/software-update.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Software update"
3 | type: docs
4 | description: >
5 | Empower the edge device to handle diverse software updates.
6 | weight: 3
7 | ---
8 |
9 | Software update enables the deployment and management of various software artifacts, both locally and remotely via an IoT cloud ecosystem of choice. It provides the following use cases:
10 |
11 | * **Robust download** - with a retry and resume mechanism when the network connection is interrupted
12 | * **Artifact validation** - with an integrity validation of every downloaded artifact
13 | * **Universal installation** - with customizable install scripts to handle any kind of software
14 | * **Operation monitoring** - with a status reporting of the download and install operations
15 |
16 | 
17 |
18 | ### How it works
19 |
20 | When the install operation is received at the edge, the download process is initiated. Retrieving the artifacts will continue until they are stored at the edge or their size threshold is reached. If successful, the artifacts are validated for integrity and further processed by the configured script. It is responsible to apply the new software and finish the operation. A status report is announced on each step of the process enabling its transparent monitoring.
21 |
22 | On start up, if there have been any ongoing operations, they will be automatically resumed as the operation state is persistently stored.
23 |
24 | ### What's next
25 |
26 | [How to update software]({{< relref "update-software" >}})
27 |
--------------------------------------------------------------------------------
/web/site/content/docs/concepts/suite-connector.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Suite connector"
3 | type: docs
4 | description: >
5 | Empower the edge device with a remote connectivity.
6 | weight: 5
7 | ---
8 |
9 | Suite connector enables the remote connectivity to an IoT cloud ecosystem of choice, powered by Eclipse Hono™ (e.g. {{% refn "https://www.eclipse.org/packages/packages/cloud2edge" %}}Eclipse Cloud2Edge{{% /refn %}} and Bosch IoT Suite). It provides the following use cases:
10 |
11 | * **Enriched remote connection**
12 | * **Optimized** - to pass the messages via a single underlying connection
13 | * **Secured** - to protect the edge identity and data via TLS with basic and certificate-based authentication
14 | * **Maintained** - with a reconnect exponential backoff algorithm
15 | * **Synchronized** - on a connectivity recovering via a message buffering
16 | * **Application protection** - suite connector is the only one component with a remote connectivity i.e. all local applications are protected from exposure to the public network
17 | * **Offline mode** - local applications don't need to care about the status of the remote connection, they can stay fully operable in offline mode
18 |
19 | 
20 |
21 | ### How it works
22 |
23 | The suite connector plays a key role in two communication aspects - local and remote.
24 |
25 | #### Cloud connectivity
26 |
27 | To initiate its connection, the edge has to be manually or automatically provisioned. The result of this operation is different parameters and identifiers. Currently, suite connector supports MQTT transport as a connection-oriented and requiring less resources in comparison to AMQP. Once established, the connection is used as a channel to pass the edge telemetry and event messages. The IoT cloud can control the edge via commands and responses.
28 |
29 | In case of a connection interruption, the suite connector will switch to offline mode. The message buffer mechanism will be activated to ensure that there is no data loss. Reconnect exponential backoff algorithm will be started to guarantee that no excessive load will be generated to the IoT cloud. All local applications are not affected and can continue to operate as normal. Once the remote connection is restored, all buffered messages will be sent and the edge will be fully restored to online mode.
30 |
31 | #### Local communication
32 |
33 | Ensuring that local applications are loosely coupled, Eclipse Hono™ MQTT definitions are in use. The event-driven local messages exchange is done via a MQTT message broker - Eclipse Mosquitto™. The suite connector takes the responsibility to forward these messages to the IoT cloud and vice versa.
34 |
35 | The provisioning information used to establish the remote communication is available locally both on request via a predefined message and on update populated via an announcement. Applications that would like to extend the edge functionality can further use it in Eclipse Hono™ and Eclipse Ditto™ definitions.
36 |
37 | Monitoring of the remote connection status is also enabled locally as well, along with details like the last known state of the connection, timestamp and a predefined connect/disconnect reason.
38 |
--------------------------------------------------------------------------------
/web/site/content/docs/concepts/update-manager.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Update manager"
3 | type: docs
4 | description: >
5 | Empower the edge device for OTA updates.
6 | weight: 4
7 | ---
8 |
9 | Update manager enables a lightweight core component which is capable to easily perform complex OTA update scenarios on a target device. The following capabilities are provided:
10 |
11 | * **Lightweight** - consists of a single core component which orchestrates the update process
12 | * **Flexible deployment** - supports different deployment models - natively, as an executable or container
13 | * **Unified API** - all domain agents utilize a unified Update Agent API for interacting with the Update Manager
14 | * **MQTT Connectivity** - the connectivity and communication between the Update Manager and domain agent is MQTT-based
15 | * **Multi-domain integration** - easily integrates, scales and performs complex update operations across multiple domains
16 | * **Default update agents** - integrates with the Kanto provided out-of-the box domain update agent implementation for deployment of container into the Kanto container management
17 | * **Pluggable architecture** - provides an extensible model for plug-in custom orchestration logic
18 | * **Asynchronous updates** - asynchronous and independent update process across the different domains
19 | * **Multi-staged updates** - the update process is organized into different stages
20 | * **Configurable** - offers a variety of configuration options for connectivity, supported domains, message reporting and etc
21 |
22 | 
23 |
24 | ### How it works
25 |
26 | The update process is initiated by sending the desired state specification as an MQTT message towards the device, which is handled by the Update Manager component.
27 |
28 | The desired state specification in the scope of the Update Manager is a JSON-based document, which consists of multiple component definitions per domain, representing the desired state to be applied on the target device.
29 | A component in the same context means a single, atomic and updatable unit, for example, OCI-compliant container, software application or firmware image.
30 |
31 | Each domain agent is a separate and independent software component, which implements the Update Agent API for interaction with the Update Manager and manages the update logic for concrete domain. For example - container management.
32 |
33 | The Update Manager, operating as a coordinator, is responsible for processing the desired state specification, distributing the split specification across the different domain agents, orchestrating the update process via MQTT-based commands, collecting and consolidating the feedback responses from the domain update agents, and reporting the final result of the update campaign to the backend.
34 |
35 | As extra features and capabilities, the Update Manager enables reboot of the host after the update process is completed and reporting of the current state of the system to the backend.
--------------------------------------------------------------------------------
/web/site/content/docs/getting-started/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Getting started"
3 | type: docs
4 | description: >
5 | Explore different ways to connect and manage your edge device remotely using Eclipse Kanto.
6 | weight: 2
7 | ---
8 |
--------------------------------------------------------------------------------
/web/site/content/docs/getting-started/install.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Install Eclipse Kanto"
3 | type: docs
4 | description: >
5 | Run Eclipse Kanto on your edge device.
6 | weight: 1
7 | ---
8 |
9 | ### Before you begin
10 |
11 | The `containerd` Debian package is required. You can install it manually or run:
12 |
13 | ```shell
14 | curl -fsSL https://github.com/eclipse-kanto/kanto/raw/main/quickstart/install_ctrd.sh | sh
15 | ```
16 |
17 | ### Install Eclipse Kanto
18 |
19 | Choose the Eclipse Kanto Debian package for your target device architecture from the ones available
20 | at the project's GitHub Releases page.
21 | Download and install it via executing the following (adjusted to your package name):
22 |
23 | ```shell
24 | wget https://github.com/eclipse-kanto/kanto/releases/download/v1.0.0/kanto_1.0.0_linux_x86_64.deb && \
25 | sudo apt install ./kanto_1.0.0_linux_x86_64.deb
26 | ```
27 |
28 | ### Verify
29 |
30 | It's important to check if all the services provided by the Eclipse Kanto package are up and running successfully. You
31 | can quickly do that via executing:
32 |
33 | ```shell
34 | systemctl status \
35 | suite-connector.service \
36 | container-management.service \
37 | software-update.service \
38 | file-upload.service \
39 | file-backup.service \
40 | system-metrics.service \
41 | kanto-update-manager.service
42 | ```
43 |
44 | All listed services must be in an active running state.
45 |
46 | ### What's next
47 |
48 | [Explore via Eclipse Hono]({{< relref "hono" >}})
49 |
--------------------------------------------------------------------------------
/web/site/content/docs/how-to-guides/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "How-to guides"
3 | type: docs
4 | weight: 4
5 | description: >
6 | Explore the functionalities of Eclipse Kanto.
7 | ---
--------------------------------------------------------------------------------
/web/site/content/docs/how-to-guides/backup-restore-files.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Back up and restore files"
3 | type: docs
4 | description: >
5 | Back up and restore a file from and to your edge device.
6 | weight: 3
7 | ---
8 |
9 | By following the steps below you will back up a simple text file to an HTTP file server
10 | and then restore it back via a publicly available Eclipse Hono sandbox using Eclipse Kanto.
11 | A simple Eclipse Hono northbound business application written in Python is
12 | provided to explore the capabilities for remotely backing up and restoring files.
13 |
14 | ### Before you begin
15 |
16 | To ensure that all steps in this guide can be executed, you need:
17 |
18 | * {{% refn "https://github.com/sebageek/servefile/" %}}`servefile`{{% /refn %}} installed
19 |
20 | This is a small Python HTTP server used in the example to serve the uploads and downloads.
21 | It does not have to be running on your edge device, but it has to be accessible from there.
22 | You can install it by executing:
23 |
24 | ```shell
25 | pip3 install servefile
26 | ```
27 |
28 | * If you don't have an installed and running Eclipse Kanto on your edge device,
29 | follow {{% relrefn "install" %}} Install Eclipse Kanto {{% /relrefn %}}
30 | * If you don't have a connected Eclipse Kanto to Eclipse Hono sandbox,
31 | follow {{% relrefn "hono" %}} Explore via Eclipse Hono {{% /relrefn %}}
32 |
33 | * The {{% refn "https://github.com/eclipse-kanto/kanto/blob/main/quickstart/hono_commands_fb.py" %}}
34 | file backup and restore application {{% /refn %}}
35 |
36 | Navigate to the `quickstart` folder where the resources from the {{% relrefn "hono" %}} Explore via Eclipse Hono
37 | {{% /relrefn %}} guide are located and execute the following script:
38 |
39 | ```shell
40 | wget https://github.com/eclipse-kanto/kanto/raw/main/quickstart/hono_commands_fb.py
41 | ```
42 |
43 | ### Back up
44 |
45 | By default, all directories in `/var/tmp/file-backup/` or the directory itself can be backed up.
46 | For this example, create a file `data.txt` which will be later backed up:
47 |
48 | ```shell
49 | sudo mkdir -p /var/tmp/file-backup && sudo echo "This is the first line in the file!" >> /var/tmp/file-backup/data.txt
50 | ```
51 |
52 | You can verify that the file was successfully created by executing the following command:
53 |
54 | ```shell
55 | cat /var/tmp/file-backup/data.txt
56 | ```
57 |
58 | This should produce `This is the first line in the file!` as an output.
59 |
60 | Choose a directory where the text file will be uploaded, open a new terminal there and run `servefile`
61 | with the flag `-u` to enable a file upload:
62 |
63 | ```shell
64 | servefile -u .
65 | ```
66 |
67 | To explore the file backup, we will use a Python script to request and monitor the operation.
68 | The location where the Python application will run does not have to be your edge device as it communicates remotely
69 | with Eclipse Hono only.
70 |
71 | Now we are ready to request the text file backup from the edge via executing the application that requires the command
72 | to execute (`backup`), Eclipse Hono tenant (`-t`), the device identifier (`-d`) and the host where the backup will
73 | be uploaded to:
74 |
75 | ```shell
76 | python3 hono_commands_fb.py backup -t demo -d demo:device -h localhost
77 | ```
78 |
79 | You can check out that the backup file `data.zip` is on your HTTP file server by
80 | listing the content of the `servefile` working directory.
81 |
82 | ### Restore
83 |
84 | To explore the restore capabilities you will first modify the `data.txt` file, and then you will restore it to
85 | the version before the changes by using the backup, that was created earlier.
86 |
87 | You can modify the `data.txt` file with the following command:
88 |
89 | ```shell
90 | sudo echo "This is the second line in the file!" >> /var/tmp/file-backup/data.txt
91 | ```
92 |
93 | You can verify that the file was successfully updated by executing the following command:
94 |
95 | ```shell
96 | cat /var/tmp/file-backup/data.txt
97 | ```
98 |
99 | This output should be:
100 | ```text
101 | This is the first line in the file!
102 | This is the second line in the file!
103 | ```
104 |
105 | Navigate to the terminal where `servefile` was started and terminate it.
106 | Start it again with the flag `-l` to enable a file download:
107 |
108 | ```shell
109 | servefile -l .
110 | ```
111 |
112 | To explore the file restore, we will use a Python script to request and monitor the operation.
113 | The location where the Python application will run does not have to be your edge device as it communicates remotely
114 | with Eclipse Hono only.
115 |
116 | Now we are ready to request the text file restore from the edge via executing the application that requires the command
117 | to execute (`restore`), Eclipse Hono tenant (`-t`), the device identifier (`-d`) and the host where the backup file
118 | will be downloaded from:
119 |
120 | ```shell
121 | python3 hono_commands_fb.py restore -t demo -d demo:device -h localhost
122 | ```
123 |
124 | ### Verify
125 |
126 | You can check out that the original file is restored by executing the following command:
127 |
128 | ```shell
129 | cat /var/tmp/file-backup/data.txt
130 | ```
131 |
132 | This should produce `This is the first line in the file!` as an output.
133 |
134 | ### Clean up
135 |
136 | Stop `servefile` and clean up its working directory.
137 | Remove the `data.txt` file from the `/var/tmp/file-backup` directory.
138 |
--------------------------------------------------------------------------------
/web/site/content/docs/how-to-guides/monitor-system-metrics.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Monitor system metrics"
3 | type: docs
4 | description: >
5 | Monitor system metrics from your edge device.
6 | weight: 4
7 | ---
8 |
9 | By following the steps below you will be able to monitor the system metrics from your edge device
10 | via a publicly available Eclipse Hono sandbox using Eclipse Kanto. A simple Eclipse Hono
11 | northbound business application written in Python is provided to explore the capabilities
12 | for remotely monitoring the CPU and memory utilization.
13 |
14 | ### Before you begin
15 |
16 | To ensure that all steps in this guide can be executed, you need:
17 |
18 | * {{% refn "https://plotly.com/" %}}`Plotly`{{% /refn %}} and
19 | {{% refn "https://plotly.com/dash/" %}}`Dash`{{% /refn %}} installed
20 |
21 | {{% refn "https://plotly.com/" %}}`Plotly`{{% /refn %}} is an open-source plotting library and
22 | {{% refn "https://plotly.com/dash/" %}}`Dash`{{% /refn %}} is a framework for building data application in Python.
23 | They are used in this example to run a simple HTTP server and visualize the incoming system metrics data
24 | in real time, and they do not have to be running on your edge device.
25 | You can install them by executing:
26 |
27 | ```shell
28 | pip3 install plotly dash
29 | ```
30 |
31 | * If you don't have an installed and running Eclipse Kanto on your edge device,
32 | follow {{% relrefn "install" %}} Install Eclipse Kanto {{% /relrefn %}}
33 | * If you don't have a connected Eclipse Kanto to Eclipse Hono sandbox,
34 | follow {{% relrefn "hono" %}} Explore via Eclipse Hono {{% /relrefn %}}
35 |
36 | * The {{% refn "https://github.com/eclipse-kanto/kanto/blob/main/quickstart/hono_commands_sm.py" %}}
37 | system metrics application {{% /refn %}}
38 |
39 | Navigate to the `quickstart` folder where the resources from the {{% relrefn "hono" %}} Explore via Eclipse Hono
40 | {{% /relrefn %}} guide are located and execute the following script:
41 |
42 | ```shell
43 | wget https://github.com/eclipse-kanto/kanto/raw/main/quickstart/hono_commands_sm.py
44 | ```
45 |
46 | ### Monitor system metrics
47 |
48 | To explore the system metrics, we will use a Python script to request and monitor the
49 | CPU and memory utilization. The location where the Python application will run does
50 | not have to be your edge device as it communicates remotely with Eclipse Hono only.
51 |
52 | Now we are ready to request the system metrics from the edge via executing the application
53 | that requires the Eclipse Hono tenant (`-t`) and the device identifier (`-d`):
54 |
55 | ```shell
56 | python3 hono_commands_sm.py -t demo -d demo:device
57 | ```
58 |
59 | ### Verify
60 |
61 | You can check out that the CPU and memory utilization metrics are properly received and displayed
62 | by checking out the application dashboard (by default - {{% refn "http://127.0.0.1:8050" %}}http://127.0.0.1:8050{{% /refn %}}).
63 |
--------------------------------------------------------------------------------
/web/site/content/docs/how-to-guides/offline-edge-device.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Offline explore edge device"
3 | type: docs
4 | description: >
5 | Offline receive the structure of your edge device.
6 | weight: 6
7 | ---
8 |
9 | By following the steps below, you will get the structure of the edge digital twins with all its features and properties using Eclipse Kanto.
10 | A simple Eclipse Hono northbound business application written in Python is provided to display the things' and their features' structure.
11 |
12 | ### Before you begin
13 |
14 | To ensure that your edge device is capable to execute the steps in this guide, you need:
15 |
16 | * If you don't have an installed and running Eclipse Kanto on your edge device,
17 | follow {{% relrefn "install" %}} Install Eclipse Kanto {{% /relrefn %}}
18 |
19 | * If you don't have a connected Eclipse Kanto to Eclipse Hono sandbox,
20 | follow {{% relrefn "hono" %}} Explore via Eclipse Hono {{% /relrefn %}}
21 |
22 | * Stop `suite-connector.service`. The local digital twins service is a replacement for the suite connector service, that is why either one of the services must be running.
23 |
24 | ```shell
25 | sudo systemctl stop suite-connector.service
26 | ```
27 |
28 | * The {{% refn "https://github.com/eclipse-kanto/kanto/blob/main/quickstart/hono_commands_ldt.py" %}} offline explore application {{% /refn %}}
29 |
30 | Navigate to the `quickstart` folder where the resources from the {{% relrefn "hono" %}} Explore via Eclipse Hono {{% /relrefn %}} guide are located and execute the following script:
31 |
32 | ```shell
33 | wget https://github.com/eclipse-kanto/kanto/raw/main/quickstart/hono_commands_ldt.py
34 | ```
35 |
36 | ### Configure Local digital twins
37 |
38 | Open file `/etc/suite-connector/config.json`, copy `tenantId`, `deviceId`, `authId` and `password`.
39 | ```json
40 | {
41 | ...
42 | "tenantId": "demo",
43 | "deviceId": "demo:device",
44 | "authId": "demo_device",
45 | "password": "secret"
46 | ...
47 | }
48 | ```
49 | The local digital twins service uses the `/etc/local-digital-twins/config.json` to acquire all the remote communication, identification and
50 | authentication data to establish the remote connection. Update the configuration as shown below and
51 | replace `tenantId`, `deviceId`, `authId` and `password` with the settings that you copied in the previous step.
52 |
53 | ```json
54 | {
55 | "logFile": "/var/log/local-digital-twins/local-digital-twins.log",
56 | "caCert": "/etc/local-digital-twins/iothub.crt",
57 | "thingsDb": "/var/lib/local-digital-twins/thing.db",
58 | "tenantId": "demo",
59 | "deviceId": "demo:device",
60 | "authId": "demo_device",
61 | "password": "secret"
62 | }
63 | ```
64 |
65 | Save the configuration and start the local digital twins service using the following command:
66 |
67 | ```shell
68 | sudo systemctl start local-digital-twins.service
69 | ```
70 |
71 | ### Receive the structure of the edge device
72 |
73 | Now we are ready to request the structure of the edge digital twins via executing the offline explore application that requires the local digital twins tenant (`-t`) and the device identifier (`-d`):
74 |
75 | ```shell
76 | python3 hono_commands_ldt.py -t demo -d demo:device
77 | ```
78 |
79 | ### Verify
80 |
81 | On the shell there will be output of the structure of the edge digital twins with all its features and properties. Things with the following identifiers will be presented:
82 | * demo:device
83 | * demo:device:edge:containers
84 |
85 | ### Clean up
86 |
87 | Stop the local digital twins service and start suite connector service by executing:
88 | ```shell
89 | sudo systemctl stop local-digital-twins.service && \
90 | sudo systemctl restart suite-connector.service
91 | ```
--------------------------------------------------------------------------------
/web/site/content/docs/how-to-guides/update-software.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Update software"
3 | type: docs
4 | description: >
5 | Install a Debian package on your edge device.
6 | weight: 1
7 | ---
8 |
9 | By following the steps below you will install a{{% refn "https://www.gnu.org/software/hello/" %}}`hello`{{% /refn %}}
10 | Debian package via a publicly available Eclipse Hono sandbox using Eclipse Kanto.
11 | A couple of simple Eclipse Hono northbound business applications written in Python are provided to explore
12 | the capabilities for remotely installing and monitoring.
13 | On the edge side, a basic
14 | {{% refn "https://github.com/eclipse-kanto/kanto/blob/main/quickstart/install_hello.sh" %}}`install_hello.sh`{{% /refn %}}
15 | script will be downloaded and executed.
16 |
17 | ### Before you begin
18 |
19 | To ensure that your edge device is capable to execute the steps in this guide, you need:
20 |
21 | * Debian-based linux distribution and the `apt` command line tool
22 | * If you don't have an installed and running Eclipse Kanto, follow {{% relrefn "install" %}} Install Eclipse Kanto {{% /relrefn %}}
23 | * If you don't have a connected Eclipse Kanto to Eclipse Hono sandbox,
24 | follow {{% relrefn "hono" %}} Explore via Eclipse Hono {{% /relrefn %}}
25 |
26 | * The {{% refn "https://github.com/eclipse-kanto/kanto/blob/main/quickstart/hono_commands_su.py" %}}
27 | software update application {{% /refn %}}
28 |
29 | Navigate to the `quickstart` folder where the resources from the {{% relrefn "hono" %}} Explore via Eclipse Hono {{% /relrefn %}}
30 | guide are located and execute the following script:
31 |
32 | ```shell
33 | wget https://github.com/eclipse-kanto/kanto/raw/main/quickstart/hono_commands_su.py
34 | ```
35 | * Executing `hello` in the terminal will return that the command is not found
36 |
37 | ### Install Debian package
38 |
39 | To explore the software management, we will use two Python scripts to install and monitor the `hello` Debian package.
40 | The location where the Python applications will run does not have to be your edge device as they communicate remotely
41 | with Eclipse Hono only.
42 |
43 | First, start the monitoring application that requires the configured Eclipse Hono tenant (`-t`) and will print all
44 | received events triggered by the device:
45 |
46 | ```shell
47 | python3 hono_events.py -t demo
48 | ```
49 |
50 | In another terminal, we are ready to spin up a `hello` Debian package at the edge via executing the second application
51 | that requires the Eclipse Hono tenant (`-t`) and the device identifier (`-d`):
52 |
53 | ```shell
54 | python3 hono_commands_su.py -t demo -d demo:device
55 | ```
56 |
57 | ### Verify
58 |
59 | You can check out that the new package is installed on your edge device via executing:
60 |
61 | ```shell
62 | hello
63 | ```
64 |
65 | The command now displays: `Hello, world!`
66 |
67 | ### Clean up
68 |
69 | The installed `hello` Debian package can be removed via executing:
70 |
71 | ```shell
72 | sudo apt remove hello
73 | ```
74 |
--------------------------------------------------------------------------------
/web/site/content/docs/how-to-guides/upload-files.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Upload files"
3 | type: docs
4 | description: >
5 | Upload a log file from your edge device.
6 | weight: 2
7 | ---
8 |
9 | By following the steps below you will upload an example log file to your HTTP file server
10 | via a publicly available Eclipse Hono sandbox using Eclipse Kanto.
11 | A simple Eclipse Hono northbound business application written in Python is
12 | provided to explore the capabilities for remotely uploading and monitoring.
13 |
14 | ### Before you begin
15 |
16 | To ensure that all steps in this guide can be executed, you need:
17 |
18 | * {{% refn "https://github.com/sebageek/servefile/" %}}`servefile`{{% /refn %}} installed
19 |
20 | This is a small Python HTTP server used in the example to serve the uploads.
21 | It does not have to be running on your edge device but it has to be accessible from there.
22 | You can install it by executing:
23 |
24 | ```shell
25 | pip3 install servefile
26 | ```
27 |
28 | * If you don't have an installed and running Eclipse Kanto on your edge device,
29 | follow {{% relrefn "install" %}} Install Eclipse Kanto {{% /relrefn %}}
30 | * If you don't have a connected Eclipse Kanto to Eclipse Hono sandbox,
31 | follow {{% relrefn "hono" %}} Explore via Eclipse Hono {{% /relrefn %}}
32 |
33 | * The {{% refn "https://github.com/eclipse-kanto/kanto/blob/main/quickstart/hono_commands_fu.py" %}}
34 | file upload application {{% /refn %}}
35 |
36 | Navigate to the `quickstart` folder where the resources from the {{% relrefn "hono" %}} Explore via Eclipse Hono
37 | {{% /relrefn %}} guide are located and execute the following script:
38 |
39 | ```shell
40 | wget https://github.com/eclipse-kanto/kanto/raw/main/quickstart/hono_commands_fu.py
41 | ```
42 |
43 | ### Upload log file
44 |
45 | By default, all files in `/var/tmp/file-upload/` directory can be uploaded.
46 | For example, grab the suite connector log file and place it in the directory via executing:
47 |
48 | ```shell
49 | mkdir -p /var/tmp/file-upload/ && sudo cp /var/log/suite-connector/suite-connector.log /var/tmp/file-upload/
50 | ```
51 |
52 | Choose a directory where the log file will be uploaded, open a new terminal there and run `servefile`:
53 |
54 | ```shell
55 | servefile -u .
56 | ```
57 |
58 | To explore the file upload, we will use a Python script to request and monitor the operation.
59 | The location where the Python application will run does not have to be your edge device as it communicates remotely
60 | with Eclipse Hono only.
61 |
62 | Now we are ready to request the log file upload from the edge via executing the application
63 | that requires the Eclipse Hono tenant (`-t`) and the device identifier (`-d`):
64 |
65 | ```shell
66 | python3 hono_commands_fu.py -t demo -d demo:device
67 | ```
68 |
69 | ### Verify
70 |
71 | You can check out that the log file is on your HTTP file server by listing the content of `servefile` working directory.
72 |
73 | ### Clean up
74 |
75 | Stop `servefile` and clean up its working directory.
76 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "References"
3 | type: docs
4 | description: >
5 | Explore customization of Eclipse Kanto.
6 | weight: 5
7 | ---
8 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/connectivity/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Remote connectivity configuration"
3 | type: docs
4 | description: >
5 | Customize the remote connectivity and automatic provisioning.
6 | weight: 1
7 | ---
--------------------------------------------------------------------------------
/web/site/content/docs/references/connectivity/aws-connector-config.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "AWS Connector configuration"
3 | type: docs
4 | description: >
5 | Customize the remote connectivity.
6 | weight: 1
7 | ---
8 |
9 | ### Properties
10 |
11 | To control all aspects of the aws connector behavior.
12 |
13 | | Property | Type | Default | Description |
14 | | - | - | - | - |
15 | | topicFilter | string | | Regex filter used to block incoming messages by their topic |
16 | | payloadFilters | string | | Regex filters used to exclude parts of the incoming messages payload |
17 | | **Remote connectivity** | | | |
18 | | address | string | | Address of the MQTT endpoint that the connector will connect for the remote communication, the format is: `scheme://host:port` |
19 | | tenantId | string | default-tenant-id | Tenant unique identifier that the device belongs to |
20 | | clientId | string | | MQTT client unique identifier |
21 | | **Remote connectivity - TLS** | | | |
22 | | alpn | string[] | | TLS application layer protocol negotiation options space separated for cloud access |
23 | | caCert | string | aws.crt | PEM encoded CA certificates file |
24 | | cert | string | | PEM encoded certificate file to authenticate to the MQTT endpoint |
25 | | key | string | | PEM encoded unencrypted private key file to authenticate to the MQTT endpoint |
26 | | **Remote connectivity - TLS over TPM** | | | |
27 | | tpmDevice | string | | Path to the device file or the unix socket to access the TPM 2.0 |
28 | | tpmHandle | int | | TPM 2.0 storage root key handle, the type is unsigned 64-bit integer |
29 | | tpmKeyPub | string | | File path to the public part of the TPM 2.0 key |
30 | | tpmKey | string | | File path to the private part of the TPM 2.0 key |
31 | | **Local connectivity** | | | |
32 | | localAddress | string | tcp://localhost:1883 | Address of the MQTT server/broker that the aws connector will connect for the local communication, the format is: `scheme://host:port` |
33 | | localUsername | string | | Username that is a part of the credentials |
34 | | localPassword | string | | Password that is a part of the credentials |
35 | | **Local connectivity - TLS** | | | |
36 | | localCACert | string | | PEM encoded CA certificates file |
37 | | localCert | string | | PEM encoded certificate file to authenticate to the MQTT server/broker |
38 | | localKey | string | | PEM encoded unencrypted private key file to authenticate to the MQTT server/broker |
39 | | **Logging** | | | |
40 | | logFile | string | logs/aws-connector.log | Path to the file where log messages are written |
41 | | logLevel | string | INFO | All log messages at this or a higher level will be logged, the log levels in descending order are: ERROR, WARN, INFO, DEBUG and TRACE |
42 | | logFileCount | int | 5 | Log file maximum rotations count |
43 | | logFileMaxAge | int | 28 | Log file rotations maximum age in days, use 0 to not remove old log files |
44 | | logFileSize | int | 2 | Log file size in MB before it gets rotated |
45 |
46 | ### Example
47 |
48 | The minimal required configuration to connect.
49 |
50 | ```json
51 | {
52 | "address": "tls://:8883",
53 | "caCert": "AmazonRootCA1.pem",
54 | "cert": "example-device.crt",
55 | "key": "example-device.key",
56 | "clientId": "org.eclipse.kanto:exampleDevice",
57 | "logFile": "/var/log/aws-connector/aws-connector.log"
58 | }
59 | ```
60 |
61 | ### Template
62 |
63 | The configuration can be further adjusted according to the use case.
64 | The following template illustrates all possible properties with their default values.
65 |
66 | {{% warn %}}
67 | Be aware that some combinations may be incompatible
68 | {{% /warn %}}
69 |
70 | ```json
71 | {
72 | "topicFilter": "",
73 | "payloadFilters": [],
74 | "address": "",
75 | "tenantId": "default-tenant-id",
76 | "clientId": "",
77 | "alpn" : [],
78 | "caCert": "aws.crt",
79 | "cert": "",
80 | "key": "",
81 | "tpmDevice": "",
82 | "tpmHandle": 0,
83 | "tpmKeyPub": "",
84 | "tpmKey": "",
85 | "localAddress": "tcp://localhost:1883",
86 | "localUsername": "",
87 | "localPassword": "",
88 | "localCACert": "",
89 | "localCert": "",
90 | "localKey": "",
91 | "logFile": "logs/aws-connector.log",
92 | "logLevel": "INFO",
93 | "logFileCount": 5,
94 | "logFileMaxAge": 28,
95 | "logFileSize": 2
96 | }
97 | ```
98 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/connectivity/azure-connector-config.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Azure Connector configuration"
3 | type: docs
4 | description: >
5 | Customize the remote connectivity.
6 | weight: 2
7 | ---
8 |
9 | ### Properties
10 |
11 | To control all aspects of the azure connector behavior.
12 |
13 | | Property | Type | Default | Description |
14 | | - | - | - | - |
15 | | tenantId | string | defaultTenant | Tenant unique identifier that the device belongs to |
16 | | connectionString | string | | The connection string for connectivity to Azure IoT Hub, the format is: `"HostName=newHostName.azure-devices.net;DeviceId=deviceId;SharedAccessKey=accessKey"` |
17 | | sasTokenValidity | string | 1h | The validity period for the generated SAS token for device authentication. Positive integer number followed by a unit suffix, such as '300m', '1h', etc., time units are: m, h, d |
18 | | idScope | string | | ID scope for Azure Device Provisioning service |
19 | | **Remote connectivity - TLS** | | | |
20 | | alpn | string[] | | TLS application layer protocol negotiation options space separated for cloud access |
21 | | caCert | string | iothub.crt | PEM encoded CA certificates file |
22 | | cert | string | | PEM encoded certificate file to authenticate to the MQTT endpoint |
23 | | key | string | | PEM encoded unencrypted private key file to authenticate to the MQTT endpoint |
24 | | **Remote connectivity - TLS over TPM** | | | |
25 | | tpmDevice | string | | Path to the device file or the unix socket to access the TPM 2.0 |
26 | | tpmHandle | int | | TPM 2.0 storage root key handle, the type is unsigned 64-bit integer |
27 | | tpmKeyPub | string | | File path to the public part of the TPM 2.0 key |
28 | | tpmKey | string | | File path to the private part of the TPM 2.0 key |
29 | | **Local connectivity** | | | |
30 | | localAddress | string | tcp://localhost:1883 | Address of the MQTT server/broker that the azure connector will connect for the local communication, the format is: `scheme://host:port` |
31 | | localUsername | string | | Username that is a part of the credentials |
32 | | localPassword | string | | Password that is a part of the credentials |
33 | | **Local connectivity - TLS** | | | |
34 | | localCACert | string | | PEM encoded CA certificates file |
35 | | localCert | string | | PEM encoded certificate file to authenticate to the MQTT server/broker |
36 | | localKey | string | | PEM encoded unencrypted private key file to authenticate to the MQTT server/broker |
37 | | **Logging** | | | |
38 | | logFile | string | logs/azure-connector.log | Path to the file where log messages are written |
39 | | logLevel | string | INFO | All log messages at this or a higher level will be logged, the log levels in descending order are: ERROR, WARN, INFO, DEBUG and TRACE |
40 | | logFileCount | int | 5 | Log file maximum rotations count |
41 | | logFileMaxAge | int | 28 | Log file rotations maximum age in days, use 0 to not remove old log files |
42 | | logFileSize | int | 2 | Log file size in MB before it gets rotated |
43 |
44 | ### Example
45 |
46 | The minimal required configuration to connect.
47 |
48 | ```json
49 | {
50 | "connectionString": "HostName=hostName.azure-devices.net;DeviceId=deviceId;SharedAccessKey=cGFzc3AvcKQ=",
51 | "caCert": "/etc/azure-connector/iothub.crt",
52 | "logFile": "/var/log/azure-connector/azure-connector.log"
53 | }
54 | ```
55 |
56 | ### Template
57 |
58 | The configuration can be further adjusted according to the use case.
59 | The following template illustrates all possible properties with their default values.
60 |
61 | {{% warn %}}
62 | Be aware that some combinations may be incompatible
63 | {{% /warn %}}
64 |
65 | ```json
66 | {
67 | "tenantId": "defaultTenant",
68 | "connectionString": "",
69 | "sasTokenValidity": "1h",
70 | "idScope": "",
71 | "alpn" : [],
72 | "caCert": "iothub.crt",
73 | "cert": "",
74 | "key": "",
75 | "tpmDevice": "",
76 | "tpmHandle": 0,
77 | "tpmKeyPub": "",
78 | "tpmKey": "",
79 | "localAddress": "tcp://localhost:1883",
80 | "localUsername": "",
81 | "localPassword": "",
82 | "localCACert": "",
83 | "localCert": "",
84 | "localKey": "",
85 | "logFile": "logs/azure-connector.log",
86 | "logLevel": "INFO",
87 | "logFileCount": 5,
88 | "logFileMaxAge": 28,
89 | "logFileSize": 2
90 | }
91 | ```
92 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/connectivity/local-digital-twins-config.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Local digital twins configuration"
3 | type: docs
4 | description: >
5 | Customize the local digital twins persistency, access and synchronization.
6 | weight: 4
7 | ---
8 |
9 | ### Properties
10 |
11 | To control all aspects of the local digital twins behavior.
12 |
13 | | Property | Type | Default | Description |
14 | | - | - | - | - |
15 | | thingsDb | string | things.db | Path to the file where digital twins will be stored |
16 | | **Remote connectivity** | | | |
17 | | address | string | mqtts://mqtt.bosch-iot-hub.com:8883 | Address of the MQTT endpoint that the local digital twins will connect for the remote communication, the format is: `scheme://host:port` |
18 | | deviceId | string | | Device unique identifier |
19 | | authId | string | | Authentication unique identifier that is a part of the credentials |
20 | | tenantId | string | | Tenant unique identifier that the device belongs to |
21 | | password | string | | Password that is a part of the credentials |
22 | | clientId | string | | MQTT client unique identifier |
23 | | policyId | string | | Policy unique identifier of the digital twin |
24 | | **Remote connectivity - TLS** | | | |
25 | | caCert | string | iothub.crt | PEM encoded CA certificates file |
26 | | cert | string | | PEM encoded certificate file to authenticate to the MQTT endpoint |
27 | | key | string | | PEM encoded unencrypted private key file to authenticate to the MQTT endpoint |
28 | | deviceIdPattern | string | | Pattern to generate the device identifier, `{{subject-dn}}` and `{{subject-cn}}` placeholders can be part of it |
29 | | **Remote connectivity - TLS over TPM** | | | |
30 | | tpmDevice | string | | Path to the device file or the unix socket to access the TPM 2.0 |
31 | | tpmHandle | int | | TPM 2.0 storage root key handle, the type is unsigned 64-bit integer |
32 | | tpmKeyPub | string | | File path to the public part of the TPM 2.0 key |
33 | | tpmKey | string | | File path to the private part of the TPM 2.0 key |
34 | | **Local connectivity** | | | |
35 | | localAddress | string | tcp://localhost:1883 | Address of the MQTT server/broker that the local digital twins will connect for the local communication, the format is: `scheme://host:port` |
36 | | localUsername | string | | Username that is a part of the credentials |
37 | | localPassword | string | | Password that is a part of the credentials |
38 | | **Local connectivity - TLS** | | | |
39 | | localCACert | string | | PEM encoded CA certificates file |
40 | | localCert | string | | PEM encoded certificate file to authenticate to the MQTT server/broker |
41 | | localKey | string | | PEM encoded unencrypted private key file to authenticate to the MQTT server/broker |
42 | | **Logging** | | | |
43 | | logFile | string | log/local-digital-twins.log | Path to the file where log messages are written |
44 | | logLevel | string | INFO | All log messages at this or a higher level will be logged, the log levels in descending order are: ERROR, WARN, INFO, DEBUG and TRACE |
45 | | logFileCount | int | 5 | Log file maximum rotations count |
46 | | logFileMaxAge | int | 28 | Log file rotations maximum age in days, use 0 to not remove old log files |
47 | | logFileSize | int | 2 | Log file size in MB before it gets rotated |
48 |
49 | ### Example
50 |
51 | The minimal required configuration to enable the local digital twins and their synchronization with the publicly available {{% refn "https://www.eclipse.org/hono/sandbox/" %}}Eclipse Hono sandbox{{% /refn %}}.
52 |
53 | ```json
54 | {
55 | "address": "hono.eclipseprojects.io:1883",
56 | "caCert": "/etc/local-digital-twins/iothub.crt",
57 | "tenantId": "org.eclipse.kanto",
58 | "deviceId": "org.eclipse.kanto:exampleDevice",
59 | "authId": "org.eclipse.kanto_example",
60 | "password": "secret",
61 | "thingsDb": "/var/lib/local-digital-twins/thing.db",
62 | "logFile": "/var/log/local-digital-twins/local-digital-twins.log"
63 | }
64 | ```
65 |
66 | ### Template
67 |
68 | The configuration can be further adjusted according to the use case.
69 | The following template illustrates all possible properties with their default values.
70 |
71 | {{% warn %}}
72 | Be aware that some combinations may be incompatible
73 | {{% /warn %}}
74 |
75 | ```json
76 | {
77 | "thingsDb": "things.db",
78 | "address": "mqtts://mqtt.bosch-iot-hub.com:8883",
79 | "deviceId": "",
80 | "authId": "",
81 | "tenantId": "",
82 | "password": "",
83 | "clientId": "",
84 | "policyId": "",
85 | "caCert": "iothub.crt",
86 | "cert": "",
87 | "key": "",
88 | "deviceIdPattern": "",
89 | "tpmDevice": "",
90 | "tpmHandle": 0,
91 | "tpmKeyPub": "",
92 | "tpmKey": "",
93 | "localAddress": "tcp://localhost:1883",
94 | "localUsername": "",
95 | "localPassword": "",
96 | "localCACert": "",
97 | "localCert": "",
98 | "localKey": "",
99 | "logFile": "log/local-digital-twins.log",
100 | "logLevel": "INFO",
101 | "logFileCount": 5,
102 | "logFileMaxAge": 28,
103 | "logFileSize": 2
104 | }
105 | ```
--------------------------------------------------------------------------------
/web/site/content/docs/references/connectivity/suite-connector-config.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Suite connector configuration"
3 | type: docs
4 | description: >
5 | Customize the remote connectivity.
6 | weight: 3
7 | ---
8 |
9 | ### Properties
10 |
11 | To control all aspects of the suite connector behavior.
12 |
13 | | Property | Type | Default | Description |
14 | | - | - | - | - |
15 | | **Remote connectivity** | | | |
16 | | address | string | mqtts://mqtt.bosch-iot-hub.com:8883 | Address of the MQTT endpoint that the suite connector will connect for the remote communication, the format is: `scheme://host:port` |
17 | | deviceId | string | | Device unique identifier |
18 | | authId | string | | Authentication unique identifier that is a part of the credentials |
19 | | tenantId | string | | Tenant unique identifier that the device belongs to |
20 | | username | string | | MQTT username that is a part of the credentials. This parameter takes precedence over authId and tenantId |
21 | | password | string | | Password that is a part of the credentials |
22 | | clientId | string | | MQTT client unique identifier |
23 | | policyId | string | | Policy unique identifier of the digital twin |
24 | | generic | bool | | Force use of modified topics for cloud access |
25 | | **Remote connectivity - TLS** | | | |
26 | | alpn | string[] | | TLS application layer protocol negotiation options space separated for cloud access |
27 | | caCert | string | iothub.crt | PEM encoded CA certificates file |
28 | | cert | string | | PEM encoded certificate file to authenticate to the MQTT endpoint |
29 | | key | string | | PEM encoded unencrypted private key file to authenticate to the MQTT endpoint |
30 | | deviceIdPattern | string | | Pattern to generate the device identifier, `{{subject-dn}}` and `{{subject-cn}}` placeholders can be part of it |
31 | | **Remote connectivity - TLS over TPM** | | | |
32 | | tpmDevice | string | | Path to the device file or the unix socket to access the TPM 2.0 |
33 | | tpmHandle | int | | TPM 2.0 storage root key handle, the type is unsigned 64-bit integer |
34 | | tpmKeyPub | string | | File path to the public part of the TPM 2.0 key |
35 | | tpmKey | string | | File path to the private part of the TPM 2.0 key |
36 | | **Local connectivity** | | | |
37 | | localAddress | string | tcp://localhost:1883 | Address of the MQTT server/broker that the suite connector will connect for the local communication, the format is: `scheme://host:port` |
38 | | localUsername | string | | Username that is a part of the credentials |
39 | | localPassword | string | | Password that is a part of the credentials |
40 | | **Local connectivity - TLS** | | | |
41 | | localCACert | string | | PEM encoded CA certificates file |
42 | | localCert | string | | PEM encoded certificate file to authenticate to the MQTT server/broker |
43 | | localKey | string | | PEM encoded unencrypted private key file to authenticate to the MQTT server/broker |
44 | | **Logging** | | | |
45 | | logFile | string | log/suite-connector.log | Path to the file where log messages are written |
46 | | logLevel | string | INFO | All log messages at this or a higher level will be logged, the log levels in descending order are: ERROR, WARN, INFO, DEBUG and TRACE |
47 | | logFileCount | int | 5 | Log file maximum rotations count |
48 | | logFileMaxAge | int | 28 | Log file rotations maximum age in days, use 0 to not remove old log files |
49 | | logFileSize | int | 2 | Log file size in MB before it gets rotated |
50 |
51 | ### Example
52 |
53 | The minimal required configuration to connect the publicly available
54 | {{% refn "https://www.eclipse.org/hono/sandbox/" %}}Eclipse Hono sandbox{{% /refn %}}.
55 |
56 | ```json
57 | {
58 | "address": "hono.eclipseprojects.io:1883",
59 | "caCert": "/etc/suite-connector/iothub.crt",
60 | "tenantId": "org.eclipse.kanto",
61 | "deviceId": "org.eclipse.kanto:exampleDevice",
62 | "authId": "org.eclipse.kanto_example",
63 | "password": "secret",
64 | "logFile": "/var/log/suite-connector/suite-connector.log"
65 | }
66 | ```
67 |
68 | ### Template
69 |
70 | The configuration can be further adjusted according to the use case.
71 | The following template illustrates all possible properties with their default values.
72 |
73 | {{% warn %}}
74 | Be aware that some combinations may be incompatible
75 | {{% /warn %}}
76 |
77 | ```json
78 | {
79 | "address": "mqtts://mqtt.bosch-iot-hub.com:8883",
80 | "deviceId": "",
81 | "authId": "",
82 | "tenantId": "",
83 | "username": "",
84 | "password": "",
85 | "clientId": "",
86 | "policyId": "",
87 | "generic": false,
88 | "alpn" : [],
89 | "caCert": "iothub.crt",
90 | "cert": "",
91 | "key": "",
92 | "deviceIdPattern": "",
93 | "tpmDevice": "",
94 | "tpmHandle": 0,
95 | "tpmKeyPub": "",
96 | "tpmKey": "",
97 | "localAddress": "tcp://localhost:1883",
98 | "localUsername": "",
99 | "localPassword": "",
100 | "localCACert": "",
101 | "localCert": "",
102 | "localKey": "",
103 | "logFile": "log/suite-connector.log",
104 | "logLevel": "INFO",
105 | "logFileCount": 5,
106 | "logFileMaxAge": 28,
107 | "logFileSize": 2
108 | }
109 | ```
110 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/containers/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Container management configuration"
3 | type: docs
4 | description: >
5 | Customize the deployment and management of containers.
6 | weight: 3
7 | ---
8 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/containers/api-reference/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "API Reference"
3 | type: docs
4 | description: >
5 | API Reference for the Container Management Things service.
6 | weight: 3
7 | ---
8 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/file-backup/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "File Backup"
3 | type: docs
4 | description: >
5 | Customize the files backup and restore to and from a backend storage.
6 | weight: 6
7 | ---
8 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/file-backup/file-backup-config.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "File backup configuration"
3 | type: docs
4 | description: >
5 | Customize the files backup and restore to and from a backend storage.
6 | weight: 3
7 | ---
8 |
9 | ### Properties
10 |
11 | To control all aspects of the file backup behavior.
12 |
13 | | Property | Type | Default | Description |
14 | | - | - | - | - |
15 | | featureId | string | BackupAndRestore | Feature unique identifier in the scope of the edge digital twin |
16 | | type | string | file | Type of the files that are backed up by this feature |
17 | | context | string | edge | Context of the files backed up by this feature, unique in the scope of the `type` |
18 | | dir | string | | Directory to be backed up |
19 | | mode | string | strict | Restriction on directories that can be dynamically selected for a backup, the supported modes are: strict, lax and scoped |
20 | | backupCmd | string | | Command to be executed before the backup is done |
21 | | restoreCmd | string | | Command to be executed after the restore |
22 | | singleUpload | bool | false | Forbid triggering of new backups when there is a backup in progress |
23 | | checksum | bool | false | Send MD5 checksum for backed up files to ensure data integrity |
24 | | stopTimeout | string | 30s | Time to wait for running backups to finish as a sequence of decimal numbers, each with optional fraction and a unit suffix, such as: 300ms, 1.5h, 10m30s, etc., time units are: ns, us (or µs), ms, s, m, h |
25 | | keepUploaded | bool | false | Keep successfully uploaded backups locally |
26 | | storage | string | ./storage | Directory where backups and downloads will be stored |
27 | | **Upload/Download - TLS** | | | |
28 | | serverCert| string | | PEM encoded certificate file for secure uploads and downloads |
29 | | **Auto backup** | | | |
30 | | active | bool | false | Activate periodic backups |
31 | | activeFrom | string | | Time from which periodic backups should be active, in RFC 3339 format, if omitted (and `active` flag is set) current time will be used as start of the periodic backups |
32 | | activeTill | string | | Time till which periodic backups should be active, in RFC 3339 format, if omitted (and `active` flag is set) periodic backups will be active indefinitely |
33 | | period | string | 10h| Backup period as a sequence of decimal numbers, each with optional fraction and a unit suffix, such as: 300ms, 1.5h, 10m30s, etc., time units are: ns, us (or µs), ms, s, m, h |
34 | | **Local connectivity** | | | |
35 | | broker | string | tcp://localhost:1883 | Address of the MQTT server/broker that the file backup will connect for the local communication, the format is: `scheme://host:port` |
36 | | username | string | | Username that is a part of the credentials |
37 | | password | string | | Password that is a part of the credentials |
38 | | **Local connectivity - TLS** | | | |
39 | | caCert | string | | PEM encoded CA certificates file |
40 | | cert | string | | PEM encoded certificate file to authenticate to the MQTT server/broker |
41 | | key | string | | PEM encoded unencrypted private key file to authenticate to the MQTT server/broker |
42 | | **Logging** | | | |
43 | | logFile | string | log/file-backup.log | Path to the file where log messages are written |
44 | | logLevel | string | INFO | All log messages at this or a higher level will be logged, the log levels in descending order are: ERROR, WARN, INFO, DEBUG and TRACE |
45 | | logFileCount | int | 5 | Log file maximum rotations count |
46 | | logFileMaxAge | int | 28 | Log file rotations maximum age in days, use 0 to not remove old log files |
47 | | logFileSize | int | 2 | Log file size in MB before it gets rotated |
48 |
49 | ### Example
50 |
51 | The minimal required configuration that enables backing up a directory and sets the file type to config.
52 |
53 | ```json
54 | {
55 | "type": "config",
56 | "dir": "/var/tmp/file-backup",
57 | "mode": "scoped",
58 | "storage": "/var/lib/file-backup",
59 | "logFile": "/var/log/file-backup/file-backup.log"
60 | }
61 | ```
62 |
63 | ### Template
64 |
65 | The configuration can be further adjusted according to the use case.
66 | The following template illustrates all possible properties with their default values.
67 |
68 | {{% warn %}}
69 | Be aware that some combinations may be incompatible.
70 | {{% /warn %}}
71 |
72 | ```json
73 | {
74 | "featureId": "BackupAndRestore",
75 | "type": "file",
76 | "context": "edge",
77 | "dir": "",
78 | "mode": "strict",
79 | "backupCmd": "",
80 | "restoreCmd": "",
81 | "singleUpload": false,
82 | "checksum": false,
83 | "stopTimeout": "30s",
84 | "keepUploaded": false,
85 | "storage": "./storage",
86 | "serverCert": "",
87 | "active": false,
88 | "activeFrom": "",
89 | "activeTill": "",
90 | "period": "10h",
91 | "broker": "tcp://localhost:1883",
92 | "username": "",
93 | "password": "",
94 | "caCert": "",
95 | "cert": "",
96 | "key": "",
97 | "logFile": "log/file-backup.log",
98 | "logLevel": "INFO",
99 | "logFileCount": 5,
100 | "logFileMaxAge": 28,
101 | "logFileSize": 2
102 | }
103 | ```
104 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/file-upload/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "File Upload"
3 | type: docs
4 | description: >
5 | Customize the files transfer to a backend storage.
6 | weight: 5
7 | ---
8 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/file-upload/file-upload-config.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "File upload configuration"
3 | type: docs
4 | description: >
5 | Customize the files transfer to a backend storage.
6 | weight: 3
7 | ---
8 |
9 | ### Properties
10 |
11 | To control all aspects of the file upload behavior.
12 |
13 | | Property | Type | Default | Description |
14 | | - | - | - | - |
15 | | featureId | string | AutoUploadable | Feature unique identifier in the scope of the edge digital twin |
16 | | type | string | file | Type of the files that are uploaded by this feature |
17 | | context | string | edge | Context of the files that are uploaded by this feature, unique in the scope of the `type` |
18 | | files | string | | Glob pattern to select the files for upload |
19 | | mode | string | strict | Restriction on files that can be dynamically selected for an upload, the supported modes are: strict, lax and scoped |
20 | | singleUpload | bool | false | Forbid triggering of new uploads when there is an upload in progress |
21 | | checksum | bool | false | Send MD5 checksum for uploaded files to ensure data integrity |
22 | | stopTimeout | string | 30s | Time to wait for running uploads to finish as a sequence of decimal numbers, each with optional fraction and a unit suffix, such as: 300ms, 1.5h, 10m30s, etc., time units are: ns, us (or µs), ms, s, m, h |
23 | | delete | bool | false | Delete successfully uploaded files |
24 | | **Upload - TLS** | | | |
25 | | serverCert| string | | PEM encoded certificate file for secure uploads |
26 | | **Auto upload** | | | |
27 | | active | bool | false | Activate periodic uploads |
28 | | activeFrom | string | | Time from which periodic uploads should be active, in RFC 3339 format, if omitted (and `active` flag is set) current time will be used as start of the periodic uploads |
29 | | activeTill | string | | Time till which periodic uploads should be active, in RFC 3339 format, if omitted (and `active` flag is set) periodic uploads will be active indefinitely |
30 | | period | string | 10h | Upload period as a sequence of decimal numbers, each with optional fraction and a unit suffix, such as: 300ms, 1.5h, 10m30s, etc., time units are: ns, us (or µs), ms, s, m, h |
31 | | **Local connectivity** | | | |
32 | | broker | string | tcp://localhost:1883 | Address of the MQTT server/broker that the file upload will connect for the local communication, the format is: `scheme://host:port` |
33 | | username | string | | Username that is a part of the credentials |
34 | | password | string | | Password that is a part of the credentials |
35 | | **Local connectivity - TLS** | | | |
36 | | caCert | string | | PEM encoded CA certificates file |
37 | | cert | string | | PEM encoded certificate file to authenticate to the MQTT server/broker |
38 | | key | string | | PEM encoded unencrypted private key file to authenticate to the MQTT server/broker |
39 | | **Logging** | | | |
40 | | logFile | string | log/file-upload.log | Path to the file where log messages are written |
41 | | logLevel | string | INFO | All log messages at this or higher level will be logged, the log levels in descending order are: ERROR, WARN, INFO, DEBUG and TRACE |
42 | | logFileCount | int | 5 | Log file maximum rotations count |
43 | | logFileMaxAge | int | 28 | Log file rotations maximum age in days, use 0 to not remove old log files |
44 | | logFileSize | int | 2 | Log file size in MB before it gets rotated |
45 |
46 | ### Example
47 |
48 | The minimal required configuration that sets the file type to log.
49 |
50 | ```json
51 | {
52 | "type": "log",
53 | "files": "/var/tmp/file-upload/*.*",
54 | "logFile": "/var/log/file-upload/file-upload.log"
55 | }
56 | ```
57 |
58 | ### Template
59 |
60 | The configuration can be further adjusted according to the use case.
61 | The following template illustrates all possible properties with their default values.
62 |
63 | ```json
64 | {
65 | "featureId": "AutoUploadable",
66 | "type": "file",
67 | "context": "edge",
68 | "files": "",
69 | "mode": "strict",
70 | "singleUpload": false,
71 | "checksum": false,
72 | "stopTimeout": "30s",
73 | "delete": false,
74 | "serverCert": "",
75 | "active": false,
76 | "activeFrom": "",
77 | "activeTill": "",
78 | "period": "10h",
79 | "broker": "tcp://localhost:1883",
80 | "username": "",
81 | "password": "",
82 | "caCert": "",
83 | "cert": "",
84 | "key": "",
85 | "logFile": "log/file-upload.log",
86 | "logLevel": "INFO",
87 | "logFileCount": 5,
88 | "logFileMaxAge": 28,
89 | "logFileSize": 2
90 | }
91 | ```
92 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/software-updatable/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Software Updatable"
3 | type: docs
4 | description: >
5 | Customize the deployment and management of software artifacts.
6 | weight: 4
7 | ---
8 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/software-updatable/software-update-config.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Software update configuration"
3 | type: docs
4 | description: >
5 | Customize the deployment and management of software artifacts.
6 | weight: 3
7 | ---
8 |
9 | ### Properties
10 |
11 | To control all aspects of the software update behavior.
12 |
13 | | Property | Type | Default | Description |
14 | | - | - | - | - |
15 | | featureId | string | SoftwareUpdatable | Feature unique identifier in the scope of the edge digital twin |
16 | | moduleType | string | software | Type of the software that is managed by this feature |
17 | | artifactType | string | archive | Type of the artifact that is to be processed: archive or plain |
18 | | install | string[] | | Absolute path to the install script/command and an optional sequence of additional flags/parameters |
19 | | storageLocation | string | ./ | Path to the storage directory where the working files are stored |
20 | | installDirs | string[] | | File system directories where the local artifacts are stored |
21 | | mode | string | strict | Restriction where the local artifacts can be stored on the file system, the supported modes are: strict, lax and scope |
22 | | **Download** | | | |
23 | | downloadRetryCount | int| 0 | Number of retries, in case of a failed download |
24 | | downloadRetryInterval | string | 5s | Interval between retries, in case of a failed download as a sequence of decimal numbers, each with optional fraction and a unit suffix, such as: 300ms, 1.5h, 10m30s, etc., time units are: ns, us (or µs), ms, s, m, h |
25 | | **Download - TLS** | | | |
26 | | serverCert | string | | PEM encoded certificate file for secure downloads |
27 | | **Local connectivity** | | | |
28 | | broker | string | tcp://localhost:1883 | Address of the MQTT server/broker that the software update will connect for the local communication, the format is: `scheme://host:port` |
29 | | username | string | | Username that is a part of the credentials |
30 | | password | string | | Password that is a part of the credentials |
31 | | **Local connectivity - TLS** | | | |
32 | | caCert | string | | PEM encoded CA certificates file |
33 | | cert | string | | PEM encoded certificate file to authenticate to the MQTT server/broker |
34 | | key | string | | PEM encoded unencrypted private key file to authenticate to the MQTT server/broker |
35 | | **Logging** | | | |
36 | | logFile | string | log/software-update.log | Path to the file where log messages are written |
37 | | logLevel | string | INFO | All log messages at this or higher level will be logged, the log levels in descending order are: ERROR, WARN, INFO, DEBUG and TRACE |
38 | | logFileCount | int | 5 | Log file maximum rotations count |
39 | | logFileMaxAge | int | 28 | Log file rotations maximum age in days, use 0 to not remove old log files |
40 | | logFileSize | int | 2 | Log file size in MB before it gets rotated |
41 |
42 | ### Example
43 |
44 | The minimal required configuration that sets the software type to firmware.
45 |
46 | ```json
47 | {
48 | "moduleType": "firmware",
49 | "storageLocation": "/var/lib/software-update",
50 | "logFile": "/var/log/software-update/software-update.log"
51 | }
52 | ```
53 |
54 | ### Template
55 |
56 | The configuration can be further adjusted according to the use case.
57 | The following template illustrates all possible properties with their default values.
58 |
59 | ```json
60 | {
61 | "featureId": "SoftwareUpdatable",
62 | "moduleType": "software",
63 | "artifactType": "archive",
64 | "install": [],
65 | "storageLocation": "./",
66 | "installDirs": [],
67 | "mode": "strict",
68 | "downloadRetryCount": 0,
69 | "downloadRetryInterval": "5s",
70 | "serverCert": "",
71 | "broker": "tcp://localhost:1883",
72 | "username": "",
73 | "password": "",
74 | "caCert": "",
75 | "cert": "",
76 | "key": "",
77 | "logFile": "log/software-update.log",
78 | "logLevel": "INFO",
79 | "logFileCount": 5,
80 | "logFileMaxAge": 28,
81 | "logFileSize": 2
82 | }
83 | ```
84 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/system-metrics/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "System Metrics"
3 | type: docs
4 | description: >
5 | Customize the reporting of system metrics.
6 | weight: 7
7 | ---
8 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/system-metrics/system-metrics-config.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "System metrics configuration"
3 | type: docs
4 | description: >
5 | Customize the reporting of system metrics.
6 | weight: 3
7 | ---
8 |
9 | ### Properties
10 |
11 | To control all aspects of the system metrics behavior.
12 |
13 | | Property | Type | Default | Description |
14 | | - | - | - | - |
15 | | frequency | string | | Initial system metrics reporting frequency as a sequence of decimal numbers, each with optional fraction and a unit suffix, such as: 300ms, 1.5h, 10m30s, etc., time units are: ns, us (or µs), ms, s, m, h |
16 | | **Local connectivity** | | | |
17 | | broker | string | tcp://localhost:1883 | Address of the MQTT server/broker that the system metrics will connect for the local communication, the format is: `scheme://host:port` |
18 | | username | string | | Username that is a part of the credentials |
19 | | password | string | | Password that is a part of the credentials |
20 | | **Local connectivity - TLS** | | | |
21 | | caCert | string | | PEM encoded CA certificates file |
22 | | clientCert | string | | PEM encoded certificate file to authenticate to the MQTT server/broker |
23 | | clientKey | string | | PEM encoded unencrypted private key file to authenticate to the MQTT server/broker |
24 | | **Logging** | | | |
25 | | logFile | string | log/system-metrics.log | Path to the file where log messages are written |
26 | | logLevel | string | INFO | All log messages at this or higher level will be logged, the log levels in descending order are: ERROR, WARN, INFO, DEBUG and TRACE |
27 | | logFileCount | int | 5 | Log file maximum rotations count |
28 | | logFileMaxAge | int | 28 | Log file rotations maximum age in days, use 0 to not remove old log files |
29 | | logFileSize | int | 2 | Log file size in MB before it gets rotated |
30 |
31 | ### Example
32 |
33 | The minimal required configuration that enables the auto reporting of system metrics.
34 |
35 | ```json
36 | {
37 | "frequency": "60s",
38 | "logFile": "/var/log/system-metrics/system-metrics.log"
39 | }
40 | ```
41 |
42 | ### Template
43 |
44 | The configuration can be further adjusted according to the use case.
45 | The following template illustrates all possible properties with their default values.
46 |
47 | ```json
48 | {
49 | "frequency" : "",
50 | "broker": "tcp://localhost:1883",
51 | "username": "",
52 | "password": "",
53 | "caCert": "",
54 | "clientCert": "",
55 | "cleintKey": "",
56 | "logFile": "log/system-metrics.log",
57 | "logLevel": "INFO",
58 | "logFileCount": 5,
59 | "logFileMaxAge": 28,
60 | "logFileSize": 2
61 | }
62 | ```
63 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/update-manager/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Update Manager"
3 | type: docs
4 | description: >
5 | The kanto update manager service provides orchestration of OTA Updates towards a target device in a smart way.
6 | weight: 8
7 | ---
8 |
--------------------------------------------------------------------------------
/web/site/content/docs/references/update-manager/update-manager-config.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Update manager configuration"
3 | type: docs
4 | description: >
5 | Customize the update manager.
6 | weight: 6
7 | ---
8 |
9 | ### Properties
10 |
11 | To control all aspects of the update manager.
12 |
13 | | Property | Type | Default | Description |
14 | | - | - | - | - |
15 | | **General** | | | |
16 | | domain | string | device | The domain of the update manager, used as MQTT topic prefix |
17 | | domains | string | containers| A comma-separated list of domains handled by the update manager. This configuration option is available only as a flag, but not inside the JSON config file. In JSON config file, the keys inside the Domain agents structure serve as domain names. |
18 | | phaseTimeout | string | 10m | Timeout as duration string for completing an Update Orchestration phase |
19 | | rebootAfter | string | 30s | Time period as duration string to wait before a reboot process is initiated after successful update operation |
20 | | rebootEnabled | bool | true | Enable the reboot process after successful update operation |
21 | | reportFeedbackInterval | string | 1m | Time interval as duration string for reporting intermediate desired state feedback messages during an active update operation |
22 | | currentStateDelay | string | 30s | Time interval as duration string for reporting current state messages |
23 | | thingsEnabled | bool | true | Enable the Update Manager to behave as a thing's feature |
24 | | ownerConsentCommands | []string | | List of commands for which an owner consent should be granted. Possible values are: 'DOWNLOAD', 'UPDATE', 'ACTIVATE' |
25 | | ownerConsentTimeout | string | 30m | Timeout as duration string to wait for owner consent" |
26 | | **Domain agents** | | | Holds a map structure (_agents_) with update agent configurations where each map key is treated as domain name |
27 | | readTimeout | string | 1m | Timeout as duration string for reading the current state for the domain |
28 | | rebootRequired | bool | false | Require a reboot for the domain after successful update |
29 | | **Local connectivity** | | | |
30 | | broker | string | tcp://localhost:1883 | Address of the MQTT server/broker that the container manager will connect for the local communication, the format is: `scheme://host:port` |
31 | | keepAlive | string | 20s | Keep alive duration for the MQTT requests as duration string |
32 | | disconnectTimeout | string | 250ms | Disconnect timeout for the MQTT server/broker as duration string |
33 | | username | string | | Username that is a part of the credentials |
34 | | password | string | | Password that is a part of the credentials |
35 | | acknowledgeTimeout | string | 15s | Acknowledge timeout for the MQTT requests as duration string |
36 | | connectTimeout | string | 30s | Connect timeout for the MQTT server/broker as duration string |
37 | | subscribeTimeout | string | 15s | Subscribe timeout for the MQTT requests as duration string |
38 | | unsubscribeTimeout | string | 5s | Unsubscribe timeout for the MQTT requests as duration string |
39 | | **Logging** | | | |
40 | | logFile | string | | Path to the file where the update manager’s log messages are written |
41 | | logLevel | string | INFO | All log messages at this or a higher level will be logged, the log levels in descending order are: ERROR, WARN, INFO, DEBUG and TRACE |
42 | | logFileCount | int | 5 | Log file maximum rotations count |
43 | | logFileMaxAge | int | 28 | Log file rotations maximum age in days, use 0 to not remove old log files |
44 | | logFileSize | int | 2 | Log file size in MB before it gets rotated |
45 |
46 | ### Example
47 |
48 | An example for configuring the update manager with two domains - `containers` and `custom-domain`, report feedback interval at 30 seconds, and log, written to custom log file `update-manager.log` with
49 | log level `DEBUG`.
50 |
51 | ```json
52 | {
53 | "log": {
54 | "logFile": "update-manager.log",
55 | "logLevel": "DEBUG"
56 | },
57 | "agents": {
58 | "containers": {
59 | "readTimeout": "30s"
60 | },
61 | "custom-domain": {
62 | "rebootRequired": true
63 | }
64 | },
65 | "reportFeedbackInterval": "30s"
66 | }
67 | ```
68 |
69 | ### Template
70 |
71 | The configuration can be further adjusted according to the use case.
72 | The following template illustrates all possible properties with their default values.
73 |
74 | ```json
75 | {
76 | "domain": "device",
77 | "agents": {
78 | "containers": {
79 | "rebootRequired": false,
80 | "readTimeout": "1m"
81 | }
82 | },
83 | "log": {
84 | "logFile": "",
85 | "logLevel": "INFO",
86 | "logFileCount": 5,
87 | "logFileMaxAge": 28,
88 | "logFileSize": 2
89 | },
90 | "connection": {
91 | "broker": "tcp://localhost:1883",
92 | "keepAlive": "20s",
93 | "acknowledgeTimeout": "15s",
94 | "username": "",
95 | "password": "",
96 | "connectTimeout": "30a",
97 | "disconnectTimeout": "250ms",
98 | "subscribeTimeout": "15s",
99 | "unsubscribeTimeout": "5s"
100 | },
101 | "phaseTimeout": "10m",
102 | "rebootAfter": "30s",
103 | "rebootEnabled": true,
104 | "reportFeedbackInterval": "1m",
105 | "currentStateDelay": "30s",
106 | "thingsEnabled": true,
107 | "ownerConsentCommands": ["DOWNLOAD"]
108 | }
109 | ```
110 |
--------------------------------------------------------------------------------
/web/site/content/kanto_background.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/eclipse-kanto/kanto/73498a5d1993d44badfec098187a0d42e78c3bca/web/site/content/kanto_background.png
--------------------------------------------------------------------------------
/web/site/content/search.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Search Results
3 | layout: search
4 | ---
5 |
--------------------------------------------------------------------------------
/web/site/go.mod:
--------------------------------------------------------------------------------
1 | module github.com/eclipse-kanto/kanto
2 |
3 | go 1.21.9
4 |
5 | require (
6 | github.com/google/docsy v0.8.0 // indirect
7 | github.com/google/docsy/dependencies v0.7.2 // indirect
8 | )
9 |
--------------------------------------------------------------------------------
/web/site/go.sum:
--------------------------------------------------------------------------------
1 | github.com/FortAwesome/Font-Awesome v0.0.0-20210804190922-7d3d774145ac/go.mod h1:IUgezN/MFpCDIlFezw3L8j83oeiIuYoj28Miwr/KUYo=
2 | github.com/FortAwesome/Font-Awesome v0.0.0-20220831210243-d3a7818c253f/go.mod h1:IUgezN/MFpCDIlFezw3L8j83oeiIuYoj28Miwr/KUYo=
3 | github.com/FortAwesome/Font-Awesome v0.0.0-20230327165841-0698449d50f2/go.mod h1:IUgezN/MFpCDIlFezw3L8j83oeiIuYoj28Miwr/KUYo=
4 | github.com/google/docsy v0.4.0 h1:Eyt2aiDC1fnw/Qq/9xnIqUU5n5Yyk4c8gX3nBDdTv/4=
5 | github.com/google/docsy v0.4.0/go.mod h1:vJjGkHNaw9bO42gpFTWwAUzHZWZEVlK46Kx7ikY5c7Y=
6 | github.com/google/docsy v0.5.0 h1:ND+6sYJD1VYEEM8olBdJLPIyQrPDeDkC0PhzuZTVZMs=
7 | github.com/google/docsy v0.5.0/go.mod h1:RKikAcSUR3b/40oqYfweD9uiNYTUirEKaCgLiEXMbQo=
8 | github.com/google/docsy v0.6.0 h1:43bVF18t2JihAamelQjjGzx1vO2ljCilVrBgetCA8oI=
9 | github.com/google/docsy v0.6.0/go.mod h1:VKKLqD8PQ7AglJc98yBorATfW7GrNVsn0kGXVYF6G+M=
10 | github.com/google/docsy v0.7.0 h1:JaeZ0/KufX/BJ3SyATb/fmZa1DFI7o5d9KU+i6+lLJY=
11 | github.com/google/docsy v0.7.0/go.mod h1:5WhIFchr5BfH6agjcInhpLRz7U7map0bcmKSpcrg6BE=
12 | github.com/google/docsy v0.7.1 h1:DUriA7Nr3lJjNi9Ulev1SfiG1sUYmvyDeU4nTp7uDxY=
13 | github.com/google/docsy v0.7.1/go.mod h1:JCmE+c+izhE0Rvzv3y+AzHhz1KdwlA9Oj5YBMklJcfc=
14 | github.com/google/docsy v0.8.0 h1:RgHyKRTo8YwScMThrf01Ky2yCGpUS1hpkspwNv6szT4=
15 | github.com/google/docsy v0.8.0/go.mod h1:FqTNN2T7pWEGW8dc+v5hQ5VF29W5uaL00PQ1LdVw5F8=
16 | github.com/google/docsy/dependencies v0.4.0/go.mod h1:2zZxHF+2qvkyXhLZtsbnqMotxMukJXLaf8fAZER48oo=
17 | github.com/google/docsy/dependencies v0.5.0/go.mod h1:2zZxHF+2qvkyXhLZtsbnqMotxMukJXLaf8fAZER48oo=
18 | github.com/google/docsy/dependencies v0.6.0/go.mod h1:EDGc2znMbGUw0RW5kWwy2oGgLt0iVXBmoq4UOqstuNE=
19 | github.com/google/docsy/dependencies v0.7.0/go.mod h1:gihhs5gmgeO+wuoay4FwOzob+jYJVyQbNaQOh788lD4=
20 | github.com/google/docsy/dependencies v0.7.1/go.mod h1:gihhs5gmgeO+wuoay4FwOzob+jYJVyQbNaQOh788lD4=
21 | github.com/google/docsy/dependencies v0.7.2 h1:+t5ufoADQAj4XneFphz4A+UU0ICAxmNaRHVWtMYXPSI=
22 | github.com/google/docsy/dependencies v0.7.2/go.mod h1:gihhs5gmgeO+wuoay4FwOzob+jYJVyQbNaQOh788lD4=
23 | github.com/twbs/bootstrap v4.6.1+incompatible/go.mod h1:fZTSrkpSf0/HkL0IIJzvVspTt1r9zuf7XlZau8kpcY0=
24 | github.com/twbs/bootstrap v4.6.2+incompatible/go.mod h1:fZTSrkpSf0/HkL0IIJzvVspTt1r9zuf7XlZau8kpcY0=
25 | github.com/twbs/bootstrap v5.2.3+incompatible/go.mod h1:fZTSrkpSf0/HkL0IIJzvVspTt1r9zuf7XlZau8kpcY0=
26 |
--------------------------------------------------------------------------------
/web/site/layouts/404.html:
--------------------------------------------------------------------------------
1 | {{ define "main"}}
2 |
3 |
4 |
5 |
6 |
Element not found
7 |
The web address you entered is not a functioning page on our site.
8 | Eclipse Kanto is based on lightweight native components, open protocols
9 | and standard containers that ensure availability on hardware, minimum
10 | integration work, reduced complexity and scalable edge applications.