Du coup c’est moi que ça intéresse… Tu le récupères comment le sensor.edf_tempo_current_cost ?
échange de bons procédés 
tout d’abord grace à un multiscrape je récupère la couleur du jour via le code ci dessous:
# TEMPO EDF
- name: edf_tempo
resource: https://particulier.edf.fr/services/rest/referentiel/searchTempoStore?dateRelevant={{now().strftime("%Y-%m-%d")}}
scan_interval: 3600
headers:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Content-Type: application/json
User-Agent: Wget/1.20.3 (linux-gnu)
sensor:
- unique_id: edf_tempo_current
name: EDF Tempo Couleur Aujourd'hui
icon: mdi:flash
# device_class: None
value_template: >
{% if value_json.couleurJourJ in ['TEMPO_BLEU','TEMPO_BLANC','TEMPO_ROUGE'] %}
{{ value_json.couleurJourJ |regex_replace(find='^TEMPO_', replace='') }}
{% else %}
unknown
{% endif %}
ensuite je crée un sensor de ce type:
- unique_id: edf_tempo_current_cost
name: EDF Tempo Tarif Aujourd'hui
icon: mdi:currency-eur
device_class: monetary
unit_of_measurement: "€/kWh"
value_template: >
{% if (value_json.couleurJourJ == 'TEMPO_BLEU') %}
{% if (now().hour >= 22 or now().hour < 6) %}
0.1296
{% else %}
0.1609
{% endif %}
{% elif (value_json.couleurJourJ == 'TEMPO_BLANC') %}
{% if (now().hour >= 22 or now().hour < 6) %}
0.1486
{% else %}
0.1894
{% endif %}
{% elif (value_json.couleurJourJ == 'TEMPO_ROUGE') %}
{% if (now().hour >= 22 or now().hour < 6) %}
0.1568
{% else %}
0.7562
{% endif %}
{% else %}
0
{% endif %}
il faut bien évidemment penser à changer le montant des jours lorsque edf augmente ses tarifs 
.
le tout est à positionner dans un fichier multiscrape.yaml à la racine du config
voili voilà …vu mon faible niveau je ne pensais avoir à t’aider…n’hésite pas si besoin.
1 « J'aime »
Ah oui ok. J’ai cru que tu avais une solution de type intégration pour récupérer cette valeur.
Merci beaucoup pour tout le travail effectué ! Question concernant la voiture : l’application Tesla impose une limite basse de 5A pour le courant. Le slider home assistant fourni par l’intégration tesla permet quand à lui de descendre plus bas. Est-ce réellement fonctionnel ? Je trouve cela étonnant. Étant en monophasé, me paramètres seraient donc :
# La puissance minimale de charge est 220 W (soit 1 Amp car convert_power_divide_factor=220 aussi)
power_min: 220
# La puissance minimale de charge est 2200W (soit10 Amp (= 2200/220) )
power_max: 2200
C’est totalement fonctionnel. Je charge a 1 A (x3 car triphasé). Car permet de consommer un petit reliquat de production.
Merci pour la réponse rapide. C’est paramétré, on verra ce que ca donne demain !
1 « J'aime »
Bonjour, merci pour cette super intégration. Tout c’est bien dérouler mais je suis en galère quand a la configuration decluttering-card. J’ai essayé différente technique ( decluttering_templates: !include test_template.yaml dans mon configuration.yaml et création du fichier avec la copie de ton code a l’intérieur) bref je ne comprend pas comment l’installer et le github officiel ne m’aide pas plus a comprendre.
Avez vous une technique particuliere ?
Merci.
Ho le boulet que je suis !!!
Bonjour, je commence à comprendre mieux le module, je voulais accélérer un peu la gestion, actuellement, je remets dans le réseau 12%/ jour en moyenne. Il y a un moyen d’accélérer la réaction ?
Hello @Nid_d_aigle,
Le premier paramètre dans la configuration de l’intégration donne la fréquence de calcul. Il est par défaut à 5 min (300 secondes).
Attention à ne pas mettre trop bas car l’algo d’optimisation fait beaucoup de calcul, donc ça sollicite pas mal la CPU.
1 « J'aime »
Ca marche du tonnerre : 95% d’auto-conso désormais. Merci de nouveau @Jean-Marc_Collin c’est une dinguerie ce module comme disent les jeunes.
Je me permets quelques questions supplémentaires plutôt liées au véhicule, ne pas hésiter à m’indiquer si c’est trop HS :
-
Le réglage du courant max est laissé par solar optimizer sur la dernière valeur renvoyée par l’algo : généralement assez faible (moins de 10A) alors que ma borne peut délivrer 32A. Si le chargement est planifié à une heure tardive pour profiter des heures creuses, 23h par exemple, la valeur de l’ampérage reste la même et la voiture charge lentement. Je me suis retrouvé avec une charge nocturne à 1A qui n’a pour ainsi dire servi à rien. Avez vous rencontré ce problème et, si oui, y avez vous remédié ?
-
Avez vous implémenté une logique pour controler la planification de la charge du véhicule la nuit en fonction de l’état de switch.enable_solar_optimizer_tesla. La doc contient des ressources mais je préfère demander avant de me lancer la dedans.
Hello,
Oui ca garde le dernier ampérage. Ce que je fais à chaque démarre de charge (hors solaire), je force l’ampérage à 32A. Donc j’ai un input_select qui donne le mode de charge : Solaire / Manuel / Automatique.
Si je suis en Solaire, l’ampérage est piloté par Solar Optimizer, sinon l’automatisation qui écoute les démarrages de charges force le 32 A.
Ca répond aussi à ton point 2. La nuit ce mode est en Automatique (l’hiver j’ai pas assez de production pour charger en solaire) donc je ne charge que la nuit et je suis en mode ‹ Automatique › du coup.
Merci pour la réponse. Je pense que j’ai mal cerné un point de la logique car ma voiture ne charge plus la nuit, en gros la charge démarre mais stoppe quelques minutes après.
Si je laisse le switch.enable_solar_optimizer_tesla sur on la nuit, et que la charge se lance, il va la couper du fait du manque de production solaire ? Donc il faut un système similaire au votre, à savoir un input select qui bascule sur off le switch.enable_solar_optimizer_tesla la nuit pour permettre la charge ?
Est-ce bien cela, ou dois-je appeler Tesla pour leur signaler que ma voiture ne charge plus ^^ ?
heuu non.
Je vais aller un peu plus dans le détail de ce que j’ai. Voici ma conf :
- name: "Recharge Tesla"
...
check_usable_template: "{{ is_state('input_select.charge_mode', 'Solaire') and is_state('binary_sensor.tesla_wall_connector_vehicle_connected', 'on') and is_state('binary_sensor.tesla_charger', 'on') and states('sensor.tesla_battery') | float(100) < states('number.tesla_charge_limit') | float(90) }}"
# 2 heures
duration_min: 120
# 15 min stop
duration_stop_min: 15
# Power management
power_entity_id: "number.tesla_charging_amps"
# 5 min
duration_power_min: 5
action_mode: "service_call"
activation_service: "switch/turn_on"
deactivation_service: "switch/turn_off"
change_power_service: "number/set_value"
convert_power_divide_factor: 660
Si tu regardes le check_usable template, il faut que mon input_select.charge_mode soit sur ‹ Solaire › pour Solar Optimizer utilise cette partie dans l’optimisation. Si il est faux, il ne regarde même pas.
Tu peux faire la même chose ou même donner les horaires directement dans ce template pour que ce soit ‹ faux › après 22h00 par exemple (ou avoir une automatisation qui passe à Automatique le input_select.charge_mode la nuit. Mais si tu charges la nuit, tu n’optimises rien du tout la journée puisque la voiture est chargée. C’est pour ça que c’est manuel chez moi. Si je veux charger la nuit, je change le input_select.charge_mode sur 'Automatique` (et Solar Optimizer ne touche à rien).
Ok merci, ca clarifie les choses. Mon besoin est différent : j’ai une 3 et une Y et je change généralement tous les 3 jours. Je compte donc charger celle qui reste à la maison avec le surplus solaire, tandis que l’autre doit être chargée la nuit (car absente la journée) pour me permettre de rouler avec.
A la lecture des logs, je m’aperçois que mon check_usable template doit être foiré. Je le voulais sur false une fois la nuit tombée pour me permettre de charger à 23h15, en mettant comme condition sun en above_horizon
check_usable_template: "{{ is_state('sun.sun', 'above_horizon') and is_state('device_tracker.titine_location_tracker', 'home') and is_state('binary_sensor.titine_charger', 'on') and states('sensor.titine_battery') | float(100) < states('number.titine_charge_limit') | float(90) }}"
Je m’attends à ce que ce soit false la nuit, mais force est de constater que ca repasse en true au moment ou ma charge planifiée démarre :
trente minutes plus tard il se relance pour 10 minutes et coupe ensuite:
Si je comprends bien la logique : pour X raison le switch solar optimizer passe sur true quand ma charge nocturne démarre, et l’algo stoppe ma charge peu après du fait de la production solaire à 0. Donc pas de charge nocturne, et direction le superchargeur.
Je pense que je vais également utiliser un input select et voir ce que ca donne.
OK, je vois. Ca repasse true parce-que toutes tes conditions sont true en fait.
Est-ce que le soleil est couché: oui, est-ce qu’elle est branchée: oui, …
Donc Solar Optimizer prend le dessus et coupe car pas de soleil.
Faut que tu changes ta condition
is_state('sun.sun', 'above_horizon')
Au dessus de l’horizon = soleil levé non ? Donc quand l’ entité sun.sun à pour status below_horizon la condition devrait être false si je ne m’abuse. Ce qui est d’autant plus étrange c’est que le status est continu :
Je vais faire un plot de l’attribut de l’optimizer en espérant trouver plus d’indices. En attendant je teste la méthode avec input select, je croise les doigts pour que ca charge ce soir ^^.
Oui tu as raison, j’ai lu trop vite. Ca devrait marcher, je ne vois pas ce qui ne va pas.
EDIT: je viens de tester dans Outils de dev / Modèle et ça marche comme prévu à priori
Bonjour, je cherche a ajouter une condition car avec l’intégration je gère une prise qui s’active avec une automatisation HC/CP. Et j’ai remarqué un conflit entre les deux (la nuit l’intégration coupe le switch).
J’essaye ceci mais je suis pas sur :
devices:
- name: "Prise Bureau"
entity_id: "switch.prise_bureau"
power_max: 100
# Toujours utilisable
# check_usable_template: "{{ True }}"
# 15 min d'activation minimum
duration_min: 15
# On active/desactive via un appel de service
action_mode: "service_call"
# Le service permettant d'activer le switch
activation_service: "switch/turn_on"
- condition: device
type: is_off
device_id: 6ecb609ff7789bf0491feba1500fbf54
entity_id: fcc58ee228327e65fedfc8bcda25cbab
domain: switch
# Le service permettant de désactiver le switch
deactivation_service: "switch/turn_off"
Merci.