Lazer

Ah oui, c'est le vieux système, obsolète... un bon vieux signal analogique sur câble coaxial ! Effectivement tu ne pourras rien en faire à part poser les câbles qui vont bien et acheter un enregistreur vidéo. Et puis la qualité d'image doit est "d'époque", avec un capteur peu sensible et des couleurs aléatoires... Aujourd'hui, toutes les caméras sont en IP.

Bienvenue sur le forum

Il te faut juste un peu de motivation. Un beau jour de juillet où ils n'annonçaient pas de pluie pendant 1 semaine, j'ai sorti mes 2 échelles, je suis monté sur le toit, j'ai détuilé jusqu'au faite, passé les câbles par la gaine technique, redescendu et parcouru 3 pentes du toit (maison en L), percé quelques trous, et j'ai une super installation pour couvrir le périmètre de la maison, avec câbles totalement invisibles, on voit juste les caméras qui dépassent. Et c'est ultra fiable évidemment. Il faisait 35°C à l'ombre, j'ai cru mourir là haut, à chaque fois que je descendais, je buvais 1/2 litre d'eau (et j'ai rien pissé), ça m'a pris 3 jours. Un autre week-end, j'ai passé un câble dans la gaine sous le jardin qui mène au garage, ce qui ne fut pas simple, car la grosse gaine est rompue, j'ai trouvé une autre gaine, qui passait par un chemin inconnu, j'ai acheté un appareil pour tracer le câble dans les murs plafond sol, j'ai trouvé le chemin, une boite de dérivation sur le mur extérieur de la maison enterré sous le niveau de la terre, et ça m'a permis de passer mon câble. Le réseau de mon salon descend à la cave, traverse les fondations et sort sous la terrasse, rentre sous la cheminée, et arrive au salon. Là aussi, un gros week-end de travail. Mon onduleur est déporté à la cave (pour le bruit et la fraicheur), j'ai tiré des lignes aller/retour pour faire des lignes secourues. Le matin je me suis fait livrer un forêt SDS Bosch Pro de 450mm, le soir il est parti à la poubelle, sa tête avait littéralement disparue. Entre la domotique, les caméras, l'électricité, le réseau, la téléinformation, etc, je ne compte plus le nombre de jours cumulés de passage de câbles. Quand on aime, on ne compte pas parait-il ! Mais une fois posé, tu es tranquille, ça fonctionne tellement bien. Je travaille dans l'informatique... parfois je branche un câble RJ45 ou une fibre optique... c'est moins violent

Q1 : Sur HC3, contrairement à la HC2, les scènes sont limitées à 1 instance. La case à cocher "Autoriser le redémarrage du scénario en cours d'exécution" fait ce qu'elle dit. Elle redémarrer la scène. Sous entendu si une instance précédente est encore en cours d'exécution, elle est arrêtée de force. Q2 : Seulement dans les QuickApps (gestion des fichiers) Q3 : Oui, c'est du LUA standard Q4 : Tu veux dire le trigger de l'instance précédente ? Dans ce cas non, car en vertu de Q1, une scène tuée... est morte... donc on efface tout et on recommence Sur HC3, contrairement à la HC2, les scènes sont réduites à des usages assez simples et basiques. Un trigger => une action. Faut pas chercher à faire beaucoup plus. C'est pas pour rien que GEA qui était une scène sur HC2, est devenu un QuickApp sur HC3, car Fibaro a complètement inversé les possibilités de l'un par rapport à l'autre. Changement de philosophie : - Scène = programme simple - QuickApp = programme plus ou moins complexe Souci, les QuickApps ne permettent pas les triggers. Il faut faire comme GEA, utiliser l'API refreshStates... pas simple... Mais j'ai partagé un bout de code qui fonctionne :

Le souci des caméras à pas cher, c'est que : - c'est du jetable (pour l'écologie en repassera, et pour le budget au bout de 2 caméras tu t'es payé une Hikvision qui tiendra des années) - la qualité d'image est souvent médiocre - Wi-Fi, un jour ça marche, un jour ça ne marche pas - il faut une application propriétaire, pas intégrable dans un NAS pour l'enregistrement du flux, et encore moins dans l'application Fibaro. La caméra Netatmo est plus qualitative, mais reste la dépendance au cloud et à l'application propriétaire. Hikvision, c'est un peu le haut de gamme de ce qu'un particulier peut se payer (marque chinoise pro, leader, qu'on retrouve de plus en plus dans l'industrie en France (groupes hôteliers, loueurs de voiture, et j'en ai même vu dans un ministère...). Je considère qu'ils n'ont plus grand chose à envier aux ténors tels que Axis. Mais avec ça tu es tranquille, ça répond à ton cahier des charges, il faudra juste amener un RJ45 et un switch POE (ou un switch normal avec un injecteur POE), slot micro-SD intégré, enregistrement sur NAS possible, intégration HC3, selon le modèle il y a des détections plus ou moins intelligentes des mouvements / changement de scène / traversée de périmètres. Le catalogue est ultra large, pas évident de faire son choix. En un peu moins cher, et un tout petit peu moins qualitatif, il y a Dahua (chinois aussi). EDIT : autre alternative, les caméras sans fil de chez Arlo, sur batterie. C'est hors de prix, le seul intérêt c'est pour installer dans une cabane dans les bois sans électricité. Dans une maison normale, je ne vois pas l'intérêt à part gaspiller son argent (et frimer devant ses amis en prétendant avoir posé un système de vidéosurveillance en 5 minutes.... en n'oubliant pas qu'il faudra les recharger régulièrement)

Pas sûr d'avoir compris ton besoin, mais le Walli a déjà un interrupteur intégré (forcément, c'est le principe de ce module). Donc l'entrée S additionnelle sert à brancher le 2nd interrupteur. Mais d'après les schémas de la doc, j'ai l'impression que lorsqu'on n'a pas de neutre, il n'est pas possible d'utiliser l'entrée S pour y brancher un 2nd interrupteur, car cette entrée S est utilisée pour ponter la borne N.

Il y a souvent une grande confusion dans la compréhension de ce qu'est l'open-source.... et dans le cas présent, je le constate une fois de plus. Surtout que la phrase que tu as cité est particulièrement mal tournée... Open-source n'a jamais été synonyme de gratuit, c'est la grande confusion que font les néophytes. L'exemple le plus célèbre, c'est Redhat, qui est devenue une entreprise multimilliardaire en vendant du service autour des logiciels open-sources. Ma remarque ne portait pas sur la possibilité d'implémenter Matter, mais bien sur le process de certification qui permet à l'objet/contrôleur d'être intégré dans un réseau existant. Et ce processus de certification, est-ce qu'il est gratuit ? Elle est bien là ma question. Et même s'il était gratuit, quels en sont les contraintes ? Je n'ai pas cherché, peut être que c'est déjà documenté...

Bienvenue sur le forum

Article sur la sécurité intégrée nativement dans Matter : [Abavala] Que propose Matter en termes de sécurité et de confidentialité pour la Smart Home ? C'est une bonne nouvelle. Là je me demande dans quelle mesure ça va ralentir (voire bloquer) les fabricants qui ne font pas partie du consortium CSA. Je pense à Fibaro bien sûr, et encore plus aux solutions communautaires (Jeedom, Domoticz, Home Assistant, etc...). Auront-il les moyens de se payer la certifications pour permettre à leur solution de s'intégrer dans l'écosystème ?

Yes, ça revient au même pris que j'avais payé le miens il y a 1 ou 2 mois

En fait là tes 2 règles ne sont pas validées. - 1ère règle : Days OK, mais Time KO (00:26 n'est pas entre 01:01 et 07:00 - 2nde règle : Time est OK, mais Days n'est plus bon (on est jeudi maintenant...) Lors de ton message précédent, les 2 conditions de ta 2nde règle étaient validées, mais c'était la durée qui ne l'était pas (voir GEA:check() difftime(0.0) < 30) Il fallait attendre 30 secondes de plus, au cycle suivant de GEA. Ce qui s'est probablement passé puisque tu dit qu'elle est passée en VALIDATION de couleur verte Pas de problème pour moi, je ne comprends pas bien les tests que tu as fait avec ton Wall Plug, mais le comportement me semble normal. En plus ce sont des règles assez standards.

Pareil que tout à l'heure, on ne voit le log que de la 2nde règle. Cependant cette fois-ci elle "matche" bien, les 2 conditions Days et Time sont valides (result = true), donc la règles est validée (ready = true). C'est normal, tu as fait le test mercredi (Wednesday), à 23:44 (entre 07:01 et 01:00). On ne voit pas la suite, mais GEA vérifie ensuite la durée pour déterminer s'il doit exécuter l'action. Je ne vois pas de problème en fait. Sinon tu as raison, je pense qu'on peut utiliser les jours en français, voici la fonction dans le code de GEA qui réalise le test des jours. Il faut juste qu'elle renvoie true, et il est trop tard pour que j'essaye de comprendre la logique, mais on voit des "trad" et "traduction" au nom assez explicite. function GEA:checkDays(days) if not days or days=="" then days = "All" end days = days:lower() local jours = days:gsub("all", "weekday,weekend") jours = jours:gsub(self.trad.weekdays, self.traduction.en.weekdays):gsub(self.trad.weekend, self.traduction.en.weekend) jours = jours:gsub(self.trad.week[1], self.traduction.en.week[1]):gsub(self.trad.week[2], self.traduction.en.week[2]):gsub(self.trad.week[3], self.traduction.en.week[3]):gsub(self.trad.week[4], self.traduction.en.week[4]):gsub(self.trad.week[5], self.traduction.en.week[5]):gsub(self.trad.week[6], self.traduction.en.week[6]):gsub(self.trad.week[7], self.traduction.en.week[7]) jours = jours:gsub("weekday", "monday,tuesday,wednesday,thursday,friday"):gsub("weekdays", "monday,tuesday,wednesday,thursday,friday"):gsub("weekend", "saturday,sunday") return tools:isNotNil(string.find(jours:lower(), os.date("%A", self.runAt):lower())) end

Ce n'est pas le LUA le problème. C'est le QuickApp. Fibaro n'a pas permis d'utiliser de trigger dans les QuickApp, uniquement dans les scènes. On a finalement trouvé que cette fameuse API refreshStates permet de détecter les événements, et de réagir instantanément. Ce ne sont pas des triggers, mais c'est tout comme.

Sur Jeedom ça n'a jamais fonctionné d'après les retours sur les forums, je pense que ce n'est tout simplement par supporté. Sur HC2 c'est censé fonctionner, c'est la base. Jamais testé perso, je n'ai pas de BSO.

Ben disons que l'utilisation de l'API refreshStates, c'est pas ce qu'il y a de plus facile à appréhender. Tu peux déjà lire le lien que je t'ai donné, et voir si ça te semble compréhensible.

@Nico c'est pas une version similaire à la tienne ? Si tu passes par là...

Merci pour le log détaillé, mais attention je pense qu'il manque le détail de la 1ère règle (qui se situe avant ta 1ère ligne de log), et à la fin tu a laissé le log de la règle suivante (qui fait un test de "Power"... donc rien à voir) En tout cas, on voit bien les logs de ta 2nde règle. {"Days", "Monday,Wednesday,Friday"} => est validé OK {"Time","07:01","01:00"} => n'est pas validé Donc à priori ça serait la condition d'heure qui ne matche pas, alors que la condition de jour est OK.

Non pas exactement, regarde plutôt ici pour différencier les deux versions du moteur Z-Wave : Je me rend compte à quel point Fibaro a mal communiqué (comprendre : "pas du tout" communiqué) auprès des utilisateurs, car vous êtes plusieurs à ne pas savoir. Il n'y a que les utilisateurs avertis qui suivent et lisent les notes de version des différents firmwares qui connaissent la différence. Pourtant ce nouveau moteur v3 est bien en beta depuis plusieurs mois, encore instable.

Il faut utiliser l'API refreshStates : Mais pas super facile.... je me demande si pour un scénario aussi simple, il ne serait pas préférable de toute simplement faire une scène, avec comme trigger ton bouton, et qui exécute l'action. Même pas besoin de boucle infinie. Ou GEA (en 2 lignes)

@Dragoniacs tu ne peux pas changer le type d'un module existant. Donc il faut bien que ça soit un nouveau QuickApp, qui gère le Qubino. Comme avant en fait.

Comme je le disais sur l'autre topic, j'ai finalement réussi à intégrer le support de l'injection dans le QuickApp Et j'ai aussi préféré tout partager d'un coup, car il faut supprimer l'ancien enfant Teleinfo, puis changer une ligne de configuration, puis le recréer, donc autant profiter d'une seule mise à jour pour tout faire d'un coup. Mais attention, c'est théorique, je n'ai pas pu le tester chez moi vu que mon compteur Linky est toujours en mode historique. Voici donc la version 1.20 du QuickApp GCE pour IPX800 et EDRT2 : Lorsque le QuickApp parent est désactivé (disabled), les enfants sont également désactivés automatiquement, et un message figure sous l’icône (log) => et donc exclus de DomoCharts Amélioration de l'état de nœud mort (dead) lors d'un problème de communication réseau Le QuickApp répond aux sollicitations de réveil (wakeUpDeadDevice) Ajout des nouveaux types EnergyMeter (com.fibaro.energyMeter) et PowerMeter (com.fibaro.powerMeter) Le type PowerSensor (com.fibaro.powerSensor) est déprécié par Fibaro et ne devrait plut être utilisé (mais il est toujours fonctionnel, comportement identique au nouveau type PowerMeter) Le type Teleinfo est maintenant de type "com.fibaro.energyMeter" afin d'être configurable comme Compteur d’énergie principal dans les paramètres de la HC3 Le type Teleinfo ne remonte plus la puissance apparence (en VA) dans sa propriété value (de toute façon c'était une information peu utile) Le type Teleinfo remonte l'index d'énergie (en kWh) dans sa propriété "value", et la puissance active (en W) dans sa propriété "power". Le type Teleinfo supporte l'injection dans le cas où le compteur Linky est paramétré en mode Standard Correctifs et améliorations divers Nouvelle syntaxe de configuration pour le type Teleinfo : Il faut maintenant spécifier pin = EAST (Energie Active Soutirée Totale) pour la value, à coté de argument et pin déjà existant (c'est valable qu'on soit en téléinfo Historique ou Standard) Eventuellement ajouter une seconde ligne Teleinfo avec pin = EAIT pour connaitre l'injection, uniquement si le compteur Linky est en mode Standard. Exemple : CONFIG = { {device = {name = "Consommation", type = "Teleinfo", options = {VG = "TELEINFO_Tarif"}}, value = {command = "Get", argument = "TI", pin = "EAST" }}, {device = {name = "Injection" , type = "Teleinfo" }, value = {command = "Get", argument = "TI", pin = "EAIT" }}, } Comme on peut le voir, s'il y a des options, il ne faut les mettre qu'une seule fois. Procédure de mise à jour si vous n'utilisez pas la Téléinfo : Mettre à jour les fichiers LUA du QuickApp avec la nouvelle version (copier/coller le contenu des 3 fichiers main, GCE, et tools) Procédure de mise à jour si vous utilisez la Téléinfo : Supprimer child device Teleinfo Mettre à jour les fichiers LUA du QuickApp avec la nouvelle version (copier/coller le contenu des 3 fichiers main, GCE, et tools) Modifier la ligne Teleinfo dans le fichier config pour ajouter : pin = EAST Eventuellement, ajouter une seconde ligne Teleinfo avec pin = EAIT pour l'injection Créer nouveau child device Teleinfo (cliquer sur le bouton dédié du QuickApp parent) Eventuellement, mettre à jour la base de données de DomoCharts via phpMyAdmin afin de refléter le changement d'ID (copier les lignes ci-dessous, modifier les 2 ID, et les coller dans la fenêtre SQL de phpMyAdmin ou équivalent) : -- Définition des ID : SET @OLD_ID = 285; SET @NEW_ID = 416; -- Requêtes SQL (ne pas toucher) : UPDATE IGNORE domocharts_power SET device_id=@NEW_ID WHERE device_id=@OLD_ID; UPDATE IGNORE domocharts_power_day SET device_id=@NEW_ID WHERE device_id=@OLD_ID; UPDATE IGNORE domocharts_energy SET device_id=@NEW_ID WHERE device_id=@OLD_ID; UPDATE IGNORE domocharts_energy_day SET device_id=@NEW_ID WHERE device_id=@OLD_ID; UPDATE IGNORE domocharts_device SET id=@NEW_ID WHERE id=@OLD_ID; UPDATE IGNORE domocharts_device_type SET device_id=@NEW_ID WHERE device_id=@OLD_ID; Téléchargement : Fichier main : GCE v1.20.lua Fichier GCE : Library - GCE v1.20.lua Fichier tools : Library - tools v2.20.lua

Les 14 To se seront les prochains qui partiront au rebut (*)... dès que les 20 To seront disponibles. (*) en réalité ils iront dans le serveur de backup, avec les 8 et 10 To que j'ai déjà retiré, car Google arrête le stockage illimité et gratuit dans le cloud, adieu les 34 To de backups en ligne Et j'ose pas imaginer le tarif s'il fallait payer....

70 To en ligne, il assure le vaillant Proliant Gen8

Pour info, bug identifié et confirmé par Fibaro concernant les entrées IN1 et IN2 du Smart Implant sur le firmware 5.093 BETA, il sera corrigé dans la prochaine version Beta : https://forum.fibaro.com/topic/58223-bug-in1-and-in2-from-smart-implant-dont-work-with-zw3-engine/ Je constate que tu as mis le numéro de série de ta box dans ton profil, essaye d'y mettre le numéro de version, ça sera plus utile. Par ailleurs j'aurais dû commencer par te demander quel moteur Z-Wave tu utilises, car là c'est le v3 qui est concerné. Pour rappel le moteur Z-Wave v3 est en Beta et ne dois pas être utilisé en production, il faut utiliser le moteur v2. (sauf si on sait ce qu'on fait) (Je le met en rouge pour que le message passe, car tu n'es pas le premier à tomber dans le panneau)

Hum, c'est une bonne idée et je n'avais pas du tout pensé à ça @MAM78, mais @flacon030 va te détester, car je viens de finir il y a 30 minutes la dernière version du nouveau QA... avec, ô surprise, la remonté d'injection car j'ai finalement réussi à l'intégrer dans le QA Du coup je suis obligé de reporter la publication du QA et d'ajouter les child devices multiPosition Ou alors plus raisonnable je partage en l'état et j'ajoute ça après....