Lazer

Remarque : les développeurs Jeedom ce sont des gros geeks qui ne prêtent aucune attention au graphisme. Mais à la tête, il y a Domadoo, et les mecs ils sont pas cons, si ils ont investi dans cette solution, c'est qu'ils pensent en faire un business. Et à mon avis ils sont sensibles à l'aspect visuel de la chose. Bon après c'est sur, un graphiste c'est souvent plus cher qu'un développeur, donc je ne peux pas te dire si tu es dans leur budget, mais ça pourrait valoir le coup de les contacter.

@Domodial, du coup, tu pourrais tenter de proposer tes services à l'équipe Jeedom, essaye de contacter Domadoo on sait jamais, ils ont peut être un poste à pourvoir et je pense qu'ils sont conscients qu'il faut qu'ils améliorent sérieusement le graphisme de Jeedom.

Je sais pas pour vous, mais chez moi le plugin Netatmo a l'air de toujours fonctionner en 4.100 bien qu'on ait dépassé la date butoir. Donc moi je dis qu'ils sont trop fort chez Fibaro, ça fonctionne sans rien faire

Réponse courte : non Réponse complète : oui c'est possible En fait, ce n'est pas possible avec le VD actuel, car j'utilise les boutons Enable et Disable, qui ont pour action d'activer et désactiver complètement les caméras, donc forcément la détection de mouvement qui va avec. Si tu souhaites activer/désactiver uniquement la détection de mouvement, mais laisser la caméra active, dans ce cas là il faut créer de nouveaux boutons sur le VD et appeler les API de Surveillance Station. D'après la doc, je pense que c'est l'API SYNO.SurveillanceStation.Camera.Event et la méthode MDParamSave. Perso je n'ai pas le besoin ni le temps de développer ça.... mais ça ne devrait pas être trop compliqué de copier/coller l'un des boutons existants et d'adapter le code.

MAJ sans souci sur ma box de test, le reboot a été ultra rapide, pas eu besoin d'attendre les 5 Minutes comme certains. Mais j'étais déjà passé par la 4.101, et celle-là avait mis longtemps à rebooter, donc le traitement spécifique avait peut être déjà été appliqué. Comme Nico, j'ai trop d'accès externes à changer à cause du renommage admin => email, donc je vais attendre un peu d'avoir le temps de préparer ça sur ma box de prod

ah mais tu es encore en 4.090 d'après ta signature ?

Oui, Nikko a donné la nouvelle API :

Etrange, il me propose bien la nouvelle 4.102

Hum oui c'est vrai que je pourrais faire le test, faut juste que je trouve le temps et surtout le courage

Oui Seb, mais ça ne ne nous dis pas si les paramètres des modules sont conservés lors de la récupération des données de la Puce Z-wave sur une autre box.

Perso je ne comprendrai jamais cet acharnement de beaucoup à vouloir l'image vidéo dans leur box domotique, qu'elle soit Fibaro ou Jeedom. A mon avis, ça n'a strictement aucun intérêt, ce qui compte c'est que la box domotique puisse piloter les caméras (enregistrement, on/off, PTZ, etc) en fonction de différentes conditions (sonnette, vacances, mouvement, intrusion, incendie, etc) Il est beaucoup plus utile d'avoir un NAS type Synology qui enregistre les caméras sur ses propres disques durs, indépendamment de la box domotique, c'est donc plus fiable. Et l'appli DS Cam est tellement pratique et ergonomique sur smartphone, qu'il serait dommage de s'en passer. Bon évidemment il faut avoir un NAS Syno/Qnap, mais c'est le cas de beaucoup ici. Il est illusoire de croire qu'une notification sur son smartphone avec vidéo en temps-réel est utile, car par définition, loi de Murphy oblige, on n'est jamais disponible pour consulter son smartphone au moment où la notification se produit. Et puis voir son cambrioleur en temps réel, perso si ça devait m'arriver je préfère encore ne pas le voir, car de toute façon il est impossible d'agir. La vidéosurveillance doit est autonome. Les caméras permettent de : - lever le doute (en live ou en décalé) à distance - procurer un enregistrement permettant d'analyser la scène à postériori En fait, on en revient au débat domotique autonome et intelligente versus domotique de Mme Michu qui allume ses lumières/caméras avec son smartphone à la main. (en parlant de VD Surveillance Station, je m'en suis servi pour créer très rapidement un nouveau VD Synology ce week-end pour un autre composant des Syno.... je vous laisse deviner quoi... un indice, ça a un rapport (non voulu) avec l'actualité geekesque d'hier). Voilà pour le teasing, et un tuto à venir bientôt

@mprinfo t'inquiète je reste avec toi, on sera au moins 2

Il n'est pas en RAMFS le /tmp sur votre Jeedom ? Ça c'est au moins un truc que Fibaro a bien fait sur son HC2

Vu que ce n'est pas dans le changelog, je pense que ce sont des nouvelles fonctionnalités encore à l'état de test, pas forcément super fiable. Ca sera dans le changelog d'une prochaine version quand ils auront décrété que c'est "stable". Et ça sera dans la doc officielle quand.... mystère !!!

Yes Krikroff, merci C'est déjà le cas pour mes nouvelles scènes, mais pas pour les anciennes (qui fonctionnent encore bien avec les fibaro:sleep().... mais pour combien de temps ?) Par contre, je n'ai jamais testé, mais pour les main loop ce n'est pas possible ? Ca fonctionne toujours avec la boucle infinie je crois : while true do -- code utilisateur fibaro:sleep(3000) end

J'ai l'impression que le nouveau trigger de scène timer va bien nous simplifier la vie pour les déclenchements à intervalle régulier :

Pour info, il y a de nouveaux Triggers de Scènes non documentées depuis la 4.100. Source : Tinman sur le forum officiel %% autostart %% properties %% globals GLOBALS %% events EVENTS %% killOtherInstances %% weather WEATHER %% timer TIMER Avec quelques nouvelles fonctions : runningManualInstances killOtherInstances runningInstances Et un début d'explication de w.rys (Fibaro) :

ah non mais moi j'ai PLEIN de boucles (que ce soit des scènes ou VD). Simplement je les laisse dériver dans le temps car je ne suis pas à la seconde près. Certaines ne se réveillent que toutes les heures (ex : Network Monitor) donc ce n'est vraiment pas gênant. C'est juste que je n'ai que 2 scènes (GEA et Domocharts) qui font du recalage temporel, car pour ces 2 là j'ai besoin de plus de précision. Mais ton scheduler fait pareil, si il fait du pressButon à intervalle régulier ça revient au même. Reste que si ton scheduler est la seule boucle à déclencher les actions, tu vas te retrouver avec des pics de charges si il clique sur plusieurs boutons au même moment. Et donc je préfère ma méthode avec pleins de boucles infinies dans tous les sens, car cela lisse mieux la charge CPU sur la durée, statistiquement parlant. Effectivement le code de Fred le ouf permet de choisir à quel moment la scène va se réveiller, donc is on générale son code à toutes les scènes, alors il faut prendre soin de choisir des instants de démarrage différents pour les scènes.

Une Nexus 7 est juste parfaite pour cet usage (mais que tu ne trouveras plus qu'en occasion, elle n'est plus commercialisée)

Peso, je trouve qu'il y a quand même un intérêt à ne pas faire de recalage temporel, et à laisser dériver les scènes dans le temps : c'est de lisser la charge CPU de la box. En effet, si toutes les boucles de toutes les scènes se réveillaient toutes à la même seconde chaque minute, cela ferait un pic de charge qui ralentirait l'ensemble. Et la plupart du temps, on n'a pas besoin d'un intervalle très précis, donc ce n'est pas gênant de dériver de quelques millisecondes par cycle. Je pense que je ne dois avoir que 2 scènes sur ma box qui font du recalage temporel : GEA et Domocharts. Il n'y a pas longtemps j'ai fait l'expérience de monitorer la charge CPU/RAM/HDD de ma box pendant 24h, et j'ai été impressionné par la régularité du lissage de la charge, pourtant j'ai beaucoup de scènes et de VD qui se réveillent à intervalle régulier et font énormément de requêtes http dans tous les sens. Résultat, ma box est stable et performance (réactive)

Super intéressant, merci du retour Nikko Donc la grande question, c'est comment le Device 3 a pu disparaitre par magie de la DB !!! On ne saura surement jamais. En tout cas bravo pour avoir trouvé, dépanné & réparé Flamalex, et pour le compte rendu

Le forum est passé en HTTPS, dites nous si vous rencontrez des problèmes.

@Nico non les 3s c'est pour la Main Loop d'un VD. Dans une scène, il n'y a pas de boucle, donc pas de "3s". Quand le code atteint la fin de la scène, l'instance s'arrête. Si tu veux une boucle, c'est à toi de le faire explicitement.

Si tu fais un sleep(60*1000), le temps total entre 2 exécution de la scène est plus long que 60s, car il faut rajouter le temps d'exécution de toutes les instructions de ta scène. Cela peut prendre 1ms, comme plusieurs secondes.... Le seul moyen d'être certain que ta scène démarre, par exemple à 00s toutes les minutes, est de prendre le timestamp du temps courant (avec os.date()) et et calculer le delta à attendre. La plupart du temps tu attendras 60s, par à certains tours tu attendras 1s de moins, pour compenser le décalage temporel. Ne pas oublier qu'en parallèle, il y a la synchro de temps NTP. Enfin le NTP c'est la théorie, car Fibaro n'a jamais su le faire fonctionner..... d'où le VD Clock Sync de Krikroff qui te resynchronise ton horloge 1 fois par nuit... donc à ce moment précis, tu as un gros saut temporel de plusieurs secondes d'un coup (car l'horloge interne de la carte mère, basée sur un quartz, dérive seule)