Forum Domoticz en français

Bonjour à tous,

J'essaie de "domotiser" ma petite maison et effectue actuellement des tests. Mon premier problème est le suivant : lorsque j'appuie sur un interrupteur chez moi, la lumière met du temps à s'allumer ET à s'éteindre. On parle d'environ 1 à 1.5 seconde.
Sur les forums Domoticz officiels, mon problème ne passionne pas les foules : https://www.domoticz.com/forum/viewtopi ... 19&p=83658

J'ai tenté de faire le tour des responsables potentiels :
- Mon interrupteur Chacon 54700, communicant en 433Mhz avec un RFXcom
- Mon interrupteur NodOn CMS-3-1-01 communicant en ZWave avec une clé Aeon Labs
- Mes lampes
- La machine host
(tl;dr : aucun de ces éléments n'est en cause, cf. ci-dessous)

Il en ressort que le signal envoyé par le Chacon met environ 300ms avant d'être loggé côté machine, celui du NodOn met environ 100ms. Il reste encore une longue seconde de traitement non imputable à ces appareils.
Mes lampes, elles, s'allument absolument instantanément lorsqu'on envoie un signal à la passerelle (LimitlessLED) en HTTP, je les ai donc éliminées de l'équation.

Côté machines : mon contrôleur domotique est une machine peu puissante, avec un petit APU AMD quad core et 8 Go de RAM, sous Debian.
Pensant que cela pouvait venir de ses performances minimales, j'ai fait l'essai avec une machine sous Windows avec la dernière version de Domoticz, équipée d'un Core i7 et 32 Go de RAM: j'obtiens les mêmes délais!

Voilà ce qui se passe côté Domoticz: Lorsque j'appuie sur mon interrupteur (ZWave ou RF433, peu importe), un petit délai (100 à 300ms) s'écoule car l'interrupteur à piles sort de veille. A partir du moment où le signal est reçu par l'ordinateur et qu'il est loggé par Domoticz (1) on pourrait penser que l'action liée à l'interrupteur va être instantanée... Mais non, comme vous pouvez le constater ligne (2), 900ms s'écoulent, pendant lesquelles rien ne se passe.

Pensant qu'un process complexe pourrait peut-être avoir lieu (lié à une lib ZWave ou RF433, pourquoi pas ?) au coeur de Domoticz mais sans que le log soit trop verbeux, j'ai donc simplifié au maximum : j'ai retiré mes interrupteurs de l'équation pour rester à 100% dans Domoticz, sans hardware extérieur. J'ai donc créé un interrupteur virtuel, qui lors d'un clic exécute une action :

- Allumer une lumière en ZWave : 1 seconde, la lampe s'allume instantanément après que Domoticz ait décidé de déclencher l'action, le call ZWave lui dure 0.001 seconde (ligne 3) - Allumer une lumière avec un call HTTP vers une autre passerelle : 1 seconde
Pour rappel, lorsque j'effectue ce call HTTP hors Domoticz depuis la même machine, depuis une autre machine, ou par un ami à 100 km de chez moi, l'éclairage dans la maison réagit tellement vite qu'on ne perçoit aucun délai. Il s'écoule en revanche 929ms entre le moment où Domoticz perçoit le clic sur le Dummy Switch et le "Admin initiated a switch command" (ligne 2) - Appeler une commande qui renvoie "toto" en interne sur la même machine : 1 seconde, même histoire. Domoticz perçoit le clic sur le dummy switch, et ne fait rien pendant une seconde avant le début d'exécution de la commande.

Je ne sais plus quoi faire ! Quelqu'un a-t-il une idée ?

Merci par avance !

Bonjour,

J'avoue que j'ai du mal à trouver une idée concernant ton souci. Personnellement j'utilise un RaspBerry PI et je n'ai aucun souci de ce type.

As-tu d'autres choses qui tournent en parallèle sur cette machine ?

Bonjour,

Sans trop m'avancer, je vois l'origine dans la façon dont domoticz fonctionne ... lorsque une action doit en entraîner une autre dz ne le traite pas "immédiatement".

Tel que conçu, domoticz c'est une ensemble de "thread", des processus fonctionnant en parallèle (au sein de l'exécutable), chacun ayant des rôles donnés. Quand une action en entraîne une autre, c'est un traitement/processus qui détecte l'action a faire mais plutôt que de le faire dans la foulée, il l'inscrit dans une liste de "taches a faire", liste dépilée ensuite par un autre processus.

Si tu as le code source sous la main fait des recherches "sleep_..." dans le code, en particulier le répertoire main . Tu vas trouver tout un tas de sleep_milliseconds et sleep_seconds dans des boucles de traitement de threads justement. En particulier le sleep_seconds(1); du CSQLHelper::Do_Work (main/SQLHelper.cpp) doit jouer dans le cas que tu décris.

Après peut-on réduire ces sleep dans le code, ça je n'en sais rien ... je ne suis pas dans l'équipe de dev domoticz. Mais dans ton cas pourquoi pas faire le test pour voir si la raison est bien là ?

Merci pour vos réponses !

manuloup a écrit :As-tu d'autres choses qui tournent en parallèle sur cette machine ?

Sur la machine Windows oui, mais elle est relativement puissante. Sur la machine Linux : rien du tout, c'est la seule appli qui tourne, la machine n'a pas de desktop et est très réactive.

rimram31 a écrit :Si tu as le code source sous la main fait des recherches "sleep_..." dans le code, en particulier le répertoire main . Tu vas trouver tout un tas de sleep_milliseconds et sleep_seconds dans des boucles de traitement de threads justement. En particulier le sleep_seconds(1); du CSQLHelper::Do_Work (main/SQLHelper.cpp) doit jouer dans le cas que tu décris.?

Ça me fait une bonne piste à suivre ! Je comprends bien qu'il y ait des contraintes dans la gestion des threads, mais n'ayant jamais mis le nez dans la source de Domoticz et ne sachant pas trop où regarder...

Je vais essayer ça et je vous tiens au courant

Merci encore !

Ça fonctionne !

Merci beaucoup, je n'aurai sûrement jamais trouvé tout seul. Je ne sais pas dans quelle mesure cela pourra avoir un impact négatif ou non sur l'ensemble de l'appli, mais j'ai modifié le sleep_seconds(1) par un sleep_milliseconds(100), recompilé...
Ça marche du tonnerre, je vais laisser tourner un peu et j'ajusterai la valeur si besoin.

Big thanks

Morveus a écrit :Ça fonctionne !
...

Excellent, je m'étais perdu par là bas dans le code pour comprendre le fonctionnement des appels des scripts lua, gestion du commandArray FOR/AFTER ( ) ... Sur l'implémentation de dz, dommage qu'il n'y ait pas quelques synchros pour éviter des sleeps a ne vraiment rien faire ...

Morveus a écrit :Ça fonctionne !

Merci beaucoup, je n'aurai sûrement jamais trouvé tout seul. Je ne sais pas dans quelle mesure cela pourra avoir un impact négatif ou non sur l'ensemble de l'appli, mais j'ai modifié le sleep_seconds(1) par un sleep_milliseconds(100), recompilé...
Ça marche du tonnerre, je vais laisser tourner un peu et j'ajusterai la valeur si besoin.

Big thanks

Moi j'aimerais bien essayer ! Si cela peut résoudre la cliquite des interrupteurs de madame parce que la lumière ne s'exécute pas assez vite...

Tu as modifier quelle ligne de quels fichier stp ?

@deennoo, il n'y a qu'une fois un sleep_seconds(1)
Et la ligne est commentée, tu ne peux pas te tromper
ctrl+f pour la trouver.

Ici c'est très réactif via l'interface web ou json..
Si mon clic sur l'inter est intercepté par un script puis envoyé vers ma prise, j'ai aussi cette seconde de delai..

J'avais mis cela sur le compte du rfxcom qui attends un silence radio pour envoyer son ordre.. Mon inter envoyant certainement plusieurs ordres à la suite (pratique plutôt courante).

Par curiosité j'ai tout de même tenté la modification cité plus haut.
Aucune différence.

on en parle également chez les anglais
http://www.domoticz.com/forum/viewtopic ... 4559a8b649

vil1driver a écrit :@deennoo, il n'y a qu'une fois un sleep_second(1)
Et la ligne est commentée, tu ne peux pas te tromper...

??? 2 fois une seconde de sleep dans Scheduler et SQLHelper, celui qu'a a priori changé Morveus, Do_Work de SQLHelper qui semble traiter les "tasks" en attente, comme les commandes (commandArray) des scripts par ex.
Je n'ai pas épluché tout le code et je ne sais pas tout de qui fait quoi mais je vois aussi 2 sleep de 500ms et 1 de 300 dans la mainworker, au bout du bout, ça peut faire du temps passé ...

@deennoo tu peux essayer de remplacer le sleep_seconds(1) ligne 2450 a peu près du SQLHelper.cpp dans main (https://github.com/domoticz/domoticz/bl ... Helper.cpp) par un sleep_milliseconds(100) par ex. pour voir.

Maintenant il y a peut-être une très bonne raison a cette tempo, le code source ne nous dit pas trop comment ça marche dynamiquement, seul le concepteur a les idées a peu près claires ...

oui, dans le fichier SQLHelper.cpp que tu indiquais à modifier
dans la fonction CSQLHelper::Do_Work qui n'est également présente qu'une fois..
il n'y a qu'une fois sleep_seconds(1) à la ligne 2369 (du moins en v3.4832) effectivement il faut peut être en modifier d'autres... mais ce n'est pas ce que j'ai compris du retour de Morveus..
toujours est il qu'ici aucun changement par cette méthode