prixCarburant et fork(s)

Est-ce que tu aurais mis un truc genre:

carburants =  (
    "Gazole"
)

Si on ne connait pas Python on ne peut pas le savoir, mais la virgule après est hyper importante et il faut l’écrire comme ça: "Gazole", (bon en vrai c’est seulement important quand il n’y a qu’un seul carburant une sombre histoire de tuples)

Si la virgule est oubliée, alors mon programme va essayer avec le carburant G puis a puis z etc. avec toutes les lettres du mot Gazole

Il faudrait que je bétonne mon programme contre ça, et contre la situation où les appels de l’API ont une réponse vide parce que la bibliothèque que j’utilise pour communiquer avec MQTT a selon moi un bug: si on lui demande de n’envoyer aucun message, elle attend indéfiniment.

J’ai corrigé mon programme de deux façons:

  1. Je n’essaie pas de contacter MQTT s’il n’y a aucun capteur à ajouter ou mettre à jour (pour contourner le bug de paho.mqtt
  2. J’ai remplacé les parenthèses dans la configuration par des crochets, qui n’ont pas le souci d’avoir besoin d’une virgule à la fin.

La dernière version est toujours ici.

(Pour les curieux, le problème est que les crochets dans ["Bonjour"] représentent une liste, à un seul élément ici, mais les parenthèses dans ("Bonjour") sont des parenthèses de calcul comme en maths. Du coup pour faire un « tuple » il faut écrire ("Bonjour",) parce qu’une fois qu’il y a une virgule dedans Python sait qu’il n’y a plus d’ambigüité avec des parenthèses mathématiques. Quand il y a plusieurs valeurs, il y a forcément une virgule donc le problème ne se voit pas.)

Bonjour,

Merci@Aohzan pour ton travail sur le sujet.

Les prix me semblent plus cohérents que ce que j’ai pu trouver comme autre solution. Je parle entre autre de la méthode proposée par @Pulpy avec le webscapping. Via carbu, j’ai trouvé souvent les prix obsolètes (en termes de date de mise à jour), en tout cas pour la localité. Le 2nd point négatif est la gestion manuelle des sensors même si cette méthode m’a permis de comprendre un peu plus les sensors.

L’avantage avec Prix Carburants est le fait que l’on puisse saisir un rayon et que l’intégration soit autonome.
Par contre, pour mon utilisation, j’ai un désavantage: je fais personnellement mon plein sur le trajet domicile-travail et j’ai donc fixé un rayon assez large pour couvrir ce trajet mais cela fait beaucoup trop de sensors (ce qui est un avantage pour la méthode par webscrapping citée plus haut), donc trop de données non utilisées.

Je suis néophyte donc incapable de savoir ce qui se charge derrière ce genre de dév, mais une utilisation envisageable sur cette même base pourrait être :

  • Lors de l’intégration, pouvoir choisir un nombre de sensors à créer (par défaut disons 10)
  • L’utilisation pourrait passer par la carte en elle-même:
    1) Avoir un input_select qui permette de choisir soit: les coordonnées de HA (comme actuellement) ou celle d’un ou plusieurs téléphones utilisés sous HA.
    2) Avoir une sélection de rayon comme actuellement
    3) Avoir un bouton rafraichissement

Cela signifie que si je suis au boulot, en vacances ou autre, je peux utiliser HA sur mon téléphone pour regarder autour de moi les stations intéressantes tout en conservant uniquement 10 sensors qui seront rafraichis avec les données.

smilorel

Ca demande beaucoup de boulot :sweat_smile:
Pour mettre que les stations que tu veux tu peux utiliser la configuration manuelle en yaml

Oui je m’en doute mais quand tu ne maitrise pas, tu ne te rends pas compte. :slight_smile:

Je vais tenter effectivement en mode manuel que j’ai découvert dans un autre post.

L’API que j’utilise accepte un polygône de filtrage en entrée. Du coup on peut en paramétrer un « le long d’un trajet ».

J’ai expérimenté avec l’interface
Prix des carburants en France - Flux instantané — Ministère de l’Économie, des Finances et de la Souveraineté industrielle et numérique et dans la case geofilter.polygon il faut entrer une liste de points (lat1,lon1),(lat2,lon2). Attention, en utilisant μMap pour « dessiner » ces points, l’export en geojson a la longitude en premier, pas la latitude donc il faut ajuster.

Je peux coder un truc si vous voulez pour générer la requête (en rajoutant l’option dans les paramètres à côté des positions).

Ou tu fait ça pour les stations peu utile (ce que je fait)

Bonjour

étant donner que le multi-scrappe n’est pas souvent mise à jour( carbu.com ),
je me suis tourné vers cette solution qui récupère les donnés sur le site du gouvernement

mais j’ai un souci, il me manque une station qui est bien sur le site, mais qui n’apparaist pas sur la carte et dans les entités.


Merci pour votre travail

Je suis pres’que sûre que c’est a cause de rupture de stock, j’ai vû parreil chez moi
EDIT: quelle type de carb t’as sélectionné ? Si pas GPLc…pas de sensor

j’ai sélectionné gasoil, je verrais dans les prochains jours, si il apparait

Bonjour,

sur le Fork D’Aozhan (merge depuis celui de Vingerha), est-il possible de faire des groupes pour une utilisation multi-carburants ensuite ? J’ai l’impression que oui au vu des résultats de certains mais il doit me manquer quelque chose pour y arriver.

J’ai configuré et j’ai l’ensemble des stations configurées dans mon configuration.yaml. J’ai aussi un group.yaml include dedans pour gérer les groupes à part. Je me demande comment faire ici car si je groupe mes sensor.xxxx il faut que je choisisse E10 ou SP95 par exemple.

Comment avoir ça avec l’intégration d’Aozhan ?

  station_essence:
  - sensor.prixcarburant_xxxx
  - sensor.prixcarburant_xxxx
  - sensor.prixcarburant_xxxx
  - sensor.prixcarburant_xxxx
  - sensor.prixcarburant_xxxx

Dans l’intégration de Ryan j’y arrive car il y a une entité mère pour la station, qui contient des valeurs pour chaque carburant. Dans celle d’Aozhan, chaque sonde est un carburant …

Voici mes cards sur l’intégration de Ryan que j’aimerai fonctionnel sur celle d’Aozhan !:
Flex table :

type: custom:flex-table-card
clickable: true
sort_by:
  - E10+
entities:
  include: sensor.prixcarburant*
columns:
  - data: friendly_name
    icon: mdi:gas-station
    name: Station
    align: left
  - data: E10
    name: E10 €/L
    align: center
    modify: x.replace("None", "-")
  - data: E95
    name: SP95 €/L
    modify: x.replace("None", "-")
    align: center
  - name: Date
    data: Last Update Gasoil
    multi_delimiter: ','
    modify: Math.round((Date.now() - Date.parse(x)) / 36000 / 100 /24)
    align: right
    suffix: J
style: |
  :host {
    --card-mod-icon-color: rgb(31, 111, 235);
    font-size: 13px;
        }

Markdown :

{% set update = states('sensor.date') %}
{% set midnight = now().replace(hour=0, minute=0, second=0, microsecond=0).timestamp() %}
{% set sorted_station_essence = "group.station_essence" | expand | sort(attribute='attributes.E10') %}
  | Station |     E10     |     E95     | Date |
  | :------- | :----: | :----: | ------: |
{% for station in sorted_station_essence %}| {{- state_attr(station.entity_id, 'friendly_name') -}}
  |{%- if state_attr(station.entity_id, "E10") == "None" -%}-{%- else -%}{{- state_attr(station.entity_id, 'E10') -}}{%- endif -%}
  |{%- if state_attr(station.entity_id, "E95") == "None" -%}-{%- else -%}{{- state_attr(station.entity_id, 'E95') -}}{%- endif -%}
{%- set event = state_attr(station.entity_id,'Last Update Gasoil') | as_timestamp -%} {%- set delta = ((event - midnight) // 86400) | int -%}
  |{{ -delta }} Jours|
{% endfor %}