[Présentation] akenad

Présentation et Vitrine d'installations
,
26

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

  • Méthode 1 : Domadoo vend une eMMC 16 Go spécialement préparée pour Smart en Debian 11 (à partir de fin juillet 2024) :

Point de détails sur la Méthode 1 : (avant fin juillet 2024, debian 10) :

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 »
27

"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 »
32

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

35

« 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 »
44

« 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

slae.sh-CC2652RB
slae.sh-CC2652RB699×357 151 KB

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 »
45

« 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 »
58

« 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 »
62

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

64

« 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 »