Merci beaucoup @Herbs
pour ton temps et ta patience.
Je confirme oui. Je me rends bien compte que je me suis lancé dans Home assistant, j’ai fait tourner des choses avec Node-Red, mais il faut bien avouer que la programmation de HA, je suis à coté de la plaque 
Tout d’abord, j’ai plus d’erreur de chargement de la configuration en suivant tes réponses. Merci beaucoup.
Je vais tenter de résumer voir si j’ai compris au moins en partie tes explications 
Les intégrations: on parle de ce que l’on installe comme LocalTuya par exemple?
Actuellement, mon arborescence packages, ne contient que la définition d’input (input_number, input_boolean,input_datetime…). Je les retrouve tous dans la page entrées de HA. Si je comprends, se ne sont que des définitions de commandes me permettant de réaliser des actions depuis un tableau de bord, par exemple.
Si je veux créer une entité qui s’historisera et fournira une valeur, je dois la créer dans mon fichier sensor.yaml?
Nouveau fichier sensor.yaml
- platform: template
sensors:
sunelevation:
friendly_name: "elevation soleil"
value_template: "{{ state_attr('sun.sun', 'elevation') }}"
#on indique que la valeur de cette entité sera égale à la valeur de l'attribut elevation de l'entité sun.sun
sunazimuth:
friendly_name: "azimut soleil"
value_template: "{{ state_attr('sun.sun', 'azimuth') }}"
#on indique que la valeur de cette entité sera égale à la valeur de l'attribut azimuth de l'entité sun.sun
- platform: integration
name: Grid Import Energy
source: sensor.grid_import_power
unit_prefix: k
unit_time: h
method: left
- platform: integration
name: Grid Export Energy
source: sensor.grid_export_power
unit_prefix: k
unit_time: h
method: left
Toujours si j’ai compris, la première partie de ce fichier est sur l’ancienne méthode d’écriture et la fin sur la nouvelle.
Si je voulais modifier la première partie du fichier dans la nouvelle syntaxe, je devrais écrire:
Nouvelle syntaxe
- platform: template
name: sunelevation
friendly_name: "elevation soleil"
value_template: "{{ state_attr('sun.sun', 'elevation') }}"
#on indique que la valeur de cette entité sera égale à la valeur de l'attribut elevation de l'entité sun.sun
- platform: template
name: sunazimuth
friendly_name: "azimut soleil"
value_template: "{{ state_attr('sun.sun', 'azimuth') }}"
#on indique que la valeur de cette entité sera égale à la valeur de l'attribut azimuth de l'entité sun.sun
j’ai bon?
J’avoue que là tu m’as perdu. Que représente cette clé platform? Puis-je retrouver ses valeurs quelque part dans HA? Tu préconises de ne plus l’utilisé. Dans ce cas:
- platform: integration
name: Grid Import Energy
source: sensor.grid_import_power
unit_prefix: k
unit_time: h
method: left
deviendrait… (bah j’ai tenté une conversion et bloqué):
Au vu des paramètres on crée une entrée Rieuman
Je comprends pas comment HA sait avec ces valeurs que je crée une entrée Rieumen?? (j’avoue que l’ancienne syntaxe je ne vois pas non plus)
J’ai tenté ça mais je ne sais pas ce que je dois faire des clés unit_prefix et les suivantes 
:
- name: Grid Import Energy
state: {{ sensor.grid_import_power }}
unit_prefix: k
unit_time: h
method: left
J’en déduis donc qu’il y a des cas on l’on ne peut que garder l’ancienne syntaxe.
Ca, c’était l’exemple. Plus généralement:
Sensor/binary_sensor: c’est la description d’une entité qui renverra une valeur qui sera historisée. On les verra apparaître dans HA sur la page des entités?
Template\sensor: C’est un autre moyen de décrire un sensor d’entité? J’ai bon?
Cela veux dire que dans mon arborescence packages, je ne peux pas créer de sensor seulement des commandes utilisable sur le dashboard par exemple?
Ce qui est appelé modèle en fin de compte ce n’ai que la description d’une nouvelle entité? c’est bien ça?
Désolé cela fait beaucoup de question sans réponse. Ai-je au moins certaine notion juste dans tout cela?
Vraiment merci à la communauté d’exister
!!!