Forum Domoticz en français

christopheHD a écrit : 05 déc. 2020, 13:54 1. Il n'y a que 2 messages reçus au lieu de 3, peut-être un problème avec mon récepteur ?

Ou alors ça dépend du modèle. Kainhofer en a aussi 2.

christopheHD a écrit : 05 déc. 2020, 13:54 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

La fin du message semble bizarre, je pencherais encore sur un probleme de bitstuffing. B ou 7 c'est 3 bits à 1 au lieu de 4 pour F.

christopheHD a écrit : 05 déc. 2020, 13:54 3. La trame termine par FF01 au lieu de FF00

Ca peut correspondre au décalage de 1 bit. Le 1 correspond au premier bit du dernier octet. Donc si on décale à gauche on obtient FF00. Moi j'ai FF00 ou FF80 car il me semble que le tout dernier bit peut varier lors du retour à l'état 0 de la sortie. Mais ça n'a pas d'impact.

Je crois bien que c'est ça. Ton deuxième message termine par:
BE D FF 1
ce qui fait
0111 1101 1011 0000 1111 1111 1000 000
Si tu enlèves le 0 souligné qui arrive après cinq 1 consécutifs, tu obtiens FE 86 FF 00 qui tombe juste avec le calcul du checksum sur le reste du message

Bravo @etimou pour la décodage de cet octet 0xFE , j'avais également quelque fois 0xFD dans mes trames. Et après vérification sur les trames que j'avais sauvegardées cela colle bien. J'ai malgré tout sur certaines (<10% de mes trames) une erreur de 1 sur le calcul du checksum, mais mes acquisitions n'ont pas toujours été rigoureuses.

Et en grand bravo à ChristoheHD pour son setup, qui semble être le moins invasif de tous. Si j'ai bien compris ton RFlink envoie les trames sur le 433MHz (?) et le récepteur radio de la chaudière les reçoit --> donc Zero intervention coté chaudière (à part enlever les piles du précédent thermostat ).

Note - Je vais poster sur GitHub la proposition de prise en compte du bit stuffing lors du décodage des trames sous forme de #define pour faciliter la vie des membres, car ce point revient souvent.

1. Il n'y a que 2 messages reçus au lieu de 3, peut-être un problème avec mon récepteur ?

Cela peut être lié à du bruit entre 2 trames, sur mon setup certaines fois je captais que 1 ou 2 trames seulement,
Si tu utilises la dernier version du decoder, elle inclut un fix qui marche chez moi et me permet d'éliminer le bruit et d'avoir toujours 3 trames.

Sinon comme discuté préalablement, la chaudière ne semble pas toujours suivre la consigne de chauffage lorsqu'elle est en mode ECS 'eco', - La V4V (avec la roue verte) reste 'bloquée' sur la position ECS - Alors que la consigne de chauffe est de 40%. Si elle finit pas se déclencher et passer en mode chauffage, cela peut prendre plusieurs heures. Je me demande s'il ne s'agit pas d'un BUG de la chaudière, car cela pourrait expliquer pourquoi je trouvais le régulation si nulle.

Voici graphiquement ce que j'observe

La période Rouge étant le "bug", et la période Verte le comportement attendu (lorsque j'ai passé le ECS ne mode STOP)

Mes constations à date
- J'ai l'impression que Polo n'a pas ce problème avec le passage en mode manuel de la chaudière (et le pilotage par les boutons)
- Le problème disparait dès que l'on passe la chaudière en mode ECS 'Stop',

Est ce quelqu'un a trouvé une solution sans hacker le bouton du tableau de bord ?

J'ai aussi des problèmes de varations importantes mais la valeur moyenne suit plutôt bien la consigne (sur plusieurs heures). Les montées semblent plus lentes que les tiennes. En tout cas ça semble démontrer que la régulation d'origine avec le satellite qui envoie régulièrment des consignes différentes ne peut pas bien fonctionner...

bonjour, passionnants vos échanges

Je ne peux pas trop vous aider coté ECS car je ne fais que du chauffage. Ce que j'ai lu sur le sujet :
- l'ECS est "prioritaire" sur le chauffage
- pour l'ECS il faut que la cuve soit très chaude >70° (?)

Du coup j'en déduirais que :
- le pilotage de la t° de cuve doit être géré localement en fonction de l'ECS et non pilotable
- si la demande de chauffage arrive, la vanne 4 voies commute sur ECS de par la priorité. La régulation de la T° chauffage passe donc au second ordre.

Mes constations à date
- J'ai l'impression que Polo n'a pas ce problème avec le passage en mode manuel de la chaudière (et le pilotage pas les boutons)

Je n'ai pas de problème car je n'ai pas d'ECS ............

J'espère que vous allez trouver une solution par rapport à l'ECS car vous avez fait un super boulot ! ce serait dommage de ne pas pouvoir en profiter pleinement .

Une idée :
pourquoi ne pas réguler sur la T° de retour ? Les pointes de t° en sortie sont brèves (commutation de la vanne d'ECS vers Chauffage). Introduire un peu d'inertie faciliterait peut-être la tache.
Good luck

J'ai aussi des problèmes de varations importantes mais la valeur moyenne suit plutôt bien la consigne (sur plusieurs heures)

La moyenne est OK, mais la chaudière n'est pas en production de chaleur, uniquement en mode ECS - la V4V est positionnée sur ECS.
On l'observe bien sur le graphique des températures (en bleu foncé température extérieure , et en orange témpérature de la piece suivit par la régulation). Sur le plage en rouge (de 12:30 à 16:30) les témpératures baissent (--> pas de chauffage), alors que lorsque j'ai coupé le ECS période verte (>17:00), le chauffage se met en marche et les températures intérieures remontent

En vrai, mon setup marche très bien en réception de trame mais n'a fonctionné qu'une seule fois en émission.

@etimou, tu avais raison pour le bitstuffing,, en le retirant, cela fonctionne très bien. Pour ceux intéressés par le code pour retirer le bistuffing, vous le trouverez ici :
https://github.com/ChristopheHD/frisque ... a2c57dee32

Buglover a écrit : 06 déc. 2020, 11:29 Cela peut être lié à du bruit entre 2 trames, sur mon setup certaines fois je captais que 1 ou 2 trames seulement,
Si tu utilises la dernier version du decoder, elle inclut un fix qui marche chez moi et me permet d'éliminer le bruit et d'avoir toujours 3 trames.

Je suis parti de la dernière version du decoder sur le github de etimou, il n'y a pas eu de modification depuis et c'est pourtant systématique : je n'ai que 2 messages. Tu sais quelle partie du code t'a permis de retrouver le message numéro 0 ?

christopheHD a écrit : 06 déc. 2020, 17:54 En vrai, mon setup marche très bien en réception de trame mais n'a fonctionné qu'une seule fois en émission.

As-tu essayé avec mon dernier code d'émission? C'est le seul que j'ai testé avec le bon format de trame.

Dans ton code pour retirer le bitstuff j'ai l'impression que tu le fais sur toute la trame, c'est ça? Kainhofer dit que c'est sur les octets4à 14.

Merci @christopheHD, j'ai abandonné Rpitx (trop de difficulté a construire une trame propre), pour passer sur ton code.
Tu indique de l'injecter sur un RFlink, peux tu détailler un peu, car RFlink est une plateforme fermé donc non modifiable.
J'ai vu que Etimou a repris les sources et réécrit une partie, par contre Somfy RTS n'est pas géré et je ne vois pas comment y integrer ton code.

J'ai du coup intégrer ton code directement sur un ESP-12e et il fonctionne très bien.
Mais je me casse la tête pour pouvoir envoyer mes commandes par le port serie
J'ai testé stty, miniterm, screen, j'arrive à envoyer la commande à la main, mais pas en script en passant un parametre afin de l'intégrer à ma solution domotique.

svp aidé moi c'est un pb de retour chariot
Je cherche juste un ligne de commande pour envoyer la trame

miniterm /dev/ttyUSB0 57600 -e --eol CRLF
ERS 3 30

Merci

christopheHD a écrit : 06 déc. 2020, 17:54 En vrai, mon setup marche très bien en réception de trame mais n'a fonctionné qu'une seule fois en émission.

@etimou, tu avais raison pour le bitstuffing,, en le retirant, cela fonctionne très bien. Pour ceux intéressés par le code pour retirer le bistuffing, vous le trouverez ici :
https://github.com/ChristopheHD/frisque ... a2c57dee32