Forum Domoticz en français

Bonjour @xbu05400,

Il n'y a pas a attendre trop longtemps normalement. Si vous êtes en débug, vous devez avoir dans les logs :
2020-11-24 23:01:43.197 (D2L) Processing 'ReadEvent' message
2020-11-24 23:01:43.197 (D2L) Received 480 bytes of data
...
2020-11-24 23:01:43.198 (D2L) Pushing 'onMessageCallback' on to queue
2020-11-24 23:01:43.198 (D2L) Processing 'onMessageCallback' message
2020-11-24 23:01:43.198 (D2L) Calling message handler 'onMessage'.

Si vous n'avez pas ces logs, votre module ne communique pas avec votre serveur domoticz pour une raison ou une autre (pb configuration module, pb réseau (dont pb pare feu), etc).

ping a écrit : 04 déc. 2020, 13:20 Bonjour @Antori91,
J'allais justement répondre la même chose. J'allais vous demander de vérifier si un dispositif Intensité n'avait pas été créer par hasard avec des valeurs importantes vers cette heure ci. Le problème, c'est que le module est sensé envoyer un champ IINST pour le monophasé et IINST1, IINST2,IINST3 pour le triphasé mais il envoi toujours IINST1,IINST2,IINST3 avec IINST2 et IINST3 à 0 pour le monophasé. Je vais juste retenir si j'ai déjà reçu IINST2 ou IINST3 !=0 et traité comme triphasé si c'est le cas quelque soit la valeur de IINST2 et IINST3.

C'est effectivement une des deux solutions auxquelles j'avais pensé. Mais cette solution ne reste pas sans problème potentiel, à savoir si par malchance lorsque le plugin démarre pour la première fois chez un abonné triphasé avec IINST2 et IINST3 nulles à ce moment du démarrage du plugin. Vous allez créer le device LINKY - L1 Instantaneous current qui n'a pas lieu d'être chez un abonné triphasé…
Ma seconde solution, qui n'est guère plaisante mais plus robuste, consiste à demander à l'utilisateur dans les paramètres entrés dans Domoticz la nature de son abonnement (monophasé ou triphasé)

ping a écrit : 04 déc. 2020, 13:20 Pour les trames courtes, je ne sais pas si elles sont géré par le module et si c'est le cas, comment elles sont gérées. Les champs étant dans le message, j'imagine qu'il les envoie s'il les a reçu (après, es-ce qu'il le fait tout de suite ou es-ce qu'il attends la fin de la minute, il faut demandé à eesmart). Pour le champs _TYPE_TRAME, comme les autres champs préfixés par _, c'est le module D2L qui l'ajoute. Je pense qu'il ne peux valoir que HISTORIQUE ou STANDARD. Pareil, il faudrait vérifié avec eesmart.

Je me propose de poser la question à eeSmart

@Ping
Le debug ne voulant pas rester j'ai supprimé et re-créé le matériel et la j'ai bien bien le debug ...
j'ai actuellement :
2020-12-04 13:49:18.956 (Mon D2L) Pushing 'onHeartbeatCallback' on to queue
2020-12-04 13:49:18.976 (Mon D2L) Processing 'onHeartbeatCallback' message
2020-12-04 13:49:18.976 (Mon D2L) Message handler 'onHeartbeat' not callable, ignored.
2020-12-04 13:49:28.957 (Mon D2L) Pushing 'onHeartbeatCallback' on to queue
2020-12-04 13:49:28.996 (Mon D2L) Processing 'onHeartbeatCallback' message
2020-12-04 13:49:28.996 (Mon D2L) Message handler 'onHeartbeat' not callable, ignored.
2020-12-04 13:49:38.959 (Mon D2L) Pushing 'onHeartbeatCallback' on to queue
2020-12-04 13:49:38.967 (Mon D2L) Processing 'onHeartbeatCallback' message
2020-12-04 13:49:38.967 (Mon D2L) Message handler 'onHeartbeat' not callable, ignored.

@xbu05400
Les heartbeat sont normaux. Mais si vous ne recevez pas de onMessage, il y a un probleme de communication module/serveur

@Antori91, je ne vois pas le problème de la création de device. C'est sur c'est moins propre mais j'ai des 100aines de devices non utilisé dans domoticz, ca ne me parait pas bien grave...

@Antori91, je ne vois pas le problème de la création de device. C'est sur c'est moins propre mais j'ai des 100aines de devices non utilisé dans domoticz, ca ne me parait pas bien grave...

C'est que le problème se reproduira potentiellement à chaque reboot du Raspberry ou restart de Domoticz, non? Certains relancent toutes les nuits par exemple leur Raspberry ou Domoticz. Cela veut dire dans mon cas par exemple problème si je reboote la nuit où je coupe tellement bien certains chauffages que I2 et I3 était nulles hier soir lors du powerload à 75%. Au reboot en pleine nuit donc, mon indicateur intensité triphasé ne sera plus mis à jour et à nouveau je ne pourrai pas expliquer mon 75%...

Je viens de trouver la solution. Il vous faut utiliser uniquement le device courant triphasé (y compris pour le monophasé). Car son fonctionnement dans Domoticz est le suivant . Lorsque i2 et i3 sont nulles, il affiche uniquement i1 et pas i1 0 0. Il faut juste avoir un nom de device qui soit suffisamment neutre par rapport au fait que ce qui s'affiche est soit le courant de la phase soit les courants des 3 phases.

[EDIT] Reste le cas du calcul du Power load...Pour ce Power load, il faudrait un calcul par phase avec un device triphasé présentant les trois pourcentages de charge qui se réduiraient à un seul pourcentage dans le cas du monophasé (puisque iinst2/isousc*100 et iinst3/isousc*100 vaudraient toujours zéro). A l'image du fonctionnement du device intensité dans Domoticz.

J'en ai bien conscience, c'est la même chose pour le P1 Smart Meter. Mais ça log en base de données 3 fois plus de données. Je trouve pas ça génial pour la carte sd. C'est pour ça que je ne créer pas un P1 Smart meter pour les contrats Base.

Je ne comprends toujours pas le problème avec la solution implémentée. Dans votre graphe, je ne vois pas d'endroit ou seule la phase 1 est > 0, les données étant moyennée sur 5 min, j'imagine que ça se produit don seulement par intermittence... Du coup, avoir quelques minutes maxi de logs non prise en compte dans le bon devices après un redémarrage du serveur, ça ne parait pas bien grave, non ?

Pour le power load, il n'y a pas à ma connaissance de device "triple pourcentage" dans domoticz. Il faut créer 3 devices.

ping a écrit : 04 déc. 2020, 15:50 Je ne comprends toujours pas le problème avec la solution implémentée. Dans votre graphe, je ne vois pas d'endroit ou seule la phase 1 est > 0,

Parce que ce graph a été construit avec le bug. C'est pour cela que l'on voit par exemple une intensité constante sur la période pour l'une des phases (L3), ce qui est totalement improbable. En fait, sans bug, le vrai graph aurait été seule I1 > 0 et les deux autres intensités à zéro. Je me répète on ne voit pas I2 et I3 à zéro parce que la dernière valeur de I2 et I3 a été conservée avant leur retour à zéro car dès lors que I2 et I3 étaient toutes les deux à zéro, ce device n'était plus mis à jour....
ce qui empêche de voir ** I3** à zéro (I3 est retournée à zéro après I2)...
A l'inverse, le device courant monophasé a été mis à jour en continu toute la nuit...Je l'ai accepté puis effacé. Dommage, car il aurait été sans doute plus convaincant pour la démonstration.

Oui effectivement, autant pour moi. Il n'empêche qu'à toutes les valeurs où I1 a été mis à jour dans votre graphe, une des deux autres valeurs était non nulle. Cela fait donc sur votre graphe, un maximum de 2 heures sans que la valeur est été mise à jour. Vous devriez pouvoir voir en regardant les points du graphe (en balayant la souris sur le graphe). Puisque le problème n'intervient que lorsque l2 et I3 sont nuls au redémarrage du serveur, il me parait toujours acceptable de perdre quelques dizaines de minute, peut être une heure en moyenne, dans un cas relativement improbable, et uniquement lorsqu'on redémarre son serveur...

Je parle de la période entre 22h et 5h sur le graph. C'est la période où je coupe en semaine chauffage au RDC et Mezzanine, ce qui fait I2 et I3 à zéro. Donc, si mon raspberry reboote à 22h30, le device courant ne sera pas mis à jour avant 5h.
J'ai un peu l'impression que l'on ne se comprends pas. Je me répète entre 22h et 5h seule I1 est non nulle. Et si vous voyez sur le graph, une autre intensité non nulle, c'est que le graph est erroné du fait du bug. Sans bug du plugin, on aurait un graph où seul I1 serait non nulle. Alors qu'ici de façon erronée, il semble que l'on a I1 et I3 non nulle avec I3 prenant une valeur fixe pendant la période.