yves.guern Posté(e) le 13 avril 2023 Signaler Posté(e) le 13 avril 2023 (modifié) Bonjour, J'utilise des modules Z-Wave 'intelligents' Z-uno2 (à base d'arduino pour faire court). Ils sont équipés d'un composant RTC que j'aurais besoin de mettre à l'heure. Au moment de l'inclusion d'un module dans le réseau Z-wave du HC3 cela fonctionne, et le RTC est mis à l'heure de la HC3 par une Command Class Time Parameters (0x8B/139). Mon problème est que cette information ne semble envoyée par la HC3 que au moment de l'inclusion : Si le module est reseté ou redémarre après une perte de puissance, la mise à jour de l'heure ne se fait pas. Question: comment forcer HC3 à envoyer cette 'Command Class' ? Le sujet est pointu, je vous remercie par avance! Modifié le 13 avril 2023 par yves.guern
Lazer Posté(e) le 13 avril 2023 Signaler Posté(e) le 13 avril 2023 Tu devrais peut-être poser la question sur le forum officiel, avec un peu de chance tu auras une réponse, car en effet la question est pointue. Même si j'ai peu d'espoir que ça soit possible, pas sûr que Fibaro ait prévu ce cas de figure... ou alors via une API (bien) cachée.
yves.guern Posté(e) le 13 avril 2023 Auteur Signaler Posté(e) le 13 avril 2023 Merci Lazer, Yes! I will ask the official one. Mais bon, je suis en train de lentement changer mon fusil d'épaule pour utiliser un paramètres de configuration... Au passage, cela est mon dernier espoir, dans les devices du home Center 3 il y a un champ interfaces qui contient une liste un peu mystérieuse, on a l'impression que cela pourrait définir une liste d'UI dans l'IHM web? Quelqu'un connait la liste des interfaces possibles? A+
Lazer Posté(e) le 13 avril 2023 Signaler Posté(e) le 13 avril 2023 Voir ici pour ajouter une interface : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/8/#comment-202936 Et ici @tinman s'est lancé dans une exploration des interfaces existantes et de leur impact sur les propriétés des devices : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/58/#comment-227370 Mais voilà, le truc c'est que ça agit sur les propriétés des devices (visibles dans leur JSON, et peut également altérer le visuel dans l'IHM), mais pas sûr que ça puisse t'aider dans la communication avec le module Z-Wave.
jojo Posté(e) le 16 avril 2023 Signaler Posté(e) le 16 avril 2023 et est-ce que une reconfiguration douce du device ne transmettrait pas cette class ? si oui, il faudrait voir si on ne pourrait pas automatiser ceka ? Autre idée : cette class serait-elle transmise au démarrage de la box (ou exclusivement lors de l'inclusion ?) =Tests
yves.guern Posté(e) le 16 avril 2023 Auteur Signaler Posté(e) le 16 avril 2023 Merci à vous deux! @lazer: je suis déçu de ne pas avoir vu une zwaveInterfaceTime dans la liste ... @jojo: Le redémarrage de la box ne donne rien. La reconfiguration douce est douce mais reste un process lourd que je ne me vois pas effectuer sur une base régulière, j'ai peut être tort? Je teste depuis 48h l'utilisation d'un paramètre de configuration pour transmettre l'heure unix. Cela fonctionne plutôt bien. Finalement à part que cela use l'eeprom cela me semble une solution viable (et pérenne). Bonne soirée.
Lazer Posté(e) le 16 avril 2023 Signaler Posté(e) le 16 avril 2023 il y a 4 minutes, yves.guern a dit : La reconfiguration douce est douce mais reste un process lourd que je ne me vois pas effectuer sur une base régulière, j'ai peut être tort? Je pense que tu n'as pas tort, la reconfiguration douce ça communique "lourdement" avec le module, donc micro-saturation temporaire du réseau Z-Wave, ce qui n'est jamais bon. Et ça triture aussi la base de données dans la box HC3, donc à un moment ça peut amener des potentielles corruptions (comme ça a été le cas dans le passé chez Fibaro...) il y a 6 minutes, yves.guern a dit : Je teste depuis 48h l'utilisation d'un paramètre de configuration pour transmettre l'heure unix. Cela fonctionne plutôt bien. Finalement à part que cela use l'eeprom cela me semble une solution viable (et pérenne). L'idée de passer par un paramètre est bonne, mais si au niveau de l'Arduino tu n'as aucun moyen d'intercepter le nouveau paramètre sans éviter l'écriture sur l'Eeprom, il est clair qu'elle va s'user... après 1 fois toutes les 48h ça me parait acceptable.
yves.guern Posté(e) le 19 avril 2023 Auteur Signaler Posté(e) le 19 avril 2023 Bonjour Lazer, Ton idée est la bonne... J'ai détourné le handler des parametres de configuration du module Z-wave et il n'écrit plus dans l'eeprom pour certaine adresses. Plus aucun remords.... PS : qui mériterais peut-être un nouveau sujet, à propos d'usure: Sur quoi sont sauvegardés les variables globales (et celles des QAs) ? Sur mon HC2 j'avais pris l'habitude de réécrire le moins possible les variables globales préférant utiliser les 'ui' (logtemp par ex) pour échanger entre VD et entre VD et scènes. J'ai vu parfois dans ce site (et l'officiel) des codes qui échangent 'à haute cadence' des données par variables globales, cela me chiffonne... Bonne journée
Lazer Posté(e) le 19 avril 2023 Signaler Posté(e) le 19 avril 2023 C'est un sujet qui a été souvent abordé par le passé. Depuis la HC2, puis la HC3, j'ai toujours eu le réflexe de limiter autant que possible les écritures. Tout ce qui est stocké dans la box l'est sur son SSD interne (sur HC2 il avait la forme d'une clé USB interne, sur HC3 c'est une puce soudée sur la carte mère... comme sur les smartphones ou les PC ultra-portables de la marque à la pomme) Donc ce sont des cellules Flash, qui s'usent. Même si l'algo interne du SSD va répartir les écritures sur l'ensemble des cellules (wear-leveling), la durée de vie n'est pas infinie. Par expérience en 10 ans de box HC2, sur le forum on en a vu très peu dont le SSD est arrivé en fin de vie (ce sont d'autres composants qui meurent avant, dans cet ordre : alimentation, pile du BIOS, carte mère) Bref c'est toujours une bonne idée de limiter les écritures. Pour l'usure, mais aussi pour les performances. En effet j'avais fait un benchmark il y a pas mal de temps, il y avait un rapport de l'ordre de 1 à 10 entre une lecture et une écriture. Donc tous mes codes font une lecture préalable de l'ancienne valeur, et n'écrivent la nouvelle que si elle est différente. Bien plus efficace ainsi. A noter sur sur HC2 les labels des modules virtuels sont persistants (stockés dans la DB), donc même problématique que les variables globales. Sur HC3 en revanche, les labels des QuickApps sont éphémères, ils ne sont pas stockées. Le recours aux variables globales est devenu très rare, car la communication inter-QuickApps peut se faire directement par passage d'arguments lors d'appels d'une fonction, bien plus efficace ainsi.
yves.guern Posté(e) le 19 avril 2023 Auteur Signaler Posté(e) le 19 avril 2023 Bonsoir Lazer, la communication inter-QuickApps peut se faire directement par passage d'arguments lors d'appels d'une fonction Tu parles bien des publish/subscribe (et des events) de jgab (https://forum.fibaro.com/topic/54538-fibaroextra/) Ou il y a qqchose de mieux que je n'ai pas encore trouvé? Merci
Lazer Posté(e) le 19 avril 2023 Signaler Posté(e) le 19 avril 2023 Je n'ai pas regardé le fonctionnement de ses librairies. Je parlais juste du fonctionnement de base des QuickApps sur HC3. Chaque fonction peut recevoir les arguments de notre choix, et ça c'est cool. Par contre il y a une limitation, une fonction appelée dans un autre QA ne peut pas retourner une valeur. Il me semble que les mécanismes proposés par @jang permettent cela. (une fonction appelée dans le même QA peut bien retourner une valeur en revanche, ça marche)
yves.guern Posté(e) le 19 avril 2023 Auteur Signaler Posté(e) le 19 avril 2023 Bonsoir Lazer, Chaque fonction peut recevoir les arguments de notre choix Oui, cela c'était assez clair dans mon esprit, encore que, envoyer des paramètres à une QA c'est (presque) écrit dans la doc, en recevoir c'est beaucoup moins clair pour mes premiers pas dans HC3!!. Ce que propose 'fibaroExtra' au travers de publish/subcribe/event c'est qu'une QA (ex: un arrosage) soit au courant des toutes dernières nouvelles (ex: une météo) au moment où elle sont disponibles, sans 'efforts' et sans écriture/lecture disque. Le fait que 2 (ou plus) QAs n'aient pas besoin de connaitre leur ID pour échanger est un gros plus (et pas que en court de développement). Bref, je trouve cela 'cool' (pour le 'disque') et finalement bien dans la philosophie des QA : ie complètement asynchrones, faire avec ce qui est disponible à To est plus efficace qu'attendre To+x un retour d'erreur... Et Dieu sait que mon passé de systèmes temps réel et mon cerveau ont du mal avec l’asynchrone . Bonne soirée
yves.guern Posté(e) le 20 avril 2023 Auteur Signaler Posté(e) le 20 avril 2023 Ok mon message n'est pas clair... Il tentait de faire de la publicité à deux fonctions inclues dans FibaroExtra qui permettent d'échanger des données de façon simple, avec un code lisible. L'idée c'est que la QA qui a quelque chose à dire utilise une fonction publish qui va déclencher un event dans toutes les QA qui se seront abonnées au préalable avec la fonction subscribe. Il n'y a pas besoin de connaitre l'Id des destinataires ni même leur nombre, et rien ne se passe sur le 'disque'. (cf https://forum.fibaro.com/topic/54538-fibaroextra/#comment-233510) J'utilise 'beaucoup' et cela fonctionne bien. Il faut juste que le code des QA abonnées soit compatible d'une réception asynchrone des informations. Voilà voilà
jang Posté(e) le 20 avril 2023 Signaler Posté(e) le 20 avril 2023 Oh, finally someone discovered that function :-) Yes, it's really cool and quite efficient as the publisher only sends to subscribers actually subscribing on the event (source filtering). Also it works well with the fibaroExtra event mechanism that makes it easy to work with HC3 device and internal events.
jang Posté(e) le 20 avril 2023 Signaler Posté(e) le 20 avril 2023 (modifié) ...it's kind of an mqtt mechanism between QAs... but with a much simpler api... Modifié le 20 avril 2023 par jang 1
Messages recommandés