diff --git a/docs/src/contribute/design/mqtt-topic-design.md b/docs/src/contribute/design/mqtt-topic-design.md
index e018a424499..747751ec4cc 100644
--- a/docs/src/contribute/design/mqtt-topic-design.md
+++ b/docs/src/contribute/design/mqtt-topic-design.md
@@ -16,13 +16,13 @@ Having a fixed **identifier** group in the topic structure makes it easier for o
 
 A client can subscribe to all measurements for the main device by subscribing to a single topic.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/device/main///m/+'
 ```
 
 Alternatively, if a client wants to subscribe to all measurements regardless of the **identifier** then it can also can be done using a single subscription, as demonstrated by the following example:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/+/+/+/+/m/+'
 ```
 
@@ -119,7 +119,7 @@ graph LR
 
 The equipment, which is a conveyor belt called "belt01", is located in factory "factory01", in the "hallA" building, in the "packaging" area. The conveyor belt can be registered as a child-device by publishing the following message.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/factory01/hallA/packaging/belt001' '{
   "@type": "child-device",
   "name": "belt001",
@@ -139,7 +139,7 @@ The registration message will associate the telemetry data or commands published
 
 For example, an event can be published to the `belt01` equipment using the following message.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub 'te/factory01/hallA/packaging/belt001/e/running_status' '{
   "text": "Belt started"
 }'
@@ -147,7 +147,7 @@ tedge mqtt pub 'te/factory01/hallA/packaging/belt001/e/running_status' '{
 
 Since the topic schema encodes additional location information about the equipment, other MQTT clients can subscribe to telemetry data coming from all equipment located in the same area using a single MQTT subscription.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub 'te/factory01/hallA/packaging/+/e/+'
 ```
 
@@ -156,7 +156,7 @@ When applying your own semantics to the **identifier**, you can leave any segmen
 
 For example, if it does not make sense to have the factory and building in the **identifier**, then they can be removed and the equipment can be registered using:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/packaging/belt001' '{
   "@type": "child-device"
 }'
@@ -164,7 +164,7 @@ tedge mqtt pub -r 'te/packaging/belt001' '{
 
 Publishing an event requires just leaving the last two segments of the **identifier** blank (whilst keeping the slashes `/` in place).
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub 'te/packaging/belt001///e/running_status' '{
   "text": "Belt started"
 }'
diff --git a/docs/src/contribute/writing-documentation/markdown-components.md b/docs/src/contribute/writing-documentation/markdown-components.md
index 1a307e1553f..2363f063df0 100644
--- a/docs/src/contribute/writing-documentation/markdown-components.md
+++ b/docs/src/contribute/writing-documentation/markdown-components.md
@@ -210,14 +210,14 @@ The following shows how to document how to publish a single MQTT message.
 **Markdown**
 
 ````markdown title="Markdown"
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/ '{"temperature": 21.3}'
 ```
 ````
 
 **Output**
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/ '{"temperature": 21.3}'
 ```
 
@@ -296,14 +296,14 @@ tedge mqtt pub te/device/child01///a/temp_hi_hi '{"text": "Temperature Hi Hi", "
 ### Example: Subscribe to MQTT messages
 
 ````markdown title="Markdown"
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/#'
 ```
 ````
 
 **Output**
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/#'
 ```
 
@@ -312,14 +312,14 @@ tedge mqtt sub 'te/#'
 Any additional arguments will be automatically preserved when translating the commands. Though the `mqtt` tab will not display this information it is just meant to represent the MQTT message and does not know anything about the terminal/console.
 
 ````markdown title="Markdown"
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/#' > logged.tedge.messages.txt
 ```
 ````
 
 **Output**
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/#' > logged.tedge.messages.txt
 ```
 
diff --git a/docs/src/operate/c8y/child_device_config_management_agent.md b/docs/src/operate/c8y/child_device_config_management_agent.md
index 91a5db0b400..7d3c4770232 100644
--- a/docs/src/operate/c8y/child_device_config_management_agent.md
+++ b/docs/src/operate/c8y/child_device_config_management_agent.md
@@ -75,7 +75,7 @@ to the URL: `http://{tedge-ip}:8000/tedge/file-transfer/{child-id}/c8y-configura
 
 Once the upload is complete, the agent should notify thin-edge about the upload by sending the following MQTT message:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub 'tedge/{child-d}/commands/res/config_snapshot' '{"type": "c8y-configuration-plugin", "path": "/child/local/fs/path"}'
 ```
 
@@ -107,7 +107,7 @@ The `url` value is what the child device agent must use to upload the requested
 
 On receipt of the request, the agent must send an "executing" MQTT status message as follows:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub tedge/{child-d}/commands/res/config_snapshot '{
   "status": "executing",
   "type": "{config-type}",
diff --git a/docs/src/operate/c8y/retrieve_jwt_token_from_cumulocity.md b/docs/src/operate/c8y/retrieve_jwt_token_from_cumulocity.md
index 26cfe4b61e6..438de01f607 100644
--- a/docs/src/operate/c8y/retrieve_jwt_token_from_cumulocity.md
+++ b/docs/src/operate/c8y/retrieve_jwt_token_from_cumulocity.md
@@ -17,13 +17,13 @@ Follow the below steps in order to retrieve the token from the Cumulocity cloud
 
 1. Subscribe to token topic
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=v1
     tedge mqtt sub c8y/s/dat --no-topic
     ```
 
 2. Publish an empty message on `c8y/s/uat` topic
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=v1
     tedge mqtt pub c8y/s/uat ''
     ```
 
diff --git a/docs/src/operate/configuration/child-device-config-management.md b/docs/src/operate/configuration/child-device-config-management.md
index c6b6d539bbd..a1b498e8a86 100644
--- a/docs/src/operate/configuration/child-device-config-management.md
+++ b/docs/src/operate/configuration/child-device-config-management.md
@@ -188,7 +188,7 @@ Follow these steps to bootstrap the child device:
 
     **Example**
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=legacy
     tedge mqtt pub "tedge/child1/commands/res/config_snapshot" '{"path": "", "type":"c8y-configuration-plugin"}'
     ```
 
@@ -202,7 +202,7 @@ Following these steps, a configuration file from the child-device will be reques
 
 1. Subscribe to config snapshot requests via MQTT
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=legacy
     tedge mqtt sub "tedge/{child-id}/commands/req/config_snapshot"
     ```
 
@@ -249,7 +249,7 @@ Following these steps, a configuration file from the child-device will be reques
 
     **Example**
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=legacy
     tedge mqtt pub "tedge/child1/commands/res/config_snapshot" '{"status": "executing", "path": "/home/pi/config/config1", "type": "config1"}'
     ```
 
@@ -289,7 +289,7 @@ Following these steps, a configuration file from the child-device will be reques
 
     **Example**
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=legacy
     tedge mqtt pub "tedge/child1/commands/res/config_snapshot" '{"status": "successful", "path": "/home/pi/config/config1", "type": "config1"}'
     ```
 
@@ -301,7 +301,7 @@ Performing config update is an 8-step process:
 
     **Example**
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=legacy
     tedge mqtt sub "tedge/child1/commands/req/config_update"
     ```
 
@@ -352,7 +352,7 @@ Performing config update is an 8-step process:
 
     **Example**
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=legacy
     tedge mqtt pub "tedge/child1/commands/res/config_update" '{"status": "executing", "path": "/home/pi/config/config1", "type": "config1"}'
     ```
 
@@ -398,7 +398,7 @@ Performing config update is an 8-step process:
 
     **Example**
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=legacy
     tedge mqtt pub "tedge/child1/commands/res/config_update" '{"status": "successful", "path": "/home/pi/config/config1", "type": "config1"}'
     ```
 
@@ -415,7 +415,7 @@ Performing config update is an 8-step process:
 
     **Example**
 
-    ```sh te2mqtt
+    ```sh te2mqtt formats=legacy
     tedge mqtt pub "tedge/child1/commands/res/config_update" '{"status": "failed", "reason": "Download failed", "path": "/home/pi/config/config1", "type": "config1"}'
     ```
 
diff --git a/docs/src/operate/monitoring/enable_tedge_watchdog_using_systemd.md b/docs/src/operate/monitoring/enable_tedge_watchdog_using_systemd.md
index 552dcee7cf0..5001c1f8bf8 100644
--- a/docs/src/operate/monitoring/enable_tedge_watchdog_using_systemd.md
+++ b/docs/src/operate/monitoring/enable_tedge_watchdog_using_systemd.md
@@ -84,11 +84,11 @@ One can observe the message exchange between the `service` and the `watchdog`
 by subscribing to the following topics:
 
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/+/+/+/+/status/health'
 ```
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/+/+/+/+/cmd/health/check'
 ```
 
diff --git a/docs/src/operate/telemetry/pub_sub.md b/docs/src/operate/telemetry/pub_sub.md
index 8af996398b9..3691c400e04 100644
--- a/docs/src/operate/telemetry/pub_sub.md
+++ b/docs/src/operate/telemetry/pub_sub.md
@@ -14,13 +14,13 @@ Command [`tedge mqtt pub`](../../references/cli/tedge-mqtt.md) can be used to pu
 
 Example:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub 'te/device/main///m/env_sensor' '{"temperature": 21.3}'
 ```
 
 Messages can also be published with a different Quality of Service (QoS).
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub 'te/device/main///m/env_sensor' '{"temperature": 21.3}' --qos 2
 ```
 
@@ -28,7 +28,7 @@ MQTT messages can also be published using the retained option which means that t
 
 Below shows an example of publishing a retained MQTT message:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain --qos 1 te/device/main///a/high_temperature '{
     "text": "Temperature is critical",
     "severity": "critical"
@@ -44,25 +44,25 @@ By default the mqtt message will be published with retain flag set to false.
 
 Command [`tedge mqtt sub`](../../references/cli/tedge-mqtt.md) can be used to ease debugging of of MQTT communication on local bridge. You can subscribe to topic of your choosing:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub te/errors
 ```
 
 Or you can subscribe to any topic on the server using wildcard (`#`) topic:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub '#'
 ```
 
 Now using a different console/shell, publish the following measurement so that the previous subscription will receive it:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain --qos 1 te/device/main///m/env_sensor '{"temperature": 21.3}'
 ```
 
 All messages from sub command are printed to `stdout` and can be captured to a file if you need to:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub '#' > filename.mqtt
 ```
 
diff --git a/docs/src/operate/troubleshooting/monitor_tedge_health.md b/docs/src/operate/troubleshooting/monitor_tedge_health.md
index 1a2577a1ff9..686cd233125 100644
--- a/docs/src/operate/troubleshooting/monitor_tedge_health.md
+++ b/docs/src/operate/troubleshooting/monitor_tedge_health.md
@@ -45,7 +45,7 @@ and this will be retained until the service is restarted.
 
 E.g. the mapper being killed:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/+/+/+/+/status/health'
 ```
 
diff --git a/docs/src/operate/troubleshooting/trouble_shooting_monitoring.md b/docs/src/operate/troubleshooting/trouble_shooting_monitoring.md
index e09d3961db0..7ad626f874a 100644
--- a/docs/src/operate/troubleshooting/trouble_shooting_monitoring.md
+++ b/docs/src/operate/troubleshooting/trouble_shooting_monitoring.md
@@ -23,7 +23,7 @@ sudo systemctl start collectd
 
 ## Is collectd publishing MQTT messages?
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'collectd/#'
 ```
 
@@ -47,13 +47,13 @@ sudo systemctl start tedge-mapper-collectd
 
 ## Are the collectd metrics published in Thin Edge JSON format?
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/device/main///m/+'
 ```
 
 ## Are the collectd metrics published to Cumulocity IoT?
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'c8y/#'
 ```
 
@@ -61,7 +61,7 @@ If not see how to [connect a device to Cumulocity IoT](../../start/connect-c8y.m
 
 ## Are the collectd metrics published to Azure IoT?
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'az/#'
 ```
 
diff --git a/docs/src/references/agent/device-management-api.md b/docs/src/references/agent/device-management-api.md
index 72143694598..aaf68584bd6 100644
--- a/docs/src/references/agent/device-management-api.md
+++ b/docs/src/references/agent/device-management-api.md
@@ -66,7 +66,7 @@ that this device can be sent commands of this type.
 These messages are published with the retained flag set. So, a client process, such a mapper, can discover on start
 what are __all the capabilities of all the devices__:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/+/+/+/+/cmd/+'
 ```
 
@@ -105,7 +105,7 @@ It is recommended to either use a unique id generator, or add a unix timestamp a
 The messages published on these topics represent each the current status of a running command.
 So, one can list __all the in-progress commands of any type across all the devices__:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/+/+/+/+/cmd/+/+'
 ```
 
@@ -222,7 +222,7 @@ As an example, let's take software updates on a child device.
 When launched on the child device `device/child001//`,
 `tedge-agent` notifies that software packages of types: `apt` and `docker` can be updated on this device:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_update' '{
     "description": "Install, update and remove software packages",
     "types": [
@@ -235,7 +235,7 @@ tedge mqtt pub --retain 'te/device/child001///cmd/software_update' '{
 On reception of this message, the Cumulocity mapper notifies Cumulocity of this capability.
 On request from a cloud operator, the Cumulocity mapper creates a new command instance, say to update `nodered`:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_update/c8y-123' '{
     "status": "init",
     "updateList": [
@@ -255,7 +255,7 @@ tedge mqtt pub --retain 'te/device/child001///cmd/software_update/c8y-123' '{
 
 The agent, running on `device/child001//`, notifies that it will execute the command:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_update/c8y-123' '{
     "status": "executing",
     "updateList": [
@@ -275,7 +275,7 @@ tedge mqtt pub --retain 'te/device/child001///cmd/software_update/c8y-123' '{
 
 Then the agent proceeds, here installing a specific version of `nodered`, and notifies the mapper when done:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_update/c8y-123' '{
     "status": "successful",
     "updateList": [
@@ -297,6 +297,6 @@ The Cumulocity mapper, having subscribed to all software_update commands,
 monitors this command instance and notifies Cumulocity of its progress upto completion.  
 Finally, the Cumulocity mapper clear the command topic:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_update/c8y-123' ''
 ```
diff --git a/docs/src/references/agent/restart-operation.md b/docs/src/references/agent/restart-operation.md
index 01d5717cfda..1bfb61fa5ab 100644
--- a/docs/src/references/agent/restart-operation.md
+++ b/docs/src/references/agent/restart-operation.md
@@ -27,7 +27,7 @@ The `restart` operation API follows the [generic thin-edge rules for operations]
 
 The registration message of the `restart` operation on a device is an empty JSON object `{}`.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/restart' '{}'
 ```
 
@@ -36,7 +36,7 @@ tedge mqtt pub --retain 'te/device/child001///cmd/restart' '{}'
 To trigger a restart operation on a device, the requester has no information to provide.
 It only has to create a new `restart` command instance topic.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/restart/c8y-2023-09-08T18:13:00' '{
     "status": "init"
 }'
@@ -47,7 +47,7 @@ tedge mqtt pub --retain 'te/device/child001///cmd/restart/c8y-2023-09-08T18:13:0
 When ready, but before actually restarting the device,
 the agent or the `restart` plugin publishes the new state of the command.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/restart/c8y-2023-09-08T18:13:00' '{
     "status": "executing"
 }'
@@ -58,7 +58,7 @@ tedge mqtt pub --retain 'te/device/child001///cmd/restart/c8y-2023-09-08T18:13:0
 After a successful reboot,
 the agent or the `restart` plugin publishes the new state of the command.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/restart/c8y-2023-09-08T18:13:00' '{
     "status": "successful"
 }'
@@ -70,7 +70,7 @@ In case the reboot failed for some reason,
 the agent or the `restart` plugin publishes the new state of the command,
 adding a `reason` text field with the error. 
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/restart/c8y-2023-09-08T18:13:00' '{
     "status": "failed",
     "reason": "The device has not restarted within 5 minutes"
@@ -82,7 +82,7 @@ tedge mqtt pub --retain 'te/device/child001///cmd/restart/c8y-2023-09-08T18:13:0
 As for all commands, the responsibility of closing a `restart` is on the requester.
 This is done by publishing an empty retained message on the command topic.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/restart/c8y-2023-09-08T18:13:00' ''
 ```
 
diff --git a/docs/src/references/agent/software-management.md b/docs/src/references/agent/software-management.md
index 20e436c0293..7d390bad30b 100644
--- a/docs/src/references/agent/software-management.md
+++ b/docs/src/references/agent/software-management.md
@@ -24,7 +24,7 @@ The registration message of the `software_list` operation on a device:
 - must provide a `types` list of the types of software package that can be installed on this device (e.g. `["apt", "docker"]`)
 - can provide a description of the operation and of each supported package type.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_list' '{
     "description": "List software packages installed on the device",
     "types": [
@@ -39,7 +39,7 @@ tedge mqtt pub --retain 'te/device/child001///cmd/software_list' '{
 A `software_list` command has nothing to provide beyond a `status` field.
 This empty message stands for a request of the list of software currently installed.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_list/c8y-2023-09-25T14:34:00' '{
     "status": "init"
 }'
@@ -79,7 +79,7 @@ The payload for a successful `software_list` command has two fields:
 
 As an example, here is a (simplified) status message for a successful `software_list` command on a child device:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_list/c8y-2023-09-25T14:34:00' '{
     "status": "successful",
     "currentSoftwareList": [
@@ -116,7 +116,7 @@ The payload for a failed `software_list` is made of two fields:
 - the `status` is set to `failed`
 - a `reason` text field is added with the root cause of the failure
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_list/c8y-2023-09-25T14:34:00' '{
     "status": "failed",  
     "reason": "Permission denied",
@@ -138,7 +138,7 @@ The registration message of the `software_update` operation on a device:
 - must provide a `types` list of the types of software package that can be installed on this device (e.g. `["apt", "docker"]`)
 - can provide a description of the operation and of each supported package type.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_update' '{
     "description": "Install, update and remove software packages",
     "types": [
@@ -182,7 +182,7 @@ A `software_update` command is defined by an `"updateList"` array giving the pac
 
 As an example, here is a message requesting a `software_update` on a child device:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_update/c8y-2023-09-25T14:53:00' '{
     "status": "init",
     "updateList": [
@@ -237,7 +237,7 @@ repeats the same content as the former request except that:
 
 As an example, here is a status message for a successful `software_update` command on a child device:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_update/c8y-2023-09-25T14:53:00' '{
     "status": "successful",  
     "updateList": [
@@ -285,7 +285,7 @@ repeats the same content as the former request except that:
 - a `reason` text field is added with the root cause of the failure
 - a `failures` array field might be added to list the errors for all the failing actions.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub --retain 'te/device/child001///cmd/software_update/c8y-2023-09-25T14:53:00' '{
     "status": "failed",  
     "reason": "Partial failure: Could not install collectd and nginx",
diff --git a/docs/src/references/agent/tedge-configuration-management.md b/docs/src/references/agent/tedge-configuration-management.md
index 8daaa311e38..035694b57b0 100644
--- a/docs/src/references/agent/tedge-configuration-management.md
+++ b/docs/src/references/agent/tedge-configuration-management.md
@@ -99,13 +99,13 @@ The message can be observed over the MQTT bus of the thin-edge device.
 Given that `mqtt.topic_root` and `mqtt.device_topic_id` are set to `te` and `device/main//` for the main device,
 the message to declare the supported configuration types is as follows.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/config_snapshot' '{
   "types": ["tedge-configuration-plugin", "tedge.toml", "/etc/tedge/mosquitto-conf/c8y-bridge.conf", "/etc/tedge/mosquitto-conf/tedge-mosquitto.conf", "mosquitto"]
 }'
 ```
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/config_update' '{
   "types": ["tedge-configuration-plugin", "tedge.toml", "/etc/tedge/mosquitto-conf/c8y-bridge.conf", "/etc/tedge/mosquitto-conf/tedge-mosquitto.conf", "mosquitto"]
 }'
@@ -135,13 +135,13 @@ During a config snapshot operation, the plugin uploads a requested configuration
 The plugin subscribes to config snapshot commands on the `<root>/<identifier>/cmd/config_snapshot/+` MQTT topics.
 For example, it subscribes to the following topic for the main device.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/device/main///cmd/config_snapshot/+'
 ```
 
 To start a new config snapshot with the ID "1234" on the device named "example", a component has to publish the following message over MQTT:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/config_snapshot/1234' '{
   "status": "init",
   "tedgeUrl": "http://127.0.0.1:8000/tedge/file-transfer/example/config_snapshot/mosquitto-1234",
@@ -166,7 +166,7 @@ providing a comprehensive `reason` for the failure.
 
 As a result, the operation status update message for the example above looks like this:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/config_snapshot/1234' '{
   "status": "successful",
   "tedgeUrl": "http://127.0.0.1:8000/tedge/file-transfer/example/config_snapshot/mosquitto-1234",
@@ -202,13 +202,13 @@ from the tedge file transfer repository and moves it to the target path.
 The plugin subscribes to config update commands on the `<root>/<identifier>/cmd/config_update/+` MQTT topics.
 For example, it subscribes to the following topic for the main device.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/device/main///cmd/config_update/+'
 ```
 
 To start a new config update with the ID "1234" on the device named "example", a component has to publish the following message over MQTT:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/config_update/1234' '{
   "status": "init",
   "tedgeUrl": "http://127.0.0.1:8000/tedge/file-transfer/example/config_update/mosquitto-1234",
@@ -234,7 +234,7 @@ the plugin updates the status to `failed` along with a comprehensive `reason` fo
 
 As a result, the operation status update message for the example above looks like this.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/config_update/1234' '{
   "status": "successful",
   "tedgeUrl": "http://127.0.0.1:8000/tedge/file-transfer/example/config_update/mosquitto-1234",
diff --git a/docs/src/references/agent/tedge-log-management.md b/docs/src/references/agent/tedge-log-management.md
index 644870a5cc5..3393bd9950a 100644
--- a/docs/src/references/agent/tedge-log-management.md
+++ b/docs/src/references/agent/tedge-log-management.md
@@ -52,7 +52,7 @@ and sends the supported log types message to the MQTT local broker on the `<root
 Given that `root.topic` and `device.topic` are set to `te` and `device/main//` for the main device,
 the message to declare the supported log types is as follows.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/log_upload' '{
   "types" : [ "mosquitto", "software-management", "c8y_CustomOperation" ]
 }'
@@ -71,13 +71,13 @@ then a JSON message with an empty array for the `types` field is sent, indicatin
 The plugin subscribes to log upload commands on the [`<root>/<identifier>/cmd/log_upload/+` MQTT topic](../mqtt-api.md).
 For example, it subscribes to the following topic for the main device.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/device/main///cmd/log_upload/+'
 ```
 
 A new log file upload command with the ID "1234" is published for the device named "example" by another component as below.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/log_upload/1234' '{
   "status": "init",
   "tedgeUrl": "http://127.0.0.1:8000/tedge/file-transfer/example/log_upload/mosquitto-1234",
@@ -106,7 +106,7 @@ If any unexpected error occurs, the plugin updates the status to `failed` with a
 
 Thus, the operation status update message for the above example looks like below.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/log_upload/1234' '{
   "status": "failed",
   "reason": "The target log file for 'mosquitto' does not exist.",
diff --git a/docs/src/references/mappers/c8y-mapper.md b/docs/src/references/mappers/c8y-mapper.md
index b5d22ebaf60..595e148c2e6 100644
--- a/docs/src/references/mappers/c8y-mapper.md
+++ b/docs/src/references/mappers/c8y-mapper.md
@@ -344,7 +344,7 @@ c8y/measurement/measurements/create
 The unit is a metadata associated with measurements which can be registered as a metadata message for a given measurement type.
 If the following metadata message is registered for the `environment` measurement type:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub -r te/device/main///m/environment/meta '{
   "units": {
     "temperature": "°C"
diff --git a/docs/src/references/mqtt-api.md b/docs/src/references/mqtt-api.md
index bbe5fa78aff..a66baf51502 100644
--- a/docs/src/references/mqtt-api.md
+++ b/docs/src/references/mqtt-api.md
@@ -270,7 +270,7 @@ Here are a few examples of how various entities can be registered.
 
 #### Register a device
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main//' '{
   "@type": "device",
   "type": "Gateway"
@@ -279,7 +279,7 @@ tedge mqtt pub -r 'te/device/main//' '{
 
 Or the device can be registered using an explicit id:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main//' '{
   "@type": "device",
   "@id": "tedge001",
@@ -289,7 +289,7 @@ tedge mqtt pub -r 'te/device/main//' '{
 
 #### Register a service of the main device
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main/service/nodered' '{
   "@type": "service",
   "name": "nodered",
@@ -302,7 +302,7 @@ The service is implicitly linked to the parent derived from the topic, `main` in
 But the parent can be explicitly provided as well with the `@parent` key,
 if the parent can not be derived from the topic directly:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/component_namespace/service/nodered/instance-1' '{
   "@type": "service",
   "@parent": "device/main//",
@@ -313,7 +313,7 @@ tedge mqtt pub -r 'te/component_namespace/service/nodered/instance-1' '{
 
 #### Register a child device
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/child01//' '{
   "@type": "child-device",
   "name": "child01",
@@ -327,7 +327,7 @@ If the `@parent` info is not provided, it is assumed to be an immediate child of
 
 Nested child devices are registered in a similar fashion as an immediate child device, however the registration message requires the additional `@parent` property to be set, indicating which parent the child device should be related to.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/nested_child01//' '{
   "@type": "child-device",
   "@parent": "device/child01//",
@@ -341,7 +341,7 @@ Service registration for child devices also follow the same rules as the main de
 where the `@parent` device info is derived from the topic itself, by default.
 But, it is advised to declare it explicitly as follows:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/child01/service/nodered' '{
   "@type": "service",
   "@parent": "device/child01//",
@@ -358,7 +358,7 @@ For example, a linux service runs on a device as it relies on physical hardware
 
 #### Register a service of a nested child device
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/nested_child01/service/nodered' '{
   "@type": "service",
   "@parent": "device/nested_child01//",
@@ -440,7 +440,7 @@ so that it can process them.
 
 #### Publish to the main device
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///m/environment' '{
   "temperature": 23.4
 }'
@@ -448,7 +448,7 @@ tedge mqtt pub -r 'te/device/main///m/environment' '{
 
 If the there is no measurement type, then the type can be left empty, but it must have the trailing slash `/` (so that the number of topic segments is the same).
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///m/' '{
   "temperature": 23.4
 }'
@@ -456,7 +456,7 @@ tedge mqtt pub -r 'te/device/main///m/' '{
 
 #### Publish to a child device
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/child01///m/environment' '{
   "temperature": 23.4
 }'
@@ -464,7 +464,7 @@ tedge mqtt pub -r 'te/device/child01///m/environment' '{
 
 #### Publish to a service on the main device
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main/service/nodered/m/environment' '{
   "temperature": 23.4
 }'
@@ -472,25 +472,25 @@ tedge mqtt pub -r 'te/device/main/service/nodered/m/environment' '{
 
 Any MQTT client can subscribe to all measurements for all entities (devices and services) using the following MQTT topic:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/+/+/+/+/m/+'
 ```
 
 If you want to be more specific and only subscribe to the main device, then you can used fixed topic names rather than wildcards:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/device/main/+/+/m/+'
 ```
 
 Or to subscribe to a specific type of measurement published to an services on the main device, then use:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/device/main/service/+/m/memory'
 ```
 
 #### Publish to a service on a child device
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/child01/service/nodered/m/environment' '{
   "temperature": 23.4
 }'
@@ -503,7 +503,7 @@ which can be added/updated by publishing to `/meta` subtopics of those data type
 For example, the units associated with measurements in the `battery_reading` measurement type
 can be updated by publishing the following message:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r te/device/main///m/battery_reading/meta '{
   "units": {
     "temperature": "°C",
@@ -590,7 +590,7 @@ For example, the `restart` could mean either a device restart or a service resta
 
 Command to fetch the software list from the main device:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/software_list/123' '{
   "status": "init"
 }'
@@ -601,7 +601,7 @@ such as `validating`, `downloading`, `executing` etc.
 
 The `status` field can even be skipped, which implies `init` status as follows:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main///cmd/software_list/123' '{}'
 ```
 
@@ -609,7 +609,7 @@ tedge mqtt pub -r 'te/device/main///cmd/software_list/123' '{}'
 
 Command to update the firmware of a child device:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/child01///cmd/firmware_update/123' '{
   "status": "init",
   "attempt": 1,
@@ -624,7 +624,7 @@ tedge mqtt pub -r 'te/device/child01///cmd/firmware_update/123' '{
 
 Command to update the configuration of a service:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r 'te/device/main/service/collectd/cmd/config_update/123' '{
   "status": "init",
   "type": "collectd",
@@ -639,7 +639,7 @@ For commands as well, additional command specific metadata can be registered as
 
 For example, the supported configuration list of the main device can be declared as follows:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r te/device/main///cmd/config_snapshot '{
   "description": "Upload a configuration from the device",
   "types": ["mosquitto", "tedge", "collectd"]
@@ -650,7 +650,7 @@ tedge mqtt pub -r te/device/main///cmd/config_snapshot '{
 
 Services can publish their health status as follows:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r te/device/main/service/tedge-agent/status/health '{
   "pid": 1234,
   "status": "up",
@@ -660,13 +660,13 @@ tedge mqtt pub -r te/device/main/service/tedge-agent/status/health '{
 
 Services are responsible for updating their own health status by publishing to the above topic on any status changes. However, other clients can request the service to update its status by sending a health check command as shown below:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r te/device/main/service/tedge-agent/cmd/health/check '{}'
 ```
 
 Services are also expected to react to device-wide health check commands as well (where service and `<service_id>` segments are left blank):
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r te/device/main///cmd/health/check '{}'
 ```
 
@@ -674,7 +674,7 @@ On receipt of the above command, all services on that device should respond with
 
 The services are also expected to register an MQTT Last Will and Testament (LWT) message with the broker to publish a `down` status message in the event that the service stops or crashes unexpectedly. The Last Will and Testament message ensures that the down status is published even if the service is not operational. The following example details such a message:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub -r te/device/main/service/tedge-agent/status/health '{
   "status": "down"
 }'
diff --git a/docs/src/start/connect-aws.md b/docs/src/start/connect-aws.md
index aa066b6ab7e..453e6ae072a 100644
--- a/docs/src/start/connect-aws.md
+++ b/docs/src/start/connect-aws.md
@@ -168,13 +168,13 @@ tedge-mapper-aws service successfully started and enabled!
 
 Using the AWS mapper, you can publish measurement telemetry data to AWS by publishing on the `te/device/main///m/` topic:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/environment '{"temperature": 21.3}'
 ```
 
 Alternatively, post your own custom messages on `aws/td/#` topic:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub aws/td '{"text": "My message"}'
 ```
 
diff --git a/docs/src/start/connect-azure.md b/docs/src/start/connect-azure.md
index 248e2a5eaf0..16f9be4e325 100644
--- a/docs/src/start/connect-azure.md
+++ b/docs/src/start/connect-azure.md
@@ -156,13 +156,13 @@ Sending data to Azure is done using MQTT over topics prefixed with `az`.
 Any messages sent on the topic will be forwarded to Azure.
 Here, we publish a json message to Azure via the tedge mqtt topic.
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/environment '{"temperature": 21.3}'
 ```
 
 Alternatively, post your own custom messages on `az/messages/events/#` topic:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub az/messages/events/ '{"text": "My message"}'
 ```
 
diff --git a/docs/src/start/connect-c8y.md b/docs/src/start/connect-c8y.md
index f94550120ad..a94b74979fc 100644
--- a/docs/src/start/connect-c8y.md
+++ b/docs/src/start/connect-c8y.md
@@ -200,7 +200,7 @@ Any messages sent to one of these topics will be forwarded to Cumulocity.
 The messages are expected to have a format specific to each topic.
 Here, we use `tedge mqtt pub` a raw Cumulocity SmartRest message to be understood as a temperature of 20°C.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub c8y/s/us 211,20
 ```
 
diff --git a/docs/src/start/device-monitoring.md b/docs/src/start/device-monitoring.md
index 1e9b7461404..6eefb5a813c 100644
--- a/docs/src/start/device-monitoring.md
+++ b/docs/src/start/device-monitoring.md
@@ -139,7 +139,7 @@ You can inspect the collected and translated metrics, by subscribing to these to
 
 The metrics collected by `collectd` are emitted to subtopics named after the collectd plugin and the metric name:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'collectd/#'
 ```
 
@@ -154,7 +154,7 @@ tedge mqtt sub 'collectd/#'
 The `tedge-mapper-collectd` translates these collectd measurements into the [thin-edge.io JSON](../understand/thin-edge-json.md) format,
 [grouping the measurements](../references/mqtt-topics.md#collectd-topics) emitted by each plugin:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'te/+/+/+/+/m/+'
 ```
 
@@ -166,7 +166,7 @@ tedge mqtt sub 'te/+/+/+/+/m/+'
 From there, if the device is actually connected to a cloud platform like Cumulocity,
 these monitoring metrics will be forwarded to the cloud.
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'c8y/#'
 ```
 
diff --git a/docs/src/start/getting-started.md b/docs/src/start/getting-started.md
index 5996f35be88..b5d48fd92ae 100644
--- a/docs/src/start/getting-started.md
+++ b/docs/src/start/getting-started.md
@@ -173,7 +173,7 @@ Once your device is configured and connected to Cumulocity IoT, you can start se
 
 Below shows some examples on how to publish an MQTT message via the command line:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub '{{TOPIC}}' '{{PAYLOAD}}'
 ```
 
@@ -197,7 +197,7 @@ te/+/+/+/+/m/+
 
 The temperature measurement described above can be sent as follows:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/ '{"temperature": 25}'
 ```
 
@@ -222,7 +222,7 @@ te/+/+/+/+/e/+
 
 So the door open event described above can be sent as follows:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///e/door '{"text": "A door was closed","time": "2022-06-10T05:30:45+00:00"}'
 ```
 
@@ -267,7 +267,7 @@ sudo systemctl restart collectd
 
 What you should see by now is that data arrives on the `collectd/#` topics. You can check that via:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'collectd/#'
 ```
 
@@ -291,7 +291,7 @@ sudo systemctl start tedge-mapper-collectd
 
 You can inspect the collected and translated metrics, by subscribing to these topics:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub 'c8y/#'
 ```
 
diff --git a/docs/src/start/raise-alarm.md b/docs/src/start/raise-alarm.md
index 842d4a6e932..c61488c1b87 100644
--- a/docs/src/start/raise-alarm.md
+++ b/docs/src/start/raise-alarm.md
@@ -48,7 +48,7 @@ If multiple messages are sent to the same alarm topic, the last alarm is conside
 
 Here is a sample alarm raised for `temperature_high` alarm type with `critical` severity:
 
-```te2mqtt formats="v1"
+```te2mqtt formats=v1
 tedge mqtt pub te/device/main///a/temperature_high '
 {
   "text": "Temperature is very high",
@@ -82,7 +82,7 @@ An already raised alarm can be cleared by sending an empty message with retained
 
 For example `temperature_high` will be cleared by publishing an empty payload message as below:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///a/temperature_high "" -q 2 -r
 ```
 
diff --git a/docs/src/start/send-events.md b/docs/src/start/send-events.md
index 606febeb1f1..3af1193fe4a 100644
--- a/docs/src/start/send-events.md
+++ b/docs/src/start/send-events.md
@@ -36,7 +36,7 @@ The payload format must be as follows:
 
 Here is a sample event triggered for a `login_event` event type:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///e/login_event '
 {
   "text": "A user just logged in",
@@ -126,7 +126,7 @@ Here is a sample event triggered for a `login_event` event type for the `externa
 
 Command to send the event from a external device as below:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/external_sensor///e/login_event '{
   "text":"A user just logged in",
   "time":"2021-01-01T05:30:45+00:00"
diff --git a/docs/src/start/send-thin-edge-data.md b/docs/src/start/send-thin-edge-data.md
index c2b715ea63d..6eb8a5e00af 100644
--- a/docs/src/start/send-thin-edge-data.md
+++ b/docs/src/start/send-thin-edge-data.md
@@ -30,7 +30,7 @@ In this tutorial, we'll be using the `tedge mqtt pub` command line utility for d
 
 The temperature measurement described above can be sent using the `tedge mqtt pub` command as follows:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/environment '{"temperature": 25}'
 ```
 
@@ -93,7 +93,7 @@ the measurements are recorded under a child device of your thin-edge.io device.
 
 Given your desired child device ID is `child1`, publish a Thin Edge JSON message to the following topic where the measurement type is set to `environment`:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/child1///m/environment '{"temperature": 25}'
 ```
 
@@ -109,6 +109,6 @@ So, use it only for debugging purposes during the development phase and it shoul
 
 You can subscribe to the error topic as follows:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub te/errors
 ```
diff --git a/docs/src/understand/tedge-mapper.md b/docs/src/understand/tedge-mapper.md
index 5ee00f73d02..ffd199cedc1 100644
--- a/docs/src/understand/tedge-mapper.md
+++ b/docs/src/understand/tedge-mapper.md
@@ -180,7 +180,7 @@ tedge mqtt pub te/device/main///m/ '{"temperature": 23,"time": 220}'
 
 Then, you'll receive error messages from the mapper on the topic `te/errors`:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt sub te/errors
 ```
 
diff --git a/docs/src/understand/thin-edge-json.md b/docs/src/understand/thin-edge-json.md
index 925a38c1679..bc538eecdc3 100644
--- a/docs/src/understand/thin-edge-json.md
+++ b/docs/src/understand/thin-edge-json.md
@@ -64,7 +64,7 @@ or a combination of both along with some auxiliary data like the timestamp at wh
 
 Simple single-valued measurements like temperature or pressure can be expressed as follows:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/environment '{
   "temperature": 25
 }'
@@ -81,7 +81,7 @@ Like the name suggests, a multi-valued measurement is allowed to contain more th
 Here is the representation of a `three_phase_current` measurement that consists of `L1`, `L2` and `L3` values,
 representing the current on each phase:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/electrical '{
   "three_phase_current": {
     "L1": 9.5,
@@ -97,7 +97,7 @@ Only one level of nesting is allowed, meaning the values of the measurement keys
 
 **❌ Example: Invalid measurement due to nesting > 2 levels**
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/example '{
   "three_phase_current": {
     "phase1": {
@@ -117,7 +117,7 @@ tedge mqtt pub te/device/main///m/example '{
 
 Multiple single-valued and multi-valued measurements can be grouped into a single Thin Edge JSON message as follows:
 
-```sh te2mqtt
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/example '{
   "temperature": 25,
   "three_phase_current": {
@@ -138,7 +138,7 @@ If the user doesn't want to rely on `thin-edge.io` generated timestamps,
 an explicit timestamp can be provided in the measurement message itself by adding the time value as a string 
 in ISO 8601 format using `time` as the key name, as follows:
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///m/example '{
   "time": "2020-10-15T05:30:47+00:00",
   "temperature": 25,
@@ -171,7 +171,7 @@ For instance:
 - a process started
 - a user has started an ssh session
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///e/login '{
   "text": "A user just logged in",
   "time": "2021-01-01T05:30:45+00:00",
@@ -198,7 +198,7 @@ For instance:
 - a process that crashed
 - free disk space going critically low
 
-```sh te2mqtt formats="v1"
+```sh te2mqtt formats=v1
 tedge mqtt pub te/device/main///a/temperature_high '{
   "text": "Temperature is very high",
   "severity": "warning",