Forum Domoticz en français

Je trouve qu'on est plus proche de :
temp = 0.4 * commande + 23
@Buglover, ça colle avec tes mesures?

J’ai également un shift entre la consigne et la température mesure par ma CTN. Je mesure 43 degré avec une consigne à 40%. Pour l’instant je n’ai pas cherché à optimiser cette partie car je ne suis pas sure de la calibration de ma CTN. Je passe pas le convertisseur ADC du wemos qui est perfectible, puis par après une conversion ohm —> dégrée, donc les risques d’erreur sont nombreux. J’attends une dizaine de ds18b20 pour calibrer mon circuit

tchuene a écrit : 27 nov. 2020, 10:03 @Buglover: tu utilises le même code que Etimou? est-ce que vous avez amélioré le calcul du checksum?

@tchuene, peux-tu stp m'indiquer comment tu as trouvé 0x13B dans le calcul de mon checksum?
message[14] = 0x13B-message[9]-message[10]-message[11]-message[12];

@Buglover, as-tu le même problème avec la valeur de commande 15?

Edit: 15 s'écrit 1111 en binaire, 4 bits à 1 consécutifs, donc c'est peut-être un problème de bitstuffing. Le problème existe aussi avec 47 (101111) mais pas avec 31 (11111) ni 79 (1001111)

@Etimou
D'après Kainhofer, le CRC se calcule comme ceci

So, the checksum seems to be simple complement of the sum of all bytes. After a few trials, one notices that bytes 4-12 and the checksum byte 14 always sum up to 0x300, i.e. 0x00! So the checksum is simply the complement of bytes 4-12 summed up.

Donc à la difference de la solution de tchuene qui est une sorte d'optimisation pour un device ID donné (les bytes 4 et 5 : le deviceID sont manquant du calcule), les autres bytes sont des constantes et donc n'ont pas d'incidence sur le calcule. Après j'ai pas revérifié et j'ai simplement fait une dizaine de captures pour trouver ma base (chez moi 0x103).

@Buglover, as-tu le même problème avec la valeur de commande 15?

Oui 15 ne fonctionne pas non plus chez moi. J'utilise
0 - Arret
10 - démarrage du circulateur
20-100 - consigne de chauffe (%)

@ Buglover :
Manifestement, le fonctionnement automatique semble assez proche du mode manuel :
- 0 pas de diode : circulateur arrêté , cuve non réchauffée
- 1 1ere diode : ~22-23° , circulateur activé, cuve à 40-50°
- 2 diodes 1+2 : 26-27°
- 3 diode 2 : 31°

ce qui à l'air de correspondre à vos 10%, 20%, 30% ....... à confirmer car cela peut aller jusqu'à la position 14 (~75°, pas testé)

Est-ce linéaire sur la fin ?

N'ayant pas bien compris l'explication de Kainhofer pour le checksum je suis allé au plus simple:
la somme des bytes 4 à 12 additionnée au byte 14 est toujours identique, donc si on prend une trame et qu'on fait cette addition on trouve une valeur x qui restera constante en permanence. Pour simplifier le code j'ai soustrait à cette valeur x tous les bytes constants et donc il ne reste dans la formule que les bytes 9 à 12.

Pour ceux que cela intéresse, je me suis permis de faire un fork du code de etimou pour le rendre compatible avec le matériel RFLink :
https://github.com/ChristopheHD/frisquet-arduino

Cela permet de commander la chaudière sans fil.

Bien joué! du coup tu remplaces complètement le firmware par ce programme dans le RFLink?

De mon côté, pour avancer sur le checksum j'ai re-décodé complètement une trame radio d'origine (enregistré avec une clef SDR). J'ai trouvé de petits écarts par rapport à notre décodeur.
Par exemple pour le début de la trame, je trouve maintenant 0x7E 0xBE 0xE7 au lieu de 0x3F 0x9F 0xE7. Le premier octet correspond exactement à ce que trouve Kainhofer. Ca change tout concernant le checksum dont le calcul devient finalement assez simple. C'est la somme négative des octets 4 à 12. Le résultat de cette somme est sur 2 octets (par exemple un int sur arduino). L'octet de poids fort se retrouve en position 13 et l'octet de poids faible en position 14. L'octet 13 est souvent 0xFD mais parfois aussi 0xFE (confirmé par mon enregistrement). Cela montre qu'il n'est pas nécessaire de valider les 3 trames complètes, car ça marchait en envoyant toujours 0xFD.
Le code de calcul du checksum: J'ai testé en changeant un peu le code d'envoi des commandes que je ne trouvais pas très clair et ça marche avec la chaudière.
EDIT: la commande 15 est bien reçue, ça commence à sentir bon!

etimou a écrit : 05 déc. 2020, 10:01 du coup tu remplaces complètement le firmware par ce programme dans le RFLink?

Oui je remplace complètement le firmware. Soit je charge le "decode", soit le "command", mais ce n'est pas grave parce qu'à ce stade je n'ai pas besoin des 2 en même temps.

J'ai fait les mêmes constatations que toi concernant le début de la trame. En revanche, concernant le checksum, je ne trouve pas du tout la même chose. Je vais néanmoins quand même tester ton code de calcul de checksum cet après-midi.

J'ai mis le code "ERS command" sur github. J'aurais sûrement dû faire une branche...
Es-tu sûr de l'ID? Car s'il n'est pas bon le checksum sera faux. Je ne sais pas encore trop d'où ça vient mais le decodeur ne donne pas le bon...
Je pense qu'un moyen simple de vérifier est de voir si le byte 13 vaut 0xFD ou 0xFE.

Pour l'ID je pensais faire en sorte que lorsqu'on decode on vient le sauvegarder en EEPROM et ensuite on vient le chercher pour émettre. Ca évite de devoir le noter et de modifier le code.

etimou a écrit : 05 déc. 2020, 12:26 Es-tu sûr de l'ID?

Oui. J'ai beaucoup changé la manière dont le "decode" renvoie les informations. Voici ce que j'ai maintenant sur le moniteur série de l'Arduino lorsque je charge le firmware "decode" : Comme tu peux le voir, il y a des choses étranges par rapport à tout ce qui a été dit dans ce forum :
1. Il n'y a que 2 messages reçus au lieu de 3, peut-être un problème avec mon récepteur ?
2. Le checksum ne commence pas par 0xFD ou 0xFE, mais par 0xBE ou 0x7D selon les cas et la règle de calcul ne semble par correspondre avec ce que dit Kainhofer
3. La trame termine par FF01 au lieu de FF00