Initialisation

data/pages/informatique/applications/zigbee2mqtt/disponibilite-des-dispositifs.txt

@@ -0,0 +1,80 @@
+====== Disponibilité des dispositifs ======
+
+La fonctionnalité de disponibilité a pour objectif de vérifier la connectivité en ligne de vos dispositifs. L'état de disponibilité d'un dispositif est publié dans le sujet MQTT ''zigbee2mqtt/[NOM_AMICAL]/availability'', avec conservation du message (//retained MQTT message//).
+
+<code YAML>
+# Optionnel : Activer la fonctionnalité de disponibilité (par défaut = false)
+availability: true
+</code>
+
+La fonctionnalité de disponibilité opère différemment pour les dispositifs actifs et passifs.
+
+Dispositifs Actifs (routeurs ou dispositifs d'extrémité alimentés sur secteur) :\\
+Par défaut, ils doivent émettre une annonce de leur disponibilité toutes les 10 minutes. En cas de non-réponse, une tentative de ping sera effectuée. Si cela échoue, le dispositif sera marqué comme étant hors ligne.
+
+Dispositifs Passifs (tout ce qui n'est pas un dispositif actif, principalement les dispositifs alimentés par batterie) :\\
+Ces dispositifs doivent émettre une annonce de leur disponibilité toutes les 25 heures. Ils ne peuvent pas être interrogés via ping. Si aucune annonce n'est reçue, ils seront automatiquement marqués comme hors ligne.
+
+Il est important de noter que ce délai est maintenu entre les redémarrages de Zigbee2MQTT. Par conséquent, si vous interrompez Zigbee2MQTT pendant plus de 10 minutes, tous vos dispositifs actifs seront initialement marqués comme hors ligne.
+
+===== Configuration Avancée de la Disponibilité =====
+
+Plutôt que de définir ''availability: true'' dans votre configuration.yaml, vous pouvez fournir une configuration plus détaillée :
+
+<code yaml>
+availability:
+  active:
+    # Délai après lequel un dispositif actif sera marqué hors ligne (en minutes, par défaut = 10 minutes)
+    timeout: 10
+  passive:
+    # Délai après lequel un dispositif passif sera marqué hors ligne (en minutes, par défaut = 1500 minutes, soit 25 heures)
+    timeout: 1500
+</code>
+
+===== Dispositifs Personnalisés =====
+
+Pour chaque dispositif spécifique, vous avez la possibilité de personnaliser davantage la gestion de la disponibilité :
+
+<code yaml>
+devices:
+  '0x12345678':
+    friendly_name: 'ma_ampoule'
+    # Désactiver la fonctionnalité de disponibilité pour ce dispositif spécifique
+    availability: false
+  '0x87654321':
+    friendly_name: 'mon_interrupteur'
+    # Changer le délai de disponibilité à 3 minutes uniquement pour ce dispositif
+    availability:
+      timeout: 3
+</code>
+
+Si vous souhaitez activer la fonctionnalité de disponibilité uniquement pour certains dispositifs, n'ajoutez pas ''availability: true'' dans votre configuration.yaml, mais spécifiez-le uniquement pour le dispositif concerné :
+
+<code yaml>
+devices:
+  '0x87654321':
+    friendly_name: 'mon_interrupteur'
+    # Activer la disponibilité uniquement pour 'mon_interrupteur'
+    availability: true
+</code>
+
+===== Récupération de l'État =====
+
+Lorsque la fonctionnalité de disponibilité est activée et qu'un dispositif se reconnecte ou annonce sa présence sur le réseau, Zigbee2MQTT récupère automatiquement l'état du dispositif. Cela se révèle utile, par exemple, lorsque une ampoule s'allume après avoir été reconnectée à l'alimentation secteur. Les attributs suivants sont lus : ''state'', ''brightness'', ''color_temp'' et ''color''.
+
+===== Considérations en Termes de Performance =====
+
+Le processus de ping peut être exigeant en termes de ressources pour le coordinateur, en particulier si vous utilisez un adaptateur CC2530 ou CC2531. Un délai plus long pour les dispositifs actifs réduit la fréquence des pings, ce qui allège la charge sur le coordinateur.
+
+===== Charge Utile de la Disponibilité =====
+
+Par défaut, la charge utile de la disponibilité publiée est en mode legacy (en ligne/hors ligne). Si le mode legacy est désactivé, la charge utile sera un objet JSON (''{"state":"online"}''/''{"state":"offline"}''). Il est à noter que cela modifie la charge utile pour les sujets ''zigbee2mqtt/bridge/state'' et ''zigbee2mqtt/MY_DEVICE/availability''.
+
+<code yaml>
+advanced:
+  # Utilisation du mode legacy pour la charge utile du message de disponibilité (par défaut : true)
+  # true = en ligne/hors ligne
+  # false = {"state":"online"} / {"state":"offline"}
+  legacy_availability_payload: true
+</code>
+

data/pages/informatique/applications/zigbee2mqtt/verification-des-modifications.txt

@@ -0,0 +1,33 @@
+====== Vérification des modifications ======
+
+Surveillance automatique des mises à jour disponibles des firmwares des dispositifs Zigbee.
+
+Les dispositifs Zigbee que vous utilisez ont la capacité de solliciter une vérification de mise à jour du firmware. Zigbee2MQTT facilite cette fonctionnalité en effectuant automatiquement des vérifications pour déterminer si des mises à jour sont disponibles pour vos dispositifs.
+
+L'état de la mise à jour est ensuite publié sous la forme d'une publication MQTT à l'adresse ''zigbee2mqtt/[NOM_AMICAL_DU_DISPOSITIF]'', avec un exemple de charge utile illustrant l'état ''available'' comme ceci : 
+<code>
+{"update": {"state": "available"}}
+</code>
+
+Les états possibles sont les suivants :
+
+1. **available** : Indique qu'une mise à jour est disponible pour le dispositif en question.
+
+2. **updating** : Signifie que la mise à jour est en cours. Pendant ce processus, des informations telles que le pourcentage de progression et le temps restant en secondes sont également incluses dans la charge utile. Par exemple : ''{"update": {"state": "updating","progress":13.37,"remaining": 219}}''.
+
+3. **idle** : Indique qu'aucune mise à jour n'est disponible ou en cours de réalisation.
+
+Afin de protéger la vie privée des utilisateurs, il est possible de limiter la fréquence à laquelle les dispositifs peuvent contacter des serveurs tiers pour effectuer des vérifications de mise à jour. Vous avez la possibilité de définir le temps minimum entre deux vérifications de mise à jour du firmware, en minutes. Par défaut, cette durée est de **1440** minutes (soit 1 jour). Par exemple, vous pouvez la régler pour qu'une vérification soit effectuée au maximum toutes les deux jours :
+<code yaml>
+ota:
+    update_check_interval: 2880
+</code>
+
+De plus, il est possible d'ignorer complètement les demandes initiées par les dispositifs pour effectuer des vérifications de mise à jour en modifiant le fichier de configuration (''configuration.yaml''). Voici un exemple de configuration permettant uniquement les vérifications manuelles de mise à jour du firmware :
+
+<code yaml>
+ota:
+    disable_automatic_update_check: true
+</code>
+
+À noter qu'il existe également une propriété obsolète appelée ''update_available''.