Lazer

Je déplace dans HC3 car ton problème n'est pas lié au QuickApp mais au panneau d'énergie de la HC3.

Désolé je n'ai pas d'explication, je ne maitrise pas encore ce nouveau panneau, et je n'ai de toute façon pas de production.

Bienvenue sur le forum

@henri-allauch repose tes questions sur le topic Hikvision

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 ?

Citation

La Connectivity Standards Alliance qui développe et promeut Matter rappelle que la sécurité et la confidentialité sont des points clés dans la définition de cette nouvelle norme. Elle est construite en prenant ces aspects en compte par défaut à la conception. Il ne s’agit pas d’une simple option que l’on peut activer sur les objets connectés, bien au contraire. C’est un engagement important que fait la CSA en créant Matter afin que celle-ci puisse non seulement rassurer les futurs clients que nous sommes, mais qu’elle puisse également fonctionner avec des principes de haute sécurité lui permettant de rendre les services attendus.

C'est une bonne nouvelle.

Citation

C’en est fini des fabricants opportunistes qui souhaitent bénéficier d’une supposée compatibilité pour tenter de vendre des produits douteux ou pire infiltrer le réseau de votre maison connectée. La certification est obligatoire et elle sera exigée et vérifiée lors de l’installation.

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....