Bonjour à tous,
Je suis tellement intéressé par ce sujet que je l’ai inclus dans ma routine du matin.
J’ouvre donc tous les matin le forum plein d’espoir.
Et je part au travail plein de désespoir depuis 27 jours ! 
Y’a t’il un blocage qui fait tomber ce projet à l’eau?
Peut on faire quelque chose? ( appart attendre 
)
Merci pour le travail déjà accompli et je vous souhaite à tous une excellente journée !
Hello !
Désolé pour le manque de nouvelles, avec @jnilo on a avancé en sous-marins. On a eu pas mal de soucis autour de rtl_433 et de clés SDR qui empêchaient la capture, mais globalement, ça devrait être bon de ce coté, on pourra avoir des captures de trames d’une installation complète.
Je pense soumettre une PR sur rtl_433 pour ajouter le protocole de frisquet pour pouvoir les faire remonter dedans.
Sur un autre sujet, je vais lancer la fabrication d’un prototype de carte pour émettre sur le réseau de la chaudière :
J’ai fait quelque essais sur ma chaudière, je confirme avoir réussi à lui envoyer l’ordre de changement de consigne et lui donner une température arbitraire, ordre qu’elle prend sans broncher. Je l’ai fait en répétant une trame enregistrée sur mon réseau…
Autre point intéressant, le satellite continue d’envoyer les informations et ne semble pas être gêné par l’ordre intercalaire.
La suite en quelques mots:
Merci pour ces nouvelles encourageantes. Comment pouvons nous aider ? J’ai déjà déchiffré des valeurs initialisation dans des protocoles propriétaires par le passé. Pouvez vous mettre à disposition des données brutes pour qu’on puisse mutualiser les travaux ?
Pour les données brutes, le souci, c’est qu’il faut que je fasse un programme qui envoie sur le RFM63 des payloads aléatoires avec des tailles croissantes, de 0 à 63, mais j’ai des soucis avec mon driver, la fin de la transmission fait n’importe quoi… J’attends de recevoir les PCB pour souder une deuxieme carte et faire un test avec deux RFM63 pour verifier si le bug vient de rtl_433 ou du driver (j’ai des présomptions sur le driver quand meme !)
Hello
Quelques nouvelles.
Je crois que je vais attendre d’avoir deux cartes à base de RFM63 pour faire des essais de transmissions et mettre de coté tout problème lié à rtl_433, on dirait que dès que j’envoie plus de 60 octets dans une payload, il y a des choses bizarres qui se passent…
Je m’explique:
model : sx1211 network_id: 12345678 size : 59 to : 3f from : 00 payload : 3b3f000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f30313233343536373839 crc : 3362
Exemple KO (60 octets):
model : sx1211 network_id: 12345678 size : 60 to : 3f from : 00 payload : 3c3f000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637383933 crc : 6333
Le 33 final devrait être un 3a… Et si je fais des stats sur les payloads de 63 d’une installation, je retrouve souvent pour les 4 derniers octet :
33, 66, XX, 30, avec XX qui varie entre deux valeurs… Et avec mes payloads, je retrouve quelque chose du même type, XX est modifié mais le reste est constant.
J’ignore si c’est un bug dans rtl_433 ou dans le chipset sx1211 / rfm 63 qui change de comportement passé 60 octets (typiquement, on pourrait imaginer qu’il rentre dans un mode de resynchronisation de l’horloge après un nombre de millisecondes passé à émettre trop important…)
Comme je reçois d’ici 10j les pcb pour souder le rfm63, je vais attendre pour faire des tests entre deux rfm63, un en réception et l’autre en émission et comparaison des résultats.
Sinon, grâce à @jnilo , je pense qu’on a réussi à decoder le protocole radio de la sonde extérieure, et coup de chance, les payload sont inférieures à 60 octets. Il reste à récupérer la procédure d’association et on devrait être en mesure d’envoyer les températures extérieures à partir d’une sonde externe sous peu 
Sacré avancé et merci pour le partage régulier, c’est tellement plaisant à lire.
En tous cas bon courage pour la suite !
Je suis également très interessé par votre projet et lit chacun de vos commentaires, même si je ne saisis pas tout.
Si vous avez besoin de quelque chose, je peux aider à récolter des données de mon côté, je n’ai qu’une chaudière Frisquet avec satellite, pas de sonde extérieure ni de Frisquet Connect
Hello !
Merci 
Par rapport à la récolte de données, comme je l’expliquais, je capte 6 installations « basique » (avec seulement un satellite) autour de chez moi, donc de ce point de vue, on est bon !
Je suis sur l’écriture du firmware pour la carte d’émission / réception à partir d’un topic MQTT, toujours en attente des PCB (qui sont désormais en belgique).
Avec le prototype fonctionnel du firmware, je tenterai une association de sonde extérieure, grâce à @jnilo on a décodé une grosse partie du protocole !
Salut et merci pour le boulot !
Je dispose d’une frisquet visio avec deux satellites et une sonde extérieure mais qui sauf erreurs est filaire chez moi.
J’ai également du matos SDR si vous avez besoin mais a priori vous avez déjà ce qu’il faut.
Quel est le comportement quand vous modifier une consigne via la modification d’une trame?
La consigne change sur la chaudière et sur le satellite ?
Le satellite ne va pas re écraser la consigne?
Sauf erreur le top serait d’avoir les trames du frisquet connect…
Bonjour,
Sujet au combien passionnant.
Tout ceci dépasse de loin mes compétences, néanmoins si je peux apporter ma pierre à l’édifice en fournissant une aide matérielle, ça peut se discuter.
Bon courage et merci pour le travail et les explications fournies.
Hello,
Quelques nouvelles !
J’ai reçu les PCBs, mais je me suis raté dans l’empreinte du rfm63… C’est soudable, mais j’ai peur de pas pouvoir le dessouder si je le fais, je vais donc refaire un batch…
J’ai aussi passé pas mal de temps sur le firmware de la partie radio dont l’objectif est de faire une passerelle entre le MQTT et la partie radio frisquet. J’ai finalement réussi, je suis en teste d’écoute sur mon réseau de chaudière depuis plusieurs jours, la stabilité est enfin au rendez-vous 
Je m’intéresse maintenant aux outils pour manipuler des octets dans un langage de haut-niveau. Je connais tous les outils pour la JVM, mais le choix me parait peu pertinent dans la communauté domotique, donc je cherche des alternatives en nodejs ou autre (j’ai envie de faire un petit projet en rust 
)
Voila, j’ai un peu le regret de dire que ce sera pour la prochaine période de chauffe 
Grosse nouvelle aujourd’hui !
Après m’être battu avec plusieurs libs rust de parsing binaire (nom) pour me rendre compte après avoir implémenté le parseur que celui-ci n’était pas réversible (donc pas possible d’encoder une valeur u_u… - raison pour laquelle je ne suis pas parti sur kaitai struct 
), j’ai réussi à utiliser deku qui permet de faire l’encoding et le decoding d’un message.
Et donc… j’ai réussi une association ! Sans paramétrage particulier nécessitant des clés SDR ou autre. De la même façon que ferait la vraie sonde extérieure
J’ai fait un programme en rust donc, qui se contente de « reproduire » le dialogue de la chaudière, mais à partir de trames que je génère de « zero »
// metadata = le header présent dans chaque requete, là, je réutilise les metadata de l'association, par "flemme"
sendData(
cli, // le client MQTT
32, // from
128, // to
metadata.request_id, // request_id présent dans la trame de la chaudière
metadata.req_or_answer + 0x80, // +0x80 en cas de réponse
metadata.msg_type, // le type du message en provenance de la chaudière
SondePayload::SondeTemperatureMessage {
data: [156, 84, 0, 4, 160, 41, 0, 1,2], // des données qui semblent fixes
temperature: 130 // la température exterieure, * 10
}
);
Et au niveau des logs :
send: FrisquetMetadata { length: 17, to_addr: 128, from_addr: 32, request_id: 3612, req_or_answer: 1, msg_type: 23 }, SondeTemperatureMessage { data: [156, 84, 0, 4, 160, 41, 0, 1, 2], temperature: 120 }, payload: "1180200e1c01179c540004a0290001020078"
Received: FrisquetMetadata { length: 15, to_addr: 32, from_addr: 128, request_id: 3612, req_or_answer: 129, msg_type: 23 } data: ChaudiereSondeResponseMessage { unknown_start: 8, year: 35, month: 4, day: 37, hour: 33, minute: 34, second: 68, data: [8, 2] }
Et pour l’exemple, le codec deku des messages de la sonde de temperature ressemble à ça:
#[derive(Debug, PartialEq, DekuRead, DekuWrite)]
#[deku(ctx = "length: u8", id = "length")]
pub enum SondePayload {
#[deku(id = "17")]
SondeTemperatureMessage {
data: [u8; 9],
#[deku(endian = "big")]
temperature: i16,
},
#[deku(id_pat = "_")]
SondeUnknownMessage {
#[deku(count = "length - 6")]
data: Vec<u8>,
},
}
J’ai donc testé sur ma chaudière et bingo, j’ai maintenant une sonde exterieure, et la température varie vite par chez moi 
Je vais continuer de tester la stabilité et des essais en cas d’échec du programme type: est-ce que je perds le chauffage si la chaudière ne reçoit plus les informations de sonde externe ?
A+
Je me répète mais merci pour le partage de ton aventure et super bon boulot ! Ça risque servir à certain !
Merci beaucoup pour votre travail. Des news sur la suite du projet ?
Hello,
Pas de grosse progression depuis la dernière fois, j’ai juste refait fonctionner mon firmware avec un ESP32C3 qui est compatible rust. Donc ca m’a permis d’adapter le PCB à l’ESP8266 et à l’ESP32C3.
C’est un peu du bricolage, mais ca sera mieux que mon plat de spaghetti sur plaque d’essai actuel
J’ai fait fabriquer le PCB chez JLCPCB, je devrais les recevoir dans la semaine, et après, il faudra que je soude les composants. Une fois cette étape effectuée, je pense m’inspirer de ce sujet pour intégrer le binding de la température extérieure sur la chaudière.
D’ailleurs, si vous avez des idées pour configurer les choses, je suis preneur. Mon idée était de configurer « quelque part » (je ne me suis jamais plongé dans les entrailles de home-assistant) le fait que à chaque changement de température (via une sonde extérieure ou via le plugin meteofrance), l’info soit transmise à l’entité chaudière.
Idéalement, j’aurais aimé une configuration depuis le firmware que je suis en train d’écrire pour donner le nom du topic MQTT à surveiller, et que mon firmware fasse un peu sa tambouille pour se connecter. J’ai l’impression que c’est la philosophie derrière nodered, que tout est envoyé dans MQTT et qu’après on travaille sur des topics, mais pas certain.
Bref, ça avance, et ça devrait être prêt pour la prochaine période de chauffage ^^
Bonjour @mgre ,
a tu avancé sur ton projet? Envisage tu l’implémentation de commande Friquet Connect avec ton module?
Merci pour ton retour.
Hello,
Je suis dans la phase de « fiabilisation ». J’ignore pourquoi, mon module frisquet <> MQTT plante au bout d’une période de temps difficile à identifier (entre 15 jours et 3 semaines, je pense)
J’ai branché le module avec le port série pendant plusieurs semaines, et en revenant de vacances, il ne propage plus les informations.
D’après les tests que j’ai pu faire, on dirait que c’est mon interaction avec le SX1211 qui plante, mais ce genre de chipset est sensé être capable de rester en écoute ad-vitam (puisque c’est ainsi que fonctionne la chaudière…)
Je m’étais mis en contrainte de toujours écouter le réseau de la chaudière, mais ce n’est pas forcement nécessaire pour les cas d’usage comme un satellite d’ambiance ou une sonde extérieure. Sinon,
je sais qu’il existe une possibilité de réinitialisation du chipset radio, je vais peut-être ajouter un « reboot préventif » toutes les 24h
Pour les tests, j’ai monté un panneau de chaudière d’occasion pour éviter d’abimer quelque chose sur le
mien qui est compatible frisquet connect, je vais aussi remettre mon original.
L’implémentation du protocole frisquet connect serait l’idéal (notamment la possibilité de changer les programmation des satellites), malheureusement, je n’ai pas le matériel (et quand il y en a sur le bon coin, ils partent vraiment vite…) et je ne suis pas pret à mettre le tarif demandé pour cette solution qui semble vraiment très limitée.
Les tests qu’on avait entrepris avec @jnilo ne m’ont pas permis de comprendre comment le frisquet connect fonctionne 
Déjà merci pour le travail accompli !
J’ai quelques question pour toi,
est ce que dans l’état actuel du développement, le système permet :
Concernant le matériel nécessaire, sachant le potentiel gain monétaire d’avoir cet intégration, je suis prêt a participer au financement (et je ne pense pas être le seul) si cela te permet de débloquer la situation.
Cdlt.
Je confirme que je suis prêt aussi à participer au financement et aux tests pour faire avancer ce projet, ça fait tellement longtemps que je voudrais exploiter correctement ma chaudière et sans système Frisquet hors de prix et limité.
Bonjour @mgre,
es-ce que tu à progressé depuis la dernière fois?
vraiment dommage qu’il n’existe pas une API locale pour le box frisquet.
