Intégration Solar Optimizer - Optimisation de sa consommation Solaire

Pour l’instant certaines voitures les ont encore mais les recentes notamment non: https://github.com/alandtse/tesla/issues/774

Voici l’erreur quand j’essaye simplement de lancer la charge via l’interface HA

2024-01-29 09:20:34.458 DEBUG (MainThread) [teslajsonpy.connection] post: https://owner-api.teslamotors.com/api/1/vehicles/*xxxxxxxxxxxxxx*/command/charge_start {}
2024-01-29 09:20:34.515 DEBUG (MainThread) [teslajsonpy.connection] 403: {"response":null,"error":"Tesla Vehicle Command Protocol required, please refer to the documentation here: [https://developer.tesla.com/docs/fl [...] 34;"}](https://developer.tesla.com/docs/fleet-api#2023-10-09-rest-api-vehicle-commands-endpoint-deprecation-warning","error_description":""})

Tesla remplace son api et supprimer l’acces gratuit, pour linstant en consultation ca fonctionne encore (teslamate) et pour les voiture c’est une question de temps avat qu’elles aient toute migrées.

Bien dommage :frowning:

Bonjour et merci pour cette intégration. Pensez-vous que l’algorithme est adaptée à l’autoproduction avec des panneaux solaires plug and Play sans injection dans le réseau puisqu’il faut définir 2 input number dont on ne dispose pas (pour le rachat par Enedis) ?
Merci

Hello @denisb88 ,

Oui ca marche aussi. Les input_number avec les couts ne sont pas la partie la plus significative sur l’algorithme. Si tu mets le même cout partout, ça marchera aussi bien.

1 « J'aime »

Merci, y aurait-il moyen de prioriser les switchs (par ex si tous mes switchs importants sont en marche alors allumer des switch secondaires comme la recharge d’appareils de jardin ou des chargeurs de piles) ˋ ? J’aimerais également déclancher le démarrage de mon cumulus en priorité mais je l’ai réglé sur 700w. L’algorithme fait quoi exactement, il répartit l’injection en fonction de quel critère ? Est-ce qu’il éteint un appareil qui consommerait 350w si l’excédent est de 150w pour allumer un appareil qui consommerait 500w afin d’utiliser les 150w en excès ?

Hello as-tu lu la doc qui explique justement ce que tu demandes ?

Bonjour, merci pour ce superbe boulot ! J’ai de mon coté pu finaliser mon Dashboard Energy :wink: Je dispose donc de sensors indiquant la quantité d’Energie produite, la quantité importée et la quantité exportée.
Je m’intéresse desormais à l’utilisation de mon surplus de manière efficace. Je dispose d’un ballon Thermodynamique Atlantic Odyssee, que je peux piloter en HP/HC grâce à un Shelly 1. Pour le moment il ne fonctionne que sur les HC, ce mode étant activé par automation via mon Shelly 1.
La cerise sur le gâteau serait évidemment de pouvoir utiliser mon surplus lorsqu’il y en a pour lancer la PAC de mon ballon (sans risquer de la flinguer par des allumage/extinction intempestive évidemment…) et pour celà, j’ai l’impression que ton intégration peut m’aider !
Un retour d’expérience sur mon cas ??

Merci donc si je comprends bien, pas moyen de mettre des priorités qui outrepassent le coût.

Hello @Tonejay ,

Non je n’ai pas de retour sur un cas comme ça. J’ai un thermodynamique avec forçage solaire (si je switch un switch ça force un cycle de chauffe). Donc je pilote ce switch lorsque j’ai plus de 1000 w de réserve.

Ca marche bien. Et je pense que ton cas est similaire sauf que je ne sais pas si ça va forcer un cycle de chauffe lorsque tu switches. En tout cas, ca se tente. C’est vraiment le cas d’usage.

Non en effet. Le but est de consommer un max de la production en trouvant la meilleure combinaison qui optimise la consommation.

Ca pourrait être une évol intéressante de mettre des priorités. La question est: comment évaluer si faire devant un switch tout en dégradant la consommation est finalement intéressant ou pas. Si tu arrives à répondre à cette question, je veux essayer d’implémenter qqe-chose. (D’ici l’été)

On m’a parlé de déclenchement selon seuil avec l’hysteresis… Le tout est effectivement de trouver le bon seuil… Et effectivement il ne faut pas qu’il tourne sur des heures pleines car plus suffisamment de soleil…
Pour le moment mes premiers essais sur les heures creuses sont concluant, mais ce serait encore mieux avec de l’énergie solaire :blush:. Le seuil atteint déclenchera mon switch et donc le ballon… :smiling_face:

1 « J'aime »

Bonjour @Jean-Marc_Collin ,

Tout d’abord un grand bravo pour cette intégration que tu as bien voulu mettre à la disposition de la communauté. Dès que tu l’as publiée, je me suis très vite intéressé mais je n’avais pas vraiment compris certaines subtilités.
Aujourd’hui je me replonge dans tes explications car je vais faire l’acquisition d’un véhicule électrique de la même marque semble t il que le tien et cerise sur le gâteau, j’ai aussi du enphase :grin:. Comme à mon habitude avant de me lancer à recopier machinalement du code gracieusement mis à notre disposition, je cherche à comprendre la logique de fonctionnement. Du coup j’ai qq questions à te poser:

1- dans la partie configuration tu parles d’un sensor ou input_number qui donne la taxe applicable sur les kwh exportée … où peut on trouver cette information svp ? ce n’est pas le turpe ?

2- tu utilises des sensors pour la conso nette instantanée et pour la production PV instantanée. On est bien d’accord que tu utilises les sensors de la passerelle enphase S metered qui a un décalage de 15 mn ?? (donc pas instantanée.) ou alors tu utilises d’autres sensors ??

3- Pour l’instant je vais surtout utiliser le code pour la recharge de ma cloucloute :wink: mais je ne comprends pas certains paramètres. quand tu marques ```
La puissance minimale de charge est 660 W (soit 1 Amp car convert_power_divide_factor=660


4-pour l'instant je n'ai pas de borne de recharge rapide. Je verrai une fois la voiture réceptionnée si il est opportun de m'équiper. Je vais donc pour l'instant charge cloucloute avec une prise domestique classique 16 A. donc le power_max que je dois rentrer c'est bien : 16*230= 3680 c'est bien çà ?

5- dans ton exemple tu as mis  duration_min à 60 . cela veut -il dire que une fois la charge lancée , la durée est de 60 mn avant que l'algo recalcule ??

6- je ne saisi pas l'intéret du duration stop min... 

a ce stade je m’arrête car les réponses que tu voudras bien m'apporter permettront de répondre à mes autres interrogations.
d'avance un grand merci.

 

Hello, @phil,

Je crois que ça s’appelle comme ça en effet. Comme ca vient baisser le prix de vente en fait, on peut en tenir compte. Mais tous ces prix jouent à la marge sur l’algo.

J’utilise la puissance instantanée qui n’est pas (à ma connaissance) décalée de 15min. Vraiment de ce que je constate, je ne pense pas que ce soit décalée.

Je pensais avoir tout nettoyé mais manifestement non :sweat_smile:

Je suis en triphasé. Donc quand je charge à 1 A → 220 volts x 1 A x 3 => 660W.
En monophasé, remplace les 660 par 220.

merci pour ta réponse.

5- dans ton exemple tu as mis duration_min à 60 . cela veut -il dire que une fois la charge lancée , la durée est de 60 mn avant que l’algo recalcule ??

Ca veut dire que lorsque je lance une charge c’est au moins pour une heure. Sinon à chaque nuage ca va couper la charge et c’est pas très bon pour le chargeur.
Par contre, l’ampérage peut varier pendant cette heure (ca s’adapte à la production)

Merci . Je me suis donc lancé mais je rencontre un problème pour le sensor du cout de l’énergie importée. Je suis sous tempo donc ce sensor change à 22h et à 6h pour afficher le tarif de la couleur du jour.

pourtant le sensor edf_tempo_current_cost renvoi bien la bonne valeur.
le message d’erreur en haut de l’image ne m’avnace pas beaucoup. merci de ton aide.

Sous HA un id d’entité est de la forme xxxx.yyyy. ça pourrait être un input_number.xxxx ou un number. Normalement il propose la liste des entités compatibles. Il suffit de la sélectionner.

C’est bizarre car mon entity_id est bon et est de la forme : sensor.edf_tempo_current_cost
Comme tu peux le voir dans l’image ci dessous, aucun sensor n’est proposé . uniquement des input_number. Mais si je me réfère à ton point 4 de ton chapitre « configurer l’intégration » , il est possible d’avoir un sensor. Du coup serait-ce un bug ?? mon entité est bonne et fonctionne bien.

Comme indiqué dans l’erreur, il faut un input_number en entrée.
Le sensor n’est pas forcément numérique et pourrait donc provoquer des soucis dans le calcul.

Tu dois pouvoir te faire un template de type input_number valorisé avec la valeur du sensor au besoin.

Ok merci pour ta réponse. Je ne suis pas très à l’aise avec les templates mais je vais essayer de faire ce que tu me proposes.

Pour ceux qui rencontreraient le même problème, voici le code qui semble fonctionner pour affecter la valeur d’un sensor à un input_number.

alias: Affecter la valeur du capteur à l'input_number
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.edf_tempo_current_cost
condition: []
action:
  - service: input_number.set_value
    data:
      value: "{{ states('sensor.edf_tempo_current_cost') }}"
    target:
      entity_id: input_number.prix_achat_edf
mode: single

L’idée: à chaque fois que le sensor edf tempo current cost change d’état (22h et 6h00), l’input_number nécessaire au paramétrage du cout actuel du kwh dans solar optimizer prend la valeur du sensor.
Je poursuis désormais le paramétrage.