Jailbraiker sa HC2 ?

[J3R3M 107]

Bonsoir à tous,

 

Le sujet sur la volonté que Fibaro autorise la création de Fonctions Globales m'a poussé à me poser quelques questions...

Depuis le temps que la HC2 existe, n'y-a-t'il pas quelqu'un qui ait encore hacké sa HC2 dans le but de la rendre encore plus efficace?

De nombreuses personnes connaissent parfaitement la HC2, personne d'entre-vous n'a passé le cap en piratant sa HC2 afin de créer, par exemple, ses propres fonctions globales?

 

Il est certain que toutes les fonctions LUA créées par Fibaro sont créées sur un fichier qu'il doit être possible de modifier, notamment en SSH je suppose.

Si une méthode pour le faire voyait le jour, cela pourrait faciliter la vie (du moins la programmation) de beaucoup de monde!

 

N'y-a-t'il que moi qui ait l'esprit tordu à ce point?

[J3R3M 107]

Je m'auto-réponds pour le SSH, seul Fibaro connait les identifiants pour y accéder.

Mais, je serai étonné que personne n'ait tout de même détourné cela d'une manière ou d'une autre!

[Lazer 8 486]

ça n'a rien de tordu, ça fait déjà plusieurs années que les initiés le pratiquent

C'est un PC sous Linux, faire sauter le mot de passe root est à la portée de n'importe quel admin système, c'est d'ailleurs la première question de la certification Redhat... donc les tutos sur le net pleuvent (mais pas sur ce forum). C'est infiniment plus simple que rooter un Android (ou jailbreaker pour les pommés)

 

Donc oui, on peut faire ce que tu demandes, et bien plus.

 

Par contre, ça n'a plus grand intérêt depuis les firmwares 4.500, car la Debian a été remplacée par une Bluidroot, distribution prévue pour l'embarquée, avec file-system racine en lecture seule (bon ça va encore, il est facile de remonter en read-write à chaud), mais maintenant la partition est écrasée à chaque mise à jour HC2. Donc toute modif que tu fait sera perdue N fois....

Perso j'ai laissé tombé, j'ai passé 3 mois à migrer mes scripts ailleurs pour ne plus dépendre de l'accès root de la HC2. Comme ça je fais mes mises à jour sans me prendre la tête.

[J3R3M 107]

Salut @Lazer et merci de cette réponse! J'avais bien en tête qu'un Linux pouvait facilement être modifié.

Mais cette solution semble être tellement du côté obscur de la force que je n'ai même pas réussi à trouver une architecture des dossiers et fichiers de la HC2, bien qu'il puisse être "rapide" de la reconstituer une fois connecté.

Par contre, ta solution d'hébergement des scripts m'intéresse fortement (notamment parce qu'elle est pérenne)!

Cela signifie qu'à chaque mise à jour, tu réédites seulement un fichier de la HC2 en précisant où trouver les fichiers que tu as délocalisé?

Fichiers délocalisés sur un NAS ?

 

Concrètement, j'aimerais que certaines informations "fixes" de ma HC2 soient directement accessibles par les scènes et VD, sans passer par une VG encodée, afin de gagner en rapidité d'accès.

Si je peux grapiller quelques millisecondes d'attente dans le noir, ça ne serait pas de refus... J'ai pu remarquer que les FGMS mettaient souvent un peu de temps à envoyer l'info à la HC2. Cumulé à un gros tableau json encodé dans une VG, je peux attendre jusqu'à 2-3s pour l'allumage d'une lumière dans certains cas... :/

 

Rien à voir, mais je ne savais même pas qu'il y avait un mot différent pour parler de l'auto-hack d'un téléphone, en fonction de la marque!

[mprinfo 3 353]

il y a 15 minutes, Lazer a dit :

 (ou jailbreaker pour les pommés) 

 

 

[Lazer 8 486]

il y a 5 minutes, J3R3M a dit :

Cela signifie qu'à chaque mise à jour, tu réédites seulement un fichier de la HC2 en précisant où trouver les fichiers que tu as délocalisé? 

Fichiers délocalisés sur un NAS ? 

Oui c'est sur le NAS, mais attention, tu as mal compris : je n'ai plus rien sur la HC2 !

Donc pas de librairie partagée, rien du tout, mon HC2 est maintenant la même que tout le monde.

 

N'espère pas gagner un quelconque gain de performance en utilisant des librairies partagées... au contraire même, avec le temps perdu à passer les infos entre process, etc.

Le seul gain serait de simplifier la programmation, mais tu ne pourrait plus rien partager sur le forum (ça ne serait pas portable), et tu t'exposes à ce que plus rien ne fonctionne en cas de modification de l'archi de la HC2. D'ailleurs, je n'ai pas d'infos détaillées sur la HC3 (ou quel que soit son nom), mais c'est pas dit qu'on puisse y brancher un clavier/écran aussi facilement que sur la HC2 pour la rooter (hop, discrètement l'air de rien, j'ai donné 50% de la procédure)

 

Bref, je ne te conseille pas de te lancer là dedans, tu vas te créer des problèmes plus qu'autre chose....

[J3R3M 107]

En effet, je n'avais pas saisi que tout avait été déporté. C'est bien au-dessus de mes compétences et je ne m'y risquerai donc pas!

Dans mon cas, la solution la plus simple serait donc de modifier les fichiers de la HC2. Qui seront donc, à remodifier à chaque mise à jour.

Puis-je pousser le bouchon en demandant quel(s) fichier(s) serai(en)t à modifier pour que les informations soient accessibles par les scènes et VDs ?

[Nico 2 170]

Mais je ne comprends pas tes programmes, comment peux tu avoir 3s pour allumer une lumière avec un FGMS... ? Ton script vérifie quoi ?

[Lazer 8 486]

Regarde dans /opt/fibaro/FibaroSceneEnv.lua c'est là dedans que se trouvent les instructions pour brider le LUA des scènes... et donc le débrider

Pour les modules virtuels, tu ne pourras rien faire, car le moteur LUA est plus ancien, et compilé avec l'exécutable. Donc bien pourri et non évolutif.

 

Comme NIco, je pense que tu as plutôt un gros gros souci dans la logique de tes scénarios là.

[J3R3M 107]

Pour détecter les mouvements, j'utilise des FGMS et des caméras. Tous les mouvements démarrent le même script et la première vérification de celui-ci est de retrouver à quelle pièce est associée son trigger.

C'est souvent assez rapide (de l'ordre d'une seconde), mais j'ai remarqué que lorsque le trigger était une caméra, l'allumage était plus rapide.

Quelques fois, la HC2 donne l'impression d'avoir besoin de se remettre en jambe et met un peu plus de temps à allumer une lumière, du moins c'est ce qu'on pourrait se dire.

Je ne m'aide pas en utilisant que des ampoules Hue, ce qui signifie que tout passe par le Pont Hue puis par le Wifi, ce qui n'aide vraiment pas à gagner du temps.

 

Mais il est vrai que des fois, je me rends vraiment compte de la lenteur d'exécution d'un script, je suis capable de le décomposer : Relais du Wall Plug qui s'enclenche avec une lumière qui s'allume 1 seconde plus tard, par exemple.

Je précise quand même qu'une lumière peut parfois mettre 3s à s'allumer, quand elle s'allumera quasiment instantanément 10mn après, dans les mêmes conditions.

 

Mon script est sans cesse modifié en ce moment, mais actuellement, voici ce qu'il fait (238 lignes) :

Citation

 

- Reformation du tableau json stocké dans une VG. Ce tableau contient toutes les infos de mes pièces

- Recherche de la pièce associée au trigger

- Démarrage d'une scène Anti-intrusion indépendante s'il n'y avait personne dans le domicile auparavant

- Mise à jour de la VG Pièce Active (Pièce dans laquelle le dernier mouvement a été détecté) via le VD associé

- Fonction (luminosite()) de vérification s'il y a besoin de lumière en fonction de la luminosité de la pièce ou si le soleil est couché pour les caméras

- Deux petites fonctions qui convertissent le "Moment de la journée" en d'autres informations, afin d'être traitées différemment dans d'autres fonctions

- Fonction qui vérifie si les lumières de la pièce sont déjà allumées ou non

- Fonction qui renvoie l'ID du bouton du VD à appuyer pour allumer la lumière, en fonction de celle-ci

- Fonction allumage (LightsOn()) de la lumière :

   * Vérification de la valeur de la VG DODO et depuis combien de temps elle est dans cet état.

   * Vérification de la nécessité d'allumer la lumière en appelant la fonction luminosite()

   * Faut-il allumer toutes les ampoules de la pièce ou pas ? Sinon, action envoyée par ampoule (sert surtout la nuit)

- Fonction Sonos :

   *  Vérification si la VG FollowSonos est sur 1

   * On parcourt les IDs des VDs Sonos

   * On vérifie si le volume actuel de ceux-ci sont au minimum au niveau prévu

   * On augmente au niveau prévu si nécessaire

- Fonction Volets Roulants :

   * On vérifie qu'il y ait des volets roulants dans la pièce

   * On boucle pour mettre ID sur la valeur VALEUR

 

- Si je suis absent ou si le mode DODO est actif, on enregistre les caméras (Syno) après avoir vérifié qu'elles n'enregistraient pas déjà

- Execution de la Fonction Sonos

- Execution de la Fonction Volets Roulants après avoir vérifié que le soleil soit levé et que le mode DODO soit bien désactivé

- Execution de la Fonction LightsOn()

- Mise à jour des timestamp là où c'est nécessaire (VG).

 

 

Modifié 28 novembre 2018 par J3R3M

[Lazer 8 486]

ouais, t'as une grosse usine à gaz, tant du coté du script, que de l'archi hétéroclite.

C'est comme quand j'utilise mon Harmony pour allumer la lumière, on est pas loin de 1s de latence, c'est la grosse usine à gaz aussi :

Harmony => (RF) => Hub => (Wifi) => Borne Unifi => (Ethernet) => Switch POE => (Ethernet) => Switch => (Ethernet) => Serveur => (ESXi) => VM HABridge => (Ethernet) => Switch => HC2 => (Z-Wave) => FGD

 

Une bonne installation haut de gamme, performante, réactive, est en full- Z-Wave (ou mieux, KNX).

Mais pas en Wi-Fi, protocole à latence importante, sans compter les nombreuses passerelles à traverser.

[J3R3M 107]

Bon, le fait que tu passes par autant de périphériques réseaux et que tu aies "aussi peu" de latence prouve quand même que j'ai un soucis de mon côté, puisque je n'ai que deux switchs et ils sont tous deux directement câblés sur le routeur!

Mais je me suis déjà bien rendu compte que les Hues posaient problème lorsque, par exemple, des téléchargements lourds étaient effectués en wifi, malgré l'utilisation d'un vrai routeur wifi (Asus RT-AC3200).

Je n'ai malheureusement pas la possibilité d'attribuer une bande uniquement aux hues, puisque pour le routeur, il n'y a qu'un périphérique Hue et il est en LAN...

Bref, voilà pourquoi j'essaie de grappiller des millisecondes par-ci, par-là, pour limiter au maximum la latence, tout en préservant une scène "intelligente".

 

Après, il est toujours possible de publier le script en question, mais le temps nécessaire pour l'apprivoiser en découragerait plus d'un, moi le premier!

[J3R3M 107]

Pour imager mes propos, voilà ce qui arrive quelques fois :

Je provoquais volontairement des mouvements dans la cuisine. Ne voyant aucun message de debug (ni de lumière s'allumer d'ailleurs), je continuais.

J'ai arrêté de bouger pour me demande ce qu'il se passait. Au bout de quelques secondes, tous ces messages sont apparus d'un coup et la scène s'est exécutée.

Pour le coup, je ne suis pas certain que ça soit vraiment lié à la lenteur d'exécution du script sur ce coup-ci, mais plus à une latence de transmission de l'information par le trigger (qui, pour le coup, est à 2m de la HC2) ou à des difficultés de la scène à s'exécuter lorsqu'elle n'a pas été sollicitée depuis plus d'un certain temps.

Modifié 28 novembre 2018 par J3R3M

[Lazer 8 486]

je sais pas trop, mais moi je repartirais à la base => 1 seul capteur de mouvement qui déclenche le trigguer sur un script LUA ultra simple (donc performant) qui allume 1 seule lumière

 

Juste pour voir si la lenteur vient de ton script ou de la communication Hue.

Ensuite tu sauras où optimiser

[J3R3M 107]

J'avais déjà fait ça il y a quelques mois et c'est à ce moment là que je m'étais dit que les FGMS avaient une certaine latence.

Mais je vais quand même réitérer, tu as raison, pour vraiment mesurer la différence entre  l'exécution directe d'une action et l'exécution de mon script avoir avoir détecté un mouvement.

[Lazer 8 486]

Le FGMS a une certaine latence inhérente au fonctionnement de tout détecteur de mouvement basé sur la technologie PIR (capteur d'alarme, etc)

Le faisceau IR perçu par le capteur est découpé en zone par la lentille de Fresnel placée devant.

Par défaut, je crois que le FGMS attend que 2 zones soient franchies pour confirmer le mouvement (cela se change dans ses paramètres).

Donc si tu rentre "juste un peu" dans son champs de vision, tu n'as activé qu'une zone, mais pas 2, donc pas de notification de mouvement.

 

Tu peux changer sa sensibilité à la hausse (comme à la baisse), mais attention aux faux positifs.

 

Une fois la détection confirmée, l'info est envoyé par Z-Wave à la box HC2, ce qui est extrêmement réactif pour peu que ton réseau Z-Wave ne soit pas surchargé (ça peut arriver...) et qu'il ne doive pas passer par des relais (réseau maillé).

 

Ensuite, c'est le trigger de la HC2 qui va déclencher ta scène, puis ton code LUA, et tu connais la suite.

 

Si tu veux du quasi instantané (modulo le temps de détection inhérent à la techno PIR décrit ci-dessus), il faut faire une association directe entre le FGMS et le Dimmer (ou relai) pilotant la lumière puisque tu bypass la box (laquelle est tout de même informée).... ce qui implique d'être en full Zwave. Dans ce cas, on peut parler de quasi instantanée, la latence n'est pas perceptible par un être humain. On est au niveau d'un réseau KNX, où les participants (les modules) discutent entre eux en direct, sans dépendre d'un contrôleur (box)

[Cmoi20 37]

Bonjour,

 

la latence avec le bridge hue ne peut-il pas venir d'une configuration cloud des appels entre la HC2 et le bridge HUE ?

pour que tout fonctionne rapidement, il faut que l'ensemble des appels soient réalisés en local.

[J3R3M 107]

Il y a 5 heures, Lazer a dit :

Le FGMS a une certaine latence inhérente au fonctionnement de tout détecteur de mouvement basé sur la technologie PIR (capteur d'alarme, etc)

Le faisceau IR perçu par le capteur est découpé en zone par la lentille de Fresnel placée devant.

Par défaut, je crois que le FGMS attend que 2 zones soient franchies pour confirmer le mouvement (cela se change dans ses paramètres).

Donc si tu rentre "juste un peu" dans son champs de vision, tu n'as activé qu'une zone, mais pas 2, donc pas de notification de mouvement.

Citation

Motion detection - pulse counter
This parameter determines the number of moves required for the PIR sensor to report motion. The higher the value, the less sensitive the PIR sensor is.
It is not recommended to modify this parameter settings!

Il s'agit effectivement du 3ème paramètre, dont il ne faut visiblement pas modifier la valeur.
J'ai déjà essayé s'augmenter la sensibilité (paramètre 1) et ça avait mené à de détections de mouvements sans raisons toutes les 4-5mn, sans arrêt!

Et ce, alors qu'ils ne mettaient pas en garde sur la baisse de cette valeur, alors quand ils nous mettent en garde, je n'ose pas imaginer à quel point ça doit devenir hasardeux!

Il y a 5 heures, Lazer a dit :

Une fois la détection confirmée, l'info est envoyé par Z-Wave à la box HC2, ce qui est extrêmement réactif pour peu que ton réseau Z-Wave ne soit pas surchargé (ça peut arriver...) et qu'il ne doive pas passer par des relais (réseau maillé). 

Pour ma part, je ne pense pas qu'un maillage soit effectué, mon pôle domotique/réseau étant au coeur du domicile.

Pour que le réseau Z-Wave soit surchargé, je présume qu'il faille que beaucoup de modules soient actifs simultanément? Ce qui n'arrive jamais chez moi.

Il y a 5 heures, Lazer a dit :

Si tu veux du quasi instantané (modulo le temps de détection inhérent à la techno PIR décrit ci-dessus), il faut faire une association directe entre le FGMS et le Dimmer (ou relai) pilotant la lumière puisque tu bypass la box (laquelle est tout de même informée).... ce qui implique d'être en full Zwave. Dans ce cas, on peut parler de quasi instantanée, la latence n'est pas perceptible par un être humain. On est au niveau d'un réseau KNX, où les participants (les modules) discutent entre eux en direct, sans dépendre d'un contrôleur (box)

C'est bien ce que j'avais en tête, mais pour le coup, c'est nettement moins "smart", d'après-moi.

Enfin, cela dépend des modules interconnectés, mais faire cela entre un interrupteur et une ampoule (ou un FGD), cela revient au même que s'il y avait un câblage électrique simple entre les deux, en plus cher. Mais cela est strictement personnel et je n'ai sans doute pas pensé à un cas où cela pourrait être utile.

 

Je vais procéder à quelques tests afin d'essayer de localiser la/les cause(s) de ces latente(s).

 

@Cmoi20, j'utilise le VD Hue de Talwayseb (un peu modifié pour me correspondre, mais le même dans le fonctionnement).

Les requêtes semblent bien envoyées sur l'API LAN du HueBridge, mais merci de cette suggestion!

Modifié 29 novembre 2018 par J3R3M

[Lazer 8 486]

il y a 29 minutes, J3R3M a dit :

C'est bien ce que j'avais en tête, mais pour le coup, c'est nettement moins "smart", d'après-moi.

Enfin, cela dépend des modules interconnectés, mais faire cela entre un interrupteur et une ampoule (ou un FGD), cela revient au même que s'il y avait un câblage électrique simple entre les deux, en plus cher. Mais cela est strictement personnel et je n'ai sans doute pas pensé à un cas où cela pourrait être utile.

Je pense que tu mélanges plusieurs choses là.

 

Déjà, je n'ai pas parlé d'intelligence ("smart"). Une association directe entre 2 modules, c'est justement tout sauf intelligent => C'est bête et méchant, un mouvement sur le détecteur allume immédiatement le dimmer, quelles qu'en soient les conditions (jour, nuit, humidité, age du capitaine, etc). L'action est donc quasiment instantanée, on parle d'une latence de quelques millisecondes entre les 2 modules.

 

Ensuite, tu parles d'interrupteur sur un dimmer, il n'y a justement pas de communication inter-module, puisque l'interrupteur est physiquement connecté au module, et que l'ampoule également. Le module Dimmer agît alors exactement comme un télérupteur électrique. C'est totalement autonome et ne dépend d'aucun autre module, ni de la box domotique (laquelle est tout de même informée après que le dimmer ait effectivement allumé la lumière). L'action est donc instantané, impossible de faire plus rapide.

 

Je me rend compte à la lecture de ton scénario rapidement décrit plus haut dans ce topic, et des autres messages que tu as laissé ailleurs sur le forum, que tu es parti dans des délires assez importants (ne le prend pas mal hein ) avec une architecture complexe, appelée couramment usine à gaz.

Les usines à gaz, c'est bien, ça sait tout faire. Mais c'est complexe, difficile à maintenir, souvent assez lent, et peu fiable.

 

C'est pour cela que je t'invite à revenir aux fondamentaux, à savoir tester chaque interaction une par une.

Tu verras que le Z-Wave est extrêmement rapide, les latences ne sont pas perceptibles pas nous autres pauvres humains, et que si latence il y a, elles proviennent d'ailleurs.

Dans ton cas, on est plusieurs (toi y compris ) à avoir de sérieux doutes sur le script LUA et ses nombreuses interactions avec la DB, ainsi que le pont Philips Hue. Sans oublier la latence du capteur PIR lui-même bien sûr, à l'origine de tout ton scénario.

 

Tu l'as dit toi même plus haut, un grand nombre d’interactions n'entrainent pas nécessaire un temps de latence de plusieurs secondes, en citant en exemple ma chaine Harmony => ... => Lampe, qui bien que longue, ne prend que 1s maxi (bon, c'est déjà trop à mon gout, mais ça reste acceptable pour cet usage, à savoir piloter la lumière du bout des doigts sans bouger mon popotin du canapé )

[J3R3M 107]

Il y a 4 heures, Lazer a dit :

Déjà, je n'ai pas parlé d'intelligence ("smart"). Une association directe entre 2 modules, c'est justement tout sauf intelligent => C'est bête et méchant, un mouvement sur le détecteur allume immédiatement le dimmer, quelles qu'en soient les conditions (jour, nuit, humidité, age du capitaine, etc). L'action est donc quasiment instantanée, on parle d'une latence de quelques millisecondes entre les 2 modules.

Nous sommes donc d'accords que si on veut supprimer au maximum la latence, il faut également faire l'impasse sur le côté smart home.

Il faut donc optimiser au maximum les scripts pour trouver un juste milieu

Il y a 4 heures, Lazer a dit :

Ensuite, tu parles d'interrupteur sur un dimmer, il n'y a justement pas de communication inter-module, puisque l'interrupteur est physiquement connecté au module, et que l'ampoule également. Le module Dimmer agît alors exactement comme un télérupteur électrique. C'est totalement autonome et ne dépend d'aucun autre module, ni de la box domotique (laquelle est tout de même informée après que le dimmer ait effectivement allumé la lumière). L'action est donc instantané, impossible de faire plus rapide.

Effectivement, je n'ai pas été assez clair dans mon exemple, je pensais à un interrupteur Z-Wave, donc sans le moindre câble

Il est vrai que ça a plus de sens lorsqu'un détecteur allume une lumière, mais c'est effectivement bête et méchant.

Il existe des déjà des appareils qui font ça parfaitement, pour des sommes très abordables, du moins bien moins que le coût des modules en domotique.

Il y a 4 heures, Lazer a dit :

Je me rend compte à la lecture de ton scénario rapidement décrit plus haut dans ce topic, et des autres messages que tu as laissé ailleurs sur le forum, que tu es parti dans des délires assez importants (ne le prend pas mal hein ) avec une architecture complexe, appelée couramment usine à gaz.

Les usines à gaz, c'est bien, ça sait tout faire. Mais c'est complexe, difficile à maintenir, souvent assez lent, et peu fiable.

Je ne me vexe pas

Ce n'est pas tant que ça une usine à gaz, une architecture est respectée et le fonctionnement est très fiable, je ne déplore pas la moindre panne, si ce n'est une certaine lenteur quelques fois.

Mais je pense dans un premier temps que reprogrammer la chose en évitant le décodage/encodage json réguliers aidera à gagner en performance.

À une époque désormais lointaine (+ de 10ans), je programmais beaucoup en PHP et j'ai découvert le LUA il y a plus d'un an sur ce forum.

Mes posts démontrent d'ailleurs l'évolution de mon apprentissage, puisque mes premiers étaient vraiment ceux d'un néophyte!

Toujours est-il que je me rends maintenant compte que le LUA s'éxécute moins rapidement que le PHP, il suffit simplement de s'y habituer et apprendre à le contrer

Il y a 4 heures, Lazer a dit :

Tu l'as dit toi même plus haut, un grand nombre d’interactions n'entrainent pas nécessaire un temps de latence de plusieurs secondes, en citant en exemple ma chaine Harmony => ... => Lampe, qui bien que longue, ne prend que 1s maxi (bon, c'est déjà trop à mon gout, mais ça reste acceptable pour cet usage, à savoir piloter la lumière du bout des doigts sans bouger mon popotin du canapé )

Je précise quand même que dans 85% des cas, lorsque le trigger est une caméra, la lumière s'allume en moins d'une demie seconde lorsqu'elle s'allume en un peu moins d'une seconde lorsque celui-ci est un FGMS.

Mais, sans que je puisse l'expliquer, lorsqu'il n'y a pas eu de mouvements depuis un certain temps, c'est plus long pour procéder au premier allumage de la lumière de chaque pièce, là où les délais réduisent considérablement la fois suivante.

C'est pour cela que je disais que ça donnait l'impression que la HC2 avait besoin de se remettre en jambe, puisqu'elle est peu sollicitée puis d'un seul coup, des scènes se manifestent?...

Bref, c'est assez étrange, mais il n'y a rien très grave au final

[Lazer 8 486]

Le 29/11/2018 à 21:50, J3R3M a dit :

Toujours est-il que je me rends maintenant compte que le LUA s'éxécute moins rapidement que le PHP

En fait c'est l'inverse, LUA est BEAUCOUP Plus rapide que PHP, il y a eu pas mal d'études à ce sujet sur le net.... enfin "pas mal" c'est relatif, car LUA est un langage assez confidentiel. La langage LUA a justement été développé pour être très rapide et peu consommateur de ressource, tout le contraire de PHP en fait.

Ce n'est que récemment que PHP, avec la v7, est devenu plus rapide (performances peut être similaires maintenant, en fait j'en sais rien, il faudrait faire tourner un programme identique sur la même machine pour comparer).... à voir si des études récentes ont été menées.

N'oublie pas que le processeur de la HC2 est un Atom pas tout jeune, et même si c'est surdimensionné pour faire de la domotique, ça reste un processeur très lent comparé aux autres CPU du marché.

 

Le 29/11/2018 à 21:50, J3R3M a dit :

Mais, sans que je puisse l'expliquer, lorsqu'il n'y a pas eu de mouvements depuis un certain temps, c'est plus long pour procéder au premier allumage de la lumière de chaque pièce, là où les délais réduisent considérablement la fois suivante.

Etrange ça....

Sans certitude, mais on dirait un problème de maillage, comme si il devait recalculer une nouvelle route à chaque fois.... route qu'il conserve un certain temps, puis "oublie".

[J3R3M 107]

Le 01/12/2018 à 18:39, Lazer a dit :

En fait c'est l'inverse, LUA est BEAUCOUP Plus rapide que PHP, il y a eu pas mal d'études à ce sujet sur le net.... enfin "pas mal" c'est relatif, car LUA est un langage assez confidentiel. La langage LUA a justement été développé pour être très rapide et peu consommateur de ressource, tout le contraire de PHP en fait.

J'avais quand même souvenir de gros codes PHP de plusieurs centaines de lignes, avec un paquet de vérifications et de boucles, qui s'exécutaient en quelques millisecondes, là où j'ai un peu l'impression qu'une grosse boucle ralentit considérablement l'exécution d'un script complet. Mais, c'était il y a plus de 10 ans encore une fois, et les accès à la base de données étaient sans doute plus rapides.

Le 01/12/2018 à 18:39, Lazer a dit :

N'oublie pas que le processeur de la HC2 est un Atom pas tout jeune, et même si c'est surdimensionné pour faire de la domotique, ça reste un processeur très lent comparé aux autres CPU du marché. 

C'est vrai que ça commence à bien dater, même s'il avait révolutionné le petit monde des CPU à sa sortie. J'ai encore un MSI Wind U100 qui traîne dans un tiroir d'ailleurs!

Mais ça reste considérablement mieux que ce qu'il y a sur les Raspberry je présume?!

 

Le 01/12/2018 à 18:39, Lazer a dit :

Sans certitude, mais on dirait un problème de maillage, comme si il devait recalculer une nouvelle route à chaque fois.... route qu'il conserve un certain temps, puis "oublie".

Je suis en train de reprendre la programmation de mes scènes principales en essayant de supprimer au maximum les vérifications. J'ai déjà bien avancé, ce week-end sans bosser aura eu ce bénéfice!

Et je dois avouer que je sens déjà l'allumage plus réactif dans l'ensemble et c'est plutôt agréable d'ailleurs. Mais cet allumage peut effectivement être plus long pour les capteurs les plus loins de la HC2, notamment lorsqu'il y a un gros mur à traverser.

Je vais donc voir s'il existe une méthode pour faire un "reset" du maillage afin que chaque module puisse recalculer la route la plus rapide pour lui, bien qu'ils doivent tous être capables de communiquer directement avec la HC2 d'après-moi.

Je vais d'ailleurs voir si je peux connaître l'état de connexion de chaque module à la HC2

Merci de cette suggestion @Lazer!

[Lazer 8 486]

Il y a 13 heures, J3R3M a dit :

J'avais quand même souvenir de gros codes PHP de plusieurs centaines de lignes, avec un paquet de vérifications et de boucles, qui s'exécutaient en quelques millisecondes, là où j'ai un peu l'impression qu'une grosse boucle ralentit considérablement l'exécution d'un script complet. Mais, c'était il y a plus de 10 ans encore une fois, et les accès à la base de données étaient sans doute plus rapides.

Faut comparer ce qui est comparable :

- du code PHP pur contre du code LUA pur

- donc pas d'accès à une base de données

- sur la même machine

Là tu parles de ressenti sur des machines différents avec 10 ans d'intervalle, et avec des données stockées dans des bases différentes.... c'est juste totalement incomparable, désolé.

 

Il y a 13 heures, J3R3M a dit :

Mais ça reste considérablement mieux que ce qu'il y a sur les Raspberry je présume?!

A priori oui

 

Il y a 13 heures, J3R3M a dit :

Je vais donc voir s'il existe une méthode pour faire un "reset" du maillage afin que chaque module puisse recalculer la route la plus rapide pour lui, bien qu'ils doivent tous être capables de communiquer directement avec la HC2 d'après-moi.

Oui, dans les paramètres du moteur Z-Wave

Tu peux reconstruire pour un module, ou pour tous

 

Il y a 13 heures, J3R3M a dit :

Je vais d'ailleurs voir si je peux connaître l'état de connexion de chaque module à la HC2

Regarde dans le topic de la 4.503 BETA, il y a tout ce qu'il faut : un petit module virtuel, et une page PHP qui permet de visualiser la topologie de façon graphique.

 

Il y a 13 heures, J3R3M a dit :

Je suis en train de reprendre la programmation de mes scènes principales en essayant de supprimer au maximum les vérifications

Aussi autre chose, puisque tu vas lire des variables globales, et potentiellement en écrire.

J'ai souvenir suite à un bench sur le forum, qu'une écriture en DB était 17 fois plus lente qu'une lecture.

Il y a surement beaucoup à optimiser dans ton code

[J3R3M 107]

Le 03/12/2018 à 11:40, Lazer a dit :

Faut comparer ce qui est comparable :

- du code PHP pur contre du code LUA pur

- donc pas d'accès à une base de données

- sur la même machine

Là tu parles de ressenti sur des machines différents avec 10 ans d'intervalle, et avec des données stockées dans des bases différentes.... c'est juste totalement incomparable, désolé.

À la lecture de ce message, je crois comprendre que LUA peut être associé à d'autres Base de Données, encore fallait-il le savoir

Je ne fais pas le procès du LUA, j'annonce simplement un ressenti par rapport à ce que j'ai pu constater auparavant.

À l'époque, les scripts PHP étaient hébergés sur un serveur dédié de chez OVH, qui ne tournaient certainement pas avec un Atom, c'est certain.

Le 03/12/2018 à 11:40, Lazer a dit :

Oui, dans les paramètres du moteur Z-Wave

Tu peux reconstruire pour un module, ou pour tous

Je vais voir à cela, merci

Je l'ai fait à distance, je ne vois pas de changement à l'heure actuelle (sur le graphisme de réseau Z-Wave).

Le 03/12/2018 à 11:40, Lazer a dit :

Regarde dans le topic de la 4.503 BETA, il y a tout ce qu'il faut : un petit module virtuel, et une page PHP qui permet de visualiser la topologie de façon graphique.

Idem. Mais c'est une tuerie !!

Le 03/12/2018 à 11:40, Lazer a dit :

Aussi autre chose, puisque tu vas lire des variables globales, et potentiellement en écrire.

J'ai souvenir suite à un bench sur le forum, qu'une écriture en DB était 17 fois plus lente qu'une lecture.

On avait vu qu'une vérification des valeurs du tableau de VG était automatiquement effectuée par la HC2 avant de l'écrire (afin de ne pas la modifier inutilement si la valeur est la même), ce qui pourrait expliquer ce délai. Après, il faut effectivement réfléchir à l'intérêt d'enregistrer une valeur en DB afin d'optimiser le temps d'exécution.

Modifié 4 décembre 2018 par J3R3M