Je comprends tout à fait. Et bien cette chaîne eBus est bien plus fiable que celle du Z-Wave.
Maintenant que j’ai accès à tous les éléments de la chaudière, je me pose la question de revenir sur le matériel Vaillant pour ses têtes thermostatiques avec sondes déportées au lieu du Z-Wave où il y a toujours truc qui foire (changement de consigne non pris en compte)
Bonjour
Ma chaudière chaffoteaux gaz est HS j’ai donc parcouru ce post pour éclairer mon choix de remplacement.
J’ai un plancher chauffant et 8 tete thermostatiques de radiateur Maxcube. Le tout pilote en TOR les 2 departs chaudière ( 1 depart plancher après la vanne 3 voies ) et le depart radiateurs. Tout cela reporté sur jeedom / 2 relais sur GPIO.
Evidemment je voudrais passer en modulant via open therm. Quelle solution me proposez vous qui soit fiable.
Frisquet à l’avantage d’avoir un module plancher intégré et théoriquement un cable spécifique open therm.
Merci car je ne voudrais pas me planter.
Bonjour Domatizer,
J’ai mis chez moi une configuration similaire en me basant sur ton post:
Chaudière Vaillant EcoVit → ebus → Passerelle esera USB → rasbPi 0 W → wifi → jeedom MQTT.
Au niveau des régulateurs, comme j’ai 2 zones, j’ai un VR70 sur lequel se trouve le récepteur sans fil de la sonde extérieure, d’un multimatic VRC700f et un VR91f.
Comme c’est le VRC700f qui contrôle toutes les zones (et le VR91f ne fait que relais pour donner les informations), lui seul est détecté dans la conf (avec la chaudière et le vr70).
Tout semble bien sur le papier, je vois mes commandes avec ebusctl find -l « * » -a, certaines commandes me donne les bonnes infos et à jour, comme le nom de ma zone 1 que j’ai modifié pour les tests :
b7v z1RoomZoneMapping = VRC700
b7v z1Name1 = ZONE
b7v z1Name2 = 1 RDC
Seulement voilà, le gros gros souci c’est que tous les compteurs associés aux températures et pression de l’eau sont à 0 
b7v z1RoomTemp = 0.0
b7v WaterPressure = 0.0
b7v z1ActualRoomTempDesired = 0.0
b7v z1DayTemp = 0.0
b7v z1NightTemp = 0.0
As-tu déjà rencontré ce problème? Je ne vois pas du tout ce qui pourrait bien être mal fait. Peut être que le parsing des ces valeurs est mauvais et que du coup ça donne toujours 0 en résultat par défaut ? Je n’arrive pas à m’en sortir.
La commande pour lancer ebusd : EBUSD_OPTS="–scanconfig=full --configpath=/etc/ebusd --mqtttopic=ebusd/%circuit/%name --mqtthost=xx.xx.xx.xx --mqttport=1883 --mqttlog --mqttjson --port=8888 --accesslevel=*"
Si tu as des idées je suis preneur, merci !
Super 
Non, c’est correct ce que tu as fait. Parmi toutes les commandes, j’en ai aussi qui sont à 0, principalement pour la chaudière bai. Il me reste aussi 2 ou 3 trames non décodées. Même si john30 a fait un travail énorme sur l’ebusd, les fichiers de configuration ne sont pas parfaits. Et je ne pense pas que Vaillant nous aidera malheureusement.
Pour la pression de l’eau, il faut interroger la chaudière, c’est plutôt bai au lieu de b7v
Ensuite, comme tu as 2 zones, tu devrais avoir un certain nombre de commandes en double z1xxx et z2xxx. As-tu 0 sur les mêmes commandes des 2 zones ?
Est-ce que les noms de commandes sont corrects ? ou utilisées pour le bon organe (bai au lieu de b7v ou inversement) ?
Prends-tu en compte la température intérieure là où est installé le VRC700f ?
Chez moi, le régulateur est encastré dans la façade de la chaudière, donc il n’en tient pas compte mais je peux connaître sa valeur. C’est entre 30 et 35°C puisque ça chauffe un peu dans le corps de la chaudière.
Ensuite, il faut tâtonner un peu pour savoir qui est qui dans les différentes consignes.
Dans le régulateur VRC430, il y a :
Du coup, j’utilise la chaudière en mode Manuel et c’est Jeedom qui change automatiquement la consigne Manuelle grâce au plugin Agenda. Si je dois désactiver la domotique, je remets la chaudière en mode Auto et avec consignes fixes à 20°C sur les têtes thermostatiques et c’est comme avant .
Même bazar pour les températures entre la valeur du potentiomètre, la valeur du potentiomètre max autorisée, la valeur vraiment max de chez max, la valeur envoyée par le régulateur, la valeur finalement prise en compte par la chaudière, les valeurs réelles mesurées à différents endroits quand ça chauffe… Bref, trop de commandes !
Merci pour ta réponse détaillé.
Effectivement, je ne l’ai pas précisé, mais j’ai 0 presque partout de chez partout.
Par exemple j’ai mis la pression du VRC700f car il l’a connait (je peux la voir sur son interface), mais sur bai c’est presque pareil :
bai WaterPressure = 0.000;ok
bai WaterpressureBranchControlOff = off
bai WaterpressureMeasureCounter = 0
bai WaterpressureVariantSum = 0
Comme mes récepteurs sont sans fils, ils sont effectivement chacun dans la zone qu’ils contrôle, donc en mode « thermostat » et non dans la façade de la chaudière. Un de mes objectifs est de récupérer les consignes de chauffes et la température de la pièce pour voir le temps nécessaire pour atteindre la consigne et la conso en fonction de tous les paramètres.
J’ai effectivement du z1xxxx, z2xxxx et même z3xxxx, mais c’est bien la z1 qui m’intéresse, car contrôlé par le VRC700, comme le prouve le nom que j’ai custom ZONE 1 RDC.
J’ai également par exemple:
bai FlowTemp = 0.00;ok
bai FlowTempDesired = 0.00
bai FlowTempMax = 0.00
b7v HwcStorageTemp = 0.0
b7v HwcStorageTempBottom = -
b7v HwcStorageTempTop = -
b7v HwcTempDesired = 0.0
b7v HwcTempDesired = no data stored
b7v HwcFlowTemp = 0.0
b7v DisplayedOutsideTemp = 0
b7v OutsideTempAvg = 0.0
Ah oui, là t’as un souci. Il faut que tu regardes le fichier /var/log/ebusd.log pour voir ce qui se passe.
Ça communique car ebusd a trouvé ton matériel b7v
Sur le github, le fichier de config du VRC700F est vide
EDIT: j’avais mal vu, il pointe sur le celui du VRC700
Contrairement au VRC700
Remarque, j’ai copié en local la version ebusd-2.1.x/en/ car je voulais éviter les soucis en cas de redémarrage du RPi ou de ebusd. En effet, ebusd va chercher la dernière version des fichiers config, c’est bien mais… Si le RPi n’a pas accès au github pour une raison ou une autre ou si le github a changé (mise à jour), ebusd pourrait ne pas redémarrer correctement. Je ne veux pas de problème de mise à jour, je préfère un truc un peu obsolète mais reproductible.
Je ne sais pas quelle branche il récupère exactement sur le github car j’avais observé une légère différence (plus ou moins de commandes broadcast inconnues) entre la dernière version en ligne et celle que j’avais copiée.
Salut,
Merci d’avoir pris du temps pour m’aider.
J’ai fini par trouver la solution et si quelqu’un n’avait pas ouvert une issue pour ça je n’aurais JAMAIS trouvé.
Le problème était… la version 21 !
Voilà, avec cette version ça retourne 0 à gogo. J’ai fait un downgrade en V3.4 et maintenant j’ai absolument tout qui marche c’est génial.
Reste plus qu’à faire un beau dashboard maintenant 
Content que ça marche 
Tu parles de quelle version ?
Domatizer
Tu parles de quelle version ?
La version ebusd de John30.
Sur le github, il n’y pas de version 3.4 pour les fichiers de config !
Dans le topic ebusd/global, je vois
updatecheck version 21.2 availableversion ebusd 3.4.v3.3-51-g57eae05
Remarque, j’ai copié en local les fichiers de config ebusd (la branche « master » du github) pour éviter les problèmes de mise à jour car il prend automatiquement la dernière version en ligne.
Excuse moi si je n’est pas été assez clair, je ne parle pas de la version des fichiers de configurations, mais bien de celle du logiciel ebusd: Release Plum · john30/ebusd · GitHub
pi@raspberrypi:~ $ ebusctl i
version: ebusd 3.4.v3.3-51-g57eae05
update check: version 21.2 available
Pour les fichiers de configurations j’ai également cloné la master en local.
A quoi ressembles tes commandes GET qui permettent le refresh des données ?
J’ai bien un refresh automatique des mêmes données que toi, mais pour les autres, pour l’instant, je le fais à la main avec ebusctl, donc c’est pas top. En plus je le fais commande par commande (je ne sais pas si on ne peut pas tout faire d’un coup, mais je n’ai rien trouvé là-dessus).
J’ai rajouté quelques commandes GET pour récupérer les info qui m’intéressent en créant à la main des commandes MQTT dans l’équipement du plugin jMQTT. Pas toutes, car il y en a trop à faire.
Exemple pour la pression de l’eau
Pareil, mais on risque de saturer le bus si on fait tout tout d’un coup. Si les éléments de la chaudière ne peuvent plus communiquer entre eux à cause d’un bus saturé, c’est dangereux ! J’avais pensé soit à système qui rafraîchie de façon un peu aléatoirement les infos en tâche de fond, soit faire un curseur qui fait défiler les codes diagnostiques d.01 à d.99 et qui rafraîchie la valeur correspondante (comme si on était devant la chaudière à faire défiler les codes avec les touches + et -). La deuxième solution me parait assez élégante pour être intégrée dans un virtuel.
Mais avant, dans tous les cas, il faut se farcir la création de toutes les commandes GET dans l’équipement JMQTT. Trop fastidieux et peu d’intérêt au final !
Salut,
Merci pour l’exemple. En fait j’avais fait une petite bêtise. Pour avoir le moins de commande possible dans mon composant j’en ai créé un nouveau sans scan auto et j’ai C/C les commandes que je voulais.
Mon comme je suis en JSON, j’ai pris des « sous-commande » sans la commande parent. Et ça ça marche pas. (ex: ebuds/b7v/date{date} sans ebuds/b7v/date).
Maintenant que j’ai bien ajouté les commandes de base le /get fonctionne parfaitement.
Je vais faire le /get que sur les commandes nécessaires oui, je voudrais pas tout casser non plus.
Bon, il ne reste plus qu’à se mettre à faire un visuel sympa
