bonjour,

j'ai posté sur le forum de Jeedom une solution de contournement qui ne modifie ni Jeedom, ni Wifinfo
voir ici: https://www.jeedom.com/forum/viewtopic.php?p=705158#p705158

non, c'est juste en sortie que ça devrait se jouer. Selon une option dans l'interface web, on pourrait choisir d'avoir les données réelles ou des données simulées.
Si on a une box domotique derrière qui ne reçoit rien, le mode debug permettrait de savoir si le soucis est en amont ou en aval de l'esp

Bonjour,

c'est pas con un mode débug. L'idéal serait de pouvoir l'activer depuis l'interface web, et sans modification de cablage. Cela permettrait en cas de soucis de faire un debug plus simple. Sur d'autres forums, certains se plaignent de ne pas recevoir de trames, ce mode permettrait déjà de savoir si le soucis est coté compteur ou coté ordinateur.

J'apporte un petit retour sur mon "expérience". Enedis est intervenu au coin de la rue pour corriger le soucis après 22 jours !
Et fiers d'eux, ils me proposent de ne pas faire de régularisation car le tarif était à mon avantage (tous les jours rouges ont basculé en blanc à 11h54)..
Mouais, sauf que le compteur ayant fournit des informations erronées à ma maison domotisée, la conso à été supérieure à ce qu'elle aurait été sans cette panne. En jours rouge, mon chauffe-eau ne se déclenche pas, les radiateurs non plus (j'utilise la cheminée) mais la maison se croyant en blanc, j'ai consommé chaque jour un peu de 'blanc' au lieu de rien en 'rouge'.
Je pensais profiter de cette panne, au final, elle va me couter.

Bonjour,

je me permet un petit hors sujet, mais comme sur ce forum, on est tous là pour suivre notre conso, c'est à mon sens le meilleur forum pour trouver des réponses. Sur 99% des autres forums, les gens ne suivent pas leur conso !

Depuis 12 jours, mon compteur bascule en "blanc" à 11h54 (tout en gardant les bascules HP/HC aux heures prévues), quelque soit la couleur du jour. C'est avantageux, car en ce moment, on est plutôt en "rouge" (et du coup, je suis HPJR que de 6h02 à 11h54)... J'ai signalé ce comportement à EDF il y a 11 jours, qui m'a renvoyé sur Enedis, qui dit que ce n'est pas un soucis réseau mais un soucis de compteur (qui plante pile à 11h54 tous les jours ?), puis EDF m'a rappelé pour me dire qu'Enedis est au courant d'un soucis d'impulsion. Bref, après 12j, je n'ai pas de nouvelles de leur part, et quelque part je m'en fou, vu que pour le moment, le tarif est à mon avantage...

Ma question est surtout de savoir si je suis un cas isolé ou non ? Avez-vous déjà vu des cas similaires ? Des conseils sur la conduite à tenir (pour le moment, je note simplement mes index chaque jours aux heures de bascule (6h02, 11h54 et 22h02) pour savoir combien j'économise.

@nico Bonjour, la téléinfo passe à 1200 bauds 7 bits, il me semble, et non 9600 8bits

@Doume Je ne me souviens plus du code exact, mais le port série pour le débug n'est pas le même que pour la programmation. Je crois qu'il y a un swap de serial et serial1 à un moment.

Bonjour,

une idée: tester chez un proche. Si ERDF prétends que la téléinfo est active par défaut, elle doit l’être chez vos voisins.

je pense qu'elle est bien activé, car EDF n'est jamais passé faire de relevé de mon compteur,
Ne pas confondre télé-relève et télé-info. L'une peu être activé et pas l'autre.

Bonjour,

si vous avez un PC, vous pouvez y brancher le dongle et le tester (avec Termite si Pc sous Windows, par exemple)
Mais on dirait un soucis de débit. Quel compteur utilisez vous ? Essayez de monter la vitesse pas par pas, pour voir si un texte clair apparait.
1200 > 2400 > 4800 > 9600 > 14400 > 19200 > 28800 > 38400 > 57600 > 115200
Si ça ne donne rien, refaites les tests avec 8 bits de données au lieu de 7

Sinon, question bête, la téléinfo est-elle bien activée sur le compteur ?

Bonjour,

@davidkls :
sur sa copie d'écran ici: https://hallard.me/utinfo/ , Charles utilise une parité paire, pas vous, ça peut être une piste.

@Benjy-Net Bonjour, si je comprends bien votre problématique vous souhaitez utiliser la paire pour remonter le signal de téléinfo à la place de celui du contacteur.
Perso j'utilise Wifinfo sur un wemos D1 mini, et le relai du chauffe-eau reste branché sur la sortie du compteur, bien que je ne l'utilise plus. Le Wemos communique en wifi, donc pas besoin de fils, juste d'une prise proche du compteur et d'une vieille alim usb. Le wemos est placé dans une boite de dérivation, pour l’esthétique..
La remonté d'info vers ma domotique se fait chez moi vers une box jeedom, sans difficulté, puisque intégré au logiciel de Charles. Et c'est ensuite ma box qui décide d'allumer ou non le chauffe-eau, selon la tarification la plus avantageuse (j'ai l'option tempo, il est préférable de chauffer un jour blanc plutôt qu'une nuit rouge..). Pour cela, j'ai un module zwave qui remplace le relai EDF (ne pas piloter directement le chauffe-eau, à moins d'avoir un module qui gère la puissance nécessaire !)

you need to be root..
use 'sudo'

@nemo
Bonjour,
PAPP et IINST sont des données temps réel de votre consommation, pas de la fourniture en énergie. En d'autres termes, c'est que vous utilisez dans votre maison en sortie du compteur, pas son/ses alimentations en entrée(s).
Les compteurs HP/HC par contre correspondent à l'entrée EDF.
Pour connaitre votre consommation solaire, il vous suffit de soustraire PAPP de votre Compteur EnPhase. Selon que le résultat sera positif ou négatif, vous aurez votre réponse.

@Doume J'utilise un Wemos D1 mini, car c'est plus petit qu'un NodeMCU, et comme vous l'avez fait remarqué, c'est facile à alimenter, on a presque tous un vieux chargeur de téléphone µUSB dans un tiroir...
Pour relier au compteur, il faut un peu plus qu'un optocoupleur.
@­Charles propose un montage très fiable:

Perso, j'utilise un montage plus simple:

Vous raccordez le montage à l'entrée RX du Wemos

Bonjour,
Je débute avec Domoticz, et j’utilise un petit script maison pour faire apparaitre dans Domoticz ma conso instantanée et ma couleur du jour (option "Tempo").
Si ça peut servir de base pour d'autre, c'est cadeau.

J'ai créé 2 "dummy" : Un type "texte" pour la couleur du jour, et un type "P1 Smart Meter" pour la conso.
Mon wifinfo est une adaptation perso, il intègre un capteur température/humidité, d'où les lignes supplémentaires dans le script et le "sensorIdx"
Je débute en Lua, donc pas forcement optimisé, mais ça me convient. Le script est appelé par une tache cron.

-- index des dispositifs (colonne IDX de domoticz)
---- capteur temp/hum
local sensorIdx = 217
---- P1 smart meter
local teleinfoIdx = 154
---- text
local colorIdx = 249
---- Domoticz
local domoURL = "http://127.0.0.1:8080/json.htm?"
local urlParams = "type=command&param=udevice&idx="

-- inclure les bibliothèques Lua
json = (loadfile "/home/pi/domoticz/scripts/lua/JSON.lua")()  -- For Linux
--   json = (loadfile "D:\\Domoticz\\scripts\\lua\\json.lua")()  -- For Windows

-- récupération des données json
local config=assert(io.popen('/usr/bin/curl -s http://192.168.5.229/json'))
local blocjson = config:read('*all')
config:close()
-- debug
print (blocjson)

-- décodage des données
local jsonValeur = json:decode(blocjson)

-- affectation dans des variables 
 papp = jsonValeur.PAPP
 iinst = jsonValeur.IINST
 temp = jsonValeur._TEMPERATURE
 hum = jsonValeur._HUMIDITY
 coulJ = jsonValeur.PTEC
 coulD = jsonValeur.DEMAIN

 BBRHCJB = jsonValeur.BBRHCJB
 BBRHPJB = jsonValeur.BBRHPJB
 BBRHCJW = jsonValeur.BBRHCJW
 BBRHPJW = jsonValeur.BBRHPJW
 BBRHCJR = jsonValeur.BBRHCJR
 BBRHPJR = jsonValeur.BBRHPJR
 CPlein = BBRHPJB + BBRHPJW + BBRHPJR
 CCreux = BBRHCJB + BBRHCJW + BBRHCJR


-- un peu de modification de texte pour faciliter la lecture
 coulJ = string.gsub(coulJ, "HPJB", "Plein%%20Bleu");
 coulJ = string.gsub(coulJ, "HCJB", "Creux%%20Bleu");
 coulJ = string.gsub(coulJ, "HPJW", "Plein%%20Blanc");
 coulJ = string.gsub(coulJ, "HCJW", "Creux%%20Blanc");
 coulJ = string.gsub(coulJ, "HPJR", "Plein%%20Rouge");
 coulJ = string.gsub(coulJ, "HCJR", "Creux%%20Rouge");

-- construction des url
url1 =  domoURL .. urlParams .. sensorIdx .. '&nvalue=0&svalue=' .. temp .. ';' .. hum .. ';0'
url2 =  domoURL .. urlParams .. teleinfoIdx .. '&nvalue=0&svalue=' .. CPlein .. ';' .. CCreux .. ';0;0;' .. papp .. ';0;'
url3 =  domoURL .. urlParams .. colorIdx .. '&nvalue=0&svalue=' .. coulJ .. '%20%2F%20Demain%20' .. coulD

-- debug
print(url1);
print(url2);
print(url3);

-- appel successif des url
local doIt=assert(io.popen('/usr/bin/curl -s "' .. url1 .. '"'))
doIt:read('*all')
doIt:close()
doIt=assert(io.popen('/usr/bin/curl -s "' .. url2 .. '"'))
doIt:read('*all')
doIt:close()
doIt=assert(io.popen('/usr/bin/curl -s "' .. url3 .. '"'))
doIt:read('*all')
doIt:close()

L'ip de mon wifinfo est 192.168.5.229, adaptez selon votre config.
J'utilise l'option "tempo", j'ai donc 6 tarifs et non 2, ça complique un peu la conso, adaptez à vos besoins.

Au final, ça me donne ça:

Bonjour,

les points de soudures n'ont rien autour et sont plutôt de bonne taille. Un fer à souder doit faire l'affaire

Bonjour,

quelqu'un a-t-il des news sur le portage sur ESP8266 ? Je ne trouve que les sources v33 sur le net, et j'arrive à les compiler pour un wemos D1 mini (il suffit de rajouter la fonction 'strncasecmp' et de changer les ports), mais je n'ai aucune réception propre de signal, que du 'oregon unknow'. Je suppose que c'est une question de timing, mais je ne maitrise pas bien le code de rflink.

Si certains veulent tenter, voici ce que j'ai ajouté en fin de l'onglet 'misc' pour définir la fonction 'strncasecmp':

#ifdef ESP8266
int 
_DEFUN (strncasecmp, (s1, s2, n),
    _CONST char *s1 _AND
    _CONST char *s2 _AND
    size_t n)
{
  if (n == 0)
    return 0;

  while (n-- != 0 && tolower(*s1) == tolower(*s2))
    {
      if (n == 0 || *s1 == '\0' || *s2 == '\0')
    break;
      s1++;
      s2++;
    }

  return tolower(*(unsigned char *) s1) - tolower(*(unsigned char *) s2);
}
#endif

On ne teste pas ici le crc de chaque variable de config, mais le crc de toute la structure.
Mes cours sur le CRC sont loin, mais ce qui est fait ici, c'est un calcul de crc sur chaque valeur de la config (et non sur l'objet "config"), qui contient elle-même une "sauvegarde" du crc. On fait donc un calcul de crc sur l'ensemble "config.* + config.crc", donc le résultat du modulo devrait être 0. Si le crc déjà calculé lors de la sauvegarde n'était pas stocké dans l'objet config, ça ne fonctionnerait pas pareil et on ferait une comparaison config.crc et crc.

Par contre, l'extrait de code à été simplifié ? Parce que je n'y vois pas l'initialisation de crc avant la boucle.

Sinon, pour simplifier la compréhension, le code dans la boucle aurait pu resembler à ça:
ancienCRC = crc;
crc = crc16Update(ancienCRC, data);