L’automatisation qui semble fonctionner puisque les logs sont renseignés
alias: "Schedule: Pronote check"
description: Mise à jour des sensors pronote
trigger:
- platform: time_pattern
minutes: /20
condition: []
action:
- service: shell_command.shell_pronote_cron
data: {}
mode: single
Le fichier pronote.log enregistre bien les heures d’execution mais la première ligne ne fonctionne pas. Mais si je le lance à la main depuis la console, tout fonctionne !
Une idée ?
System Information
version
core-2023.2.2
installation_type
Home Assistant OS
dev
false
hassio
true
docker
true
user
root
virtualenv
false
python_version
3.10.7
os_name
Linux
os_version
5.15.90
arch
x86_64
timezone
Europe/Paris
config_dir
/config
Home Assistant Community Store
GitHub API
ok
GitHub Content
ok
GitHub Web
ok
GitHub API Calls Remaining
4970
Installed Version
1.30.0
Stage
waiting
Available Repositories
1195
Downloaded Repositories
4
AccuWeather
can_reach_server
ok
remaining_requests
21
Home Assistant Cloud
logged_in
false
can_reach_cert_server
ok
can_reach_cloud_auth
ok
can_reach_cloud
ok
Home Assistant Supervisor
host_os
Home Assistant OS 9.5
update_channel
stable
supervisor_version
supervisor-2023.01.1
agent_version
1.4.1
docker_version
20.10.22
disk_total
30.8 GB
disk_used
3.4 GB
healthy
true
supported
true
board
ova
supervisor_api
ok
version_api
ok
installed_addons
SSH & Web Terminal (13.0.2), File editor (5.5.0)
Dashboards
dashboards
2
resources
3
views
2
mode
storage
Recorder
oldest_recorder_run
31 janvier 2023 à 22:59
current_recorder_run
7 février 2023 à 14:19
estimated_db_size
311.53 MiB
database_engine
sqlite
database_version
3.38.5
Ma configuration
Texte à remplacer par votre configuration
Comment récupérer ma configuration :
Dans votre HA, Menu latéral Paramètres > Système > Corrections puis les trois petits points en haut a droite > Informations Système puis une fois en bas Copier
J’ai aussi testé /usr/bin/python -m /config/script_python/Pronote2Homeassistant/pronote.py 2>&1
Puis en séparant en deux commandes distincts dans shell_command.yaml
Rien n’y fait. Il y a un truc qui m’échappe !
Pour trouver la « bonne » commande, il faut être connecté dans le container HA. L’exécution se fait depuis ce container. Il faut que la commande que tu veux lancer marche dans ce contexte-là.
C’est comme ça que tu testes?
En effet, je crois que j’ai un début de réponse dans le sujet concernant pronote
Je débute avec HA OS (avec HA tout cours d’ailleurs) et je n’avais pas saisi tout ça !
Ca fait partie de la logique des containers à intégrer. Tout ce qui s’y exécute est propre au contexte de ce container. Les exécutables, les chemins, les librairies,…
Ou les accès ssh sortant qui nécessitent un clé dans le « bon » répertoire.
Dans ton cas, si tu lances depuis le container et ce que tu as vu dans l’autre post est bien le problème, tu vas avoir un message d’erreur indiquant que telle ou telle librairie manque.
La solution est bien là, merci pour ces explications. Je comprends donc qu’en fait, je suis passé d’une version container à une version HA OS, et en fait, c’est un OS (alpine) que je ne maitrise pas trop avec des containers
Je me demande si je ferais pas mieux de revenir sur mon OS et gérer moi même les container.
Si j’ai bien compris, ce serait une installation supervisée.
Oui et non
Si tu gères les containers à la main, alors tu es en mode Home Assistant Container (voir Installation - Home Assistant)
Si tu veux utiliser ton OS (debian) mais avoir les add-on, le superviseur… alors c’est ça Home Assistant Supervised.
Personnellement, je trouve que HA Supervised est une solution bancale.
Ca part du postulat que tu es suffisamment compétent pour installer debian sur ta plateforme matérielle (avec docker et le reste). Mais, pas assez pour gérer le tout à la main et comprendre ce qui se passe. C’est un compromis que je ne comprends pas trop. La bonne nouvelle c’est qu’il y a quatre méthodes d’installation. La mauvaise, c’est qu’il faut arriver à choisir la « bonne ».
Et la bonne pour l’un n’est pas la bonne pour l’autre…
Pas tout à fait tout: il y a des répertoires partagées, comme /config par exemple. Par contre, ce qui touche à l’OS et ses paquets, c’est effectivement « dédié » au conteneur.
L’avantage de HAOS est qu’on ne s’occupe plus du système, et il y a les AddOns (Modules complémentaires).
Perso, je trouves que c’est plus simple à maintenir.
Pour maintenir la configuration de la console, ses paquets et les modules python, je me suis concocté un script:
Presque. Le /config est partagé quand tu décides explicitement qu’il doit l’être. Et le /config vu du container peut être un chemin totalement différent sur le serveur.
Par défaut, « rien » n’est partagé…
Chacun son sale goût comme aurait dit ma grand-mère.
C’est ce que j’indiquais dans un mail précédent il n’y a pas de réponse universelle et absolue. Il faut choisir « sa » méthode d’installation et comprendre ce que ça signifie. Et, ça ne n’est pas si simple.
Dans HAOS - comme c’est géré - c’est partagé par défaut. Si on gère ses propres conteneurs, il faut bien sûr mettre ces options soi-même.
D’ailleurs, le scruot et …/pronote.log étaient bien visibles dans la console bien que générés dans un autre conteneur (sous HAOS).
Effectivement, j’ai écrit « Perso » pour indiquer que c’est un goût personnel.
