Bug Transmetteurs

[Julien]

Bonjour,

La "difficulté" de la programmation du EnOcean vient du fait que nous avons voulu apporter du retour d'états dans un protocole qui n'en avais pas.
Il est tout à fait exact que le choix de na pas pouvoir associer les interrupteurs aux commutateur était une erreur que nous pourrions être amené à faire évoluer.

Qu'appelez vous "introduction directe des valeurs" ?

Julien

[tilleul]

Julien a écrit :Bonjour,

La "difficulté" de la programmation du EnOcean vient du fait que nous avons voulu apporter du retour d'états dans un protocole qui n'en avais pas.
Il est tout à fait exact que le choix de na pas pouvoir associer les interrupteurs aux commutateur était une erreur que nous pourrions être amené à faire évoluer.

Qu'appelez vous "introduction directe des valeurs" ?

Julien

Je crois que pour ce qui concerne l'appairage (qui pour moi est inutilement compliqué sur LD) vous devez vous inspirer de ce que fait Weinzierl avec ses modules KNX/ENO 634, c'est
simple, clair, transparent autant en entrée qu'en sortie. N'hésitez pas au moment de l'appairement à afficher en même temps le debug des télégrammes, ca simplifie vraiment la vie.

En ce qui concerne le retour d'état que LD a choisi de "simuler" ca part d'une bonne intention mais c'est clairement une erreur si ca a complexifié la gestion des modules. En outre, il y a de plus en plus de modules avec retour d'état et ca se généralise de marque en marque donc je pense qu'on peut laisser tomber la "simulation" LD.

[Ludwigp94]

A première vu, n'hésitez pas à faire évolué les choses car nous sommes nombreux à pouvoir tester et validé ces évolutions. Ce protocole est prometteur dans les maisons passives et les locaux d'entreprises il est donc intéressant d'avoir un système clair et simple pour ne pas perdre de temps sur cette intégration.

[raffar]

Pour les valeurs directes ma réflexion allait dans le sens de ce que tilleul présentait, le scan de tout ce qui passe y compris LD d'un côté et la boite de dialogue de ce que l'on attend de LD de l'autre. Le processus d'apairage est parfois obscur, un appairage 'manuel' copier coller/glisser deposer prend moins de temps qu'un automatique qui ne dit pas ce qu'il fait.

je le rejoins également sur la simulation du retour d'état, il vaut mieux dire 'message envoyé' que 'lampe allumee' , si l'utilisateur est sûr à 100% de ses transmissions il forcera le message. Mais EnOcean c'est rarement 100% LD ne peut pas compenser ce défaut qui ne lui appartiens pas.

[Ludwigp94]

Dans le même ordre, comment on utilise un Inter NodOn pour commander un store vu qu'il est géré comme une Lampe? Vu l'expérience sur un variateur, l'inter fait sa variation sur le temps de relachement mais c'est en association directe entre le module et l'inter, en mode lampe je récupère que du 0-1 sur l'état de la lampe dans mon script, pas moyen de faire une variation et donc pas moyen de faire monté un store tant que j'appui sur monté jusqu'au relachement en passant par lifedomus.

[Ludwigp94]

Sérieusement quelqu'un à déjà réussi à utilisé des inter EnOcean comme monté/descente de store en dehors de 0% = Off et 100%= On ... j'ai fait un bout d'automate mais c'est du suicide si je sort ça a un client. Je peut l'associé directement à un contrôleur EnOcean mais dans ce cas pas besoin d'avoir une LifeDomus en intermédiaire et surtout je me complique la vie avec une gestion des retours d'info pour renvoyer vers une autre appli qui a besoin de connaitre la position du Store ! Bref, a quand un mode normal de gestion des Inter EnOcean?