J’ai récemment développé une intégration météo pour utiliser les données de l’Institut Royal Météorologique de Belgique (https://www.meteo.be) dans Home Assistant. L’intégration utilise leur API Android non documentée pour obtenir les données.
Pour installer l’intégration, cela se fait via un dépôt personnalisé sur HACS: Custom Repositories | HACS (instructions). Catégorie: intégration. Lien du dépôt: https://github.com/jdejaegh/irm-kmi-ha
Depuis la version 0.2.6, l’intégration offre les fonctionnalités suivantes:
Ca a l’air super ! j’ai installé l’addon. je ferai des tests et te ferai des retours au cas où mais d’après la documentation dans HACS, ça a l’air déjà bien complet.
Un tout grand merci, les Addons pour la Belgique manquent un peu
@jdejaegh, Voilà j’ai créé les cartes qui vont bien et je vois bien les prévisions ainsi que la carte ! c’est juste Génial et ça tombe vraiment top vu les neiges
Je n’ai rien à ajouter donc si tu as des questions ou si tu aimerais que je fasse des tests n’hésites pas a me contacter.
Si jamais tu as des infos sur un endroit ou on peut récupérer les données des prix de l’électricité de chez nos fournisseurs Belges, je suis preneur à 200%
Superbe initiative
J’utilise leur application sur mon smartphone.
J’ai maintenant intégré ton intégration à HA.
Je n’ai pas encore tout compris, et je dois encore jouer avec les cartes et les attributs pour avoir ce que je veux.
En tout cas merci pour le cadeau de bon an et le travail réalisé
@+ Guy
@Vincha j’ai déjà eu l’occasion de tester pas mal et d’avoir des retours via le forum Home Assistant Community, merci pour la proposition.
Concernant les données sur les prix de l’électricité, je n’ai aucune idée… Sans avoir creusé la question, ça me semble être un bon casse-tête pour trouver les données (si elles existent). Ca ne m’étonnerait pas que les fournisseurs calculent leur prix de vente pour les contrats variables a posteriori, une fois que le relevé annuel est établi. Bon courage dans ta recherche!
@GDX2 n’hésite pas à poster un message ici si tu bloques. Ca permettra à d’autres d’avoir des idées et de mon côté d’éventuellement améliorer l’intégration.
@jdejaegh
Après avoir testé je trouve qu’il fonctionne très bien, mais serait il possible et est-ce réalisable bien sur, d’avoir l’information de l’état du Warning?. ( Le pourquoi pourquoi il se met en Dangereux, Sécurisé,…)
L’information est disponible dans les attributs du binary_sensor, comme mentionné par @GDX2. Comme il est possible qu’il y ait plusieurs warnings en cours, il s’agit d’une liste de warnings avec leur détail (raison, niveau, description et période). Certains peuvent être émis d’avance: ils sont affichés dans la liste mais ne sont pas encore d’application.
J’en conviens, la liste d’attributs n’est peut être pas le plus simple à afficher sur un dashboard.
Qu’essaies tu d’accomplir avec cette information? L’afficher sur un dashboard? L’utiliser dans des automatisations?
@GDX2
je ne suis pas encore trop habitué à HA donc je n’ai pas encore l’habitude farfouiller pour avoir les info mais je vais regarder de plus près
@jdejaegh
Oui, l’afficher sur le Dashboard et plus trad cette information serait utilisé dans une/des automation(s) (quand j’en maitriserai les base ) :-
Un endroit que tu te dois d’aprivoiser et même te servir à retour de bras des outils qui y son disponnibles, c’est bien « outils de développement » qui se trouve dans ton menu de droite.
Ensuite, tu peux aller dans « Etats »
C’est de cette rubrique que j’ai tiré la capture d’écran ci-dessus.
Les autres sections de " Outils de développement " sont aussi très utiles.
A explorer et utiliser sans retenue
Je viens de publier une nouvelle version (0.2.0) qui ajoute quelques attributs au binary sensor.
Le sensor a maintenant un attribut active_warnings_friendly_names qui liste tous les avertissements actifs en utilisant leur nom commun.
Chaque avertissement dans la liste possède un attribut is_active qui est true si l’avertissement en question est actif (l’heure actuelle est après l’heure de début et avant l’heure de fin). Cela devrait rendre les choses plus simples pour les automatisations
Voici un exemple des attributs du binary sensor après la mise à jour:
Je viens de publier une nouvelle version (0.2.6) qui ajoute un capteur par type de pollen suivi par l’IRM. Chaque capteur lié au pollen rapporte la même valeur que ce qui est affiché dans l’app IRM.
Par exemple, les pollens suivants affichés dans l’app se traduisent directement dans Home Assistant
Merci @jdejaegh
J’ai mis à jour et intégré les pollens.
Si non, j’ai une demande.
Pour la gestion de mon chauffage, j’ai besoin de connaître la température minimale qu’il fera la nuit.
J’utilise pour celà, et ce dèjà avant ton intégration, l’intégration native de HA → Meteorologisk Institute (Met.no).
En fait, à quelques rares exception près, c’est la t° minimale de demain (la température la plus basse du jour est juste avant le lever du soleil)
Dans l’intégration Meteorologisk Institute (Met.no), c’est la templow du premier jour des prévisions (demain)
Je récupère cette valeur dans un template
Si j’avais cette info dans ton intégration, je me passerai de Meteorologisk Institute.
Est-ce possible ?
Autre chose:
J’ai une rose des vents dynamique qui est fonction du wind_bearing.
Là aussi, je dois continuer avec Meteorologisk Institute parce qu’ils me donnent le wind_bearing en degrés alors que ton intégration me le donne sous forme « WSW ».
Voilà, rien de grave ou d’urgent et ton travail pour lequel je te remercie, est dèjà super.
@+ Guy
Concernant la température minimale pour la nuit
La dernière version de Home Assistant (2024.4) supprime l’attribut forecast des entités météo en faveur du service weather.get_forecasts.
L’intégration Met.no ne fonctionnera donc plus à partir de 2024.4 pour le template.
A ce jour, je n’ai pas trouvé de moyen simple d’appeler un service dans un template (ce qui est nécessaire dans l’exemple ci-dessus pour remplacer l’attribut forecast).
Je suis en train de regarder pour maintenir l’attribut forecast de mon intégration comme certaines cartes personnalisées et templates en dépendent.
Dans la prochaine version de l’intégration, il devrait être possible d’utiliser le même genre de template.
Concernant la direction du vent
L’API de l’IRM fournit les degrés et la forme « WSW ». Par facilité j’ai pris la forme « WSW » comme les degrés ne semblaient pas conventionnels (ils indiquent 0 pour S et 180 pour N, ça devrait être l’inverse).
J’en conviens, il est souvent plus simple d’écrire un programme qui utilise des degrés pour la direction du vent qu’une valeur du genre « WSW ».
Comme Home Assistant accepte les deux formes, je vais mettre à jour pour retourner des degrés.
Effectivement, j’ai lu celà.
Je n’ai pas encore passer à la version 2024.4.0 (première du mois). J’attends toujours un peu, pour voir s’il n’y apas de problème signalé.
Ils sont aujourd’hui à la version 2024.4.1, je vais donc me lancer
On verra !
Pour le wind_bearing en degrés, je vais dire que c’est plus précis que les formats « WSW »
Peut-être, avant de changer, voir s’il y a beaucoup d’utilisateurs qui utilise ce format.
Si non tu risques de faire plus de mécontants.
Donc ne case pas tout juste pour moi
Je viens de publier la version 0.2.8 avec quelques petites mises à jour. Notamment, l’attribut forecast est toujours présent (en attendant qu’une solution simple pour les templates existe).
Concernant la température minimale pour la nuit
En utilisant les prévisions biquotidiennes dans l’attribut forecast (configurable dans les paramètres de l’intégration), le template suivant donne la température minimum de la prochaine nuit. Cela devrait permettre de remplacer Met.no qui, à partir de 2024.4, ne fournit plus l’attribut forecast.
Concernant la direction du vent
C’est maintenant retourné en degrés et plus en 1-3 lettres pour le point cardinal.
Comme je n’ai pas de tracking pour savoir qui utilise l’intégration et comment, j’ai testé avec 4 cartes Lovelace qui ont été mentionnées sur les forums par des utilisateurs de mon intégration:
Comme les deux formats sont spécifiés dans la documentation, les cartes et intégrations populaires ont généralement une logique pour convertir si besoin.
