Effectivement il serait intéressant d’avoir une information à minima en % de la mémoire disponible sur un dashboard.
L’attribution de la mémoire dans les dashboard est par ordre décroissant. Sur ma config, j’utilise des dashboard en fonction de l’usage.
J’ai mis en pièce jointe le dashboard qui est en limite de mémoire, il permet de gérer les automatisme (en particulier la lumière en Enocean).
Comme vous pouvez le constater il n’y as pas grand-chose. Mes premiers dashboard sont déjà bien fournis.
Malheureusement on atteint vite les limites de l’IPX 800 V4, je n’utilise pas de contrôle de volet de gestion de la lumière (X-PWM, Mylight) et pas encore l’ECO-DEVICES RT.
Une solution est d’acheter un 2° IPX800V4, ce n’est pas le top avec un échange d’informations par Ethernet (push).
Est-il possible d’augmenter la mémoire pour les dashboard les moins dotés ?
Est-il prévu une gestion d’IPX800V4 esclaves/maître par le bus V4 ?
Est –il prévu un IPX800 V5, une version avec plus de mémoire ?
Le fonctionnement du Widget Thermostat lié à une sonde de température EnOcean est maintenant opérationnel!
Un grand merci pour cette modification qui me permet maintenant de piloter correctement mon poêle à granulés.
Pas d’autres beugs constatés pour l’instant pour les fonctionnalités utilisées.
Lorsque j’utilise un seuil de l’entrée analogique d’un détecteur de mouvement la valeur enregistrée est différente.Pour les seuil haut je saisis 250 mais lorsque je fait sauvegarde du scénario la valeur enregistrée est différente.
Pour le seuil à priori cela ne pose pas de pb.
bonjour,
en beta 14 je souhaite récupérer la température de mon X-TLH avec les étiquettes PUSH.
Dans mon push j’utilise l’étiquette $THL01 => 30.30
Malgré l’utilisation des formules de conversion dispo dans le wiki, je n’arrive pas à mes 4.2°C
Pour info : X-THL
Analogue > Valeur
Luminosité : Aucune formule appliquée
Humidité : 125 * x / 65535 - 6
Température : 175.72 * x / 65535 - 46.85
Je fais quelques tests concernant le problème de détecteur de mouvement de @TRABAC et je publie une version dans la journée. Cette dernière corrigera les soucis d’étiquette THL (@youyoupapayou) et modifiera quelque peu la manière de gérer les actionneurs Enocean (notamment les double mais aussi potentiellement les simples qui posaient problèmes jusqu’alors). Cela pourra nécessiter un ré-enregistrement des actionneurs mais l’objectif reste d’être plus ouvert quand à ces technologies et ses variantes
Bonjour Maxime,
Etant en cours d’intégration des capteurs de présence, je me permets d’intervenir suite à votre message.
Si vous regardez le problème des détecteurs de présence, pourriez vous vérifier aussi la chose suivante:
Suivant le descriptif sur votre site GCE « En l’absence de mouvement détecté pendant une période de 2 minutes, il envoie un premier message radio de non présence. Puis un second message au bout de 10 minutes et un dernier au bout de 30 minutes »
Or, avec les capteurs achetés sur votre site, j’ai constaté qu’au bout de 2 mn il n’y a pas de message radio de non présence, mais uniquement au bout de 10mn (s’il n’y a pas eu de détection entre temps).
En analysant la doc livrée avec le capteur, je retrouve ce fonctionnement, mais cette doc dit aussi que si une présence est détectée après ces 2mn (et avant les 10mn), le capteur envoi de nouveau un signal de détection, et on repart pour une attente de 10mn.
Sauf erreur de ma part, L’IPX ne semble pas gérer ce nouveau signal de présence entre 2 et 10mn, et qu’il faille attendre un signal de non présence ( Soit 10mn plus tard ! ) avant de traiter un nouveau signal de présence.
Pourriez vous voir si ce fonctionnement est celui que vous aviez prévu ?
Pour ma part, utilisant ces capteurs dans une démarche de surveillance, mon souhait serait que l’IPX traite le signal de présence envoyé par le capteur quelque soit le moment ( Actuellement, 10 mn sont trop long entre 2 détections possibles )
Encore merci pour votre disponibilité
Bien cordialement
C’est la doc. du produit qui est dans le vrai. J’ai corrigé la description de notre site qui était en effet plus ambiguë.
Malheureusement ce n’est pas quelque chose que nous pouvons corrigé, ce n’est pas un produit que nous fabriquons. Sans le message indiquant qu’il n’y a plus de présence, il est impossible de contourner. Une temporisation de 2 minutes sur l’ensemble des capteurs poseraient en effet deux problèmes : une grande consommation de ressources mais aussi un soucis de fiabilité. En effet, s’il y a un mouvement dans les 2 premières minutes rien ne l’indiquera, le capteur est éteint (pour des raisons d’économies d’énergies).
La seule chose que nous pourrions faire serai de gérer le fait qu’il envoi un message régulièrement en cas de mouvement. En ce cas, nous pourrions travailler sur le même principe que le ON EVENT et remettre le capteur à 0 dès que la données est traitée dans le moteur de scénario. Il vous reviendrait ensuite de la gérer avec des temporisations (sorties virtuelles par exemple).
J’attends le retour de @Mario et d’autres utilisateurs concernant le détecteur de mouvement Enocean ainsi que vos retours concernant les soucis précédemment identifiés. J’espère que nous nous aurons une release pour Noël !
Je n’ai pas compris le problème de la tempo: Je suis conscient que le capteur est « éteint » durant les 2 premières minutes, mais comme il est capable d’envoyer des signaux de détections après ces 2 minutes, ne peut on pas imaginer le fonctionnement suivant:
Premier signal de détection: L’entrée analogique de l’IPX passe à 255, puis retombe à 0 au bout d’une petite période indépendamment du capteur. Ainsi, l’IPX serait disponible pour recevoir le prochain signal de présence dès l’émission suivante.( Un peu comme le fonctionnement d’un capteur de présence « tout ou rien » classique )
Mais ne connaissant pas les contraintes de développement ou les effets de bord de cette proposition, votre deuxième solution avec ON EVENT répond tout à fait au problème, et c’est OK de mon côté pour la tester.
Vraiment, merci encore de votre réactivité !
Le problème est ici ce que vous appelez une petite période. En effet, s’il s’agit d’une période indépendante sur chaque capteur, même si elle n’est pas personnalisable, cela consommera énormément de ressources (il faudrait timer un potentiel de 24 entrées analogiques…).
La solution que je proposais aurait le fonctionnement suivant : la sonde passe à 255, si elle est traitée dans UNE scène, cette scène la remet à 0 IMMÉDIATEMENT (si une seconde scène veut traiter l’info il sera trop tard). Si elle n’est pas dans une scène le comportement est le même qu’actuellement.
Concrètement dans une situation normal il suffirait d’assigner une sortie virtuelle à votre capteur (capteur ON SV), de lui mettre le Tb que vous souhaitez (pour la tempo souhaitée) et de ne plus tenir compte de la valeur du capteur (qui serait remise immédiatement à 0) mais de la SV attribuée pour vos automatisations.
Si cela vous convient et que je n’est pas d’avis contraire, je vous ferai parvenir une version en MP pour valider et elle fera office de base pour la beta 16
Bonjour Maxime,
bien reçu la beta16 que je viens d’installer
Ça ne marche pas encore, la scène ne remet pas à zéro l’entrée analogique, il faut tjs attendre les 10 mn.
Ce que j’ai fait:
Affichage widget Entrée analogique pour vérifier la valeur 0 ou 255 du capteur de déplacement
Affichage widget:Indicateurs sortie virtuelles pour vérifier exécution du scénario
Création scénario: Evènement:Entrée analogique (Seuil H=250 et seuil B=20; Action:ON/OFF; résultat:Sortie virtuelle avec TA=0 et TB=60
Au premier déclenchement:
Valeur entrée analogique passe à 255
Indicateur sortie virtuelle passe à ON pendant 60 secondes ( La scène est donc bien lancée )
l’entrée analogique reste à 255
Pour info, je retrouve le bug de la beta14 ( Pb valeurs seuils de déclenchement de l’entrée analogique )
Bug affichage GSM → OK
Seuil haut sur entrée analogique dans une scène → la valeur n’est pas sauvegardée.
Suivit conso Wall plug UBID1001 et Nodon → pas de variation ils restent à 0.
Dimer Nodon 2 relais → fonctionnement en individuel RAS, par contre dans une scène ou l’on veut activer les 2 relais en même temps → fonctionnement aléatoire
Je n’ai jamais réussi à reproduire les soucis d’enregistrement de seuil haut.
Pour ce qui est des technos Enocean, les tests réalisés ici n’ont jamais posé de problème que ce soit en pilotage (scène ou autre) qu’en retour de consommation. Comme nous l’avions annoncé, nous regarderons en priorité les problèmes provenant des produits que nous vendons.
Je vous invite donc à ouvrir un ticket sur notre helpdesk à la fois pour les seuils hauts et pour les prises Enocean, nous regarderons d’où tout cela peut venir.
PS : petite précision sur les prise, elle n’affiche pas les très faible consommations.
béta 15 suite : X-THL vers Notifix → les valeurs remontées semblent cohérentes
je ferai des investigation plus poussées la semaine prochaine pour le matériel ENOCEAN.
J’achète mes produits en priorité sur le site GCE, concernant les Dimer Enocean j’ai anticipé.
Pour le Wall plug Nodon, il est raccordé sur une lampe de faible consommation, je ferai un essai avec un convecteur.
Pour le suivit de conso, le Wall plug UBID1001 a remonté des consos jusqu’à la béta 13.
Je vais ré-appairer les Wall plug et Dimer.
Pouvez vous m’indiquer la procédure pour appairer les Dimer Enocean (2relais) ?
J’arrive à appairer le premier relais, mais lorsque je passe au deuxième, la fonction appairer de l’IPX n’a aucun effet, par contre les 2 relais fonctionnent avec l’IPX.
:
!