Thermostat KNX DPT 9.002
#1
Bonjour à tous,

Je suis bloqué par une limitation du module thermostat dans DS. L'écriture de la valeur de température de confort est en DPT 9.001; °C, et n'est pas modifiable. Ce DPT envoie la valeur de température (20°, 20,5, 21 …), ce qui est un type de fonctionnement des thermostats KNX simples.

Mes Thermostats KNX Fonctionnent en offset de température donc DPT 9.002; K. (ont travaille avec l'incrément +0,5)) … et donc les ordres venant de Lifedomus ne donnent pas le résultat espéré (les thermostats KNX attendent un déplacement mais reçoivent une valeur de température).

Il faudrait dans l'Ideal avoir le choix entre les 2 modes de fonctionnement des thermostats KNX; mais y a t'il encore des Dev ?

Est ce que d'autres utilisateurs ont déjà fait face à ce problème ?
Répondre
#2
Bonjour,

Mes thermostats KNX supportent les 2 types de valeurs DPT 9.001 et DPT 9.002 donc je n'ai pas été bloqué par cette limitation de DS.

Désolé car je sais que ma réponse ne te sera pas très utile.

Daniel
Répondre
#3
Bonsoir Jdrenne, 

J'ai un peu le même problème que toi, pour l'instant j'ai laissé en l'état mais il faudra que je m'y attaque un jour (probablement via un automate LD ou un futur module logique ABB).

J'ai un interrupteur Glass Push Buttons II Smart et un thermostat Zennio en plus du LifeDomus.

En mode "Consigne Absolues" = DPT 9.001 pas de problème avec LD mais cela ne fonctionne pas correctement avec l'interrupteur MDT (il ne gère que la consigne relative)
En mode "Consigne Relatives" = DPT 9.002 c'est l'inverse...

J'envisage donc de rester en consigne relatives en recalculant à chaque changement via un automate la consigne absolue pour envoyer l'info à LD car comme tu dis les devs ont l'air d'avoir déserté...
Répondre
#4
(01-31-2020, 10:29 PM)aureOhwo a écrit : Bonsoir Jdrenne, 

J'ai un peu le même problème que toi, pour l'instant j'ai laissé en l'état mais il faudra que je m'y attaque un jour (probablement via un automate LD ou un futur module logique ABB).

J'ai un interrupteur Glass Push Buttons II Smart et un thermostat Zennio en plus du LifeDomus.

En mode "Consigne Absolues" = DPT 9.001 pas de problème avec LD mais cela ne fonctionne pas correctement avec l'interrupteur MDT (il ne gère que la consigne relative)
En mode "Consigne Relatives" =  DPT 9.002 c'est l'inverse...

J'envisage donc de rester en consigne relatives en recalculant à chaque changement via un automate la consigne absolue pour envoyer l'info à LD car comme tu dis les devs ont l'air d'avoir déserté...

Bonjour,

Je suis dans le même cas que toi, des Zennio et des MDT. Aucun problème avec les Zennio, mais mauvais fonctionnement avec les MDT en mode Consigne absolue (ils savent le faire, il faut pour cela parametrer le "Temperature shuft" avec "2Byte shift of basis comfort setpoint value".
LE PROBLEME, c'est qu'il ne se base pas sur la temperature de consigne actuelle mais sur le parametre "Lower limit"... Donc par exemple, si la consigne actuelle est de 19° et que tu as codé le "Lower limit" à 7°, quand tu vas appuyer sur + ta consigne va passer de 19 à 7 ...


Pour moi c'est un bug, et je travaille avec MDT dessus depuis une semaine; je dois être mis en contact avec la R&D lundi.


Mais bon, si ces 2 modes de fonctionnements étaient prévus dans LD ce serait mieux, car le mode "Consigne relative en DPT 9.002 est le mode de fonctionnement professionnel comparé à l'autre qui est simpliste.
Répondre
#5
(02-01-2020, 09:16 AM)jdrenne a écrit :
(01-31-2020, 10:29 PM)aureOhwo a écrit : Bonsoir Jdrenne, 

J'ai un peu le même problème que toi, pour l'instant j'ai laissé en l'état mais il faudra que je m'y attaque un jour (probablement via un automate LD ou un futur module logique ABB).

J'ai un interrupteur Glass Push Buttons II Smart et un thermostat Zennio en plus du LifeDomus.

En mode "Consigne Absolues" = DPT 9.001 pas de problème avec LD mais cela ne fonctionne pas correctement avec l'interrupteur MDT (il ne gère que la consigne relative)
En mode "Consigne Relatives" =  DPT 9.002 c'est l'inverse...

J'envisage donc de rester en consigne relatives en recalculant à chaque changement via un automate la consigne absolue pour envoyer l'info à LD car comme tu dis les devs ont l'air d'avoir déserté...

Bonjour,

Je suis dans le même cas que toi, des Zennio et des MDT. Aucun problème avec les Zennio, mais mauvais fonctionnement avec les MDT en mode Consigne absolue (ils savent le faire, il faut pour cela parametrer le "Temperature shuft" avec "2Byte shift of basis comfort setpoint value".
LE PROBLEME, c'est qu'il ne se base pas sur la temperature de consigne actuelle mais sur le parametre "Lower limit"... Donc par exemple, si la consigne actuelle est de 19° et que tu as codé le "Lower limit" à 7°, quand tu vas appuyer sur + ta consigne va passer de 19 à 7 ...


Pour moi c'est un bug, et je travaille avec MDT dessus depuis une semaine; je dois être mis en contact avec la R&D lundi.


Mais bon, si ces 2 modes de fonctionnements étaient prévus dans LD ce serait mieux, car le mode "Consigne relative en DPT 9.002 est le mode de fonctionnement professionnel comparé à l'autre qui est simpliste.
Pourquoi tu fais pas un automate que va te prendre le +0.5 et le rajouter à la température de consigne actuelle  pour envoyer la nouvelle température à ton régulateur ?
Le perfectionnement de soi et l'accession à sa légende personnelle passe obligatoirement par le partage de son savoir et de son expérience avec les profanes en demande d'initiation. (R. Bach)
Répondre
#6
(02-01-2020, 11:01 AM)Pollux06 a écrit :
(02-01-2020, 09:16 AM)jdrenne a écrit : Bonjour,

Je suis dans le même cas que toi, des Zennio et des MDT. Aucun problème avec les Zennio, mais mauvais fonctionnement avec les MDT en mode Consigne absolue (ils savent le faire, il faut pour cela parametrer le "Temperature shuft" avec "2Byte shift of basis comfort setpoint value".
LE PROBLEME, c'est qu'il ne se base pas sur la temperature de consigne actuelle mais sur le parametre "Lower limit"... Donc par exemple, si la consigne actuelle est de 19° et que tu as codé le "Lower limit" à 7°, quand tu vas appuyer sur + ta consigne va passer de 19 à 7 ...


Pour moi c'est un bug, et je travaille avec MDT dessus depuis une semaine; je dois être mis en contact avec la R&D lundi.


Mais bon, si ces 2 modes de fonctionnements étaient prévus dans LD ce serait mieux, car le mode "Consigne relative en DPT 9.002 est le mode de fonctionnement professionnel comparé à l'autre qui est simpliste.
Pourquoi tu fais pas un automate que va te prendre le +0.5 et le rajouter à la température de consigne actuelle  pour envoyer la nouvelle température à ton régulateur ?

Parceque je ne pourrai plus utiliser les Thermostats LD, il me faudra tout recréer avec des painter…
Répondre
#7
(01-31-2020, 10:29 PM)aureOhwo a écrit : J'ai un peu le même problème que toi, pour l'instant j'ai laissé en l'état mais il faudra que je m'y attaque un jour (probablement via un automate LD ou un futur module logique ABB).

L'ABB ABA/S 1.2.1 ne dispose que d'un bloc pour la conversion directe de données (ensuite il est possible d'utiliser les blocs mathématiques (addition, soustraction, multiplication, division). Voici ses propriétés :
[Image: 200201112609778197.jpg]
Répondre
#8
Merci pour vos idées, manque de bol ETS n'est pas en forme pour tester ça, je ferai un retour une fois que j'aurai pu mettre en place quelque chose  Eek-1e6fb
Répondre
#9
MDT m'a donné un "workaround" qui fonctionne, donc nous pouvons utiliser les BP MDT Smart programmé en déplacement de température de consigne absolue.

En revanche tout ne fonctionne pas car le produit est Buggé.

Si comme moi vos thermostats KNX (Zennio) permettent de mémoriser les modifications des utilisateurs (ex: mode chauffage de base = 19°, l'utilisateur le passe à 20°, le thermostat mémorise cela, et donc quand ont change de mode, au retour sur confort nous aurons une consigne de 20 et non de 19).

Ce fonctionnement ne marche pas avec les BP MDT Smart en mode déplacement de temp absolue (mais fonctionne en relatif).

Mon analyse et ma compréhension suite aux très nombreux échanges avec MDT, c'est que MDT a focalisé sur le shift relatif en K, et a "chier" le shift absolu car ça es intéresse pas.

Ils sont très rigides (teutons) et donc j'ai peu d'espoir qu'ils corrigent le bug.
Répondre




Utilisateur(s) parcourant ce sujet : 1 visiteur(s)