MCZ Maestro et Jeedom

Là, c’est l’expérience qui me manque. Comme je l’ai déjà dis, je n’ai le poêle que depuis 1 mois et demi. Et encore, il est dans une seconde résidence à 100km où je ne vais que le weekend. Je sais donc très peu t’aider.
As tu essayé de contrôler le poêle et de faire la même opération avec l’application MCZ ?

Salut,
As-tu regardé le log du python ? Maestro.py devrait créer un log nommé activity.log
Si le programme reçoit une commande pour le poele, il devrait y avoir dans le log :
Message MQTT reçu : <le message ?>
Contenu Pile Message_MQTT : ’ <quelque chose ?>

Salut, qu’est-ce qui ne marche pas ?
Arrives tu à modifier certains paramètres depuis Jeedom ? Comme passer les sons en On ou Off ?
Est ce que dans jeedom tu as bien les mêmes dates et heures que celles dans l’appli Maestro ?

Si oui il est possible que tu as mal configuré les commandes comme ON/OFF (vérifie bien les codes à envoyer sur SUBmcz).

Si la réponse est non c’est que la communication n’est pas correctement établie entre le poêle et jeedom.

Bonjour,

Est il possible de récupérer les valeurs de l’état du poele (allumage, extinction, éteint, allumé)? Idem pour les états défectueux?

Merci

Salut,
L’info est normalement remontée

[1,« Etat du poêle »,[
[0, « Eteint »],
[1, « Controle du poele froid / chaud »],
[2, « Clean Froid »],
[3, « Load Froid »],
[4, « Start 1 Froid »],
[5, « Start 2 Froid »],
[6, « Clean Chaud »],
[7, « Load Chaud »],
[8, « Start 1 chaud »],
[9, « Start 2 chaud »],
[10, « Stabilisation »],
[11, « Puissance 1 »],
[12, « Puissance 2 »],
[13, « Puissance 3 »],
[14, « Puissance 4 »],
[15, « Puissance 5 »],
[30, « Mode diagnostique »],
[31, « Marche »],
[40, « Extinction »],
[41, « Refroidissement en cours »],
[42, « Nettoyage basse p. »],
[43, « Nettoyage haute p. »],
[44, « Débloquage vis sans fin »],
[45, « AUTO ECO »],
[46, « Standby »],
[48, « Diagnostique »],
[49, « CHARG. VIS SANS FIN »],
[50, « Erreur A01 - Allumage raté »],
[51, « Erreur A02 - Pas de flamme »],
[52, « Erreur A03 - Surchauffe du réservoir »],
[53, « Erreur A04 - Température des fumées trop haute »],
[54, « Erreur A05 - Obstruction conduit - Vent »],
[55, « Erreur A06 - Mauvais tirage »],
[56, « Erreur A09 - Défaillance sonde de fumées »],
[57, « Erreur A11 - Défaillance motoréducteur »],
[58, « Erreur A13 - Température carte mère trop haute »],
[59, « Erreur A14 - Défaut Active »],
[60, « Erreur A18 - Température d’eau trop haute »],
[61, « Erreur A19 - Défaut sonde température eau »],
[62, « Erreur A20 - Défaut sonde auxiliaire »],
[63, « Erreur A21 - Alarme pressostat »],
[64, « Erreur A22 - Défaut sonde ambiante »],
[65, « Erreur A23 - Défaut fermeture brasero »],
[66, « Erreur A12 - Panne controleur motoréducteur »],
[67, « Erreur A17 - Bourrage vis sans fin »],
[69, « Attente Alarmes securité »],
]]

Je déterre un peu mais l’arrivée de l’automne me fait revenir sur ce sujet… Pour contourner ce « problème » j’ai créé un petit scénario avec comme déclencheur l’état du poêle et à chaque changement le scénario m’envoie l’état du poêle sur télégram.

Bonjour,
Je me permet de venir ici pour déjà dire merci beaucoup pour ce tuto et ce service pour connecté mon mcz

J’ai suivi donc le tuto et tous ce passe bien jusqu’au lancement du daemon

J’ai ce message d’erreur : Job for maestro.service failed because the control process exited with error code. See « systemctl status maestro.service » and « journalctl -xe » for details.

alors que quand je fait un essai de lancement en console cela fonctionne bien et cela me remonte les infos

Un petit coup de main svp

le log de systemctl status maestro.service

maestro.service - Passerelle Equipements MCZ Maestro avec serveur MQTT
   Loaded: loaded (/etc/systemd/system/maestro.service; enabled; vendor preset:
   Active: failed (Result: exit-code) since Wed 2021-10-20 23:44:21 BST; 4min 50
  Process: 5988 ExecStart=/usr/bin/python /opt/maestro/maestro.py (code=exited,

oct. 20 23:44:21 jeedom-test systemd[1]: maestro.service: Service RestartSec=100
oct. 20 23:44:21 jeedom-test systemd[1]: maestro.service: Scheduled restart job,
oct. 20 23:44:21 jeedom-test systemd[1]: Stopped Passerelle Equipements MCZ Maes
oct. 20 23:44:21 jeedom-test systemd[1]: maestro.service: Start request repeated
oct. 20 23:44:21 jeedom-test systemd[1]: maestro.service: Failed with result 'ex
oct. 20 23:44:21 jeedom-test systemd[1]: Failed to start Passerelle Equipements
lines 1-11/11 (END)...skipping...
● maestro.service - Passerelle Equipements MCZ Maestro avec serveur MQTT
   Loaded: loaded (/etc/systemd/system/maestro.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2021-10-20 23:44:21 BST; 4min 50s ago
  Process: 5988 ExecStart=/usr/bin/python /opt/maestro/maestro.py (code=exited, status=1/FAILUR

oct. 20 23:44:21 jeedom-test systemd[1]: maestro.service: Service RestartSec=100ms expired, sch
oct. 20 23:44:21 jeedom-test systemd[1]: maestro.service: Scheduled restart job, restart counte
oct. 20 23:44:21 jeedom-test systemd[1]: Stopped Passerelle Equipements MCZ Maestro avec serveu
oct. 20 23:44:21 jeedom-test systemd[1]: maestro.service: Start request repeated too quickly.
oct. 20 23:44:21 jeedom-test systemd[1]: maestro.service: Failed with result 'exit-code'.
oct. 20 23:44:21 jeedom-test systemd[1]: Failed to start Passerelle Equipements MCZ Maestro ave`

et journalctl -xe

– L’unité (unit) maestro.service a échoué, avec le résultat failed.
oct. 20 23:45:01 jeedom-test CRON[5994]: pam_unix(cron:session): session opened for user root b
oct. 20 23:45:01 jeedom-test CRON[5993]: pam_unix(cron:session): session opened for user www-da
oct. 20 23:45:01 jeedom-test CRON[5995]: (root) CMD (/usr/bin/php /var/www/html/core/php/watchd
oct. 20 23:45:01 jeedom-test CRON[5996]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/je
oct. 20 23:45:01 jeedom-test CRON[5994]: pam_unix(cron:session): session closed for user root
oct. 20 23:45:02 jeedom-test sudo[6095]: www-data : TTY=unknown ; PWD=/var/www ; USER=root ; CO
oct. 20 23:45:02 jeedom-test sudo[6095]: pam_unix(sudo:session): session opened for user root b
oct. 20 23:45:02 jeedom-test sudo[6095]: pam_unix(sudo:session): session closed for user root
oct. 20 23:45:03 jeedom-test CRON[5993]: pam_unix(cron:session): session closed for user www-da
oct. 20 23:46:01 jeedom-test CRON[6143]: pam_unix(cron:session): session opened for user www-da
oct. 20 23:46:01 jeedom-test CRON[6144]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/je
oct. 20 23:46:02 jeedom-test CRON[6143]: pam_unix(cron:session): session closed for user www-da
oct. 20 23:47:01 jeedom-test CRON[6194]: pam_unix(cron:session): session opened for user www-da
oct. 20 23:47:01 jeedom-test CRON[6195]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/je
oct. 20 23:47:02 jeedom-test CRON[6194]: pam_unix(cron:session): session closed for user www-da
oct. 20 23:48:01 jeedom-test CRON[6245]: pam_unix(cron:session): session opened for user www-da
oct. 20 23:48:01 jeedom-test CRON[6246]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/je
oct. 20 23:48:02 jeedom-test CRON[6245]: pam_unix(cron:session): session closed for user www-da
oct. 20 23:49:01 jeedom-test CRON[6298]: pam_unix(cron:session): session opened for user www-da
oct. 20 23:49:01 jeedom-test CRON[6299]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/je
oct. 20 23:49:02 jeedom-test CRON[6298]: pam_unix(cron:session): session closed for user www-da
oct. 20 23:49:11 jeedom-test systemd[1]: Configuration file /etc/systemd/system/maestro.service

Je ne suis pas tres doué ^^

1 « J'aime »

Bonjour

Avec beaucoup de retard, merci beaucoup.
Comment faire pour obtenir ces valeurs en numérique et non en Expression. Il me remonte bien l’info mais sous format " Eteint, Extection, Refroidissement en cours…"

Bonjour, je rencontre le même problème avez vous trouvé une solution ? Cordialement

Bonsoir non malheureusement rien j’ai tout réinstaller jeedom et application rien n’y fait

Bonsoir, j’ai fini par trouver, j’avais plusieurs version de python 2.7 et 3.5, j’ai modifié pour que python3 réponde sous python puis j ai relancé l install de Socket.io.
Nb. J utilise la solution de @pipolaq https://github.com/pipolaq/maestro
J’ espère que cela pourra vous aider.
Cordialement

1 « J'aime »

Merci pour votre retour je vais testé cela

Bonjour @pipolas,

Merci pour votre code. J’ai réussi à le faire fonctionner. Je bloque juste sur ce sujet :

Pour finir, il arrive que le programme plante (communication avec les serveurs MCZ ou bug du broker MQTT). J’ai donc un scenario qui check toutes les 10 minutes la date de la dernière remontée d’information, et si celle-ci est supérieure à 4 minutes, le scenario déclenche un

systemctl restart maestro.service

Pourriez vous m’indiquer si vous gérez ceci depuis jeedom, si oui avec quel plugin lancez vous la commande ssh ? Et comment faites vous la comparaison de temps dans le scénario ?

Merci d’avance.

Cordialement

Bonjour, cette solution m’intéresse aussi pour remédier aux déconnexions !

Bonjour,

J’ai réalisé le même genre de fonction mais en me basant sur la date du poele. Elle est remontée dans les informations du poele.
J’ai le scenario suivant qui est exécuté toutes les 5 minutes. Si l’heure du poele est en retard de plus de 900 secondes (15 minutes), je lance via le plugin script la commande de restart du script python maestro.

// Recupere current time comme timestamp
$ts_curtime = time();
$curtime = date("d/m/Y H:i:s", $ts_curtime);
$scenario->setLog('=== ts_curtime: ' . $ts_curtime . ' =.=  '. $curtime);


$cmd = cmd::byString("#[Chauffage][PUBmcz][Heure]#");
$heure = $cmd->execCmd();

$cmd = cmd::byString("#[Chauffage][PUBmcz][Minute]#");
$minute = $cmd->execCmd();

$cmd = cmd::byString("#[Chauffage][PUBmcz][Annee]#");
$annee = $cmd->execCmd();

$cmd = cmd::byString("#[Chauffage][PUBmcz][Mois]#");
$mois = $cmd->execCmd();

$cmd = cmd::byString("#[Chauffage][PUBmcz][Jour]#");
$jour = $cmd->execCmd();

$ts_poele = mktime($heure, $minute, 0, $mois, $jour, $annee);
$scenario->setLog('=== ts_poele..: ' . $ts_poele . ' =.=  '. date("d/m/Y H:i:s", $ts_poele) );

if ($ts_curtime > $ts_poele) {
  if (($ts_curtime - $ts_poele) > 900) {
    $scenario->setLog('!!!!!  La mise à jour de maestro a un problème  ===>  Lancement du script de restart');    
    cmd::byString('#[Chauffage][Restart_Maestro][restart]#')->execCmd();   
  }  
}

Dans le plugin script, j’ai la commande [Chauffage][Restart_Maestro][Restart] qui contient ceci.

Le shell script restartmaestro.sh, lui contient ceci

#!/bin/bash
sudo systemctl restart maestro

Ce script doit être executable et avoir www-data comme owner et groupe.

Tout cela a très bien fonctionné pendant deux mois, jusqu’au changement d’heure.
Le poele ne change pas automatiquement heure d’été/heure d’hiver.
Pour le moment, je cherche une solution à ce problème.
(Edit)
J’ai modifié le script python pour le dialogue avec Maestro et plus précisément la fonction « on_message_mqtt »
Voici le code de cette fonction

def on_message_mqtt(client, userdata, message):
    # @@@@ fonction modifiée.
    logger.info('Message MQTT reçu : ' + str(message.payload.decode()))
    cmd = message.payload.decode().split(",")
    if (int(cmd[0])) < 9000:
        if cmd[0] == "42":
            cmd[1] = (int(cmd[1]))
        Message_MQTT.empile("C|WriteParametri|" + cmd[0] + "|" + str(cmd[1]))
        logger.info('Contenu Pile Message_MQTT : ' + str(Message_MQTT.copiepile()))
        send()
    else:
        if cmd[0] == "9001":
            order = "C|SalvaDataOra|"
        Message_MQTT.empile(str(order) + str(cmd[1]))
        logger.info('Contenu Pile Message_MQTT : ' + str(Message_MQTT.copiepile()))
        send()

Cette modification permet d’envoyer des commandes « spéciales » au poêle.
Ici, la commande 9001, qui n’existe pas dans le poêle envoie en fait la commande C|SalvaDataOra|DDMMYYYYHHmm
Je compte l’exécuter tous les jours à 3h05 pour resynchroniser l’heure du poele.

Merci beaucoup @henribi on ne peut pas faire plus clair !

Hello,

Content de voir que la communication avec les serveurs MCZ est utilisée !

La proposition de @henribi fonctionne en effet. De mon côté, j’ai rarement eu le script qui plantait, peut-être deux/trois fois lors de l’hiver dernier.
J’ai fait qqc de peut-être plus simple, car pas dépendant de l’heure du poêle :

  1. J’ai créé un scénario qui se lance toutes les 5 minutes
  2. Ce scénario vérifie si la dernière date de communication avec le poêle est supérieure à 4 minutes : #timestamp#-collectDate(#[Shellies][M Poele][PUBmcz]#,U)>240
  3. Si c’est le cas, je reçois une notification, et je relance en effet le service via le plugin « sshcommander » : systemctl restart maestro.service
  4. au bout d’une minute j’arrête le scénario qui ne s’arrête pas tout seul
  5. Je fais la même chose d’ailleurs pour ma caméra ring
1 « J'aime »

Salut Pipolas, est-ce que tu peux me dire ce qui change entre « ta programmation » et celle d’Anthony ?

Je cherche à vraiment stabiliser mon système de chauffage avec le poêle, à vrai dire avec l’installation d’Anthony et le tuto de Pierrick j’ai déjà quelque chose de pas mal…

J’ai encore quelques allumages ratés (?) et parfois des pertes de connexions avec le poêle. Je vais essayer de faire ce que vous faites pour relancer la connexion.

Salut
Un grand merci pour les tutos, après quelques temps pour bien comprendre le fonctionnement jmqtt, j’ai finis par installer le broker sur le pi déporté vers mon poêle plutôt que sur mon jeedom principal dans le garage et je rapatrie les commandes et infos via jeelink et tout fonctionne parfaitement avec mon MCZ MUSA air up :smiley:

Etant une bille en script ,pour vérifier qu’il n’y a pas de problème de perte d’info et que l’action donné par le plugin thermostat soit bien prise en compte j’ai mis un wait de 60s dans le scenario de « gestion d’allumage arrêt » pour tous les états suivant la commande lors d’un allumage ou extinction avec relance de la commande via un autre scenario « erreur » + sms si il y a échec, et si il y a 3 échecs de suite ça reboot le pi déporté. (la seule fois ou j’ai eu le souci du pi déconnecté du poêle c’était un soir venteux remplit de micro coupure de courant , les pi sont sur onduleur mais pas le poêle et le reboot du pi déporté avait suffit à tous remettre en ordre.)

Bonjour @pipolas,

J’avais le même problème de script qui ne s’arrétait pas tout seul.
Je l’ai résolu en modifiant le fichier maestro.service. J’ai passé le Type de forking en simple.
Depuis la commande systemctl restart maestro.service se termine correctement.

J’avais déjà donné l’info dans ce fil. Voici le lien MCZ Maestro et Jeedom - #245 par Mika59

2 « J'aime »