-
**Describe the bug**
The `tedge connect c8y` and `tedge disconnect c8y` are inconsistent with the handling when the default service manager is not configured.
For example, on an alpine docker …
-
Currently reference-by-name seems not to be supported for:
* c8y devicegroups children assign
* c8y devices children assign
Reference by name concept is already existing for e.g. `c8y devices get…
-
**Is your feature improvement request related to a problem? Please describe.**
Connection the bridge using the `tedge connect ` command is a container throws an unexpected error when the service …
-
**Describe the bug**
When the tedge-log-plugin is not running as the main device it still reports the service health status to the main device, overwriting the status of the real tedge-log-plugin…
-
**Describe the bug**
The tedge-mapper-c8y is clearing `log_upload` operations which were not requested by it, which results in the chance to give the original requestor confirmation that they hav…
-
**Describe the bug**
The package listed generated by multiple sm-plugins are not published to Cumulocity in a stable order, for example if you have two sm-plugins called dummy1 and dummy2, someti…
-
Cumulocity recommends to use the device id of the MQTT client as part of each child device.
> All children require a unique ID defined when creating the device. We recommend you to use a combinatio…
-
Services are shown as child devices
![image](https://github.com/thin-edge/thin-edge.io/assets/29426188/f1abe63f-ad2e-4620-befa-b9890ce30eda)
It's weird though that the bridge is show correctly a…
-
**Describe the bug**
When a custom Cumulocity IoT operation fails and there a large standard error output greater than the max MQTT message size, then it results in an ill-formed SmartREST messag…
-
**Is your feature request related to a problem? Please describe.**
A device is using thin-edge.io to connect to two clouds, however the same telemetry data being pushed from the device (through t…