Forum Domoticz en français

Alors je viens de refaire tout une série de test pour vérifier... Et je suis un peu perplexe. J'avais bien testé en supprimant tout les scripts, et je restais très haut en CPU... Mais là je viens de refaire le test, et en supprimant les scripts, le CPU redescend... Donc est ce que je me suis planté sur mes premiers tests, ou est ce dû à une mise à jour que j'ai fait depuis, je ne sais pas... En tout cas, à ce matin, quand je supprime tout mes scripts, mon RPI redescend aux alentours des 25%... Donc à priori je ne suis plus tout à fait dans le même cas que toi... désolé

Pourtant il ne me semble pas avoir un nombre de scripts si élevé que ça (16)... Et en les remettants en place petit à petit, mon CPU augmente avec des scripts qui ont comme condition le passage à "On" d'un interrupteur... donc à priori pas de raison que ça provoque un changement si important au niveau CPU tant que je n'appuie pas sur le switch...

les scripts device sont tous lancés dès qu'un device est mis à jour, et ça peut très très vite être non stop.

essai un script_device_test.lua avec ce contenu tu vas voir à quel point c'est fréquent.
ici ça peut aller jusqu'à 6 fois par seconde !

donc suivant la complexité des scripts, ça peut très nettement faire monter la charge CPU
sinon pas besoin de supprimer les scripts pour tester, simplement leur extension suffit.
ex: renommes script_device_test.lua en script_device_test

Pour eviter que tous les scripts se relancent , il a été souvent évoqué le fait de tous les regrouper en un seul gros plutot que x petits

je ne pense pas que ce soit le nombre le problème..mais ça se tente..

Bonsoir
Une solution: le Raspberry pi2. Ça ne résout pas le problème mais ça donne une bonne marge de capacité CPU.

@vil1driver : J'avais effectivement déjà fait le test, et constaté la fréquence élevée de lancement des scripts LUA... Sinon, quand je parlais de supprimer c'était plus dans le sens de supprimer des scripts actifs donc soit par renommage effectivement, soit en les déplaçant tous dans un répertoire temp pour avoir un répertoire LUA complétement vide...

@Jihem:ah ça pourrait être une solution de contournement... mais c'est dommage je n'ai mon Rpi que depuis 6 mois

En tout cas c'est dommage que Domoticz sature assez rapidement le raspberry... Je vais refaire une passe sur mes scripts, mais il ne me semblait pas avoir mis des choses si complexes que ça, et j'ai déjà vu des nombres de scripts beaucoup plus élevés... Après je ne sais pas si c'était sur des RPI. Peut être qu'il vaut mieux être sur PC ou Mac pour pleinement utiliser Domoticz. Je pense que je vais commencer à regarder les autres solutions de portail domotique... c'est dommage, Domoticz était vraiment sympa à utiliser...

Mais pour finir, nous nous éloignons du problème de JC38 qui est un peu différent, puisque même sans scripts son CPU reste proche de 100%...

Jihem a écrit :Bonsoir
Une solution: le Raspberry pi2. Ça ne résout pas le problème mais ça donne une bonne marge de capacité CPU.

Je ne pense pas qu'en changeant de machine, ça réglera le problème
N'importe quel processus, s'il fait une boucle, consommera 100% d'une CPU, quelle que soit la puissance de cette CPU
Le trompe l'oeil, ce serait les cores multiples...

Mais la seule véritable solution, c'est corriger Domoticz pour ne plus avoir de boucle !

Bonjour
Pour info et comparaison .
Avec un rasp B+,
6 scripts Lua, 4 blocky, 5/6 periph zwave, 6/7 rfxcom, des crontab de mise a jour de widgets
Et je ne depasse pas 65%
My 2 cts

Bonsoir,

J'ai fait un test avec un Rpi 2 avec la même image pour être vraiment dans une comparaison parfaite. Le taux de Cpu s'effondre de manière très significative avec cette version du Rpi.
A mon avis, on est dans la limite avec le Rpi B ou alors ils ont introduit un code bancal avec le support des Rpi2.
J'invite les âmes de bonne volonté à faire 2 tests :
- comparer l'occupation du CPU avec et sans l'Eventlog activé.
- faire la mise à jour full de leur distri pour la rendre compatible Arm7 et tester le taux d'occupation du Cpu dans les 2 cas.

Quoiqu'il en soit, pensez à faire des backup.

Voici le résultat d'une migration de Raspberry B vers Raspberry B 2.
J'ai seulement fait l'image de la SD vers une microSD