List view
- Due by August 4, 2025•3/3 issues closed
- Due by July 15, 2025•12/12 issues closed
- No due date•4/4 issues closed
- Due by May 5, 2025•55/55 issues closed
- Due by January 14, 2025•3/3 issues closed
- Due by December 19, 2024•1/1 issues closed
- Due by December 17, 2024•41/41 issues closed
- Due by October 4, 2024•7/7 issues closed
- Due by September 17, 2024•15/15 issues closed
- Due by August 1, 2024•26/26 issues closed
- Due by May 29, 2024•2/2 issues closed
- Due by May 22, 2024•26/26 issues closed
- Due by February 15, 2024•5/5 issues closed
- Due by November 14, 2023•9/9 issues closed
- No due date•65/65 issues closed
- Due by November 3, 2023•80/80 issues closed
- No due date•17/17 issues closed
- Due by May 17, 2023•33/33 issues closed
- Due by March 27, 2023•26/26 issues closed
- Due by January 27, 2023•30/30 issues closed
- No due date
- Due by November 11, 2022•8/8 issues closed
- Due by October 27, 2022•14/14 issues closed
- Due by October 12, 2022•10/10 issues closed
**Child Device Product Requirements Document:** **Description: What is it?** Users would like to connect, operate, represent devices (sensors, actors, PLCs, other gateways) which are connected to gateways running thin-edge.io “Child devices” (can also imply multiple hierarchies of devices). **Problem: What problem is this solving?** The support of “child devices” handling indicates multiple needs and problems to be addressed: - Enabling devices for IoT which cannot/should not directly connect to cloud (e.g. due to security risk or missing capabilities) - They can either have thin edge installed or not - Due to security concerns/regulations some users would like to “cascade” multiple devices on different network layers in the factory to ensure network isolation and no direct connection to cloud/higher level layers - To save bandwidth/data amounts, data should be pre-processed on the thin edge device before it is sent to IoT/cloud platform - To have the physical and/or logical device hierarchy also visible in the cloud, enabling better contextualization of data points coming from different devices/assets - Examples: - Sending telemetry from child devices to cloud - Sending operations back to child device (from cloud or parent device) e.g. after processing of data (on cloud or parent device) - Handling device child onboarding & data buffering scenarios during offline periods **Why: How do we know this is a real problem and worth solving** We are dealing with various IoT customers who have articulated the needs above and have validated the general need of child device support, its a very common representation of asset hierarchies **Success: How do we know if we’ve solved this problem?** - We need to measure adoption and amount of thin edge customers with child device usage - Feedback from target users on how they leverage this feature (discovery calls, experiments/POCs, early adopters/testers) - Feedback and number of tickets/requests from community **Audience: Who are we building for?** - IoT project teams who have the challenge to connect and represent devices in IoT platform as “digital twins” - Embedded Engineers who need to integrate devices connected to the parent gateway (thin edge gateway) and leverage the interfaces we offer **What: Roughly, what does this look like in the product?** - A newly created interface/API to create and manage child devices, following consistent design patterns regarding - domain model (representation of child device entity and its properties/meta data, capabilities) - telemetry data handling (measurements, events, alarms) - device management (configuration management, software management, operations handling) - monitoring - Security (e.g. authentication between child and parent, certificate handling, traffic encryption) - Integration with reference IoT platform (e.g. Cumulocity IoT or Azure IoT) **How: What is the experiment plan?** - Interviewing 2 early adopters on their needs regarding thin edge *Results:* - Use-cases from customers on what all they would/could do with child devices - Initial priotization of problems will be created and EPIC list to be created - Solution proposals to be validated with stakeholders - We created a user-facing doc on the telemetry data handling - Create technical design and user journeys + validate with 5 testers - Create simple POC and ask for feedback **When: When does it ship and what are the milestones?** Priorities: - Child-Dev Support for **Measurements** note: already implemented - Child-Dev Support for **Events** note: implementation in progress - Child-Dev Support for **Alarms** note: ready for implementation - Child-Dev Support for **C8Y Configuration Plugin** note: in discovery phase. - a) allow to associate config-files to child-dev twins in the cloud b) allow to consume/provide config-files to/from external devices (or containers), e.g. via network c) allow external devices (or containers) to add own config-files to be handled by c8y config plugin Further Links: The concept and requirements of Child Device Support: https://github.com/thin-edge/thin-edge.io/pull/1195
No due date•3/3 issues closed- No due date•4/4 issues closed
**Requirements** * Based on "new" configuration management in c8y (file based config management) * Download config file from URL and place it on the predefined path on the thin-edge.io system * Should not be limited to specific files (has to be open for users individual files) * **Out of Scope for this Drop** * Restarting any 3rd party components after placing a configuration * Checking about the validity of the configuration
No due date•3/3 issues closedThe thin-edge.io data model should be extended to events. An event is basically like an alarm, but without a severity, it could be a signal without any further information than the type or it could contain some textual information. AC: * thin-edge.io data model supports events under "tedge/events/\<event-type\>" * c8y mapper supports these events (hint smartrest 400) * Empty events with only a type should be possible * Events with some textual information should be possible Out of Scope: * Binary files attached to events (e.g. pictures)
No due date•3/3 issues closed- No due date•1/1 issues closed
- No due date•2/2 issues closed
To apply another thin-edge version to a fleet of thin-edge devices in the field (e.g. due to bug-fixes or new available features), thin-edge shall provide a "thin-edge update mechanism" to update it-self via some Cloud operation. That "thin-edge update mechanism" shall assure that the device is again connected to the cloud after progressing the update-procedure - even if the update-procedure has failed. The basic vision is as below: 1) That "thin-edge update mechanism" shall be encapsulated in a self-contained binary, that contains all parts of the whole "thin-edge update mechanism" (starting from receiving the update operation from cloud, progress it and finally report the result back to the cloud). That is to assure update-mechanism will not overwrite it-self, and so it will still works after a failed update procedure. NOTE 1: On source-code level re-use can achieved with code-sharing. But on level of flash-deployment no dependency to components that will be updated are allowed (e.g. binaries, libraries, configs). That is to assure update-mechanism will no break it-self. 2) take a "thin-edge configuration" snapshot; thin-edge configuration shall be captured and stored before update procedure starts, to allow reproducing the last working one in case update has failed. To be defined: Which configuration(s) are required here. Mosquitto? tedge.toml? ...? 3) take a "thin-edge installation" snapshot; After a successful update store/keep that used "thin-edge update package" and mark it somehow as last working one. That can be used later to role-back in case of any failed update procedure (required for "option 1" in topic no. 5 bellow). To be defined: Check how to have a "working one" on initial device setup. 4) All files (binaries, configurations, service-files, ...) of the "thin-edge update mechanism" shall be wrapped somehow in thin-edge, but initially not be deployed/installed to the final location. Just in case a first successful connection was established to the cloud these files shall be installed by thin-edge to the proper location (and potentially overwrite existing ones). That is to avoid a progressing thin-edge update will overwrite (and potentially break) the executing update-mechanism it-self. Only when update was realized as "successfully finished" (here successful cloud-connection is used as indication), also "thin-edge update mechanism" from the new thin-edge version will be replace old-one. 5) In case cloud-connection permanent fails after update self-healing shall be started. There are two potential options: Option 1: Restore to snapshots; Do rollback by installing "last-working" thin.edge package, and restoring "last working" configuration. Option 2: Restore "last working" configuration to connect again just "thin-edge update mechanism" to cloud. Then wait, and a cloud operator need to restore the device by load the version from before or another one to the device. NOTE: Options to be evaluated during POC phase. Keep in mind that manual required interaction as in Option 2 could lead to extended efforts and device off-times especially for large fleets. 6) For now it is not clear which C8Y operation shall be used to execute "thin-edge update mechanism". Obviously there are two options: Option 1: Use "C8Y firmware update". However there is exactly one firmware update. I.e. when we use that one for "thin-edge update mechanism", we might not be able to use it for others, as "bootloader update" or "kernel update". Option 2: Use a special package type in "Software Management". However it might not be obviously clear for a Cloud Operator about all the impact and risc of "thin-edge update", when having it just as (normal) SW module underneath all other SW modules in the C8Y UI. NOTE: Also do not forget to avoid any dependency to SM agent binary. AC: - proves whether the basic vision from above works and fits for the purpose - details the vision from above - identifies missing things of vision above - identifies downsides and potential improvements of vision above
No due date•7/7 issues closedExtend Thin Edge data model to alarms and events
No due date•3/3 issues closedAs a user i want to see the logs of my software management operations in my cloud platform. The idea is to send the logs for software management that we now have locally to c8y. AC: - Logs of software management operation can be seen in c8y UI on request - Logs should only be sent on request to not pile up to much storage in c8y ( Could be configurable as improvement after MVP) Reference: https://cumulocity.com/guides/10.5.7/reference/device-management/#c8y_logfilerequest https://cumulocity.com/api/#section/Device-management-library/Miscellaneous
No due date•1/1 issues closedAbility to inject EPL files into apama correlator running on thin-edge Using C8Y DM (Software Repository)
No due date•3/3 issues closedAC: Installing a new component(like remote access) must not delete other supported_operations Cloud should always have the latest list of supported_operations
No due date•4/4 issues closedSupport measurements associated with child devices. Out of Scope for Drop 1: Authentication of child devices Device management for child-devices(software management, etc.)
No due date•2/2 issues closed