Si j’ai bien compris, tu as :
dossier Config |
puis un dossier packages|
puis un dossier tiko | avec le fichier tiko.yaml
ma questions :
est il possible d’avoir un 2eme fichier dans le dossier tiko.
exemple : avoir tiko1.yaml avec les sensors et des inputs…
et avoir tiko2.yaml avec les scripts et les automations ?
c’est le nom de mon package, destiné à gérer mes radiateurs via la solution proposée par TIKO…
le fichier de conf est /config/packages/tiko/tiko.yaml, ce qui veut dire qu’il cherche la config du package tiko dans ce fichier…
depuis ton package, tu peux refaire des include…
sensor: !include…
sinon une autre approche est de charger tous les yaml du dossier package, voir l’exemple ici :
+
le contenu des fichier YAML dans le dossier packages:
Une autre petite question.
J’ai modifier mon organisation avec packages, dans les 2 exemples ci dessous lequel type de fichier.yaml je dois conserver. je m’y perd un peu avec l’ancienne et la nouvelle méthode pour les templates. (les 2 sont apparemment fonctionnel, j’ai pas d’erreur)
# compteur eau test 1
template:
- sensor:
- name: "test ECS mètres cubes"
unique_id: test_ecs_metres_cubes
icon: mdi:counter
device_class: volume
state: >
{{ (states('counter.compteur_ecs') | float(default=0) / 1000) | round(3) }}
unit_of_measurement: "m³"
- name: "test ECS litres"
unique_id: test_ecs_litres
icon: mdi:counter
device_class: volume
state_class: measurement
state: >
{{ (states('counter.compteur_ecs') | float(default=0) / 1) | round(3) }}
unit_of_measurement: "L"
utility_meter:
# Utility water Counter EF
test_water_ef_l_hourly :
source : sensor.compteur_ef_litre
cycle : hourly
test_water_ef_l_daily :
source : sensor.compteur_ef_litre
cycle : daily
# compteur eau test 2
sensor:
- platform: template
sensors:
# Comptage Eau
ecs_metres_cubes:
friendly_name: "compteur eau chaude m³"
icon_template: mdi:counter
device_class: water
unit_of_measurement: "m³"
value_template: >
{{ (states('counter.compteur_ecs') | float(default=0) / 1000) | round(3) }}
ef_metres_cubes:
friendly_name: "Compteur eau froide m³"
icon_template: mdi:counter
device_class: water
unit_of_measurement: "m³"
value_template: >
{{ (states('counter.compteur_ef') | float(default=0) / 1000) | round(3) }}
utility_meter:
# Utility water Counter EF
util_water_ef_l_hourly :
source : sensor.compteur_ef_litre
cycle : hourly
util_water_ef_l_daily :
source : sensor.compteur_ef_litre
cycle : daily
Il me semble que c’est le modèle 1 qu’il convient d’appliquer maintenant…
c’est bien la méthode 2, la 1 est l’ancienne manière, qui génère des alertes depuis la 2023.6 dans h.a annonçant l’arrêt de la prise en charge à partir de 2023.8.
Je pense que tu as inversé… 
si tu peux me confirmer
Bonjour Benoit (@noiwid)
Je pense que c’est línverse, @pascal_ha a raison il fait référence aux sensors, binary_ sensors utilisant platform: template
sensor:
- platform: template
ou
binary_sensor:
- platform: template
Sont les anciens formats (Legacy Configuration Format)
C’est command_line qui genère des erreurs depuis 2023.06 et dont l’ancien format sera supprimé dans 2023.8.
Cordialement,
Abel
Bonjour à tous,
J’ai enfin réussi a faire remonter mon input_number contenu dans le package. Je vais faire un peu de nettoyage pour savoir ce qui l’a fait fonctionner et je vous ferai un retour.
Merci a tous pour votre aide.
Alors, ce retour ? 
J’ai pas trop eu le temps de finir. Mais aujourd’hui ça fonctionne. Et c’est plutôt bien pratique.
Salut
je migre progressivement aussi de mon coté
c’est vrai que c’est vraiment pratique et propre
il n’y a qu’un truc entre autre que j’ai pas encore migré c’est les automations