Nouveau plugin Tydom

Tydom 1.0 également. Un plantage tous les trois mois… C’est normal ? C’est un systéme pro qui, par principe ne devrait pas planter sans raisons techniques avérées, par contre je ne sais si cela vient de la Tydom ou de Jeedore et avec le principe de perte des Id, on est dans les choux pour relancer…
Je confirme, pour ma part, les deux plugs ne tournent pas ensemble. Le lancement de Tydom met en erreur le demon de jeedore. Reboot de la tydom 1.0 et ça repart aprés arret du nouveau plug Tydom.
@tuxgasy continuez votre bon boulot, je reviendrais un peu plus tard car je suis persuadé que cela va fonctionner parfaitement.
@+

J’ai ajouté les bouton on/off. Je me le note pour plus tard pour le toggle.
Tu me confirmes que les actions marchent ?

Je pense que c’est une limitation au niveau de la box Tydom qui coupe les connexions sans raison.
Je t’avoue qu’avec ce module, je cherche encore à gérer cela mais je ne parviens pas à reproduire le problème.
Sinon, le module Jeedore fonctionnait très bien chez moi mais j’ai peur que ça ne marche plus du jour au lendemain sans pouvoir debugger/corriger le problème. Je suis très dépendant avec mon chauffage.

1 « J'aime »

Le problème des id perdus, quelqu’un peut m’expliquer précisément ? Je n’ai pas encore eu le problème, mais je pense que si ce sont les id dans jeedom, un petit scénario devrait pouvoir régler le soucis quand ça arrive…

c bon on et off fonctionnent bien ainsi que le set level

@Tonybot77 @RGLD @scanab je viens d’ajouter le support de volet.

manque les commande monté descente stop favori 1 favori 2

1 « J'aime »

Qu’est ce qui fut faire pour remonter les commandes?

mise a jour et synchro

Hum! Je ne vois pas comment faire ces actions. Tu peux me dire le logicalID de la commande dans Jeedore ?

Les commandes infos sont créées lors que le Tydom remonte les valeurs. Les commandes actions sont « devinés » selon le type d’infos.
Tydom n’envoie aucun détails (sauf pour le type consommation).

1 « J'aime »

pour les volets :

  • setModeAsso123456789#123456789 : action other
  • setPosition123456789#123456789 : action slider
  • setPositionCmdDown123456789#123456789 : action other
  • setPositionCmdFavorit1123456789#123456789 : action other
  • setPositionCmdFavorit2123456789#123456789 : action other
  • setPositionCmdStop123456789#123456789 : action other
  • setPositionCmdUp123456789#123456789 : action other
  • setRecFav1123456789#123456789 : action other
  • setRecFav2123456789#123456789 : action other
1 « J'aime »

J’ai ajouté les boutons up/down/stop/favorit1 et 2. La base de fonctionnement semble identique. À tester.

1 « J'aime »

Pourquoi pas les autres commandes des volets ?
As tu besoin aussi de la liste des commandes pour l’alarme ?

Tu veux parler des setModeAsso et setRecFav ? Si oui, je ne suis pas sûr de la requête à envoyer à Tydom. On peut tester un truc si ça t’intéresse.
Sinon, le reste des actions fonctionne ?

Je te dirai quand je travaillerai sur cette partie (il semble qu’il faut une paramètre supplémentaire pour ça, il faut donc que je regarde en détail comment ça fonctionne dans tydom2mqtt).

J’ai testé les commandes de volets, ça semble bien fonctionner.

Je t’ai fait un petit PR, car les commandes infos était systématiquement réinitialisées si l’utilisateur les avait customisés

Je pense qu’il faudrait faire un système de paramétrage d’équipement sous forme de fichiers json par types d’équipements qui contiendrait le paramétrage par défaut à utiliser à la création. Ca éviterai toute la liste de if qui fait la création des équipements et faciliterai les ajouts futurs. Je ne pense pas avoir le temps de m’y pencher avant la semaine prochaine, mais si je peux, je te ferai une PR

Un exemple de fichier json de configuration d’équipement (je me suis inspiré de ce qui se fait sur le plugin zigbee) :

belmDoor.belmDoor.json ({first_usage}.{last_usage}.json)

{
   "name":"Capteur d'ouverture de porte",
   "generic_type":"Opening",
   "configuration":{
      "battery_type":"1x3V CR2032"
   },
   "commands":{
      "intrusionDetect":{
         "name":"Etat",
         "type":"info",
         "subtype":"binary",
         "generic_type":"OPENING",
         "isVisible":1,
         "isHistorized":1,
         "logicalId":"intrusionDetect",
         "template":{
            "dashboard":"core::timeDoor",
            "mobile":"core::timeDoor"
         }
      },
      "autoProtect":{
         "name":"Auto protection",
         "type":"info",
         "subtype":"binary",
         "isVisible":1,
         "isHistorized":1,
         "logicalId":"autoProtect"
      },
      "battDefect":{
         "name":"Batterie",
         "type":"info",
         "subtype":"binary",
         "isVisible":0,
         "isHistorized":0,
         "logicalId":"battDefect"
      },
      "config":{
         "name":"Config",
         "type":"info",
         "subtype":"string",
         "isVisible":0,
         "isHistorized":0,
         "logicalId":"config"
      }
   }
}

Il faudra ajouter les commandes action dans le même style…

[edit] j’ai finalement complété ma MR avec le début du code d’initialisation des devices. J’y ai mis 2 fichiers json d’exemple pour les PIR et les capteurs d’ouverture de porte. J’ai géré les commandes info, il faut faire le même système sur les commandes action.
Ça va simplifier énormément ton code je pense, il faudra faire du ménage après.
Comme je t’ai dit, pas le temps de m’en occuper ce we, mais je pense que ce que j’ai poussé est déjà bien fonctionnel et permettra à chacun de contribuer avec ses propres devices.

une autre amélioration à faire : capter l’'info ‹ battDefect › pour alimenter le mécanisme de batterie de jeedom

@scanab Super idée !!! Je commençais à me poser la question car je sentais que ça allais devenir un bordel monstre avec les if dans tous les sens.

Je vais étudier ton PR. Merci.

Bonjour,
J’ai profité d’une plantade de plus de la Tydom pour repatir à zéro avec ce nouveau plugin.
Verification faite avec le téléphone, les équipements ne sont pas perdu, donc on active le démon, synchronisation et les équipements apparaissent.
En se penchant sur ceux ci je note que pour certains capteurs boilers,( je rappelle que mon équipement utilise 4 capteurs pour commander les trappes de soufflage de la clim) il manque certains postes et particuliérement les « set ». en regardant de plus prét j’ai modifié jeeTydom.php du core pour ajouter le fonction « set_autorization » qui pour moi était importante car c’est la commande du mode ‹ chaud,froid,arret. › les autres commandes sont totalement inconnus pour leur utilisation; je n’ai donc rien modifié.Je relance, tout va bien la fonction est crée. On continu la découverte et l’étude du fonctionnement. Pour la commande de la Calybox 1020WT, toutes les commandes set sont absentes, y compris ‹ set_hvacode › qui pourtant est importante, l’indicateur de température est par défaut en ‹ autre ›, pas grave on passe en numérique mais impossible de lui faire accepter le nombre de décimale et l’ajout de l’unité (c°) dans tous les cas, en cas d’une nouvelle synchronisation, tout repart par défaut… Ce probléme concerne d’ailleurs tous les équipements et c’est particuliérement ennuyeux quand l’on a changé les libellés par des textes plus lisible en utilisation courante. J’ai également rencontré le probléme sur l’equipement « Conso » qui pour l’instant reste stable malgré quelques disparitions inquiétantes mais qui revenaient toutes seules.
Conclusions…Bravo, cela fonctionne malgré quelques défauts de jeunesse surtout que Tydom n’est pas des plus simple dans son fonctionnement. Je n’a malheureusement pas les compétences necessaires pour vous aider au développement si ce n’est faire remonter mes constations, mais reste volontier à dispo pour aider en surveillant dans le temps la stabilité.et/ou les améliorations qui pourraient être apportées. Je n’ai pas l’alarme ni de volets roulants qui semblent pourtant être des postes d’intérets.Désolé.
@+,