Open ed0uardb opened 10 months ago
Pour apporter ma petite pierre, perso j'ai utilisé le code de psykokwak-com avant que hallard sorte le sien (qui est bien optimisé faut l'avouer) Ton cas: les deux frequences trouvées sont peut etre, en fonction de ton emplacement, ton compteur ainsi que celui de ton voisin.. Tu peux monitorer ton ESP via le cable usb pour avoir le debug en serie via putty par exemple, ainsi voir si il scan ou si il essaye de lire ton compteur (en fonction de l'heure que tu as mis.)
Merci pour ta réponse, Avec le n° de série qu'on ajoute dans le fichier de config ça n'est pas censé réveiller uniquement le module everblu concerné ? J'ai aussi essayé le code de psykokwak, mais je n'ai pas réussi a obtenir de résultat pour la fréquence. Je me demande si l'alimentation de mon port USB est assez stable, car une fois le code de hallard installé et comme il permet de suivre le scan par mqtt, j'ai branché l'ESP sur un chargeur usb et là j'ai trouvé les 2 fréquences.
alors, as tu pu avancer sur ton scan ? met ton pc portable directement a coté du compteur everblue et monitor ca en direct. Des que tu as la fréquence, alors injecte la dans le code.
Désolé j'arrive juste sur le sujet, la petite subtilité est
float frequency = preferences.getFloat("frequency", 433.82000f);
En fait ça prends la dernière fréquence sauvée et met 433.82000f si il n'y en a jamais eu (donc après un scan elle peut être sauvée et dans ce cas il ne prend pas le 2eme paramètre)
donc pour la mettre manuellement tu dois la supprimer de la config avec un remove
preferences.remove("frequency");
float frequency = preferences.getFloat("frequency", tafrequence);
tu build et flash (ce qui au 1er boot va sauver ta fréquence) et ensuite tu commentes à nouveau le remove
//preferences.remove("frequency");
tu build et reflash
Bien entendu le tout avec le FORCE_SCAN
désactivé :-)
Désolé j'arrive juste sur le sujet, la petite subtilité est
float frequency = preferences.getFloat("frequency", 433.82000f);
En fait ça prends la dernière fréquence sauvée et met 433.82000f si il n'y en a jamais eu (donc après un scan elle peut être sauvée et dans ce cas il ne prend pas le 2eme paramètre)
donc pour la mettre manuellement tu dois la supprimer de la config avec un
remove
preferences.remove("frequency"); float frequency = preferences.getFloat("frequency", tafrequence);
tu build et flash (ce qui au 1er boot va sauver ta fréquence) et ensuite tu commentes à nouveau le
remove
//preferences.remove("frequency");
tu build et reflash
Bien entendu le tout avec le
FORCE_SCAN
désactivé :-)
Merci pour ta réponse, j'avais compris comment supprimer la fréquence sauvegarder mais pas comment l'injecter manuellement.
Mon problème c'est de n'avoir jamais la même fréquence lors du scan avec relève OK dans la foulée. A chaque fois que j'ai eu un test scan OK, j'ai build reflash avec le 'FORCE_SCAN' désactivé, mais la relève ne fonctionne pas, tout les retry renvoient 'no data'. Est-il possible que mon module CC1101 soit instable au niveau de sa fréquence ? Est-ce que d'être sur une breadboard avec des fils dupont peut rendre le système instable ?
Tous les CC1101 que j'ai fonctionnent correctement c'est de ebytes et pas les clones avec parfois des crystal pas très précis (et variant avec la temperature) Clairement le breadboard peut jouer :-)
si tu es sur PI j'ai qq modules https://www.tindie.com/products/hallard/cc1101-mini-shield-for-raspberry-pi/ sinon il doit me rester qq proto ESP32 C3 aussi
C'est sur ceux la que tourne le code avec la batterie :-)
hello @ed0uardb , est ce que tu utilise MQTT avec Home Assistant ? si oui est ce que l'entité everblu/cyble-xx-espxx remonte automatiquement dans ton intégration MQTT ?
hello @ed0uardb , est ce que tu utilise MQTT avec Home Assistant ? si oui est ce que l'entité everblu/cyble-xx-espxx remonte automatiquement dans ton intégration MQTT ?
Salut @rommess Aucun problème niveau MQTT, j'ai bien mon topic qui remonte sur mon Jeedom, mais pour les tests j'utilise MQTT Explorer. Dans l'ensemble tout fonctionne bien, juste ce problème d'instabilité sur la fréquence à utiliser... ça semble plus être un problème matériel que logiciel.
Salut @hallard,
En fait tu créés toi même tes PCB et tu soudes tout ? Si tu as un proto esp32 C3 je suis éventuellement preneur. Quel est le tarif ? j'ai essayé de trouver un autre module CC1101 mais à part les clones chinois cheap, les prix sont hauts avec parfois plus de frais de port.
Jeedom donc, merci pour ta réponse. Utilisant le même matériel que toi (esp32 dev kit v1 et le CC1101) et le code de hallard (suite au remplacement de mon compteur de 2009 par un de 2023, pas de problème pour qu'il trouve la frequence des le debut du run (meme sans le force_scan)
Perso, en terme de cablage j'ai ca (fait pas attention au couleurs, c'etait pour moi) CC1101 <-> ESP32 1.GND noir GND 2.VCC (3V3) rouge 3V3 3.GOD0 (GDO0) jaune D22 4.CSN (SPI chip select) vert D5 5.SCK (SPI clock) orange D18 6.MOSI (SPI MOSI) bleu D23 7.GOD1 (SPI MISO) marron D19 8.GOD2 (GDO2) D21
Comme tu dis, peut etre un probleme materiel sur ton cc1101 ..
En fait tu créés toi même tes PCB et tu soudes tout ?
Disons que je fais assembler, avant oui je faisais à la main et avec mon four c'était sport :-)
Si tu as un proto esp32 C3 je suis éventuellement preneur. Quel est le tarif ?
Oui il me reste qq boards assemblées (celle de la photo précédente) la board [env:c3-cc1101]
dans le platformio.ini
vu le prix que j'ai payé pour les proto je peux te la faire à 25€ port compris en lettre suivi. Elle contient le chargeur de batterie et le chip I2C pour monitorer la batterie aussi.
sinon tu peux prendre celle sur tindie qui contient juste un CC1101 de chez ebyte qui eux sont d'excellente qualité mais tu devras souder les Pin du SPI depuis entre ton ESP la carte.
@rommess
CC1101 <--> ESP32
Dans mes notes le GDO0 se branchait sur GPIO22, mais je sais pas pourquoi sur mon montage et dans le code j'ai mis sur le GPIO2. Je retesterai sur le GPIO22
Tu as quoi comme module CC1101 ?
le V2, E07-M11010 en cables dupont sur l'esp
le V2, E07-M11010 en cables dupont sur l'esp
un module EByte, pas de secret :-)
@hallard
Par acquis de conscience je vais refaire un test demain et si ce n'est pas concluant je prendrai ton esp32 c3 Je te confirme ça demain soir.
Si c'était pour moi je m'accommoderai de ce problème en refaisant le scan à chaque fois, mais comme c'est pour mon père qui a besoin de faire une relève par mois, il faut que ça soit stable et simple à utiliser. L'idéal ça aurait été un esp32 avec un petit écran : on allume on attend que la relève s'affiche et hop on éteint. Mais c'est hors de mes compétences ou alors ça me prendrai des mois !
Ya un connecteur QWIIC pour un afficheur OLED sur la carte ESP32 tu dois pouvoir y connecter un truc comme ça (ok faudra ré écrire un peu de code) https://www.amazon.fr/DollaTek-Module-Broches-Interface-Arduino/dp/B07QJW7Z4C
je te mettrais le cordon qui va bien si tu veux.
J'ai compris mon erreur ! Trop de manipulation à brancher débrancher l'usb de l'esp32. Dans les premiers tests je n'arrivai pas du tout à trouver la fréquence, j'ai donc par la suite fait mes tests en branchant l'esp32 sur un powerbank près du compteur, le problème c'est qu'en rebranchant l'esp32 sur mon pc pour le flasher ça remet en route le programme avec le 'FORCE_SCAN' activé :
#if defined FORCE_SCAN float frequency = preferences.getFloat("frequency", 0.0f);
je flash et quand je relance l'esp32 sur la powerbank la fréquence est de nouveau celle par défaut 433.82000f.
J'ai donc entré manuellement ma dernière fréquence qui a fonctionnée ce matin 433,7830 comme expliqué par @hallard, tout ça en laissant bien l'esp branché sur le pc pour ne pas provoquer le redémarrage du programme.
donc pour la mettre manuellement tu dois la supprimer de la config avec un remove
`preferences.remove("frequency");
float frequency = preferences.getFloat("frequency", tafrequence);`
tu build et flash (ce qui au 1er boot va sauver ta fréquence) et ensuite tu commentes à nouveau le remove
//preferences.remove("frequency");
tu build et reflash
Bien entendu le tout avec le FORCE_SCAN désactivé :-)
Maintenant ça fonctionne, si je souhaite faire une relève j'ai juste à brancher mon esp32 et attendre ma trame mqtt.
Bonjour,
Je fais des recherches sur la relève des compteurs avec everblu depuis quelques jours et les améliorations que vous avez apportées pour le déploiement sur ESP32 m'intéressent. J'ai tester le code de neutrinus sur github, je pense avoir le bon câblage au niveau des pins, le programme avait l'air de bien tourner, wifi et mqtt ok, pas de soucis pour lancer le scan, mais je n'ai jamais réussi a trouver la bonne fréquence.
J'ai comme matériel un ESP32WROOM32 (de Az-delivery), et pour le module RF une E07 (M1101D-SMA).
J'ai réussi à installer votre code cet après-midi et j'ai quelques questions si ça ne vous dérange pas et que vous avez le temps d'y répondre.
Pour installer le code sur une autre carte, esp32dev dans mon cas, dans le fichier platformio.ini ligne 20 il faut bien modifier le
default_envs = c3-cc1101
pardefault_envs = esp32dev
? c'est ce que j'ai fait, mais pendant la compilation j'ai eu des erreurs dans everblu-meters.cpp et cc1101.cpp, concernant des variables non déclarées dans le scope.Dans everblu-meters.cpp j'ai mis en commentaire :
Dans cc1101.cpp, GDO0 était considéré comme non déclaré J'ai rajouté la configuration des pins dans platformio.ini :
Après ces modifications j'ai pu compiler et charger le code. Je pense avoir réussi a trouver la bonne fréquence, j'ai eu 2 confirmations via mqtt : {"date":"10/10/2023 16:06:20","ts":1696946780,"min":"433.8599","max":"433.8663","frequency":"433.8631"} {"date":"10/10/2023 16:27:06","ts":1696948026,"min":"433.8524","max":"433.8647","frequency":"433.8583"}
Je suis un peu dubitatif sur la différence des résultats obtenus ...
Pour le moment le module est débranché, quand je le redémarrerai va-t-il recommencer un scan ou va-t-il utiliser la fréquence trouvée ? le paramètre
-D FORCE_SCAN
(ligne 42 dans platformio.ini) étant toujours actif dans mon ESP32 sans rechargement du code.J'ai refais la manipulation en reprenant le code d'origine, j'ai juste changé![Capture](https://github.com/hallard/everblu-meters-esp32/assets/146395386/9428bb4f-b28d-48db-8ad6-dd3c23744fae)
default_envs = esp32dev
et renseigné les infos pour le wifi, le mqtt, et le serial pour l'everblu. Ca m'affiche ces erreurs dans VisualCode.EDIT 11/10/23
J'ai rebrancher mon ESP ce matin sur un chargeur usb, il a relancé automatiquement le scan, je l'ai donc laissé faire. Une fois la fréquence trouvée j'ai reçu ce message mqtt :
{"date":"11/10/2023 10:00:48","ts":1697011248,"min":"433.8353","max":"433.8706","frequency":"433.8528"}
Puis l'ESP est entré en mode sleep (le programme considère que l'esp fonctionne sur batterie comme l'espc3). j'ai relancer l'esp avec le bouton RST, et là j'ai reçu ce message mqtt :
{"ts":1697011251,"date":"Wed Oct 11 10:00:51 2023","esp_battery":{"percent":0,"vbat":0},"liters":344078,"battery":141,"read":66,"rssi":-76,"lqi":-119,"hours":"06:18"}
La relève s'est donc bien passé, c'est bon signe ! mais ce dernier message mqtt aurait du être envoyé avant le mode sleep en même temps que la confirmation de la fréquence je pense ? Ensuite l'esp a recommencé à faire un scan !
J'ai donc désactivé le paramètre
;-D FORCE_SCAN
(ligne 42 dans platformio.ini) et changé la fréquence dans everblu-meters.cpp ligne 423 (c'est bien le bon endroit pour modifier la fréquence ?)float frequency = preferences.getFloat("frequency", 433.85280f);
Compilation, recharge du code dans l'ESP, et là pas de lecture possible ...
{ "ts": 1697012483, "date": "Wed Oct 11 10:21:23 2023", "esp_battery": { "percent": 0, "vbat": 0 }, "type": "No Data", "retries": 5 }
Voilà où j'en suis pour le moment, j'ai pas envie de vider la pile de l'everblu donc j'évite de faire trop de tests inutiles. Je vais réessayer dans la semaine un scan de fréquence en plaçant l'ESP au plus proche du compteur.
EDIT 12/10/23
Aujourd'hui nouveau test de relève ==> Echec
Reload du firmware avec
-D FORCE_SCAN
activé. J'ai branché l'ESP sur un powerbank pour le poser juste au dessus du regard du compteur d'eau.Test de fréquence OK, mais relève NOK
Il a alors relancé automatiquement un nouveau scan OK, et cette fois-ci une relève OK
J'ai réussi à faire 2 relèves, uniquement en mode "scanning", avec 2 fréquences trouvées ... 433.8528Mhz et 433.7841Mhz.
Ensuite j'ai rechargé le firmware en mode "normal" (
;-D FORCE_SCAN
) et en remettant la fréquence par défaut 433.82000Mhz.J'ai aussi essayé le
mqtt.enableHTTPWebUpdater(); // Enable the web updater.
, ça fonctionne bien. Par contremqtt.enableDebuggingMessages(); // Enable debugging messages sent to serial output
est bien censé envoyé les messages de serial monitor par MQTT ? je ne crois pas que ça fonctionne pas.//mqtt.enableLastWillMessage(String(topic + "lastwill").c_str(), "offline", true);
empêche la connexion au broker mqtt.mqtt.enableOTA(); // Enable OTA (Over The Air) updates.
Je ne comprends pas comment ça fonctionne.