Bonjour
Je suis sur Jeedom depuis quelque temps en version stable sur une machine virtuelle sur un DS218+. J’ai voulu changer mon vieillissant DS218+ et je viens d’acheter un TereeMaster F4-425 Pro avec 16Go de mémoire avec un premier pool système composé de 2 NVME et d’un pool de data avec 2 HDD. Bien entendu Docker est installer sur le pool NVME.
J’ai essayé d’installé Jeedom sur une machine virtuelle : tout fonctionnait sauf le plugin Zigbee dont le port USB de ma clé était ttyACM0 –> non reconu par la VM. Ce plugin m"‘étant indispensable j’ai installé Jeedom en Docker comme je le faisais au début.
Voici mon Docker Compose qui actuellement fonctionne :
services:
jeedom:
image: jeedom/jeedom:4.5-bookworm
container_name: jeedom08 # n° de Jeedom
restart: always # always ou « no »
mem_limit: 3072M # 3 Go de RAM physique max
memswap_limit: 3584M # 3,5 Go au total (soit 3 Go RAM + 512 Mo de Swap max autorisés)
network_mode: bridge
ports:
- « 9080:80 » # Port = 0 si prod sinon n° de Jeedom - Interface Web Jeedom - n° de Jeedom ou 0 si prod
- « 9090:9090 » # Port = 0 si prod sinon n° de Jeedom - Port WebSocket Jeedom
- « 8080:8080 » # Port = 0 si prod sinon n° de Jeedom - Port Z2M / JeeZigbee
cap_add:- NET_ADMIN # Nécessaire pour la gestion réseau (interfaces TUN/TAP, routage)
- SYS_PTRACE # Autorise le suivi des processus
- SYS_ADMIN # Nécessaire pour les opérations système d’administration
volumes:- jeedom08_db:/var/lib/mysql # n° de Jeedom
- /Volume1/Docker/Jeedom08/html:/var/www/html # n° de Jeedom
tmpfs:- /tmp/jeedom:size=256M,mode=1777
healthcheck:
test: [« CMD », « curl », « -fs », « -S », « –max-time », « 2 », « http://localhost:80 »]
interval: 30s
timeout: 10s
retries: 5
environment:- TZ=Europe/Paris
- PYTHONPATH=/usr/local/lib/python3.11/dist-packages:/var/www/html/plugins/rfxcom/resources/python_venv/lib/python3.11/site-packages:/var/www/html/plugins/broadlink/resources/python_venv/lib/python3.11/site-packages
devices: - "/dev/net/tun" - "/dev/ttyACM0-zwave:/dev/ttyACM0" # zwave - "/dev/ttyUSB0-zigbee:/dev/ttyUSB0" # zigbee - "/dev/ttyUSB1-enocean:/dev/ttyUSB1" # enocean - "/dev/ttyUSB2-rfxcom:/dev/ttyUSB2" # rfxcomvolumes:
jeedom08_db: # n° de Jeedom
Probleme : Le démon du plugin RFXcom refusait de démarrer et tombait en erreur après plusieurs tentatives de relance automatique. Dans les logs de dépendances, un message externally-managed-environment apparaissait, et dans les logs du démon, la ligne suivante apparaissait :
[ERROR] : Timeout waiting status, is your rfxcom firmware up to date ?
Explications & Solution :
1. Dépendances Python : Sur les installations récentes (Debian 12 / Bookworm), l’installation système PIP bloque par sécurité (externally-managed-environment). Le plugin RFXcom gère cela correctement en créant son propre environnement virtuel Python dans resources/python_venv. L’installation des dépendances s’est terminée avec succès (End of package installation).
2. Timeout RFXcom : Le message Timeout waiting status lors de la première poignée de main avec le boîtier est un comportement classique lors d’un démarrage à froid du RFXcom. Il ne s’agit pas d’un blocage définitif : le plugin réessaie immédiatement, lit correctement le firmware (ex: Firmware version = 0x33) et active les protocoles demandés.
Après avoir relancé les dépendances et le démon : le démon est passé au vert et fonctionne parfaitement.
Je me suis aidé de GEMINI : car je n’ai pas les compétences pour résoudre ce probleme.
Comment peut on à l’avenir ne plus avoir ce souci ?
Vous remerciant par avance
Lemars