Agrandir la fenêtre augmente le retard, il faut faire l’inverse. J’ai vécu la même chose à une époque où je travaillais sur des drones.La source du retard est la moyenne elle-même : une moyenne mobile sur 20 mesures arrive avec environ 1 seconde de retard, et l’erreur augmente à mesure que la vitesse de rotation augmente. Le manque de calibration évoqué par Büşra Hanım explique aussi la différence entre la droite et la gauche.La solution consiste à combiner avec le gyroscope. Le gyroscope voit la rotation instantanément mais dérive lentement, le magnétomètre est lent mais ne dérive pas. Un filtre complémentaire combine les deux :

// dt = 0.1 s, gz = derece/s (z ekseni jiroskop)
float a = 0.98;
heading = a * (heading + gz * dt) + (1 - a) * magHeading;
// 0/360 geçişini düzelt
float fark = magHeading - heading;
if (fark > 180) heading += 360 * (1 - a);
if (fark < -180) heading -= 360 * (1 - a);
heading = fmod(heading + 360, 360);

Si la carte n’a pas de gyroscope, ajouter un MPU6050 est la solution la moins chère. Commencez par faire tourner le bateau sur deux tours complets dans l’eau et effectuez la calibration hard/soft iron.Le problème du 180 est distinct : un angle ne peut pas être moyenné. La moyenne de 359 et 1 donne 180. Le graphique hebdomadaire lit des valeurs agrégées toutes les heures et la fonction par défaut est average. Sur le graphique du cap, réglez la fonction sur last, et pour l’analyse envoyez heading_sin et heading_cos en plus du cap ; leur moyenne donne le bon résultat.

Ce n’est pas le débit en bauds, c’est la tension. Si tu as mesuré -9 V, la réponse est déjà là.Le signal RS-232 varie d’environ ±3 à ±15 V et sa logique est inversée : au repos il est négatif, « 1 » est négatif, « 0 » est positif. L’UART du Pi, lui, fonctionne en TTL 3,3 V, de 0 à 3,3 V, avec une logique normale. En les reliant directement, le niveau et la polarité sont tous deux faux, et ces caractères parasites en sortie en sont exactement la conséquence. De plus, appliquer une tension négative et environ 9 V sur le GPIO15 peut détruire la broche. Débranche tout de suite ; c’est un coup de chance si le Pi est encore intact.J’ai résolu le même problème à deux endroits, avec deux méthodes :1. Module MAX3232 (MAX3232, pas MAX232 ; il fonctionne en 3,3 V). VCC sur les 3,3 V du Pi, le côté TTL sur GPIO14/15, le côté RS-232 sur le DB9. 2. La solution plus propre : un convertisseur USB-RS232 (puce PL2303 ou FTDI). Il apparaît comme /dev/ttyUSB0 et tu n’as pas du tout à t’occuper du GPIO.Pour l’écran de connexion : la console série du Pi est active sur /dev/serial0. Dans raspi-config > Interface > Serial Port, réponds Non à « login shell over serial » et Oui à « serial port hardware ».Et pour le croisement TX/RX : on ne sait pas si la balance est DCE ou DTE. Si aucune donnée n’arrive, inverse les broches 2 et 3.Ensuite, l’envoi vers Hermetry est simple : avec paho et un token d’accès, tu publies sur v1/telemetry :

import re, json, serial
import paho.mqtt.client as mqtt

c = mqtt.Client(client_id="kantar-1")
c.username_pw_set(TOKEN, "")
c.tls_set()
c.connect(BROKER_HOST, 8883, keepalive=60)
c.loop_start()

s = serial.Serial('/dev/ttyUSB0', 9600, timeout=2)
while True:
    line = s.readline().decode('ascii', 'ignore')
    m = re.search(r'(-?d+.d+)s*kg', line)
    if m:
        c.publish("v1/telemetry", json.dumps({"weight_kg": float(m.group(1))}), qos=1)

Hakan, regarde la documentation, il n’y a rien de tel. Hermetry n’a pas de rapport prêt à l’emploi programmé ou envoyé par e-mail, c’est écrit clairement. Mais la méthode qui fonctionne aujourd’hui, c’est celle-ci, nous l’avons exactement appliquée dans une usine textile :Mesure : pour 38A, prends un SCT-013-050 (sortie 1V), relie-le à l’ADC de l’ESP32 avec un biais de 1,65V, et effectue le calcul RMS façon EmonLib directement sur l’appareil. Fais envoyer à l’appareil un current_a toutes les 30 secondes. Si tu veux de vrais kWh, il te faudra un analyseur d’énergie avec Modbus sur rail DIN. Accepte une marge d’erreur de 10 % avec une pince + un cosφ estimé.Puissance et énergie : dans le root flow, place un bloc Calculate avant Save telemetry et dérive power_kw. Le détail est sur la page valeurs dérivées.

expr:   round(1.732 * 400 * msg.payload.current_a * 0.85 / 1000, 2)
target: msg.payload.power_kw

Rapport : place une carte graphique sur le tableau de bord, règle le regroupement sur jour, et dans les réglages de la carte coche Download data (CSV). En fin de mois, règle la fenêtre sur Ce mois-ci et télécharge le fichier Excel. Si tu veux l’automatiser, un petit script peut récupérer les valeurs journalières depuis l’API history avec agg=sum, ou avec increase si tu envoies un compteur, et tu enverras le mail toi-même.