Bonjour,
J’essaie de mettre en route ce contrôleur sur un Raspberry Pi4 exécutant Jeedom 4.3.5 en suivant fidèlement les indications du tuto publié le 17/10 sur domo-blog.
L’installation du plugin Zigbee semble s’être bien passée mais lorsque j’essaie une association, je constate que le démon ne fonctionne pas (failed to connect to +++ ; connection refused).
Essayant d’en trouver la cause, j’ai lancé une mise à jour du firmware du contrôleur et obtenu ceci sur le log
....
Looking in indexes: +++
Requirement already satisfied: pyserial==3.4 in +++dist-packages (from -r requirements.txt (line 1)) (3.4)
Requirement already satisfied: xmodem==0.4.6 in +++dist-packages (from -r requirements.txt (line 2)) (0.4.6)
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: +++
2022/10/23 18:46:37 Elelabs_EzspFwUtility: Couldn't communicate with the adapter in Zigbee (EZSP) mode, Thread (Spinel) mode or bootloader mode
...
Quelqu"un peut-il m’aider ?
Merci
Nota : j’ai abrégé le log et remplacé les liens par +++ puisque, nouvel utilisateur , on me limite à 2 liens par message
Vous avez désactivé le bluetooth interne de ce Raspberry pi ?
L’utilisation du port gpio et du bluetooth interne en même temps n’est pas possible (pour faire simple).
Oui, j’ai désactivé le bluetooth, ainsi d’ailleurs que, dans un second temps, le Wifi, sans autre résultat.
J’ai par contre regardé entretemps le log Zigbeed_1 et vu une mention d"erreur fatale :
...
File "/usr/local/lib/python3.7/dist-packages/bellows/ezsp/__init__.py", line 121, in connect
self._gw = await bellows.uart.connect(self._config, self)
File "/usr/local/lib/python3.7/dist-packages/bellows/uart.py", line 393, in connect
_connect(config, application)
File "/usr/local/lib/python3.7/dist-packages/bellows/uart.py", line 377, in _connect
rtscts=rtscts,
File "/usr/local/lib/python3.7/dist-packages/serial_asyncio/__init__.py", line 448, in create_serial_connection
serial_instance = serial.serial_for_url(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/serial/__init__.py", line 88, in serial_for_url
instance.open()
File "/usr/local/lib/python3.7/dist-packages/serial/serialposix.py", line 268, in open
raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port Array: [Errno 2] No such file or directory: 'Array'
[2022-10-23 17:04:10]ERROR : [start_zigbee] Fatal error : [Errno 2] could not open port Array: [Errno 2] No such file or directory: 'Array'
Je ne sais pas quoi en penser mais cela pourrait être une piste
Tout d’abord merci de vous être intéressé à mon message.
Je reviens sur mon problème non résolu. Après m’être plongé dans la documentation Raspberry, il me semble que la connexion au module Popp est correcte. Par contre la lecture attentive de la documentation jeedom me laisse à penser que le problèmes est ailleurs.
Voici le résultat « Santé Jeedom »
|Système à jour|OK|Cron actif|OK|
|Scénario actif|OK|Démarré|OK 2022-10-30 12:07:22|
|Date système (dernière heure enregistrée)|OK 2022-10-30 16:02:17 (2022-10-30 15:52:02)|Droits sudo|OK|
|Version Jeedom|4.3.8|Version OS|debian 10.13|
|Version PHP|7.3.31-1~deb10u1|Apache|13|
|Version OS|Linux jeedom 5.15.74-v7l+ #1595 SMP Wed Oct 26 11:05:08 BST 2022 armv7l GNU/Linux [10.13]|Version database|10.3.36-MariaDB-0+deb10u2|
|Espace disque libre|92 %|Connexion active/max/autorisée|12/15/151|
|Espace disque libre tmp|100 %|Mémoire disponible|92 % (Total 3889 Mo)|
|Mémoire suffisante|0|Erreur I/O|0|
|Swap disponible|100 % (Total 1024 Mo)|Swapiness|10 %|
|Charge|0.19 - 0.19 - 0.18|Configuration réseau interne|OK|
|Configuration réseau externe|NOK|Persistance du cache|OK (2022-10-30 16:00:04)|
|Apache private tmp|OK|
|Plugins|1 NOK|
et « Santé Zigbee »
Dépendances
OK
Configuration démon
NOK
Statut démon
NOK
Je suis invité à configurer correctement le réseau externe et ne sais pas quoi changer pour avoir une configuration correcte (je n’ai rien trouvé dans la doc jeedom qui réponde à cette question).
Accès interne
Protocole
HTTPS
://
192.168.1.155
:
443
/
Gestion avancée
Interface IP Mac
lo 127.0.0.1 00:00:00:00:00:00
eth0 192.168.1.155 dc:a6:32:ec:19:64
wlan0 dc:a6:32:ec:19:65
Désactiver la gestion du réseau par Jeedom
Masque IP local (uniquement pour des installations type docker, sous la forme 192.168.1.)
127.0.0.1;192.168..;10...;172.16..
Pour la configuration Zigbee je suis revenu à la configuration initiale (celle qui est préconisée) après avoir essayé d’autres paramètres.
Contrôleur 1
Activer
Nom du contrôleur
Popp GPIO
Type de contrôleur
EZSP (Atlas/Luna)
Type de clé
Atlas/Luna/Elelabs/Popp
Port du contrôleur
/dev/ttyAMA0
Port du démon
8089
Cycle (secondes)
0.3
Canal
15
Dans tous les cas, je retrouve l’erreur « Veuillez vérifier la configuration » avec dans le log
« cURL error : failed to connect to 127.0.0.1 port 8089 connection refused »
J’ai vu dans le blog que d’autres avaient été confronté à ce problème avec d’autres configurations de matériel mais n’ai pas trouvé de réponse claire ou applicable.
Bonsoir,
Merci de votre réponse. Je viens donc d’effacer les contenus de la ligne « Accès externe » et sélectionner « Aucun » dans la case protocole.
Par acquit de conscience j’ai rebooté la machine.
Et rien n’a changé dans la page « Santé de Jeedom »…
C’est normal, car il faudrait configurer un vrai accès externe, mais cela n’est plus l’origine de votre problème.
Je ne sais pas vous aider plus sur ce sujet. Hormis un truc, vous avez un Raspberry Pi 4 avec 4 go de mémoire RAM. Une telle configuration nécessite un os en 64 bits, vous avez installé une édition 32 bits.
Refaites l’installation en 64 bits, il est possible que cela corrige votre problème d’installation des dépendances.
Je viens clore ce sujet.
Merci à Fabrice pour ses réponses et surtout pour son excellent tutoriel d’installation de jeedom que j’ai suivi à la lettre.
Après réinstallation de l’OS et de jeedom, le problème subsistait mais j’en suis venu à bout en procédant d’abord à la mise à jour du module Zigbee GPIO, ce qui démontrait que le problème n’était pas au niveau de sa communication avec le RPI, puis par une mise à jour systématique (parfois « à la main ») de chacun des packages que les vérifications système (onglet OS/DB) signalaient comme n’étant pas à jour. Le plugin Zigbee a ainsi fini par fonctionner.