(16/04/2020, 18:52:19)filou59 a écrit : ..........
Si j'ai bien compris quand on est en mode 6bytes , on recoit l'info du compteur sur 4 byte et l'info du tarif sur 2 byte, du coup n'importe quel système sachant interpretter des mots sur 4bytes fera l'affaire.
Ce que je ne comprend pas en fait c'est pourquoi tu n'arrivais pas a t'en sortir en passant en mode 4 byte ?
Le TE331 envoi dans ce mode les 2 info des tarif sur 2 mots différent, T1 et T2. Du coup tu as tout ce que tu as besoin non ? En combinant ca avec l'info tarif en cours tu dois obtenir le même resultat qu'en 6 bytes ?
Pas tout à fat Filou et je t'explique dans le détal le vrai problème au sens purement informatique et logique :
Chez un particulier lambda tu as généralement 2 index tarifaires : heures pleines et heures creuses autrement appelé mode jour ou nuit.
Mais car il y a un mais sinon ce ne serait pas drôle tu peux avoir 6 index différents : bleu / blanc / rouge en mode plein ou creux dans chacune des couleurs.
Donc imagine si tu es en triphasé + mode bleu/blanc/rouge ce sera 24 consommations différentes que tu vas monitorer auxquelles certains puristes vont ajouter les consos actives et réactives dans chacun des modes.
Quand on est en mode 4 bytes, on a un objet indiquant le tarif en cours et un second objet donnant la consommation totale
depuis le dernier reset. Donc aucune indication sur la conso par index tarifaire à moins de guetter le changement de tarif, mémoriser la conso juste avant le changement, faire un reset de la conso, ........ bref un véritable bordel surtout qu'il peut y avoir plusieurs changements d'index dans la même journée.
En mode 6 bytes, c'est le participant qui fait les calculs de consommation en fonction des index reçus en télé-information. Ensuite cycliquement le participant envoi les conso en rafale selon la norme du DPT 235.001 à savoir une valeur sur 6 bytes les 4 premiers étant la conso, le cinquième l'index et le sixième étant inutilisé.
A ma connaissance seul DOMOVEA est capable de gérer ce type de DPT. Tous les autres superviseurs en sont incapables car aucun d'entre eux ne sait gérer les tableaux à plus de 2 dimensions (GA en ordonnée et valeur en abscisse). Or le système du DPT 235.001 est que l'on reçoit toutes les infos de consommation sur
une seule et unique GA. A la charge de "l'utilisateur" de distribuer les consos en fonction des index. Chaque fois que le participant déclenche l'envoi des infos de consommation, il envoi les unes derrière les autres la consommation pour CHAQUE index dans des télégrammes séparés (donc 24 télégrammes avec la même GA de diffusion pour une install triphasée + bleu/blanc/rouge).
A l'époque ou je tournai avec KNXWEB, comme on pouvait lancer des scripts LUA j'avais écrit une routine qui permettait d'extraire la conso et l'index et de les retourner à KNXWEB. Malheureusement, j'ai vite déchanté car si le LUA est installé sur une machine 32 bits (Raspberry par exemple) on ne peux pas travailler sur une variable numérique dont la taille est supérieure à 4 octets soit 32 bits.
Donc pour le moment on est totalement piégé entre 2 solutions qui ne servent à rien :
- Travailler en 4 bytes sans pouvoir faire le distinguo entre les différents index et se baser sur une conso quotidienne globale sans plus.
- Travailler sur 6 bytes et être incapable de décoder les datas.
Les DPT 229.001 et 235.001 qui ont la même architecture sont essentiels si on chercher à optimiser les consommations au sein d'un bâtiment ..... mais hormis Hager les autres fabricants de superviseurs sont incapables d'exploiter ce type de DPT.
PS : sur le TE330 il n'y a même pas les objets 47 et 48. On s'arrête au 36
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)
![[Image: 200405014535337824.jpg]](https://www.casimages.com/i/200405014535337824.jpg.html)
