[Présentation] akenad

« Flash » Les ports Jeedom :

Bonjour,

Voici quelques ports que l’on peut rencontrer dans les plugins Jeedom :

Port d’une clé USB :

  • /dev/ttyUSB* : JeedomSmart Stretch Kernel 3, Odroid-C2 Armbian Stretch Kernel 3

  • /dev/ttyACM* : JeedomSmart Buster Kernel 3, Pi3 Raspbian Stretch Kernel 4, Pi4 Raspbian Buster Kernel 4, Odroid-C2 Armbian Buster Kernel 5

port d’un carte GPIO (Razberry, Enocean Pi, RaspBee) :

  • /dev/ttyS1 : JeedomSmart Stretch ou Buster Kernel 3, Odroid-C2 Armbian Stretch Kernel 3, Atlas Buster Kernel 5
  • /dev/ttyAMA0 : Pi3 Raspbian Stretch Kernel 4, Pi4 Raspbian Buster Kernel 4, Pi4 PioS Bullseye
  • /dev/ttyAML1 : Odroid-C2 Armbian Buster Kernel 5

RPi3 & RPi4

Le SoC du Pi3 possède 2 interfaces séries : UART0 et UART1(miniUART).
Par défaut le module Bluetooth interne est connecté à UART0 et les broches 8 et 10 du connecteur GPIO connecté au miniUART .
Pour que des cartes GPIO utilisant l’interface série fonctionne correctement, il est préférable de ne pas utiliser le module Bluetooth interne et de permuter les entrées/sorties des 2 UART en modifiant la configuration de la manière suivante :

  • Dans /boot/config.txt ajouter à la fin :
    dtoverlay = pi3-disable-bt
  • Dans /boot/cmdline.txt supprimer :
    console=serial0,115200

plus de détails ici : https://www.framboise314.fr/le-port-serie-du-raspberry-pi-3-pas-simple/

EDIT : Dans les dernières version de PiOS, pi3-disable-bt devient un alias sur disable-bt

Pour le Pi4 (avec Pi OS 64) :

  • Dans /boot/config.txt ajouter à la fin :
    dtoverlay = disable-bt

plus de détails ici : Raspberry Pi Documentation - Configuration

Rebooter.
La commande :
$ ls -l /dev
devrait retourner un port serial0 qui pointe vers ttyAMA0

Voir exemple Pi4 et Razberry ici : Pi4 et Razberry

Odroid-C2

Un exemple ici de ce qu’il a fallu faire pour qu’un carte GPIO RaZberry fonctionne sur un Odroid-C2 : [RTEX] Odroid-C2 - eMMC - Armbian Buster Kernel 5.3 - Jeedom V4

Nota : compte tenu de la difficulté de faire fonctionner une carte serie GPIO,
(le port série GPIO peut ne pas être actif en fonction de la version de l’OS/Kernel utilisé)
je conseille plutôt pour les utilisateurs non avancés de n’utiliser que des ports série en USB.

RPi5

Voir ici : Aide : RPI 5 + Debian 12 + ZwaveJS (Razberry) - #24 par Typher

akenad :slight_smile:

"Flash" Les ports USB du Pi4 :

Bonjour,

Le Pi4 dispose de :

  • 1 port USB-C pour l’alimentation
  • 2 ports USB2 (couleur noire)
  • 2 ports USB3 (couleur bleue)

1 port USB3 peut-être utilisé pour connecter un disque USB3 SSD.
1 port USB2 peut-être utilisé pour connecter un Hub USB2 avec sa propre alimentation.

Les clés USB peuvent alors être connectées sur le HUB, car il a été constaté un problème de fonctionnement pour certaines clés USB connectées directement sur les ports USB du Pi4 telles que la clé USB Aeotec Z-Stick Gen5

Un exemple de mise en oeuvre ici : [RTEX] RPi4B - Raspbian Buster Lite - USB SSD - Jeedom V4
Sujet abordé aussi ici : Tentative fonctionnement premier équipement Jeedom - #16 par akenad

akenad :slight_smile:

2 « J'aime »

"Flash" Restauration de la Smart :

Bonjour,

Sur la JeedomSmart vous avez fait une « Restauration Image » (pour passer en Buster), la sauvegarde de Jeedom a été effectuée sur la clé USB, le système et un Jeedom vierge ont été effectivement installés, mais la restauration n’a pas fonctionné (étape 5, finalisation, figé à 1%).

Voici une méthode pour effectuer la restauration de Jeedom manuellement :

Réglages > Système > Sauvegardes
Dans Sauvegardes locales
-Ajouter une sauvegarde (depuis la clé USB)
-Restaurer la sauvegarde

Autre méthode :

  1. Installer le plugin JeeXplorer
  2. Introduisez la clé USB dans votre PC
  3. Lancer JeeXplorer
    -Aller dans le dossier /html/backup
    -Cliquer droit sur le dossier et sélectionner « Envoyer les fichiers »
    -Glissez-déposez le fichier backup-xxx.tar.gz de la clé USB
  4. Aller dans le menu « Sauvegardes » (Onglet Jeedom Roue crantée en V3, Réglages-> Système en V4)
    Vous devriez voir le fichier dans Sauvegardes locales/Sauvegardes disponibles
    -Cliquer sur « Restaurer la sauvegarde »

Nota : il est aussi possible de faire l’opération inverse, pour exporter une sauvegarde Jeedom, aller dans le dossier /html/backup, cliquer droit sur un fichier et sélectionner « Télécharger ».

akenad :slight_smile:

2 « J'aime »

« Flash » Le Projet CHIP, ConnectedHomeIP, Matter :

Bonjour,

Le projet « Connected Home over IP » (CHIP), vise à promouvoir l’interopérabilité de différentes solutions domotiques.
Apple, Google, Amazon et la ZigBee Alliance forment un groupe de travail pour développer un standard ouvert (projet open-source sur github) pour le smart Home, un protocole de connectivité unifié basé sur IP, qui sera compatible avec les services smart home et assistant vocaux tels que Google Assistant (Weave), Amazon Alexa, Apple Siri (HomeKit).
Silicon Labs, membre de la ZigBee Alliance, qui possède par ailleurs Sigma Designs, le créateur du protocole propriétaire Z-Wave, envisage pour rester dans la course de faire du Z-Wave un standard ouvert.

Il faut donc probablement s’attendre dans un futur proche dans le monde des équipements domotique à une convergence des messages s’appuyant sur les radios Wi-Fi, Bluetooth BLE, Zigbee et Z-Wave et à la disparition à terme de quelques Gateway.
Matter est ici : https://csa-iot.org (anciennement https://www.connectedhomeip.com, puis https://buildwithmatter.com)

Le github de Matter est ici (https://github.com/project-chip/connectedhomeip) : GitHub - project-chip/connectedhomeip: Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.

et pour l’aspect sécurité de l’IoT : https://fr.ioxtalliance.org

L’ouverture du Z-Wave est ici : Specifications - z-wavealliance

Passerelles Wi-Fi ou Ethernet/Zigbee3 Matter :

-Aqara Hub M2 et Aqara Hub M1S (compatible Matter avec mise à jour firmware)
-Aqara Hub M3 : border router Thread, et controlleur et commissioner Matter
-Ikea Dirigera (compatible Matter)
-Philips Hue bridge (compatible Matter avec mise à jour firmware)

On peut imaginer au moins 3 plugins jeedom de nature différentes relatifs à Matter :

-interactions Matter sur le LAN (avec par exemple les passerelles philips, ikea, Aqara …)
-interactions Matter sur réseau Thread (border router/commissioner, avec par exemple un dongle USB embarquant un chipset radio 802.15.4 Silicon Labs EFR32MG21)
-passerelle logicielle : exposition des équipements jeedom non matter en matter sur le LAN` (analogue au principe utilisé dans le plugin homebridge qui expose des équipements jeedom non homekit en homekit sur le LAN)

(Merci de ne pas réagir sur ce post mais de créer un nouveau sujet, comme expliqué dans mon premier post)

Un sujet dédié pour en discuter ouvert ici : Le projet Connected Home over IP : CHIP -> matter

akenad :slight_smile:

1 « J'aime »

« Flash » Les Box Jeedom :

Bonjour,

akenad :slight_smile:

"Flash" Xiaomi Gateway Wi-Fi, mode Dev/LAN et port udp 9898 :

pour la Xiaomi GW DGNWG02LM,
lorsque le mode Dev/LAN est inopérant,

le port udp 9898 peut être ouvert par une méthode matérielle.

/!\ IMPORTANT :
Parmi les très nombreuses Xiaomi Gateway Wi-Fi,
seul le modèle DGNWG02LM est compatible avec le #plugin-xiaomihome, mais elle semble malheureusement dorénavant en fin de commercialisation.

Ne pas confondre les différentes LUMI gateway :

  • DGNWG02LM avec prise chinoise (Mi Control Hub)[lumi.gateway.v3]
  • DGNWG03LM pour Taïwan
  • DGNWG05LM avec prise Europe (Mi Control Hub)[lumi.gateway.mieu01]
  • ZHWG11LM Aqara Hub Homekit [lumi.gateway.aqhm01]
  • ZHWG12LM (version chinoise) Aqara Hub M2 Homekit, Zigbee 3.0, Ethernet, BLE 5.0, IR
  • HM2-G01 version EUrope de l’Aqara Hub M2
  • ZHWG15LM Aqara Hub M1S Homekit Zigbee 3.0
  • HM1S-G01 version EUrope de l’Aqara Hub M1S [lumi.gateway.aeu01] Homekit, Zigbee 3.0, Wi-Fi
  • HM1S-G02 version EUrope de l’Aqara Hub M1S Gen2 Homekit, Zigbee 3.0, Wi-Fi WPA3
  • ZNDMWG02LM et ZNDMWG03LM Xiaomi Mijia Smart multi-mode Gateway Homekit, Zigbee 3.0, Bluetooth Mesh (Mi Smart Home Hub)[lumi.gateway.mgl03]

Un conseil, ne parlez pas de la « Gateway V3 ». L’appellation n’est pas suffisamment précise, plusieurs peuvent être dénommées ainsi !

La DGNWG02LM ne fonctionne pas avec Le #plugin-xiaomihome lorsque l’activation du mode développeur (API LAN) est inopérante dans l’App Mi Home.

Cette méthode est censée ouvrir le port udp 9898 sur la Gateway mais parfois cela n’a aucun effet.

Pour ouvrir ce port une méthode matérielle consiste à lancer sur la Gateway la commande :

psm-set network.open_pf 3

La procédure détaillée est décrite ici : [RTEX] Xiaomi Gateway - mode Dev/LAN et port udp 9898

Plugin HkControl :
Pour la compatibilité des Xiaomi GW Homekit avec Jeedom, il est possible, moyennant certains pré-requis, d’utiliser le plugin « HkControl » (Homekit Network Devices Control). Testé avec les Xiaomi Gateway :

  • Aqara Hub
  • Mi Smart Home Hub (multi-mode)
  • Aqara Hub M1S
  • Aqara Hub M2

Voir ici :Plugin Homekit Network Devices Control (hkControl)

akenad :slight_smile:

1 « J'aime »

« Flash » Version OS :

Bonjour,

Jessie et Stretch obsolète !
(Fin du support LTS Debian 8 « Jessie » le 30 juin 2020 et Debian 9 Stretch le 30 juin 2022 : fr/LTS - Debian Wiki)
(Certaines dépendances indispensables à certains plugins ne sont plus disponibles.)

Depuis Jeedom V3.3.54 (01/12/2020), si l’OS est supérieur à Jessie (Debian 9 « Stretch » ou Debian 10 « Buster »), un outil de migration facile est disponible dans le Centre de mise à jour (Bouton « Mettre à niveau V4 ») : https://doc.jeedom.com/fr_FR/howto/migration.version

Je recommande de passer en Buster pour la Smart, la Mini+ et le DIY.

Les méthodes officielles de Jeedom SAS :
(Ce sont des installations d’images, et non une mise à jour de l’OS, qui nécessitent ensuite une restauration d’une sauvegarde Jeedom.)

Pour la Smart :

La « Restauration Image » est un assistant qui automatise le « Recovery Mode » pour une « Migration Facile ».

Les 2 méthodes utilisent l’image backupJeedom.tar.gz (Buster+Jeedom V4) ici : Index of /smart
(Contient plus précisément Debian 10.4 + Jeedom V4.0.61)
/!\ ATTENTION : depuis le 24/11/2020, cette image à remplacé l’ancienne (Stretch+Jeedom V3).
Plus de détails ici : [RTEX] Jeedom Smart Recovery mode - passage en Buster Jeedom V4

L’ancienne image backupJeedom.tar.gz (Stretch+Jeedom V3) est pour l’instant toujours disponible ici : images sur cloud amazon
(Empreinte Hash SHA256 : cd e1 ff a9 c0 14 4d a0 22 cd 98 15 ef 2f 76 9f c2 ea 0f 47 f0 44 e7 9d 82 99 ad 9c 9a d8 c9 2d)

Pour la Mini Plus :
/!\ ATTENTION : il n’existe pas d’image Jeedom Buster ! (uniquement Stretch + Jeedom v3)
cependant la Mini+ (« JeeBoard ») est basée sur une HummingBoard iMX6 dont les images buster et bullseye sont ici : SolidRun Images

(jeeboard, microSD uniquement, SDHC 32GB SanDisk Extreme PRO conseillé) :
pour la passer en Stretch, documentation officielle Jeedom SAS : https://doc.jeedom.com/fr_FR/installation/mini
il est indiqué que l’image est ici (Stretch+Jeedom V3 uniquement, autrement dit pas de Buster+Jeedom V4) :
Index of /jeeboard
Méthode qui fonctionne :
-télécharger jeedom_jeeboard_3.3.24_stretch.zip (environ 1,4 Go) avec Edge Chromium
-décompresser avec 7-Zip dernière version => jeedom_jeeboard_3.3.24_stretch.img (environ 8,1 Go)
-bien vérifier l’empreinte Hash SHA256 de jeedom_jeeboard_3.3.24_stretch.img : 41 98 f6 45 6b 43 a9 6a 32 7c 56 8e 4a 08 54 81 65 03 bc c8 04 1a e3 a3 7c 66 c6 9f ea 33 b7 1b)
-Flasher avec balenaEtcher
Voir aussi : Installation Linux sur mini+ - #7 par purplelynx42

Pour Rpi et x86-64 (Buster+Jeedom V4) :
les images sont ici :
https://images.jeedom.com

RPi avec eMMC : RAZ Jeedom sur RPI 3 - #4 par akenad

/!\ ATTENTION : exporter au préalable une sauvegarde de Jeedom pour la restaurer ensuite (par exemple avec le plugin JeeXplorer).

Pour avoir des informations sur le système :

$ cat /etc/debian_version
$ uname -a
$ cat /etc/os-release
$ lsb_release -a
$ arch
$ lscpu
$ dpkg --print-architecture

exemple :

$ cat /etc/debian_version
10.4

$ uname -a
Linux jeedom9 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux      

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

$ arch
x86_64

$ lscpu | grep Arch
Architecture:        x86_64

$ dpkg --print-architecture
amd64

SMART :
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

ATLAS :
$ cat /etc/os-release
PRETTY_NAME="Armbian 21.05.8 Buster"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Pour RPi :

$ cat /proc/cpuinfo | grep Model
Model		: Raspberry Pi 4 Model B Rev 1.2

La version du système dans Jeedom s’obtient en allant dans :
Analyse → Santé
Version OS : […]

C’est très utile pour résoudre un problème de préciser sont matériel et son système lorsqu’on expose un problème sur Jeedom Community.

Les architectures (Kernel 3.x, 4.x, 5.x, 6.x) :

Quelques exemples :

  • Jeedom Luna
    Version OS : Linux JeedomLuna 4.4.194 #101 SMP Wed Sep 14 01:49:23 UTC 2022 aarch64 GNU/Linux [11.6]

  • Jeedom Atlas Armbian Bullseye (après recovery depuis 2024)
    Version OS : Linux JeedomAtlas 5.15.93-rockchip64 #23.02.2 SMP PREEMPT Fri Feb 17 23:48:36 UTC 2023 aarch64 GNU/Linux [11.8]

  • Jeedom Atlas Armbian Buster (après recovery avant 2024)
    Version OS : Linux JeedomAtlas 5.10.43-rockchip64 #21.05.4 SMP PREEMPT Wed Jun 16 08:02:12 UTC 2021 aarch64 GNU/Linux [10.10]

  • Jeedom Smart Debian Buster (avec Kernel mis à jour)
    Version OS : Linux jeedom 3.16.85+ #1 SMP PREEMPT Mon Jul 13 14:40:04 UTC 2020 aarch64 GNU/Linux [10.4]

  • Rock Pi4B+ V1.72 Armbian bullseye
    Version OS : Linux rockpi-4b 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux [11.2]

  • Rock Pi4B+ V1.72 Armbian bullseye
    Version OS : Linux rockpi-4b 6.1.50-current-rockchip64 #3 SMP PREEMPT Wed Aug 30 14:11:13 UTC 2023 aarch64 GNU/Linux [11.7]

  • Odroid-C2 eMMC Armbian Bullseye
    Version OS : Linux odroidc2 5.10.123-meson64 #22.05.3 SMP PREEMPT Wed Jun 22 07:23:04 UTC 2022 aarch64 GNU/Linux [11.3]

  • Odroid-C2 eMMC Armbian Buster
    Version OS : Linux odroidc2 5.3.11-meson64 #19.11.3 SMP PREEMPT Mon Nov 18 20:10:57 CET 2019 aarch64 GNU/Linux [10.2]

  • RPi4B SSD Raspbian Buster
    Version OS : Linux hostname 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux [10.3]

  • RPi4B V1.2 SSD Pi OS 64 Bits (Buster)
    Version OS : Linux hostname 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux [10.13]

  • RPi4B V1.1 SSD Pi OS 64 Bits (Buster)
    Version OS : Linux hostname 5.4.51-v8+ #1327 SMP PREEMPT Thu Jul 23 11:11:34 BST 2020 aarch64 GNU/Linux [10.13]

  • RPi3B+ SSD Pi OS 32 Bits (Bullseye)
    Version OS : Linux raspberrypi 5.15.76-v7+ #1597 SMP Fri Nov 4 12:13:17 GMT 2022 armv7l GNU/Linux [11.5]

  • image RPi 64 Bits (Buster) de Jeedom SAS : jeedom-debian-buster-rpi-64-4.0.61.zip (du 03/12/2020)
    Version OS : Linux jeedom 5.4.72-v8+ #1356 SMP PREEMPT Thu Oct 22 13:58:52 BST 2020 aarch64 GNU/Linux [10.7]

  • image x86-64 (Buster) de Jeedom SAS : jeedom-debian-buster-amd64-4.1.19.iso (du 03/02/2021)
    Version OS : Linux jeedom 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux [10.7]

  • image x86-64 (Bulleye) de Jeedom SAS : jeedom-debian-bullseye-amd64-4.3.17.iso (du 20/04/2023)
    Version OS : Linux jeedom 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux [11.6]

  • NUC Intel VM proxmox Buster
    Version OS : Linux hostname 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux [10.0]

  • NUC Intel VM proxmox Buster
    Version OS : Linux hostname 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux [10.5]

  • NUC Intel VM proxmox Bullseye
    Version OS : Linux hostname 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux [11.1]

Voici un petit tableau comparatif simplifié de versions de paquets Debian, fréquemment utilisés par Jeedom :

------------Jessie---------Stretch--------Buster----------Bullseye------Bookworm
------------Debian 8.0—Debian 9.0—Debian 10.0—Debian 11.0—Debian-12.0
Kernel—3.16------------4.9-------------4.19-------------5.10--------------6.1
GCC-----4.9------------6.3-------------7.4 et 8.3------10.2
PHP------5.6-------------7.0-------------7.3--------------7.4----------------8.2
Python—2.7 et 3.4------2.7 et 3.5-----2.7 et 3.7------3.9--------------3.11
Apache–2.4.10--------2.4.25---------2.4.38----------2.4.51-------------2.4.57
MariaDB-MySQL 5.5-----5.8------------10.3-------------10.5
npm--------5.8
NodeJS—10.15
ffmpeg-----3.2-------------4.1--------------4.3

A noter que le Core et les plugins de Jeedom peuvent être amenés, via l’installation des Dépendances, à désinstaller certains paquets et les remplacer par d’autres versions.

Il suffit d’un seul plugin qui gère mal l’installation de ses dépendances (certaines pouvant être communes avec d’autres plugins) et cela peut générer une inconsistance au détriment de tous les autres plugins.

Afin de cadrer et structurer l’installation de dépendances système,
et pour minimiser les problèmes associés, une solution serait de réaliser une librairie bash commune à Jeedom, utilisable par les plugins dans leur script d’installation des dépendances.
L’idée étant donc d’éviter les inconsistances essentiellement sur PHP, Python et NodeJS.

Concernant NodeJS, les plugins orientés Apple de @nebz sont pour moi des références en la matière.
Astuce : NodeJS et NPM dans une version utilisée par plusieurs plugins peuvent être installées en installant les dépendances du plugin alexa-api.

akenad :slight_smile:

2 « J'aime »

“Flash” Plugin Jeedom Homebridge :

Bonjour,

Sur le iPhone, dans l’App « Maison », pour voir les ponts Homebridge et leurs accessoires,
2 méthodes :

  1. cliquer l’icone « Maison » en bas à gauche
    puis cliquer sur l’icone Maison en haut à gauche
    puis sélectionner « Réglages des domiciles » puis le nom d’un domicile (« Maison » pour moi)

  2. cliquer l’icone « Maison » en bas à gauche
    puis cliquer le bouton « Modifier » (en haut à droite)
    alors un chevron « > » apparait à droite du nom du domicile (« Maison » pour moi)
    cliquer sur « > »

ensuite sélectionner « concentrateur et ponts »,
puis sélectionner le pont.

Pour supprimer le pont cliquer « Supprimer le pont du domicile ».

Version en images animées par @nebz ici : Voir pont Homebridge dans iPhone App Maison - #2 par nebz

akenad :slight_smile:

“Flash” équipements Zigbee Xiaomi :

Bonjour,

Pour savoir si un équipement Zigbee est compatible avec le plugin Jeedom « Xiaomi Home » (associé à la Xiaomi Gateway DGNWG02LM),
le mieux est de consulter le site du développeur lunarok : https://lunarok-domotique.com :
Ensuite sélectionner « Plugins Jeedom » > "Xiaomi Home > « Xiaomi Smart Home Security »
(accès direct : Aqara - Lumi - Xiaomi Smart Home Security - Domotique de Lunarok)
et parcourir le tableau.

Par exemple on peut y trouver :

  • le double interrupteur encastrable, de son petit nom « Aqara Wall Switch », alias « QBKG03LM ZigBee Aqara Wall double Switch » (L L1 L2, sans Neutre)
  • la prise, de son petit nom « Aqara Plug », alias « ZNCZ02LM ZigBee Xiaomi Mijia Power Plug »

QBKG03LM-Zigbee-Aqara-Wall-double-Switch


ZNCZ02LM-Xiaomi-Mijia-ZigBee-Power-Plug-Front
ZNCZ02LM-Xiaomi-Mijia-ZigBee-Power-Plug-Back
A 99 %, Si l’équipement Zigbee n’est pas dans ce tableau, c’est qu’il n’est pas compatible avec le plugin Xiaomi Home.

Par exemple on ne trouve pas dans le tableau :

  • le double relais, de son petit nom “Aqara Relay", alias ”LLKZMK11LM Zigbee Xiaomi Mijia Aqara Two way Wireless Relay Controller (2 channels) (model:lumi.ctrl_dualchn)"

Inutile de demander au développeur du plugin quand un équipement qui n’est pas dans le tableau sera compatible car la compatibilité n’est pas du fait du plugin mais de l’API LAN Xiaomi sur laquelle s’appuie le plugin.
Par ailleurs ce n’est pas parce qu’un équipement fonctionne avec l’App Mi Home qu’il va fonctionner avec le plugin Xiaomi Home. En effet l’App Mi Home fonctionne avec le Cloud Xiaomi mais pas L’API LAN qui peut comporter des différences.

Une description de l’API LAN et des équipements pris en charge (se trouvait en anglais mais retiré) ici :

http://docs.opencloud.aqara.com/en/development/gateway-LAN-communication/
http://docs.opencloud.aqara.com/development/gateway-LAN-communication

Le relais lumi.ctrl.dualchn est certes mentionné dans la documentation, mais l’API ne permet pas de le commander.

Pré-requis pour qu’un périphérique Xiaomi Zigbee soit intégrable dans le plugin Xiaomi Home.

L’illustration est faite avec le Xiaomi Aqara Wireless Relay Controller (2 channels), modèle LLKZMK11LM (model lumi.ctrl.dualchn)

Le plugin Xiaomi Home communique avec la Xiaomi Gateway, laquelle communique avec les périphériques Xiaomi Zigbee.
Pour communiquer le plugin Xiaomi s’interface avec l’API LAN de la Xiaomi Gateway.
Ce mode de communication est différent de la communication entre l’App Mi Home et la Xiaomi Gateway (mode cloud HTTP).
Ces 2 modes semblent évoluer indépendamment et peuvent ne pas avoir le même niveau de compatibilité à un instant donné.
Autrement dit à un instant donné un périphérique peut être contrôlé (via la Xiaomi Gateway avec dernière version firmware)
avec la dernière version de l’App Mi Home alors que la version du protocole d’API LAN embarquée dans la Xiaomi Gateway ne le permet pas.

La compatibilité du plugin Xiaomi Home vis à vis d’un périphérique Xiaomi Zigbee est donc dépendante de la prise en charge de ce périphérique par la Xiaomi Gateway en mode API LAN.
Cette prise en charge pourrait dépendre à priori du modèle de Xiaomi Gateway et de la version de son firmware.

Le pré-requis pour qu’un périphérique Xiaomi Zigbee puisse être intégrable dans le plugin Xiaomi Home, c’est que lors d’un changement d’état du périphérique,l 'API LAN transmette une commande « report » en multicast IP 224.0.0.50 udp 9898.

Dans le cas du relais le « model » renvoyé dans une commande « report » devrait être « lumi.ctrl.dualchn » et visible dans la log du plugin en mode debug.
A ce stade, pour une Xiaomi Gateway, modèle DGNWG02LM, (model=lumi.gateway.v3) des membres du forum ont signalés que le relais n’était pas visible.
(v1.4.1_167.0158, dernière version de firmware connue en date du 09/04/2019)
Une explication serait que la version de l’API LAN embarquée dans le firmware de la Xiaomi Gateway n’est pas suffisamment récente ou que le relais n’est en réalité pas correctement ou que partiellement implémenté dans le protocole API LAN.

L’API ne fait pas apparaitre au jour ou j’écris ce post de commande « write ».
Ce qui voudrait dire que les relais ne peuvent pas être commandés via l’API LAN, mais avoir au mieux uniquement un retour d’état on/off,
Ce qui limite l’intérêt de ce relais vis à vis du plugin Xiaomi Home.

akenad :slight_smile:

1 « J'aime »

"Flash" plugin Z-Wave :

Bonjour,

Depuis plus de 2 ans que je l’utilise je suis très satisfait du plugin Jeedom Z-Wave.

Cependant, 2 petits bémols :

1) Retours d’état :
Depuis la mise à jour du plugin du 04-02-2019 (c’était donc il y a un an) (https://jeedom.github.io/plugin-openzwave/fr_FR/changelog), il arrive que pour certains modules, certains retours d’états ne soient pas pris en compte par le plugin en configuration par défaut (identifiés par exemple pour certains modules double switch).
Un contournement est possible dans la configuration du module :
Equipement → Configuration → Valeurs
Changer le Rafaichissement de « Auto » à « 5 min ».
On perd le temps réel mais ce n’est pas forcement un problème, ça dépend de l’usage.

2) Compatibilité avec de nouveaux modules
Certains nouveaux modules ne sont pas complétements fonctionnels.
Ceci est lié au fait que le plugin Jeedom Z-wave s’appuie toujours sur un fork de Openzwave 1.4 alors que certains nouveaux modules nécessitent Openzwave 1.6 pour être pleinement fonctionnel.

Toutefois une alternative au plugin actuel ou à OpenZWave 1.6 pourrait être étudié.
En effet Comme je l’ai indiqué dans un post plus haut Silicon Labs ouvre ses spécifications Z-Wave.
Une alternative pourrait être de développer un nouveau plugin s’appuyant sur le Z-Wave SDK de Silicon Labs.
L’outil « Z-Wave PC Controller » (téléchargeable depuis https://www.silabs.com) est un exemple d’application qui utilise les fonctionnalités exposées par l’API série Z-Wave embarquée dans un contrôleur Z-Wave.
sur Z-Wave 700 Series End Device Software Development Kit - Silicon Labs
Cliquer « PC Controller ».
Créer un compte Silicon Labs.

Et quelques informations complémentaires en passant :

Les spécifications Z-Wave Plus : Z-Wave Specifications - Z-Wave Alliance

  • Les classes de commandes Z-Wave :
  1. Liste de référence des classes de commandes Z-Wave : https://www.silabs.com/documents/login/miscellaneous/SDS13548-List-of-defined-Z-Wave-Command-Classes.xlsx
  2. Les classes de commandes utilisées dans le plugin Z-Wave : https://github.com/jeedom/plugin-openzwave/blob/master/resources/openzwaved/ozwave/globals.py (COMMAND_CLASS_SOUND_SWITCH = 121 #0x79 n’existe pas dans ce fichier)

akenad :slight_smile:

7 « J'aime »

« Flash » Logs Debug :

Bonjour,

Un petit Flash à l’attention particulière des nouveaux arrivants sur le forum.

Vous avez un problème sur Jeedom, vous voulez vous faire aider.
Vous êtes les bienvenus et au bon endroit.
Mais attention les « aideurs/Helpeurs » n’ont ni la science infuse ni de boule de cristal.

Si vous dites par exemple « j’ai un problème depuis la dernière mise à jour du plugin totopouet, vous avez une idée ? »
C’est peut-être un peu court.
L’aideur qui voudra essayer de vous aider vous demandera « les logs debug ».

"Papa, c'est quoi cette bouteille de lait ?"

  • Log : fichier journal contenant les enregistrements historique des événements d’un processus particulier.
  • Debug : dans le contexte Jeedom c’est le niveau du log au maximum de verbosité.

Toutes les logs Jeedom sont rassemblées et visibles via :
Onglet « Analyse » → Logs
quelques exemples :

  • backup
  • http.error
  • jeedom
  • network
  • plugin
  • restore
  • scenario
  • starting
  • update

Les logs des plugins sont « tournant », c’est-à-dire que les lignes les plus récentes viennent écraser les lignes les plus anciennes. Ceci pour éviter que le disque ne se remplisse à l’infini.

Le nombre de lignes maximum dans un fichier de log est de 500 initialement, lors de l’installation de Jeedom.
Parfois ce n’est pas suffisant pour tracer entièrement un phénomène ou un bug.

le « Nombre de lignes maximum dans un fichier de log » est modifiable (Jeedom V4) :
Onglet Réglages → Système → Configuration → Logs
puis cliquer sur l’onglet « Logs » (et pas « Alertes »)

Lorsque c’est nécessaire le nombre de lignes peut être passé temporairement à 1000 ou 2000, le temps des investigations.

les logs d’un plugin se gèrent dans la configuration du plugin.
souvent un plugin a 3 logs ;

  • le log des dépendances, d’installation et/ou de mise à jour
  • le log du démon (s’il en a un)
  • le log de fonctionnement

prenons l’exemple des plugins Z-Wave et Homebridge.
Dans
Gestion → configuration du plugin → « Logs et surveillance » :

Z-Wave :

  • le log des dépendances, d’installation et/ou de mise à jour : « Openzwave_update »
  • le log du démon : « Openzwaved »
  • le log de fonctionnement : « Openzwave »

Homebridge :

  • le log des dépendances, d’installation et/ou de mise à jour : « Homebridge_dep »
  • le log du démon : « Homebridge_daemon »
  • le log de fonctionnement : « Homebridge »

Pour générer des logs en niveau Log Debug,
cliquer sur le bouton radio « Debug » puis sur le bouton « Sauvegarder » (de la fenêtre « Logs et surveillance »)

et pour générer de la log :

  • Relancer les Dépendances
  • ReDémarrer le Démon

Si le forum ne vous autorise pas à joindre un fichier parce que en tant que nouvel utilisateur vous n’avez pas encore atteint le niveau de confiance 1 (« Basic user », badge « Actif » : Badge Actif sur Communauté Jeedom), le contenu de chaque Log peut être copié/collé dans un post.

Pour une bonne lisibilité et pour ne pas « charger » le post, utiliser l’icône « Texte préformaté » :

Une fois les investigations terminées, revenir au niveau de log par défaut et au nombre de lignes maximum dans un fichier de log à 500.
(ceci pour ne pas remplir le disque inutilement).

Un développeur de plugin Jeedom peut parfois avoir besoin de logs qui ne sont pas directement dans jeedom
(donc pas dans un sous dossier de /var/www/html) mais au niveau de l’OS.

Exemple avec le plugin Homebridge :
il peut arriver que les dépendances du plugin Homebridge ne s’intallent pas correctement, un fichier log debug peut alors être généré dans le dossier /root/.npm/_logs

Pour afficher le log :

Jeedom → Réglages → Système (ou Roue crantée en V3) → Configuration → OS/DB → Administration Système

Taper les commandes :

sudo ls /root/.npm/_logs
XXXXXXXX-debug.log
sudo cat /root/.npm/_logs/XXXXXXXX-debug.log

akenad :slight_smile:

5 « J'aime »

“Flash” sur deCONZ :

EDIT 17/06/2023 : dernier test qui fonctionne :
-RPi4 Buster (Pi OS 64 10.13)
-plugin deconz 2023-02-16
-firmware ConBee2 0x26780700
-deconz 2.21.02

deCONZ et la “Phoscon Gateway” (pont Zigbee), alias “La Gateway ZigBee USB Universelle” de dresden-elektronik.

Liste de compatibilité équipements Zigbee : Database of Zigbee devices compatible with ZHA, Tasmota, Zigbee2MQTT, deCONZ, ZiGate and ioBroker

Pour faire simple, une Phoscon Gateway c’est du matériel (clé USB ConBee, ConBee2 ou Carte GPIO RaspBee dans un Rpi) et du logiciel en mode déporté ou local.

  • en « déporté » sur Rpi avec une image pour Rpi disponible ici : Index of /sd-card-image-beta/ (pour interface graphique GUI ne pas prendre Headless)

  • en « local » avec paquet deb deCONZ en fonction des architectures processeur.

Embarque une serveur web et une web API (Phoscon App et logiciel deCONZ).

Les paquets deb deCONZ sont disponibles en stable et beta ici:
sur les architectures suivantes :

Au 17/11/2023, DeCONZ v2.24.2 Stable
Changelog : changelog.en

Jeedom publie les paquets deb deCONZ utilisés par le plugin Jeedom Deconz ici : Index of /resources/deconz

Le plugin deCONZ reconnait l’architecture et installe (ou remplace lors d’une mise à jour) le paquet deb deCONZ correspondant lorsque l’on clique sur le bouton “Lancer” Installation Deconz local dans la configuration du plugin (puis redémarrer le démon, la version est visible dans Réseau Deconz/onglet Résumé).

A un instant t, le paquet deCONZ utilisé par le plugin Deconz peut être plus ancien que la dernière version disponible chez dresden-elektronik. Ce qui peut expliquer que certains utilisateurs remontent des problèmes de compatibilité de certains équipements avec le plugin deconz alors que ses équipements sont supportés avec la dernière version de deCONZ. Ce décalage est en principe de quelques jours.

La liste des équipements Zigbee supportés maintenue par Dresden est ici : Supported Devices · dresden-elektronik/deconz-rest-plugin Wiki · GitHub

Une présentation de deCONZ très intéressante en français pour commencer à appréhender le sujet ici : https://presentationdeconz.wordpress.com

Le meilleur point d’entrée de dresden-elektronik est ici : https://phoscon.de

et la documentation sur le plugin jeedom Deconz : https://doc.jeedom.com/fr_FR/plugins/automation%20protocol/deconz/

Quelques accès directs sur Phoscon :

Les firmwares des clés Conbee2 et Conbee sont disponibles ici: Index of /deconz-firmware/

Au 15/05/2022 en stable :

  • pour la Conbee 2 : deCONZ_ConBeeII_0x26780700.bin.GCF
  • pour la RaspBeeII : deCONZ_RaspBeeII_0x26780700.bin.GCF
    Au 19/08/2021 en stable :
  • pour la conbee (et RaspBee) : deCONZ_Rpi_0x26400500.bin.GCF

(la dernière version beta est dans le dossier beta)

Pour mettre à jour le firmware d’une clé Conbee2 ou Conbee ce qui semble fonctionner le mieux c’est
sous Windows
avec l’outil GCFFlasher ici : Index of /win/
Nota : après installation de deCONZ, GCFFlasher.exe se trouve aussi dans le même répertoire que Deconz.exe, à savoir :
C:\Users\<user>\AppData\Local\deCONZ\bin

>GCFFlasher.exe -l
>GCFFlasher.exe -f deCONZ_ConBeeII_0x26580700.bin.GCF -d COM28 -t 60

J’ai fais fonctionner la Conbee2 et la Conbee sur un Pi4 (avec Pi OS 64 Buster) et Odroid-C2 (avec Armbian Buster).

Sous debian,
en SSH, pour voir le port, brancher la clé, lancer les commandes :

$ su -
# GCFFlasher_internal -l

donne :

GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------
/dev/ttyACM0    | 0x1CF1 | 0x0030  | xxxxxxxxx  | ConBee II

A noter que la Conbee2 est montée sur un port /dev/ttyACMx alors que la Conbee est sur un port /dev/ttyUSBx.

Pour mettre à jour le firmware (téléchargé dans le répertoire courant) :
-débrancher la clé
-lancer la commande :
# GCFFlasher_internal -d /dev/ttyACM0 -t 60 -f deCONZ_ConBeeII_0x26580700.bin.GCF
-rebrancher la clé.

/!\ ATTENTION : Il est très vivement recommandé de ne pas flasher la Conbee depuis une VM Debian, au risque de corruption définitive de cette clé.

/!\ ATTENTION : après une mise à jour du paquet deCONZ ou/et du firmware, il peut être nécessaire de réveiller ou/et réappairer certains équipements.

Restauration de la base de donnée DeCONZ/Phoscon :

Les inclusions (appairage) d’équipements (noeuds) réalisés avec la clé Conbee2 (contrôleur)
et l’application Phoscon ne sont pas stockées dans la clé mais dans un fichier de base de données DeCONZ.
Le plugin DeConz sauvegarde ce fichier de base de donnée DeCONZ dans son dossier data.
Ce fichier de base de donnée DeCONZ se trouve donc dans la sauvegarde Jeedom
mais n’est pas restauré automatiquement dans DeCONZ/Phoscon lors de la restauration de Jeedom.

Lorsque l’on réinstalle le système, par exemple lorsqu’on réalise une « Restauration Image »
ou une mise à jour pour passer en Buster sur une Smart, Si on utilisait déjà le plugin DeCONZ, il faut
refaire ce qui est indiqué dans la documentation Jeedom SAS officielle : https://doc.jeedom.com/fr_FR/plugins/automation%20protocol/deconz/
à savoir :

  • réinstaller les dépendances et Deconz local
  • configurer la clé conbee2
  • restaurer manuellement le fichier de base de donnée DeCONZ avec l’application Phoscon
  • synchroniser

La sauvegarde du fichier de base de donnée DeCONZ est dans le dossier /var/www/html/plugins/deconz/data
Télécharger ce fichier (il a l’extension .tar.gz) sur PC avec le plugin-jeexplorer (ou à partir de Jeedom 4.2, Réglages > Systèmes > Editeur de fichiers) . Renommer l’extension de ce fichier « .tar.gz » en « .dat ».
Charger ce fichier avec l’extension .dat dans phoscon (bouton « Backup options ») et cliquer bouton « synchronisation » dans le plugin.

Nombre de devices max
voir ici : Zigbee, impossible d'ajouter de nouveaux peripheriques - #2 par akenad

Un sujet dédié pour discussion ouvert par @Beber53 ici : Deconz - key usb plus détecté

akenad :slight_smile:

7 « J'aime »

"Flash" Jeedom Community :

Ce nouveau forum « Jeedom Community » s’appuie sur un nouvel outils nommé « Discourse » : https://www.discourse.org

La règle d’or : 1 sujet => 1 Problème => 1 Solution

Je suggère de prendre le temps d’apprendre à s’en servir tant pour créer des sujets, cliquer des solutions et utiliser le moteur de recherche avancé qui est bien plus puissant que sur l’ancien forum.

A noter que dans ce nouveau fonctionnement il n’y a pas de sujet « Officiel » dans la catégorie « Plugins ». (n’est « officiel » dans ce nouveau forum que les sujets de la catégorie « Annonces officielles ».)

Même avec un moteur de recherche puissant on ne trouve que ce qu’on y a mis.
Une bonne question (problème) fera une bonne réponse (solution).
Donc si chacun pose soigneusement sa question tous profiteront de la réponse (et vice versa).
C’est un peu pour ça que ça s’appelle « Community ».

Le principe pour un plugin-xxx, c’est d’ouvrir un sujet avec un titre explicite de problème et y ajouter une étiquette (tag) « plugin-xxx ».
Par exemple pour plugin-deconz ou plugin-openzwave, aller dans la catégorie « Plugins »/« Protocole domotique » : https://community.jeedom.com/c/plugins/protocole-domotique/
et cliquer le bouton « Créer un sujet », entrer un titre explicite du problème et ajouter le tag plugin-xxx.

L’intérêt de bien mettre le tag c’est que dans la recherche avancée on peut filtrer dessus.
ça permet aussi au développeur du plugin de mettre une alerte sur ce tag pour être notifié d’un nouveau sujet.
Lorsque un sujet a sa solution il suffit que le créateur du sujet clique sur le bouton solution du post qui décrit la solution et la solution remonte au niveau du premier post du sujet.
Ce principe, si la plupart, jouent le jeu fait gagner beaucoup de temps, il n’est pas nécessaire de lire l’intégralité des sujets.

Un exemple de méthode de recherche :

Les sujets sur les installations d’OS et Jeedom sont essentiellement dans la catégorie « Matériel Jeedom Hardware ».
Pour chercher, cliquer sur la loupe en haut à droite, puis cliquer sur « options ».
Dans la recherche avancée sélectionner la catégorie « Matériel Jeedom Hardware » et l’étiquette (tags).
On peut par exemple chercher sur la base du tag buster ou tutoriel.
La chaîne directe de recherche produite est :

#materiel-jeedom-hardware tags:buster
ou
#materiel-jeedom-hardware tags:tutoriel

Ensuite trier au choix par Pertinence, Dernier message, Plus aimé, Plus vu, Dernier sujet.

Pour plus de détails : Comment nous aider à vous aider - ou Comment poser une bonne question?

Un sujet dédié pour discussion ouvert par @pifou ici : Utilisation du forum community

akenad :slight_smile:

3 « J'aime »

« Flash » modules On/Off encastrables :

Quelques modules radios :

Zigbee : Legrand Netatmo 0 648 88
Z-Wave : Fibaro FGS-222
EnOcean : Nodon SIN-2-2-01
Wi-Fi : Shelly1PM, Sonoff Mini DIY

akenad :slight_smile:

1 « J'aime »

« Flash » Legrand Céliane with Netatmo :

Les équipements Legrand Netatmo sont en principes appairés avec la Gateway Legrand Netatmo.


Pour réaliser un ré-appairage sur cette GW Zigbee (ou une autre, par exemple la clé Conbee2), un reset doit être réalisé sur l’équipement.
Chaque équipement possède un bouton « Reset » en façade, qu’il faut pour certains démonter.
L’accès au bouton est repéré par la représentation d’une roue crantée :

  • prise de courant on/off ref 0 677 25
  • micromodule switch ON/OFF ref 0 648 88
  • interrupteur variable sans neutre ref 0 677 21 (avec compensateur ref 0 401 49 pour LED dimmable faible puissance.)


Pour dés-appairer l’équipement, appuyer quelques secondes sur le bouton reset (5 a 10 s en fonction de l’équipement) jusqu’à ce que la led passe au rouge fixe.
Pour ré-appairer l’équipement sur la GW Legrand, suivre la documentation.
Pour ré-appairer l’équipement sur une autre GW Zigbee, mettre la GW en mode appairage, puis appuyer brièvement sur le bouton reset de l’équipement, et attendre, la LED doit passer au vert.

Pour qu’une GW Zigbee puisse bénéficier de toutes les fonctionnalités d’un équipement Legrand (par exemple la mesure de la consommation d’une prise ou la fonction variateur) il est nécessaire en principe d’appairer l’équipement au moins une fois sur la GW Legrand pour réaliser une mise à jour du firmware.
Par ailleurs la gamme Legrand Netatmo ne fonctionne que sur le canal Zigbee numéro 11.

Nota : La passerelle Zigbee Legrand Céliane with Netatmo fonctionne avec le plugin « HkControl » (Homekit Network Devices Control).

akenad :slight_smile:

4 « J'aime »

"Flash" Plugin SMS et clé Huawei E3372 ou E3531 :

/!\ ATTENTION : utiliser une version d’origine et non pas fourni via opérateur ou en marque blanche, car probablement firmware modifié et bridé.
Je recommande de ne pas modifier le firmware.

Configuration du système pour envoyer des SMS avec le plugin SMS.

pour la JeedomSmart (en Stretch) :
Je préconise l’utilisation de la E3372 (s-153 ou h-153), la clé est reconnue par défaut.
(/!\ ATTENTION : je n’ai pas connaissance que le modèle E3372h-320 et E3372h-607 soient reconnues par défaut).

Dans d’autres cas comme la Smart en Buster, Odroid-C2 Armbian, Pi3 Raspbian ou Pi4 PiOS-64, VM Debian amd64,
en root, vérifier que le paquet usb-modeswitch est installé, sinon l’installer et :

Pour la E3372 (s-153 ou h-153, mais pas h-320 ou h-607):

Créer le fichier /etc/usb_modeswitch.d/12d1:1f01 avec comme contenu :

# Huawei E3372s-153 ou E3372h-153 switch mode vers 12d1:1442 (mode GSM modem) :
TargetVendor=0x12d1
Targetproduct=0x1f01
MessageContent="55534243000000000000000000000011060000000000000000000000000000"

Pour la E3531 :

créer le fichier /etc/usb_modeswitch.d/12d1:1f01 avec comme contenu :

# Huawei E3531i-2 ou E3531s-2 switch mode vers 12d1:1001 (mode GSM modem, 3 ports)
TargetVendor=0x12d1
Targetproduct=0x1f01
MessageContent="55534243123456780000000000000011062000000100000000000000000000"

Puis débrancher et rebrancher la clé.

Le switch de 12d1:1f01 vers le mode GSM modem est visible avec la commande :
dmesg | grep USB

Le résultat du switch est visible par la commande :
lsusb

L’affectation des ttyUSBx pour la clé HUAWEI est visible par la commande :

ls -l /dev/serial/by-id

Utiliser le premier port.

La documentation Jeedom officielle du #plugin-sms est ici : https://doc.jeedom.com/fr_FR/plugins/communication/sms/

Et pour les très téméraires, une autre méthode, à vos risques et périls, flasher le firmware Huawei E3372 en stick :

Plus de détails ici : [RTEX] Plugin SMS - clé Huawei 4G E3372 & 3G E3531 - JeedomSmart & JeedomOdroid - Page 3 - Forum Communauté Jeedom

Voir aussi ce sujet : Compatibilité Raspberry pi 4B avec clef GSM (CHIPSET HUAWEI E3372) - #24 par akenad

akenad :slight_smile:

« Flash » Dépendances Python pour Jeedom et plugins :

EDIT : /!\ ATTENTION : Avec pip 21.0 (23/01/2021) : python2 et python3.5 ne sont plus supportés : Changelog - pip documentation v24.0 et pip · PyPI

Des plugins ont des démons en python3 alors que d’autres sont encore en python2.

Quelques exemples :

Plugin---------Python
deCONZ---------3
BLEA-------------3 (migré)
RfXCom----------3 (migré)
Broadlink---------3 (migré)
OpenZwave------2
OpenEnOcean—2

Jusqu’à début janvier 2020, pip et python pointaient par défaut sur python2.
Python2.7 n’est plus maintenu depuis janvier 2020, mais il y a encore des plugins qui l’utilisent.
pip 21.0 ne supportera plus python 2.7 en janvier 2021.
Donc si les plugin-openenocean et plugin-openzwave ne sont pas migrés en python3 (ou réécris) avant Janvier 2021, ça va se compliquer.

Dans le cas général, pour ajouter un module python nécessaire au fonctionnement d’un plugin en python2 :
$ sudo pip2 install nomdumodule

Jeedom installe python3 et pip3 mais il n’en n’a pas toujours été ainsi.

Pour voir si python3 et pip3 sont installés, commandes :

$ python3 --version
$ pip3 --version

S’ils ne sont pas installés, ils peuvent être installés manuellement avec les commandes :

$ sudo apt install python3
$ sudo apt install python3-pip

Pour lister les modules de la lib python2 :
$ pip2 list
ou
$ python2 -m pip list

Pour lister les modules de la lib python3 :
$ pip3 list
ou
$ python3 -m pip list

Les commandes :

$ pip list
ou
$ python -m pip list

listes les modules de la lib python 2 si pip et python pointent sur python2, et listes les modules de la lib python 3 si pip et python pointent sur python3.

/!\ ATTENTION : Voici 2 commandes que je recommande de ne pas lancer manuellement sous peine de casser les démons et/ou les dépendances de Jeedom et ses plugins :

$ sudo python3 -m pip install --upgrade pip NePasLancer
ou
$ sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.7 2 NePasLancer

La première commande met à jour pip et fait pointer pip sur python3 (et non plus python2).

La 2ième commande modifie la version de python par défaut au niveau système, python pointe alors sur python3 (et non plus python2). Par défaut, la 2ième commande (python3.7) concerne Buster (ce serait python3.5 sous Stretch).

Pour savoir sur quelle version de python pointent pip et python :

$ pip --version
$ python --version

Si pip ou python pointent sur python3 cela peut provoquer un dysfonctionnement pour les plugins encore en python2.

Si pip pointe sur python3, lors de l’installation des dépendances du plugin, les modules sont installés dans la lib python3 au lieu de python2.

Lorsque le démon (en python2) du plugin est lancé il ne va pas trouver les modules dont il a besoin et provoquer une erreur et donc peut s’arrêter.

Si python pointe sur python3, le démon (en python 2) est lancé avec python3, il peut alors y avoir des erreurs de syntaxe et donc peut s’arrêter.

Cas du plugin broadlink et le module python3 cryptography ici : Broadlink - Dépendances Dead après maj vers Buster - module python3 cryptography - #21 par akenad
(Problème similaire avec le plugin xiaomihome)

Un sujet dédié pour discussion ouvert par @Bonson et intitulé " Python 2 ou python 3" ici : Python 2 ou python 3

akenad :slight_smile:

4 « J'aime »

« Flash » Box Smart de Jeedom SAS

La smart est un Odroid-C2
Sans ouvrir le boîtier, on peut apercevoir 2 leds derrière le connecteur micro usb.

En principe si le démarrage u-boot/kernel s’est bien passé, la led rouge est allumée et la led bleue clignote 2 fois, pause, 2 fois, etc …

Panne Smart :
Si la led rouge est allumée mais que la led bleue ne clignote pas (éteinte ou fixe) c’est qu’il y a un problème de démarrage donc certainement un problème sur l’eMMC (hardware ou u-boot/system corrompu).

Le contenu d’une eMMC d’une Smart (debian+Jeedom+Recovery) est préparé spécialement par Jeedom SAS.

Si la Smart est sous garantie (moins de 2 ans) faire appel au SAV du vendeur.

Si la Smart n’est plus sous garantie, plusieurs alternatives :

Point de détails sur la Méthode 1 :

Après remplacement sur la Smart de l’eMMC avec l’eMMC venant de Domadoo, comme pour un recovery, celle-ci contient une image de 2020, Buster 10.4/jeedom 4.0.61 (donc antérieur à Bullseye et Bookworm).
Il est recommandé de mettre à jour Jeedom avant de réaliser une restauration Jeedom.
A défaut :
-pour remédier à l’erreur « oldoldstable », exécuter install/update/4.2.3.php, ou faire la même chose manuellement :
aller dans :
Réglages > Système > Configuration > OS/DB > Administration Système > ouvrir
taper commande :

sudo apt-get update --allow-releaseinfo-change

-pour remédier à l’erreur « certificate », exécuter install/update/4.2.4.php, ou faire la même chose manuellement :
aller dans :
Réglages > Système > Configuration > OS/DB > Administration Système > ouvrir
taper les commandes :

sudo sed -i s%mozilla/DST_Root_CA_X3.crt%!mozilla/DST_Root_CA_X3.crt%g /etc/ca-certificates.conf

sudo update-ca-certificates

Petite explication pour le certificat :
La smart ne peut pas valider la chaine de certification du certificat Let’s Encrypt actuel pour https://oph.mdrjr.net, à partir du contenu ancien de son magasin des certificats de confiance.
La première commande désélectionne le nom de fichier du certificat de l’AC Racine « DST_Root_CA_X3 ».
La deuxième commande modifie le magasin des certificats de confiance en conséquence (/etc/ssl/certs/ca-certificates.crt).
(ce qui a pour effet d’utiliser l’AC Racine « ISRG Root X1 » pour valider la chaîne de certification).

Voir ici : La chaîne de confiance - Let's Encrypt - Certificats SSL/TLS gratuits

akenad :slight_smile:

2 « J'aime »

"Flash" Flasher le firmware de l’EEPROM du Pi4

(Opération de niveau avancé, à vos risques et périls.)

  • Avec Raspberry Pi Imager, graver l’image Pi OS Lite sur SD. (Créer un ficher vide de nom « ssh » à la racine de la SD .)

en SSH :

$ sudo su -

le fichier /etc/default/rpi-eeprom-update doit contenir la ligne suivante :
FIRMWARE_RELEASE_STATUS="critical"
remplacer par :
FIRMWARE_RELEASE_STATUS="stable"

  • Vérifier la version actuelle et la dernière version installable disponible localement avec la commande :

# rpi-eeprom-update

BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
 LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
 FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad

La version du firmware de l’EEPROM du Pi4 du 16/04/2020 installée ne supporte pas le Boot USB.

  • Mettre à jour avec les commandes :
# apt update
# apt full-upgrade
# rpi-update
# reboot

(avec apt full-upgrade, la dernière version stable disponible du binaire du firmware de l’eeprom du Pi4 est copiée localement dans le dossier /lib/firmware/raspberrypi/bootloader/stable/)

  • Mettre à jour à la dernière version stable du firmware de l’EEPROM du Pi4 :
    (à partir du Dossier /lib/firmware/raspberrypi/bootloader/stable/
    Au jour ou j’écris ses lignes, elle date du 15/06/2020)
# rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/stable/pieeprom-2020-06-15.bin
# reboot
  • Vérifier la version actuelle avec la commande :

# rpi-eeprom-update

BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Mon 15 Jun 13:36:19 UTC 2020 (1592228179)
 LATEST: Mon 15 Jun 13:36:19 UTC 2020 (1592228179)
 FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad
  • Vérifier que le code BOOT est correct :

# vcgencmd bootloader_config
BOOT_ORDER=0xf41
Sinon ne boot pas sur USB.

EDIT 21/09/2020 : le firmware pieeprom-2020-09-03.bin est passé en critical
donc il est possible de conserver par défaut :

FIRMWARE_RELEASE_STATUS="critical"

et la commande de mise à jour devient :

# rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/critical/pieeprom-2020-09-03.bin

Nota : Après avoir flashé ce nouveau firmware de l’EEPROM du Pi4, il est possible de booter directement sur USB SSD mSATA.
Plus de détails ici : [RTEX] Pi4 - SSD mSATA – Pi OS 64Bits Buster – Jeedom V4

Pour une discussion sur le Boot USB, le sujet de @bronche ici : [TUTO] Beta - Boot USB natif sur PI 4 -
et un retour d’expérience d’un « péril » par @olive : [TUTO] Beta - Boot USB natif sur PI 4 - - #8 par olive

Références :

Pour plus de détails, @guipom a réalisé une vidéo ici : Raspberry Pi (4B): Boot sur USB & Installation Raspberry Pi OS (tuto complet) - YouTube

akenad :slight_smile:

7 « J'aime »

"Flash" Certificat CN=*.jeedom.com

En Jeedom V4, pour désactiver la vérification du certificat du site market.jeedom.com,
dans Réglages > Système > Configuration > Mises à jour/Market
cocher la case « Pas de validationSSL (non recommandé) ».

Il y a eu des problèmes d’accès le 30/05/2020 par certains clients à https://*.jeedom.com car certains certificats d’AC de la chaîne de certification avaient expirés.

Pour remédier au problème les AC utilisent le mécanisme de signature croisée (cross signing).
Un exemple ici : Chaîne de confiance - Let's Encrypt - Certificats SSL/TLS gratuits

*.jeedom.com est signé par l’AC intermédiaire « COMODO RSA Domain Validation Secure Server CA », toujours valide, mais elle même signée par l’AC intermédiaire « COMODO RSA Certification Authority » qui est elle même signée par l’AC Racine « AddTrust External CA Root », ces 2 derniers certificats ayant expirés le 30/05/2020.

Sur Debian tous les certificats AC racine sont installés dans le magasin ca-certificates avec le paquet ca-certificates dans le répertoire /etc/ssl/certs.
exemples :

$ ls /etc/ssl/certs | grep Comodo_AAA
Comodo_AAA_Services_root.pem
$ ls /etc/ssl/certs | grep COMODO_RSA
COMODO_RSA_Certification_Authority.pem

(L’installation ou la mise à jour de certificats se fait avec la commande update-ca-certificates).

Pour que la chaîne de certification soit toujours validée,

le client doit avoir dans son magasin :

  • l’AC Racine (1) : « COMODO RSA Certification Authority » (expire 18/01/2038)(hash cert SHA256: 52f0e1c4e58ec629291b60317f074671b85d7ea80d5b07273463534b32b40234)

et/ou bien

  • l’AC Racine (2) : « AAA Certificate Services » (expire 31/12/2028) (hash cert SHA256: d7a7a0fb5d7e2731d771e9484ebcdef71d5f0c3e0a2948782bc83ee0ea699ef4)

et le serveur doit transmettre dans le handshake TLS,

  • l’AC intermédiaire « COMODO RSA Domain Validation Secure Server CA » (expire 11/02/2029)(hash cert SHA256: 02AB57E4E67A0CB48DD2FF34830E8AC40F4476FB08CA6BE3F5CD846F646840F0)

et, si AC Racine (2) mais pas Racine (1) dans magasin client :

  • l’AC intermédiaire « COMODO RSA Certification Authority » (expire 31/12/2028) (hash cert SHA256: 38392f17ce7b682c198d29c6e71d2740964a2074c8d2558e6cff64c27823f129)

Un certificat d’AC Racine est toujours auto-signé, et s’il est de confiance il est ou il peut-être ajouté dans le magasin ca-certificates.

Ceci règle en particulier les problèmes d’accès à https://images.jeedom.com et https://market.jeedom.com
et https://*.dnsX.jeedom.com (avec X=1, 2 ou 3)
que certains ont pu avoir le 30/05/2020.
Une alternative étant de désactiver la validation SSL ! (c’est-à-dire de ne pas vérifier la chaîne de certification).
(pour X=4 à 6, le certificat est signé par DigiCert/GeoTrust, pas de problème).

Par ailleurs certains on rencontré un autre problème remonté vers le 07/07/2020 :
attention à l’utilisation de * (« wild card ») dans le CN (common name) et/ou SAN Subject Alternative Name).

Prenons l’exemple de https://www.dns.jeedom.com
Actuellement dans le certificat on a
CN=*.jeedom.com

Le « wild card *» couvre uniquement le premier niveau de sous domaine. Autrement dit ici cela couvre dns.jeedom.com mais pas www.dns.jeedom.com

Depuis le 08/12/2020 :
Les sites www.jeedom.com images.jeedom.com market.jeedom.com blog.jeedom.com repo.jeedom.com forum.jeedom.com,
ont comme certificat *.jeedom.com, qui est signé par l’AC intermédiaire « GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1 »
qui est elle même signée par l’AC Racine « DigiCert Global Root CA ».
Les serveurs de terminaison SSL transmettent la chaîne de certificats dans le handshake TLS.
Protocoles TLS 1.2 et TLS 1.3 activés uniquement.

discussions ici :

akenad :slight_smile: