Non, car je me base sur la gravité, en mesurant g. ça se remet en fonctionnement tout seul.
Au rallumage de l’ESP, l’IMU va donner les valeurs de g sur (x,y,z), SUN va te donner la position du Soleil, puis l’asservissement va faire son job.
Wouah, sacré boulot, effectivement, le code est nettement plus évolué 
Reste plus qu’à digérer tout ça et le faire fonctionner chez moi parce que je dois le faire fonctionner avec un ESP32 (plutôt qu’un ESP Seeed C6) et un double pont en H DBH-12V (plutôt que 2 DRV8871) mais ça semble grandement possible avec ton code … 
Pour passer de ton ESP32, c’est simplement dans la déclaration de la classe qui devras ajuster.
esp32:
board: esp32-c6-devkitc-1
variant: ESP32C6
flash_size: 4MB
framework:
type: esp-idf
version: latest
Puis pour le DBH-12V, à la place des DRV8871, tu n’as rien à toucher dans le code, si ce n’est les GPIO de ton ESP, sinon c’est juste mettre les bons fils aux bons endroits.
Les 4 outputs, doivent aller sur tes IN1A, IN2A, IN1B, IN2B.
1 « J'aime »
Les offset_acc, tu les as calculé comment, comment as-tu eu le retour lorsque tu mets ton IMU sur une table nivelé ?
Sur une table, ou une surface plane (plaque d’alu, cul de casserole, …) que tu auras mis de niveau avec des petites cales si nécessaire.
Tu poses ton IMU dessus, par exemple l’axe Z perpendiculaire à ta surface, et donc à la gravité.
Tu relèves les valeurs sur (x,y) que ton IMU te donnes à ce moment là. Normalement ça devrait être (0,0), mais il y a des petites erreurs, que tu compenses avec offset_accX, offset_accY.
Pour Z, tu tournes ton IMU de 90°.
Si tu veux ajuster encore un peu mieux, tu fais les 6 faces (x, -x, y, -y, z, -z), tu relèves à chaque fois le couple perpendiculaire à la surface, puis tu fais une moyenne, tu devrais avoir 4 valeurs par axe.
Sinon, pour faire encore plus simpliste, tu poses ton IMU comme elle sera installée sous tes panneaux, en position horizontale, et par exemple avec mes valeurs ça aurait voulu dire que l’IMU me donne (chez moi, quand mes panneaux sont à l’horizontal, l’axe Z est colinéaire et en direction de g):
Acc X = 0,35 m/s²
Acc Y = -0,1 m/s²
Acc Z = 10,51 m/s²
D’où les offset pour ramener à 9,81 m/s².
1 « J'aime »
Bonjour @Scorpix , j’ai relu ton code plusieurs fois et je n’ai pas trouvé comment réagi le traqueur s’il n’a pas reçu de Home Assistant les valeurs de sunElevation et sunAzimuth … 
… (si par exemple, l’ESP est coupé du réseau)
Je n’ai jamais fait l’essai hors réseau, donc je ne sais pas trop comment il se comporte. Mais ça serait intéressant que je me penche sur cet aspect.
Cependant, sunElevation et sunAzimuth sont calculés en interne sur l’ESP, à l’aide de la position géographique et l’heure.
La position tu la mets directement dans le yaml dans la classe SUN.
L’heure, elle est synchronisée avec HA au démarrage. Si tu passes hors réseau, elle va continuer, à sa dérive près de la clock interne. Mais négligeable sur l’échelle de quelques jours, voire mois. ça dépend de ses caractéristiques.
Sinon, tu peux changer la plateforme de TIME, par un autre élément. Tu dois pouvoir te débrouiller avec HOST, et avec un WEB SERVER en Local, entrer l’heure à la main.
Autre petite question :
Dans le code, on voit qu’il peut basculer en mode manuel, lorsque l’IMU renvoie des valeurs en dehors des limites fixées.
Comment pilotes-tu dans ce cas les vérins ?
Je n’ai pas vu de « boutons » pour agir directement sur eux …
La classe FAN te crée une entité dans HA qui te permet de piloter les vérins.
Et aussi sur ta page WEB SERVER si tu en paramètres une.
Dans le rectangle bleuté tu slides plus ou moins vers le haut pour piloter la vitesse (ici 39%), en dessous tu as un bouton ON/OFF, et tout en bas, tu inverses le sens.
1 « J'aime »
Encore d’autres questions (je suis vraiment désolé de te déranger sans arrêt, mais j’aime bien comprendre avant d’appliquer, pour éviter de déranger lors de la maintenance ) :
Question 1 :
Dans le code, on voit le bouton storm_mode, j’ai bien vu qu’on pouvait l’activer/désactiver par la page Web mais comment est-il activé en automatique ?
Est-ce qu’il y a une entité à créer côté HA pour le lié à une alerte météo par exemple ?
Question 2 :
Dans les calculs de sunRoulis et sunTangage, j’ai vu qu’il y avait un décalage sur l’update_interval (update_interval: 10.1s pour sunRoulis et update_interval: 10.15s pour sunTangage), c’est parce que, lors de tes tests, tu as vu quelques choses de particulier ou c’est juste histoire de décaler les ressources de calculs ?
Question 3 :
Dans le bouton storm_mode :
- platform: template
id: storm_mode
name: "Mode nuit/intemperie"
icon: "mdi:weather-lightning-rainy"
optimistic: True
on_turn_on:
- lambda: return id(sunTangage).publish_state($repos_tangage); # Angle elevation repos
- lambda: return id(sunRoulis).publish_state($repos_roulis); # Angle azimuth repos
Tu retournes sunTangage avec la valeur $repos_tangage.
Et dans le capteur sunTangage:
- platform: template
id: sunTangage
name: sunTangage
unit_of_measurement: °
internal: ${PUSHED_TO_HA}
update_interval: 10.15s
lambda: |-
if (id(storm_mode).state) return {$repos_tangage}; // Angle elevation repos
return asin(id(sunX).state)/sqrt( pow( id(sunX).state , 2) + pow( id(sunZ).state , 2))*180/$PI;
Tu indiques que si storm_mode est activé, alors il faut retourner la valeur $repos_tangage.
Ça ne fait pas redondance ?
En plus de la partie soft, voici le hard et le câblage que je compte mettre en œuvre :
Je sais que le module de charge, batterie et convertisseur 5v => 3.3v ne sont pas indispensable mais, pensant que le MPU6050 perdait son étalonnage lors d’une coupure de courant, j’avais déjà acheté et intégré ces composants.
N’étant pas du monde de l’aviation, le roulis, tangage sont un peu perturbant pour moi, j’ai donc ajouté les notions de E/O pour le roulis et N/S pour le tangage. J’espère que je ne me suis pas trompé et si on positionne l’IMU comme ce ci (le capteur de l’IMU étant au dessus du PCB):
Réponse question 1 :
Effectivement, aujourd’hui ce n’est pas en automatique en local, j’ai une automatisation HA qui récupère des niveaux d’alerte météo France.
L’idéal serait d’avoir un anémomètre sur le µC, qui bascule ce mode en fonction de la vitesse du vent.
Réponse question 2 :
Je décale légèrement mes updates, qui remontent les états dans HA, car j’ai remarqué que ça permettait d’avoir une liaison Wifi plus stable quand tu as des bilans de liaison mauvais. Mon point d’accès wifi est au centre de ma maison, et le tracker dehors, et je suis aux alentours de -80/-90dB.
Quand toutes mes valeurs sont remontées à HA en même temps, souvent ça plantait et je perds l’ESP.
En étalant ainsi, c’est mieux.
Réponse question 3 :
Tu as raison c’est de la redondance.
Peut-être que sous cette formulation ça aurait été mieux :
if (!id(storm_mode).state) return asin(id(sunX).state)/sqrt( pow( id(sunX).state , 2) + pow( id(sunZ).state , 2))*180/$PI;
Oui, tu as bien illustré la concordance roulis/tangage avec les axes géographiques NS/EO.
Si je ne me trompe pas, avec mes signes dans le code, les axes correspondants sont :
J’ai appliqué un - sur z, car j’ai collé l’IMU sous les panneaux, la tête à l’envers.
Sinon c’est un moins par ci par là à ajouter ou supprimer.
Dans tous les cas, il faut faire des essais préalables sur table voir si les angles correspondent 
Bonjour @Scorpix , je reçu tout le matériel pour remplacer mon contrôleur (à part la résine pour isoler l’IMU de l’humidité), donc je fais des essais de calibrage avant la mise en place sur le traqueur en extérieur.
J’essaie de créer des sensors ESPHome pour avoir les sensors Accel X, Accel Y et Accel Z corrigé par l’offset :
Est-ce que tu peux confirmer que ce code va bien afficher les sensors corrigés qui seront utilisés dans ton code :
# Description
# Déclaration des capteurs d'accélération du MPU6050 corrigé par l'offset
# Utilisation :
# Ces capteurs 'accel_x', 'accel_y', 'accel_z' sont utilisés pour le calcul des
# angles des panneaux dans les capteurs 'PV_roulis' et 'PV_tangage'
- platform: template
id: accel_x_corrected
name: "solar-tracker Accel X with offset"
internal: ${KEEP_INTERNE}
unit_of_measurement: °
update_interval: $boucle_asservissement
lambda: return id(accel_x).state + $offset_accX;
- platform: template
id: accel_y_corrected
name: "solar-tracker Accel Y with offset"
internal: ${KEEP_INTERNE}
unit_of_measurement: °
update_interval: $boucle_asservissement
lambda: return id(accel_y).state + $offset_accY;
- platform: template
id: accel_z_corrected
name: "solar-tracker Accel Z with offset"
internal: ${KEEP_INTERNE}
unit_of_measurement: °
update_interval: $boucle_asservissement
lambda: return id(accel_z).state + $offset_accZ;
Et avec ce code, je ne vois rien côté page Web d’ESPHome :
Et ce normal ?
Ai-je oubli quelque chose pour afficher ces capteurs ?
J’ai trouvé …
Il fallait retirer le internal: ... pour être visible dans la page Web.
Désolé du dérangement
Bonjour,
je travaille sur un projet similaire depuis plusieurs mois déjà (j’avance lentement faute de temps) et je suis donc avec beaucoup d’attention ce post. Un grand merci @Scorpix pour le partage du code initial et des évolutions, merci également @Sylvain_G pour la contribution! J’en suis personnellement au stade des tests sur table qui sont très prometteurs, ça marche au top (à part quelques soucis sur la liaison I2C du MPU). J’ai également ajouté un anémomètre au code, ainsi qu’un INA260 qui me permettra de gérer le tracker en cas de coupure réseau.
Voici le schéma de mon projet:
Je continue de vous suivre avec intérêt, bonne continuation !
Bonjour @Julien_Galliot , je voulais savoir si tu avait déjà le code ESPHOME pour le capteur anemometre ?
J’en ai un 2 fils aussi qui a une plage de 0-2v et je voudrais l’ajouter à la config de @Scorpix. D’après ce que j’ai pu lire, il faut brancher son « + » à la borne AD0 de l’ESP32.
Tu peux regarder du côté ADC d’Esphome
Analog To Digital Sensor — ESPHome
Il te faudra la table de correspondance tension/vitesse.
Bonsoir,
Ci-joint le code de mon anemo :
- platform: adc
pin: GPIO34
name: "Anémomètre"
id: Anemo_volts
internal: True
filters:
- offset : $offset_Anemo
- clamp:
min_value: 0.1
max_value: 3.0
ignore_out_of_range: False
attenuation : 12db # Range 0,075 V ~ 3,12 V
accuracy_decimals: 2
unit_of_measurement: V
update_interval: 1s
- platform: template
id: Vent_kmh
unit_of_measurement: Km/h
internal: True
update_interval: 1s
lambda: return (id(Anemo_volts).state)*50;
filters:
- clamp:
min_value: 5
max_value: 150
ignore_out_of_range: False
on_value_range:
- above: 30
then:
- switch.turn_on: storm_mode
- platform: template
name: Vent_kmh
accuracy_decimals: 0
unit_of_measurement: Km/h
update_interval: 1s
lambda: return id(Vent_kmh).state;
Le rapport kmh/volt (pour moi 50) dépendra de ton capteur.
Merci pour ton partage.
Je voudrais savoir, à quoi correspond la variable offset_Anemo dans ton code ?
Autre question, on voit que le mode tempête est enclenché dès que l’anémomètre détecte un vent de 30 km/h :
Mais comment réactives tu le mode asservi ?
Est-ce que tu attends que l’anémomètre redescende en dessous des 30 km/h pendant XX minutes ou il faut attendre le levé du soleil du lendemain et ce code switch.turn_off: storm_mode :
# Description :
# Récupération de la position du soleil.
# Utilisation :
# Utiliser pour les capteurs sunElevation et sunAzimuth
sun:
latitude: xx.xxxxx
longitude: y.yyyyy
on_sunrise:
- then:
- switch.turn_off: storm_mode # Asservir vers position du levée du soleil
on_sunset:
- then:
- switch.turn_on: storm_mode # Mettre en position de repos/vent à presque horizontal, avec légère pente pour écoulement pluie
- number.to_min: number_roulis # RàZ le soir
- number.to_min: number_tangage # RàZ le soir
substitutions:
offset_Anemo: '-0.05'
L’offset anemo me permet de corriger l’erreur du 0 du capteur, je me suis rendu compte qu’il fallait déjà une certaine vitesse de vent pour que la mesure en volts commence à décoller. L’offset corrige ce décalage.
Oui c’est ça j’ai prévu d’attendre 10 minutes sans rafales (en dessous de 25km/h) pour désactiver le storm mode, et du coup j’ai également totalement dissocié les modes storm et night :
- platform: template
id: night_mode
name: "Mode nuit"
icon: "mdi:weather-night"
optimistic: True
on_turn_on:
- lambda: return id(Angle_NS).publish_state($repos_NS); # Angle elevation repos
- lambda: return id(Angle_EO).publish_state($repos_EO); # Angle azimuth repos
- platform: template
id: storm_mode
name: "Mode tempete"
icon: "mdi:weather-lightning-rainy"
optimistic: True
on_turn_on:
- lambda: return id(Angle_NS).publish_state($repos_NS); # Angle elevation repos
- lambda: return id(Angle_EO).publish_state($repos_EO); # Angle azimuth repos
- wait_until:
condition:
for:
time: 10min
condition:
lambda: |-
return id(Vent_kmh).state < 25;
- switch.turn_off: storm_mode