[Présentation] akenad

« Flash » Version OS :

Bonjour,

Jessie, Stretch et Buster obsolètes !
(Fin du support LTS Debian 8 Jessie le 30 juin 2020, Debian 9 Stretch le 30 juin 2022, Debian 10 Buster le 30 juin 2024 : 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

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

Pour la Mini Plus :
/!\ ATTENTION : il n’existe pas d’image Jeedom Buster ! (uniquement Stretch + Jeedom v3)
La Mini+ (« JeeBoard ») est basée sur une HummingBoard iMX6.

(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:

« Flash » Class object not found

Pour une nouvelle installation de Jeedom V4, la classe ‘object’ a été retirée et remplacée par la classe ´jeeObject’.

Si un plugin utilise toujours la classe ´object’ alors jeedom affiche le message :

Class ‘object’ not found

D’autre part, avec Buster (et php 7.3), si un plugin Jeedom affiche des doubles accolades {{ }} c’est aussi probablement que le développeur n’a pas encore remplacé dans le code php la classe « object:: » par « jeeObject:: ».

Pour les utilisateurs avancés impatients, pour le faire soi-même :

  • Plugin JeeXplorer
  • recherche des fichiers .php dans le dossier du plugin dans /var/www/html/plugins/
    (il s'agit souvent de /plugins/<plugin-id>/desktop/php/<plugin-id>.php)
  • édition/recherche/remplace

(/!\ ATTENTION : le remplacement ne concernent que certains plugins et pas le core)

Un exemple Résolu en décembre 2019 avec sa solution sur un plugin particulier : [Résolu] Init Install suiviconso "Class 'object' not found"
(Ce plugin ayant été mis à jour depuis)

akenad :slight_smile:

5 « J'aime »

« Flash » Plugin Zigbee

Basé sur zigpy : zigpy · GitHub

Les équipements compatibles :

Les contrôleurs compatibles avec zigpy :

Type de contrôleur—librairie---------puce----------------firmware----Exemple
EZSP--------------------bellows---------SiLabs EFR32---------------------POPP Elelabs
Conbee-----------------zigpy-deconz
Zigate-------------------zigpy-zigate----NXP JN5168
Xbee--------------------zigpy-xbee
ZNP---------------------zigpy-znp--------TI------------------Z-Stack 3 CC2531 CC2652RB

Les contrôleurs compatibles avec le plugin Zigbee :
(modulo équipements Zigbee 1.2 versus 3)
(avec des maillages mesh/routage de capacité et de niveau de qualité variables, consultable ici : #plugin-zigbee partager mon graphique maillage réseau)

Conbee2 : dresden elektronik ConBee II Zigbee USB Gateway BN-600107 Zigbee compatibility

ELU013 (Popp) : GitHub - Elelabs/elelabs-zigbee-ezsp-utility: Elelabs Zigbee EZSP Utility to perform firmware update on a range of Elelabs EZSP products as well as other generic EZSP adapters.
contrôleur USB Elelabs ELU013 EZSP (puce Silicon Labs EFR32MG13P)

ELU013

ELR023 : GitHub - Elelabs/elelabs-zigbee-ezsp-utility: Elelabs Zigbee EZSP Utility to perform firmware update on a range of Elelabs EZSP products as well as other generic EZSP adapters.
Contrôleur (RPi GPIO) Elelabs ELR023 (puce Silicon Labs EFR32MG13P)
Pré-flashée firmware EZSP EmberZNet v6
EDIT 10/02/2021 : mis en oeuvre par @llaumgui : firmware mis à jour en EZSP v8

ELR023

Sonoff Zigbee 3.0 USB Dongle plus
Il y a 2 modèles :
Modèle-------------------------Chip-----------------------Type de contrôleur (Protocole/firmware)
La V1 : ZBDongle-P-----TI CC2652P-------------ZNP (Z-Stack)
La V2 : ZBDongle-E-----Silabs EFR32MG21—EZSP (EmberZnet) partiellement compatible
(Le modèle est indiqué au dos de la clé.)
La V1 a un adaptateur UART/Serial vers USB Silicon Labs CP2102

sonoff-cle-usb-zigbee-30-antenne-externe-20dbm-v2-zbdongle-e

exemple de :
ls -l /dev/serial/by-id

usb-Silicon_Labs_Sonoff_Zigbee_3.0_USB_Dongle_Plus … (=> ZBDongle-P)
usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2 … (=> ZBDongle-E)

CC2531 ITEAD : ITEAD CC2531 Zigbee USB Dongle M0802010007 Zigbee compatibility
Pré-flashée avec un firmware CC2531ZNP.
CC2531 avec antenne SMA :

CC2531-SMA-Zigbee

CC2652RB : CC2652R stick - slae.sh
Le contrôleur (type ZNP) USB CC2652RB antenne SMA doit être flashé avec le firmware coordinator zigbee 3 ici : https://github.com/Koenkk/Z-Stack-firmware/raw/master/coordinator/Z-Stack_3.x.0/bin/CC2652RB_coordinator_20210120.zip
détails ici : plugin-ZIGBEE Beta - CC2652RB

SilverCrest (Lidl) Smart Home Gateway : (EDIT 03/02/2021)
Passerelle « propulsée » par Lidl, LAN Eth, Tuya Zigbee 3.0, avec le Hack de Paul Banks (redirige les informations Zigbee locales vers un port TCP/IP au lieu d’utiliser le Cloud Tuya).

Lidl-SilverCrest-GW-Zigbee

  • Type de Contrôleur : EZSP
  • Type de clé : Elelabs
  • Port Zigbee : Passerelle distante
  • Passerelle distante : IP:8888

Références :

Le hack consiste à :

  1. accèder à la GW sur le port série console système (38400,n,8,1)
  2. extraire 2 clés secretes permettant de calculer le mot de passe root
  3. se connecter en SSH root sur le port 2333
  4. injecter un programme « Serial Gateway » qui redirige le port série /dev/tty local du module Zigbee sur l’IP port TCP 8888

Pour plus de détails voir les travaux de @Kazymir et @krosand ici : [Tutoriel] Autopsie du matériel Lidl - #6 par krosand

Un récapitulatif de quelques posts sur le forum :

Il est préférable de fournir des images d’équipements détourées (éliminer l’arrière plan) au dev du plugin zigbee :
Un site simple pour supprimer le fond d’une image : Téléchargez une image – remove.bg

akenad :slight_smile:

3 « J'aime »

« Flash » Log

Il arrive de constater que le contenu d’un Log d’un plugin est vide alors que ça ne devrait pas être le cas.
Cela peut se produire si on a déjà ouvert la log et cliqué par inadvertance sur le bouton rouge « Supprimer » en haut à droite de la fenêtre de Log du plugin.
Cela a pour effet de supprimer le fichier log correspondant qui se trouvait dans le dossier système /var/www/html/log.

En principe ce fichier est recréé automatiquement lorsque le démon du plugin est redémarré ou lors d’un reboot de la box Jeedom.
Si ce n’est pas le cas, pour y remédier il faut recréer un fichier log vide avec comme nom de fichier log celui qui avait été supprimé.

2 méthodes possibles (sans devoir passer par SSH) :

1) avec Jeedom :

Réglages > Système (si V4) > Configuration > OS/DB > Administration Système > Ouvrir
taper la commande :

touch /var/www/html/log/<nomdufichierlog>

ou <nomdufichierlog> est à remplacer par le nom du fichier log

2) avec le plugin JeeXplorer (ou à partir de Jeedom 4.2, Réglages > Systèmes > Editeur de fichiers) :

Aller dans le dossier /html/log
Cliquer droit > nouveau fichier > TXT > saisir nomdufichierlog

exemple avec la log d’installation des dépendances du #plugin-rfxcom :
nomdufichierlog = rfxcom_update

akenad :slight_smile:

7 « J'aime »

« Flash » Box Atlas de Jeedom SAS

L’Atlas est basée sur un Radxa RockPi4B+ v1.6 ou v1.7 avec une image spécifique dans la SPI flash pour supporter le boot USB.

Recovery Mode Atlas

La mise à jour du noyau Armbian peut être réalisée par erreur ou par ignorance (apt upgrade).
Si l’Atlas est plantée, il conviendrait d’appliquer la procédure de Recovery Atlas sur le site de documentation Jeedom SAS officiel ici : https://doc.jeedom.com/fr_FR/installation/atlas

Une partie de la procédure est décrite aussi dans le contexte du plugin Atlas ici : https://doc.jeedom.com/fr_FR/plugins/home%20automation%20protocol/atlas, extrait :

Vous devez brancher une clé usb de plus de 10Go dans le port USB de droite (Noir) en bas. une fois fait vous pouvez lancer le recovery de la clé et de suivre les instructions. Cela permet à votre Atlas de ce lancer sur cette clé USB vous avez du coup accés a votre atlas recovery mode sur http://jeedomatlasrecovery.local. il suffira de mettre admin/admin puis mettre correctement votre compte market. pour que votre jeedom recovery puisse restaurer la memoire interne de la box. il suffit de suivre les instructions.

L’image jeedomAtlasUSB.img.gz peut être flashée sur la clé USB avec balenaEtcher.
Elle est téléchargeable dans Market Jeedom > Mes services > Téléchargement USB Recovery Jeedom Atlas
Une sauvegarde de Jeedom doit être externalisée avant le plantage afin de pouvoir la restaurer après le Recovery.

Voir aussi ici : [RTEX] Recovery Mode Atlas

Il y a 2 problèmes principaux potentiels sur l’Atlas (pas de Démarrage ou pas de montée de l’interface ethernet) en fonction :

-du modele zwave ou zigbee
-de la date de réception
-de la date d’un recovery
-de la date d’un retour éventuel au SAV.
-de la version hardware de la carte SBC.

Problème de démarrage :

Avant décembre 2021 les Atlas Zwave pouvaient avoir un problème aléatoire de démarrage (boot) lié a la gestion de l’interface série GPIO sur laquelle est branchée la carte zwave.

Se voit avec les 2 led à l’intérieur du boitier, au travers du plexiglas apres avoir enlevé la protection adhésive, s’il n’y a pas de led clignotante bleue juste à côté de la led verte fixe c’est que le système n’a pas démarré.

Le firmware de la SPI flash a été mis à jour sur toutes les Atlas expédiées à partir de décembre 2021 (et toutes les Atlas d’avant décembre 2021 retournées au SAV), pour semble-t-il remédier à ce problème.

Problème de montée de l’interface ethernet :

Lié à la version hardware de la carte SBC :

L’image système doit être compatible avec la version hardware de la carte SBC.
A noter que la V1.4 a un chip ethernet RTL8211E alors que la V1.6 a un chip ethernet RTL8211F :
un recovery (depuis juillet 2022) semble remédier à ce problème.

Les versions hardware : Rockpi4/hardware/revision - Radxa Wiki

Voir la photo de la carte SBC avec la version hardware inscrite ici : [RTEX] Rock Pi4B+ - SSD NVMe - Armbian Bullseye - Jeedom V4

Sur l’atlas, le numéro de version hardware est caché derrière le plastique rond de couleur orange (contenant une pile cr2032, pour sauvegarder l’horloge en temps réel). Il suffit de décoller ce plastique pour voir apparaitre la version.

Lié à la configuration de l’interface ethernet :

Configuration de l’interface Ethernet et du serveur DNS
25/03/2023

Sur certaines Atlas, 2 services de configuration d’interfaces réseaux différents sont actifs simultanément, ce qui peut être source de conflit et donc engendrer un fonctionnement aléatoire.
Il s’agit des services networking et NetworkManager qui exécutent chacun un client DHCP dhclient (visible avec les commandes) :

systemctl status networking
systemctl status NetworkManager

Voit ici : Network-Manager : configuration du réseau / Wiki / Debian-facile

C’est ce que l’on peut constater sur une Armbian Buster ou Bullseye mais la particularité sur l’Atlas c’est que les 2 services sont configurés avec le même nom d’interface Ethernet (eth0) et la même adresse MAC :

pour networking dans /etc/network/interfaces
et NetworkManager dans :
/etc/NetworkManager/system-connections/ethernet-eth0.nmconnection
/etc/NetworkManager/system-connections/Wired connection 1.nmconnection

Pour la configuration du serveur DNS, l’information est récupérée du client DHCP et inscrite dans resolv.conf :
-NetworkManager génére /etc/resolv.conf
-networking génére /etc/resolvconf/run/resolv.conf (avec le programme resolvconf), /etc/resolv.conf devrait être un lien symbolique vers /etc/resolvconf/run/resolv.conf mais il a probablement été écrasé par NetworkManager.

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

akenad :slight_smile:

4 « J'aime »

2 messages ont été scindés en un nouveau sujet : Remplacer une de mes prises « Céliane » standard par la prise 067725

« Flash » Box Luna de Jeedom SAS

La Luna est basée sur un Dusun DSGW-210 Gateway IoT modulaire.
(RockChip RK3328 Quad-core Cortex-A53 1,5GHz 64 bits, RAM 2 Go, eMMC 16Go) :
-https://www.dusuniot.com/fr/landing-pages/modular-iot-gateway/
-https://www.dusuniot.com/fr/landing-pages/jeedom-smart-gateway/
La Luna est une box domotique tout intégré pour ceux qui recherchent la simplicité d’utilisation.
Jeedom SAS a visiblement cherché à la fois à résoudre la plus part des problèmes complexes qu’un Jeedomien pouvait rencontrer jusqu’à présent et à préparer l’avenir.
En effet la Luna dispose d’un bouton reset et d’une connectivité hardware embarqué récente : Ethernet, wifi, Zwave700, batterie et un chip zigbee3/802.15.4 Silabs EFR32MG21 compatible Thread/Matter.
Modules IoT en option sur Dusun, mais pas forcement sur Luna : : LTE /4G, LoraWAN sur PCI, bluetooth BLE 5.2 (? à vérifier)
Exit les clés USB et cartes GPIO diverses et variées.
La 4G permettra potentiellement une bi-connexion Internet.

La Luna est dite complémentaire/satellite de l’Atlas dans le sens ou d’une part pour ceux qui veulent couvrir une grande surface l’Atlas peut être une jeeLink maitre et les Luna des esclaves, et d’autre part l’Atlas étant plus ouverte elle peut faire ce que la Luna ne pourrait pas faire.

Version OS (Debian 11/Bullseye) :
Si « Swap disponible Inconnue » dans page santé, il s’agit de l’image V1 : Comment savoir quelle version de l'image est présente sur la Luna? - #4 par 1suisse
07/03/2023 image Jeedom Luna (« V2 ») : Index of /luna

plugin Luna :

-02/05/2023 plugin Luna, le port Zigbee a été fixé : ttyUSBLUNA-Zigbee. Pour les usb externes, cela ce fixe aussi automatiquement avec le nom et ou numero de série.

contrôleur interne Zigbee :

Port du contrôleur Zigbee :

  • Luna Zigbee : /dev/ttyLuna-Zigbee ou /dev/ttyUSB1
  • Luna Zigbee V2

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

akenad :slight_smile:

10 « J'aime »