Page bloquée

Cette page est actuellement bloquée pour modification par un autre utilisateur. Vous devez attendre que cet utilisateur ait terminé ou que le blocage de la page expire.

Actuellement bloqué par :
Le blocage expire à : 2025/09/03 06:16 (15 min)

Vous affichez une ancienne révision du document ! Si vous l'enregistrez, vous créerez une nouvelle version avec ce contenu.

====== Interface chauffage - Local Process Bus LPB ======

===== Introduction =====

Mon objectif est de récupérer des données et de piloter ma chaudière de la marque **Weishaupt**.
Cette chaudière communique avec mon thermostat via un bus numérique qui a été développé par SIEMENS. **Local Process Bus LPB**
Je n'ai pas trouvé de document complet sur le protocole mais quelques informations par ci par là. Je vais essayer de regrouper toutes les informations dont je dispose et qui m'ont été utile ci dessous.

ND : Le bus LPB est proche du bus BSB et eBus. L'interface hardware et le format est trame est en partie équivalent. Certains des informations ci dessous peuvent dont être utilisées pour ces bus.

===== Hardware =====

Liaison série sur 2 fils (Data et 0V)
Nivaux signaux : 
  * < 7V : '1' logic (Sortie interface : 0V)
  * > 9V : '0' logic (Sortie interface : +5V)

Un simple comparateur est utilisé pour convertir le signal en 0/3V compatible avec un convertisseur UART/USB du type FTDI

==== Schema interface de lecture ====

NB : Le même schéma peut être utilisé pour un eBus avec R2 = 6.8K les seuils étant différents : 
  * 9-12V : '0' logic (Sortie interface : 0V)
  * 15-24V : '1' logic (Sortie interface : +5V)

===== Protocole ===== 
Le bus est équvalent à une liaison série avec le RX et le TX sur le même fil et des niveaux de tension différents

Liaison UART (RS232) 4800 Bauds - 8 bits Data - parity odd - 1 stop bit

==== 1er lecture ====

Lors de la première lecture, on obtient des trames du type : 
<code>
87 EB FF EF 33 FD FF EB 9C C2 D2 FD F2 F9 FE FF FF FF FE 10 8B 87 F1 EF FF 33 FD FF EB 9B D2 C2 FD F2 0A 9E 
87 EA 00 FF 03 FD FF EB FD D2 FF FD CE FF FF CE 4F FD FF F2 0F FC 
87 E2 00 FF 33 FD FF EB FD D2 FF FD F0 F9 F9 FE FE D5 7B 6F 6F 6F 6F 6F 6F 03 ED FF 14 04 
87 EF 00 FF 33 FD FF EB FD EA FF FE 04 CD FE 0B 42 
87 EE 00 FF 33 FD FF EB FD FA FF FD E2 FF F3 2C 0C 81 
</code>

Ces trames débutent toutes par "87" et ne sont pas directement exploitables. Les trames devraient commencer par "78"
Pour cela, il faut inverser tous les bits des données reçues : 
<code csharp>
for (int i = 0; i < buffer.Length; i++)
{
   byte InvertByte = (byte)~(uint)buffer[i];
   buffer[i] = InvertByte;
}
</code>

Ensuite vous devivriez bien obtenir des trames debutant pour "78"
<code>
78 11 FF 00 CC 02 00 14 02 05 00 02 1D 00 0F 06 F2 B4 
78 13 FF 00 FC 02 00 14 02 15 00 02 0A 00 01 1F 00 00 F0 F0 
78 11 FF 00 CC 02 00 14 02 05 00 02 1D 00 0E C0 F3 6D 
78 10 FF 00 CC 02 00 14 02 15 00 01 FB 00 00 F4 8A 78 14 00 10 CC 02 00 14 A3 3D 2D 02 0D 06 01 00 00 00 01 EF B4 
</code>

==== Le format de la trame ====

Exemple : 78 11 FF 00 CC 02 00 14 02 05 00 02 1D 00 0F 06 F2 B4 
  * 78 : Magic Byte - Indique le debut de la trame (Toujours 78)
  * 11 : Taille - Indique la taille du télégramme sans compter le Magic Byte 0x11 = 0d17 et on a bien 7 octets dans la trame.
  * FF : Destination - Adresse de destination du telegramme (0xFF Broadcast à touts les périphériques sur le bus)
  * 00 : Expéditeur - Adresse de l'expediteur du telegramme
  * CC : Flag d'envoi ou de réception ? 
  * 02 : inconnu
  * 00 : inconnu
  * 14 : inconnu
  * 02 : type ? 2 : info / 3 : Set / 4: Ack to Set / 6 : Request / 7 : reply to request - Le type est augmenté de 0x20 entre chaque échange
  * 05 : (cmd & 0x00ff0000) >> 16;
  * 00 : (cmd & 0xff000000) >> 24;
  * 02 : (cmd & 0x0000ff00) >> 8;
  * 1D : (cmd & 0x000000ff);
  * 00 : valeur

Les octect 1 et 2 sont inversés entre la demande et la réponse :

Exemple : 
  * Demande : 053D0064 type 86
  * Réponse : 3D050064 type 87

Echange suivant +0x20

* Demande : 053D0064 type A6
  * Réponse : 3D050064 type A7

* 0F 06 : Valeur du telegramme
  * F2 B4 : CRC

==== Calcul du CRC ====

Le CRC se calcule avec l'ensemble des reçus

<code csharp>
        public static string CRC_LPB(byte[] bytes)
        {
            int crc = 0;
            int len = bytes.Length-1;
            crc = (257 - len) * 256 + len - 2;

if (bytes != null && bytes.Length > 0)
            {
                for(int i=0;i<(len-1);i++)
                {
                    crc += bytes[i];
                }
            }
            return String.Format("{0:X2}", crc);
        }
</code>
  
  Si bytes[] = {0x78,0x11,0xFF,0x00,0xCC,0x02,0x00,0x14,0x02,0x05,0x00,0x02,0x1D,0x00,0x0F,0x06,0xF2,0xB4}
  
  Alors crc = F2B4 
==== Liste des télégramme et décodage ====

La majorité des informations ci dessous sont issu de tests (reverse engineering) et ne sont pas donc pas fiables à 100%

=== Décodage températures === 
Toutes les températures se décodent de la même manière.

Exemple : 78 11 FF 00 FC 02 00 14 02 31 00 02 22 00 **0A 7B** F3 85

On récupère la valeur (Ici il s'agit d'une information de température de l'ECS)
On convertir cette valeur en entier : 0x0A7B = d2683 
On divise par 64 par avoir la valeur en °C : 2683 / 64 = 41°C

=== Décodage DateTime ===

Exemple 78 17 FF 00 FC 02 00 14 02 05 00 00 6C 00 **75 0C 1F 07 10 0E 1A 00** EE 07

* 75 : 1900 + 0x75 (117) = 2017 (année)
  * 0C : 12 (mois) 
  * 1F : 31 (jour)
  * 07 : 7eme jour de la semaine donc dimanche
  * 10 : 16 (heure)
  * 0E : 14 (min)
  * 1A : 26 (secondes ?)
  * 00 : ??

Question de sécurité : Après le mois d'avril, il y a le mois de ? ma.... Merci de laisser ce champ vide :

Résumé