From 0269a89723d0718ce7aaad08447f14aabaa90c63 Mon Sep 17 00:00:00 2001
From: fslef <23463958+fslef@users.noreply.github.com>
Date: Tue, 10 Jun 2025 08:36:50 +0200
Subject: [PATCH] =?UTF-8?q?fix(mqtt.markdown):=20correct=20formatting=20an?=
 =?UTF-8?q?d=20update=20links=20in=20MQTT=20docum=E2=80=A6=20(#39453)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 source/_integrations/mqtt.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/source/_integrations/mqtt.markdown b/source/_integrations/mqtt.markdown
index 79ed02ae6b7..cac932e38b7 100644
--- a/source/_integrations/mqtt.markdown
+++ b/source/_integrations/mqtt.markdown
@@ -1078,7 +1078,7 @@ payload_not_available:
   required: false
   type: string
   default: offline
-{% endconfiguration %}  
+{% endconfiguration %}
 
 {% enddetails %}
 
@@ -1221,7 +1221,7 @@ Setting up a light, switch etc. is similar but requires a `command_topic` as men
 - Configuration topic: `homeassistant/switch/irrigation/config`
 - State topic: `homeassistant/switch/irrigation/state`
 - Command topic: `homeassistant/switch/irrigation/set`
-- Payload:  
+- Payload:
 
 ```json
 {
@@ -1367,7 +1367,7 @@ The following software has built-in support for MQTT discovery:
 - [Tasmota](https://github.com/arendst/Tasmota) (starting with 5.11.1e, development halted)
 - [TeddyCloud](https://github.com/toniebox-reverse-engineering/teddycloud)
 - [Teleinfo MQTT](https://fmartinou.github.io/teleinfo2mqtt) (starting with 3.0.0)
-- [Tydom2MQTT](https://fmartinou.github.io/tydom2mqtt/)
+- [Tydom2MQTT](https://tydom2mqtt.github.io/tydom2mqtt/)
 - [What's up Docker?](https://fmartinou.github.io/whats-up-docker/) (starting with 3.5.0)
 - [WyzeSense2MQTT](https://github.com/raetha/wyzesense2mqtt)
 - [Xiaomi DaFang Hacks](https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks)
@@ -1429,7 +1429,7 @@ Note that MQTT device payloads often contain information for updating multiple e
 
 ### The last reported state attribute
 
-Because MQTT state updates are often repeated frequently, even when no actual changes exist, it is up to the MQTT subscriber to determine whether a status update was received. If the latest update is missed, it might take some time before the next one arrives. If a retained payload exists at the broker, that value will be replayed first, but it will be an update of a previous last state. 
+Because MQTT state updates are often repeated frequently, even when no actual changes exist, it is up to the MQTT subscriber to determine whether a status update was received. If the latest update is missed, it might take some time before the next one arrives. If a retained payload exists at the broker, that value will be replayed first, but it will be an update of a previous last state.
 
 MQTT devices often continuously generate numerous state updates. MQTT does not update `last_reported` to avoid impacting system stability unless `force_update` is set. Alternatively, an MQTT sensor can be created to measure the last update.