Port RS485 de la batterie connecté

[jlm]

Voilà les 1ers dialogues obtenus de haute lutte avec le couple "Smartphoton - Nodered"
via le le port RS485 de la batterie et le port USB du Raspberry.

J'ai fait un peu de reverse engineering pour comprendre comment discuter avec ce port de communication. Je n'y connaissais rien avant.
J'y reviendrai pour l'explication. Ça vaut la peine.

Reste à comprendre ce dialogue digne de piloter une centrale électrique. C'est touffu et pas du tout "humanisé"
Ça viendra dans quelques jours.

Voici à quoi ça ressemble.
Scénario:

1. J'appuie sur le nœud "buffer 1" qui envoie une suite de bytes au nœud série qui va donc aller discuter avec le BMS de la batterie via son port RS485.
   
2. La réponse à la demande arrive via le nœud "Réponse BMS Pylon" et s'affiche dans la fenêtre de droite.
   

Ça reste incompréhensible pour le moment mais avec la documentation on devrait pouvoir décrypter ces réponses et aussi les questions  

Voici l'exemple:

Le branchement du matériel:

   

Et le software qui va avec:

   

[jlm]

Je manque un peu d'énergie et de temps pour décrypter le dialogue utilisé par le BMS Pylontech en RS485.

Alors si une âme sensible est intéressée à le faire, voici de quoi se faire les dents.
Merci

Ci dessous un extrait du dialogue, avec en bleu le Pc ou l'onduleur qui initie le dialogue, en rouge les réponses du BMS.

   

et ci-dessous le log complet du dialogue:


  RS485-Live-Protocol.txt (Taille : 176.29 Ko / Téléchargements : 117)

et la documentation qui décrit les diverses trames et leurs significations


  PYLON LFP Battery communication protocol - RS232 V2.8 20161216.pdf (Taille : 256.72 Ko / Téléchargements : 352)

https://domosimple.eu/wp-content/uploads...200219.pdf

[jean.pustel@gmail.com]

Je manque un peu d'énergie et de temps pour décrypter le dialogue utilisé par le BMS Pylontech en RS485.

Alors si une âme sensible est intéressée à le faire, voici de quoi se faire les dents.
Merci

Ci dessous un extrait du dialogue, avec en bleu le Pc ou l'onduleur qui initie le dialogue, en rouge les réponses du BMS.



et ci-dessous le log complet du dialogue:



et la documentation qui décrit les diverses trames et leurs significations



https://domosimple.eu/wp-content/uploads...200219.pdf

ben quand même , c'est simple non ?...    

[ChrisPv]

de mon coté j'y travaille du moins sur la qualification des commandes envoyées.
réception heu ! plus tard :-(

[ChrisPv]

Des nouvelles du décodage partiel des commandes pour batteries pylontech
Dans le fichier texte j'ai place le nom de la commande envoyé.
je n'ai pas traité tout le fichier car très long et inutile car les commandes sont répetitives .
prochaines étapes
1 décodage des trames reçues brrr grrr ! :-(
2 calcul du checksum  (ah le mal de tête)
ChrisPv

[jlm]

Une personne que je connais bien m'a donné un coup de pouce.
Je pense qu'il n'est pas utile de savoir décoder le checksum. Donc on s'enlève un truc pénible.

Voici un début de décryptage:

7E = Début des données
32 30 = Version
30 32 = Numéro de batterie ou champ ADR
34 36 = 34 est un 4 en ASCII en hexadécimal et 36 est un 6 en hexadécimal en ASCII, donc 46 et c'est le code pour les batteries lithium ion (CID1)
34 32 = 42 c'est le code pour l'information analogique de la batterie (CID2)
45 30 30 32 = LENGTH c'est la longueur des données calculées avec un calcul complexe
30 32 = Info batterie 2
46 44 33 33 = Checksum
0d = retour chariot fin requête
7e 32 30 30 32 34 36 34 32 45 30 30 32 30 32 46 44 33 33 0d = Requête pour infos batterie 2
7e 32 30 30 33 34 36 34 32 45 30 30 32 30 33 46 44 33 31 0d   Requête pour infos batterie 3
7e 32 30 30 34 34 36 34 32 45 30 30 32 30 34 46 44 32 46 0d = Requête pour infos batterie 4
7e 32 30 30 35 34 36 34 32 45 30 30 32 30 35 46 44 32 44 0d  = Requête pour infos batterie 5
7e 32 30 30 36 34 36 34 32 45 30 30 32 30 36 46 44 32 42 0d = Requête pour infos batterie 6
manque juste la requête pour la batterie 1, mais à part le checksum cela devrait être
7e 32 30 30 31 34 36 34 32 45 30 30 32 30 32 46 44 XX XX 0d

[ChrisPv]

Une personne que je connais bien m'a donné un coup de pouce.
Je pense qu'il n'est pas utile de savoir décoder le checksum. Donc on s'enlève un truc pénible.

Voici un début de décryptage:

7E = Début des données
32 30 = Version
30 32 = Numéro de batterie ou champ ADR
34 36 = 34 est un 4 en ASCII en hexadécimal et 36 est un 6 en hexadécimal en ASCII, donc 46 et c'est le code pour les batteries lithium ion (CID1)
34 32 = 42 c'est le code pour l'information analogique de la batterie (CID2)
45 30 30 32 = LENGTH c'est la longueur des données calculées avec un calcul complexe
30 32 = Info batterie 2
46 44 33 33 = Checksum
0d = retour chariot fin requête
7e 32 30 30 32 34 36 34 32 45 30 30 32 30 32 46 44 33 33 0d = Requête pour infos batterie 2
7e 32 30 30 33 34 36 34 32 45 30 30 32 30 33 46 44 33 31 0d   Requête pour infos batterie 3
7e 32 30 30 34 34 36 34 32 45 30 30 32 30 34 46 44 32 46 0d = Requête pour infos batterie 4
7e 32 30 30 35 34 36 34 32 45 30 30 32 30 35 46 44 32 44 0d  = Requête pour infos batterie 5
7e 32 30 30 36 34 36 34 32 45 30 30 32 30 36 46 44 32 42 0d = Requête pour infos batterie 6
manque juste la requête pour la batterie 1, mais à part le checksum cela devrait être
7e 32 30 30 31 34 36 34 32 45 30 30 32 30 32 46 44 XX XX 0d

a priori le checksum est utilisé pour l'envoi de commande qui est vérifié par le master des batteries.
pour le retour des datas demandées  le checksum est présent mais utilisés seulement pour les systèmes critiques qui en ont l'utilité.

[Micclfr]

Du coup, si je met ma pylon en rs485, est-ce que je vais récupérer des infos ?