Outils pour utilisateurs
Table des matières
Index
Cyble RF 433Mhz installé par ma communauté de commune
Le module radio fréquence Actaris pour compteur d’eau : un outil fiable, compact et intelligent pour la relève à distance, du réseau de distribution à l’habitat collectif. Module de communication radio compact compatible RADIAN™ totalement étanche, Cyble RF s’installe très facilement, sur site ou en usine, aussi bien sur un compteur d’eau froide que d’eau chaude. Sa pose sur site ne nécessite ni câblage ou fixation murale, ni dépose ou déplombage du compteur. Spécialement conçu pour résister aux environnements difficiles, Cyble RF est adapté à toutes les conditions rencontrées, du regard inondé à la gaine technique. Ses nombreuses fonctions intelligentes permettent, en complément du relevé d’index, d’obtenir :
- l’historique mensuel de l’index sur 13 mois,
- la détection des retours d’eau, le volume cumulé inverse et l’historique mensuel sur 13 mois
- la détection de fuites et l’historique mensuel sur 13 mois
- la détection des tentatives de fraude
- l’indication de fin de vie de pile
- diverses alarmes
protocole RADIAN
- impossible a trouver sur internet , l'adresse http://www.radianprotocol.com/ n'est plus active
issue de web.archive.org
The Radian Protocol
A two-way 433 Mhz Radio Protocol
Radian Protocol is designed for all applications in water, electricity, gas and heat meter reading and data transmitting. Its two way caracteristics allows developed service solutions, including information exchange with final user.
reliability
physical layer : FSK modulation, narrow band Logical Link Layer : packet numbering
two ways, half duplex, data transmission relaying capability
receive an repeat datagrams up to 7 nodes forward
sophisticated wake up mechanism
standby mode wake-up signal => awaken mode
my address ?
yes => let’s communicate !
no => back to stand by
time to get data from a node : 2-3 s
both master - slave control and CSMA asynchronous communications
issue d'une doc d'un outil de reléve
- Procédé FSK, bidirectionnel
- Fréquence 433.82 MHz
- Modulation FSK, NRZ asynchrone
- Protocole Radian
- Décalage de modulation 5 KHz
- Bande passante du canal 25 KHz
- Vitesse de transmission 2’400 baud
- Puissance d’émission centrale de radiotransmission + 10 dBm (10 mW)
- Sensibilité de réception - 105 dBm
- Portée 50 m env
f5943_cyblerfvacatris.pdf n'apporte rien de plus
autres piste
- norme 13757-4 (DATA\DOCUMENTATIONS_div) → bof finalement le protocole n'est pas vraiment raccord
- open-meter_wp2_d2.1_part3_v1.0.pdf –> EverBlu (5.4.11) 10Kbps → fausse piste
-
- la porteuse est 433,82Mhz
- ils parlent de cryptographie (a part le CRC , ya rien …)
- le compteur ne peut être reveillé que pendant ses “heures ouvrable ” (effectivement mais les heures et les jours sont configurable en usine)
hacking
En 2011 j'ai lâché cette page web au vent du web.
En 2014 julien a accroché on a groupé quelques docs que l'on avait sur le sujet.
Il a décidé d’écouter H24 les compteurs de sa résidence avec un SDR et un gros disque dur.
En février 2016 il a réussi capturer plusieurs relève de compteur, on a commencé a gratter.
Mais il nous manquait comment calculer le CRC et comment faire le lien entre ce qu'il y a marqué sur notre compteur et la trame de relève.
SigmaPic a rejoint le projet et il a mit pas mal de chose a plat (enfin surtout les bit 
).
Restais encore cette problématique d’étiquette .
En décembre 2016 nous étions tous en train de sniffer nos compteur et julien a réussi a capturer la relève de son propre compteur.
1 mois plus tard signacPic arrivait a relever son propre compteur 
.
Protocol
Physical Layer
RF Transmission
- Procédé FSK, bidirectionnel
- Fréquence 433.82 MHz
- Modulation FSK, NRZ asynchrone
- Protocole Radian
- Décalage de modulation 5 KHz
- Bande passante du canal 25 KHz
- Vitesse de transmission 2’400 baud
Communication Frame
Any communication frame consists in:
- A preamble used to notify the receiver that data will be sent
- A sync word used to notify the receiver that data transmission is starting
- Some data
Preamble
Preamble is a series of 0101….0101 at 2400 bits/sec. There are two preamble durations:
- Long preamble for meter wake-up: 4928 bits (2464 x 01)
- Short preamble for other frames: 80 bit (40 x01)
In order to save energy, meter wakes-up every 2 seconds and check if someone is speaking. If nobody is speaking, meter goes back to sleep. This is the reason why long preamble is used when the master send a request.
a preamble with a master request
zoom on end of preamble
Sync pattern
Sync pattern starts with low level during 14.3ms followed by a high level during 14.3ms.
preamble and synch pattern of meter response
Data
Data are sent by UART:
- Baudrate: 2400 bits/sec
- lsb first
- 1 start bit / No parity / 2 or 2.5 stop bits
Frame Structure
| L(1) | C(1) | S(1) | Receiver Address(5) | S(1) | Sender Address(5) | S(1) | Data + Checksum (4-240) |
|---|
- L (Length Byte) Total number of bytes including length byte and checksum
- C (Control Byte)
- 0x10: Request
- 0x06: Acknowledge
- 0x11: Response
- S (Spacer) 0x00
- Receiver Address (5bytes) : Meter address when master is speaking and master address when meter is speaking
- S (Spacer) 0x00
- Sender Address (5bytes) : Master address when master is speaking and meter address when meter is speaking
- Data Payload (Up to 238 bytes)
- Checksum (2bytes) CRC-CCITT (Kermit)
- Polynomial : 0x8408
- Initial Value : 0
- Bytes are reversed (MSB first)
- Result is inverted
- Final XOR : 0
- Stored in little endian.
Meter Data mapping
Meter Address Encoding
- Address is encoded over 5 bytes.
- First byte is 0x45 (TBC).
- Four other bytes are deduced from numbers below the bar-code
- format is YY-AAAAAAA-CCC.
- 2nd byte YY: Years encoded on 8bits
- 3rd-to 5th Byte AAAAAAA to be converted in from decimal to hex MSB first
- CCC: Check digits (Not used in address encoding but used to verify YY-AAAAAAA consistency)
example
- Serial number 16-0123456-CCC
- YY = 16d → 10h
- AAAAAAA = 0123456d →01E240h
- Master request to be predecing by 2s of 2464*01 then follow by Sync pattern and encapsulated in 1 start bit / No parity / 2.5 stop bits (works also with 2bit and 3bit)
- 13 10 00 45 10 01 E2 40 00 45 67 89 AB CD 00 0A 40 DA DC (cks) pour le calcul du CKS prendre la ligne Kermit et swapper les nibbles ⇒ http://crccalc.com/?crc=131000451001E24000456789ABCD000A40&method=crc16&datatype=hex
| Length | Control | Spacer | Receiver Address | Spacer | Sender Address | Spacer | Data + Checksum | |
|---|---|---|---|---|---|---|---|---|
| Master request | 13 | 10 | 00 | 45 10 01 E2 40 | 00 | 45 67 89 AB CD | 00 | 0A 40 DA DC |
| Meter Acq | 12 | 06 | 00 | 45 67 89 AB CD | 00 | 45 10 01 E2 40 | 00 | 0A 90 9E |
| Meter response | 7C | 11 | 00 | 45 67 89 AB CD | 00 | 45 10 01 E2 40 | 00 | 01 08 00 D2 73 07 00 40 ….. cks (488402 litres) |
| Master Acq | 12 | 06 | 00 | 45 10 01 E2 40 | 00 | 45 67 89 AB CD | 00 | 0A 23 93 |
solutions de relève
CC1101
le CC1101 est un transceiver RF on peux régler un tas de paramètre , mais la fréquence réel n'est pas exactement celle que l'on règle.
//par exemple j'ai 2 carte CC101 pour un même réglage de fréquence un montage obtient une réponse l'autre non halRfWriteReg(FREQ0,0xC1); //Frequency Control Word, Low Byte CC1101_N1 814 824 (KO) ; CC1101_N2 810 820 (OK) halRfWriteReg(FREQ0,0xB7); //CC1101_N1 810 819.5 OK mon compteur aussi fait F1 : 433808500 F2 : 433819500
d’où la nécessité de calibrer le registre FREQ0 en utilisant une clef TNT qui fait SDR
rpi + CC1101
schéma de câblage
5V,GND ---> RPi HE26 ---.-----2*GND; 2*3.3V , SCLK ,MISO , MOSI , CSn, GDO2, GDO0 --------> CC1101 HE10 | debug_connector(HE14)
RPi PIN allocation
WiringPi Pin = WPP
| Fonction | WPP | Name | Header | Name | WPP | Fonction | |
|---|---|---|---|---|---|---|---|
| 3.3v | 1 | 2 | 5v | ||||
| 8 | SDA | 3 | 4 | 5v | |||
| 9 | SCL | 5 | 6 | 0v | |||
| 7 | GPIO7 | 7 | 8 | TxD | 15 | ||
| 0v | 9 | 10 | RxD | 16 | |||
| GDO0 | 0 | GPIO0 | 11 | 12 | GPIO1 | 1 | |
| GDO2 | 2 | GPIO2 | 13 | 14 | 0v | ||
| LED | 3 | GPIO3 | 15 | 16 | GPIO4 | 4 | |
| 3.3v | 17 | 18 | GPIO5 | 5 | |||
| MOSI | 12 | MOSI | 19 | 20 | 0v | ||
| MISO | 13 | MISO | 21 | 22 | GPIO6 | 6 | |
| SCLK | 14 | SCLK | 23 | 24 | CE0 | 10 | Csn |
| GND | 0v | 25 | 26 | CE1 | 11 | ||
#define GDO2 2 //header 13 #define GDO1_MISO 13 #define GDO0 0 //header 11 #define MOSI 12 #define cc1101_CSn 10 ////header 24 #define LED 3 //header 15
HE10 CC101
Top view
| Fonction | Header | Fonction | |
|---|---|---|---|
| 3.3v | 1 | 2 | 3.3V |
| MOSI | 3 | 4 | SCLK |
| MISO | 5 | 6 | GDO2 |
| CSn | 7 | 8 | GDO0 |
| GND | 9 | 10 | GND |
Flipped view from bottom
| Fonction | Header | Fonction | |
|---|---|---|---|
| 3.3v | 2 | 1 | 3.3V |
| MOSI | 4 | 3 | SCLK |
| MISO | 6 | 5 | GDO2 |
| CSn | 8 | 7 | GDO0 |
| GND | 10 | 9 | GND |
debug_connector(HE14)
SALEAE led(1)
| Fonction | Header | Fonction | |
|---|---|---|---|
| D1 | 1 | 2 | D2 |
| D3 | 3 | 4 | D4 |
| D5 | 5 | 6 | D6 |
| D7 | 7 | 8 | D8 |
| GND | 9 | 10 | GND |
DB9 TDA (face
(GND) 5 4 3 2 1 (data)
9 8 7 6(5v)
HE14
| Fonction | Header | Fonction | |
|---|---|---|---|
| (D1 saleae)DATA TDA | 1 | 2 | (D2 saleae)LED |
| (D3 saleae)SCLK | 3 | 4 | (D4 saleae)SI |
| (D5 saleae)GDO2 | 5 | 6 | (D6 saleae)SO |
| (D7 saleae)GDO0 | 7 | 8 | (D8 saleae)CSn |
| GND | 9 | 10 | GND |
| 3.3 | 11 | 12 | GND |
| DATA TDA | 13 | 14 | 5V |
code
le zip a un mo t d3 pa5se il s'agit du nom du fichier zip radian_trx.zip
config
le code livré ne compilera pas (gcc radian_trx.c -o radian_trx -lwiringPi -lpthread -Wall) parce qu’il y a 2 paramètres a ajuster + 2 tipo
- fréquence a ajuster en fonction de votre CC1101 CC1101.c : ligne 229 : halRfWriteReg(FREQ0 , ….)
- je conseil de commencer avec la fréquence de base puis de mesurer avec le dongle TNT pour le centrer sur le 433.820 ou la réponse du compteur
- si il n'y a pas eu de réponse du compteur alors il faudra essayer de décaler par pas de 2kHz de chaque coté de 433.820
- il faut modifier FREQ0 en ajoutant/retranchant quelques unité pour décaler la fréquence principale de 2kHz , il faut savoir qu'un “SDR clef TNT a 20€” ne donne pas le fréquence réel en absolue, en relatif c'est déjà mieux
- le numéro de série du compteur. voici la ligne de code qui va avec le paragraphe exemple
- CC1101.c : ligne 664 : TS_len_u8=Make_Radian_Master_req(txbuffer, 16 , 123456 );
- dans CC1101.c ajouter en haut #define TX_LOOP_OUT 300
- un caractère “c” a supprimer en ligne 5 de radian_trc.c
script
sudo crontab -e 55 9 * * * sudo /home/pi/radian_trx/web_tx_releve >/dev/null 2>&1 55 9 * * * sudo /home/pi/radian_trx/web_tx_releve >> /var/log/crontab.log
performance
| minepi + CC1101(2) + lambda/4 derrière cloison | volet ouvert | rssi=185 lqi=128 F_est=255 |
| minepi + CC1101(2) + lambda/4 dans cloison | volet ouvert | rssi=185 lqi=128 F_est=255 |
| minepi + CC1101(2) + ant spirale derrière cloison | volet ouvert | rssi=183-4 lqi=128 F_est=255 |
Mbed+ CC1101
RTL SDR
-
- Plug your NESDR into an available USB port
- Open the 'NESDR Driver Installer', Zadig
- Select 'List All Devices' from the 'Options' menu in Zadig
- From the main dropdown, select the NESDR
- Confirm the selected device has a USB ID of '0BDA 2838'
- Press the big button to install drivers–button
=⇒SDR console OK
- http://rtl-sdr.sceners.org/?p=193 kalibrate
Avec une fréquence de sampling de 31.25 ksps c'est 2.5Go de données sur 12h. Ça parait lourd mais sur un HDD de 1To ça te permet quand même d'enregistrer 1024/2.5=410 jours ouvrées.
matos
- http://fr.farnell.com/mipot/32000508e/emetteur-fsk-50-pll-5-12v-433-92mhz/dp/1702924 , Gamme de fréquence: 433.42MHz à 434.42MHz
- SDR
- SX1212
antennes
classement selon http://www.modelisme.com/forum/aero-vol-en-immersion/195087-amplifier-un-signal-uhf-433mhz-optimiser-la-reception.html
du moin bon gain au meilleur
- Monopole 1/2 Onde
- Monopole 1/4 onde
- Dipole 1/2 onde
- Dipole 1/4 onde (env 70ohm)
- Antenne V inversée 1/2 onde
- Antenne V inversée 1/4 onde
- Antenne Moxon (env 50ohm)
- Antenne Yagi , patch ou quad (Antenne directive)
Outils de la page
Discussion
je suis en quête de la solution pour interroger des modules Cyble RF.
je suis prêt à mettre la main à la poche pour avoir du matos (materiel pour interroger les compteurs cyble RF). en attendant, mes recherches sur internet me montrent que le protocole everblu est compatible avec le protocole radian.
si j'avais assez de temps pour experimenter, je mettrai tout prêt de mon module un recepteur SDR calé sur la frequence et j'attendrai (une semaine /un mois/trois mois). tout en logguant la reception. une fois qu'une emission à tres fort niveau est détectée , il suffira de regarder les trames en amont.
néanmoins je suppute qu'il y a un cryptage des données...
I have access to an SDR and understand how the communication frames (size, content, checksums etc.) for these meters work, however I don't own a physical meter to test. If anyone knows where I can buy or obtain an Everblu Cyble Enhanced meter I would really appreciate it!
we can find some meters in ebay from times to times (i found a new one in italy) , i bought one, but the most difficult material is the programming console to initialize it.
the difficult point is the meter itself doesnt send any frames, it justs lookups up for a snc pattern every 2 secs (you can "listen it" by butting the sdr centered on 433.82mhz very near the meter.)
if you think you can find how to trigger a sleeping meter by trying to send "wake up" patterns, i d be ready to offer you a unit if you find one on the ebay.
take care, units already initialized are usually listening for wake up frames from 6am to 6pm from monday to friday (its not a joke, and its the most efficient and clever powerwsaving idea i never heard of).
regards
Did anybody find how to wake up the Everblu Cyble RF ?
What's new since one year ?
Best regards
I managed today to sniff Radian Frames with my sdr during teletransmission to hand held in my building, I captured many frames from different Water meters with the help of my sdr ( 30€ TNT usb stick) , I ll soon upload the raw and demodulated data for getting help to decode.
be ready to download audacity , gnuradio an the latest version of gqrx :)
have a look at
http://ouinouin.net/owncloud/index.php/s/Nt8lnC6PPkO8AeL
i m sharing a demodulated file to open with audacity, this is a fm demodulation of a 7minutes capture of radian polling and answers by some water meters.
i just finished the capture + cut, i ll quickly look at the file , calculate the symbol rate and try to find the encoding.
I ll nearly post on the snootlab forum more complete informations + link to the raw file captured with my sdr.
http://hackaday.com/2014/02/25/using-sdr-to-read-your-smart-meter/
https://github.com/bemasher/rtlamr
Fred
Je suis également intéressé !
Avez vous avancé sur le sujet ?
Comment peut on contribuer ?
@+
à la fin on a décodé les messages (au niveau bit et byte), maintenant il nous faut :
- comprendre comment est construit le message de l'outil de relevé (on est intéressé par d'autre enregistrement si en plus on a le numero du compteur marqué sur l’étiquette ca pourrais aider)
- essayer de rejouer un message pré-enregistré pour voir si on obtiens une reponse
de mon coté j’attends un tranceiver a base de CC1101 qui viens de chine pour pouvoir jouer avec.
Fred(l'admin du site)
Mon compteur est en 868MHz, il y a dessus une étiquette Homerider avec l'adresse du compteur du style 5322/11.81.xx.xx.xx
J'ai une clé sdr (rtl2832 avec rt820t) achetée une dizaine d'euros
Je suis près de Montpellier et c'est Veol!a qui as mis le compteur
frederic34
Je viens de tenter une acquisition avec le logiciel SDRSharp et un dongle TNT RTL2832U + RT820 (Samedi 12h00).
L'antenne se trouve à 20cm du compteur.
A 433.92MHz, je n'ai aucun signal. Rien du tout...
Est ce normal à ce moment de la semaine qu'il n'y ait rien ?
Les données sont-elles transmises avec un bits de start + stop + parité ?
les heures ouvrable du compteur sont du lundi au samedi 6h00 à 18h00, donc samedi vers 12h00 ce n'est pas mal, mais pour "réveiller" le compteur il faut lui envoyer une trame de réveille.
2.5s de 0/1 @1.2khz suivie d'une trame comme celle la maison2:compteur_d_eau:14270.png.
le problème c'est que cette trame est spécifique à chaque compteur.
pour avoir cette trame il faut écouter au moment ou le mec passe dans la rue pour relever ton compteur(1 fois par an...) ou si tu as de la chance toutes les semaine lorsque la télé-relève est installer sur les poteau téléphonique ou les lampadaires.
nous n'avons pas identifié de bits start + stop + parité, mais on a remarqué que chaque octet était séparé par 3 bits lorsque c'est l'outil de relevé qui parle et de 4 bits lorsque c'est le compteur qui parle. dans le fichier out_raw.zip ces bits de séparations sont présent. dans les fichiers out.zip et out.xls ils ont été supprimé.
J'ai rapidement regardé le fichier Excel et voici ce que j'ai compris.
Trame du hand recorder:
Octet 0 à 1: ????
Octet 2 à 7: Une sorte d'adresse de l’émetteur (qui embarque peut être un id lié au fabricant)
Octet 8 à 13: Adresse du destinataire
Octet 14 et 15: (0x00 0x28)????
Octet 16: ?
Octet 17 et 18: Peut être un CRC mais avec quel polynôme ???
Première réponse du compteur avec une trame vide peut être pour dire "je suis là, je vais t'envoyer les data":
Octet 0 à 1: ????
Octet 2 à 7: Adresse du compteur
Octet 8 à 13: Adresse du hand recorder qui a émis la request
Octet 14 et 15: (0x00 0x28)????
Octet 16 et 17: Peut être un CRC mais avec quel polynôme ???
Deuxième réponse du compteur avec une trame vide peut être pour dire "je suis là, je vais t'envoyer les data":
Octet 0 à 1: ????
Octet 2 à 7: Adresse du compteur
Octet 8 à 13: Adresse du hand recorder qui a émis la request
Octet 14 à 121: Des données avec peut être des index sur les derniers mois ???
Octet 122 et 123: CRC ??
Est ce que quelqu'un a réussi à trouver l'algo de CRC qui est utilisé ?
@+
Octet 2 à 7: Adresse du destinataire
Octet 8 à 13: Adresse de l’émetteur
Since, is somebody have made some new discovers?
-> http://hackaday.com/2014/02/25/using-sdr-to-read-your-smart-meter/
J'ai également un compteur d'eau Veolia en HRF à 868Mhz et un RTL-SDR à proximité. Est-ce que je peux aider à faire des captures ? des analyses ? des tests ?
Les RF fonctionnent à 433.82 Mhz. Est-ce qu'on connait la fréquence des 868Mhz ?
Merci,
--- Patrick
sur la partie 868 mhz, la couche phsique sera plutot du everblue, qui est crypté , mais faites tjs des enregistrements si le compteur emet en continu, avec gqrx ou rtl_fm , ou bin essayez meme de voir si rtl_433 ou rtl_amr decode vos trames (à compiler soi meme).
Est-ce que quelqu'un pourrait poster une trame avec les numéros qui se trouvent sur le compteur correspondant et pourquoi pas l'index.
L'expérience a pu nous montrer que les Cyble RF et les EverBlu Cyble Enhanced utilisent le même protocole à 433MHz.
As-tu pu vérifier si ton compteur émet en permanence.
Si tu as un dongle TNT du type "RTL2832 + R820T", c'est presque gagné.
Il y a de nombreux logiciel qui te permettent d'enregistrer la baseband à la fréquence que tu choisie (SDR# par exemple).
Si ton compteur n'émet pas en permanence, il va falloir même un "piège à loup" en place pour capturer des trames lors de la télé-relève.
@+
Est ce que quelqu'un à tester cela?
https://github.com/merbanan/rtl_433
On peut facilement changer la fréquence sur 433.82, je pense que ça vaut le coup d'essayer.
Comment faite vous concrètement pour récupérer les données ?
Logiciel ....
J'ai une clé TNT du type RTL2832 + R820T
Merci par avance
I have some Everblue Cyble Sensor with RADIAN protocol,
I have both C1101+Mbed and RPI + CC1101.
Could you help me with protocol?
Thanks
MM
C'est quoi le matos qu'il faut finalement ?
Merci par avance
et il te faut un micro contrôleur pour le contrôler moi j'ai choisis un RaspberryPI et sigma une carte Mbed
pour la mise au point l'utilisation d'un dongle Clé USB RTL-SDR (avec R820T2) est fortement recommandé pour vérifier que tu émets quelque chose et aussi vérifier le spectre d'émission.
la première étape consiste a emmètre une trame d’interrogation de ton compteur(voir Master request dans le paragraphe "example") (ne pas oublié les 2s de WUP) , pendant les heures ouvrable de ton compteur => pour être sur d’être dedans 9h-17h en semaine
Merci par avance pour les infos
Je te remercie par avance.
Je viens de découvrir cette page en cherchant des infos sur le protocole RADIAN vu que j'ai un compteur avec un module Everblu. J'ai un RPi, différents Arduino et mon module CC1101 est en cours d'acheminement. S'il y a du code sur lequel se baser, je suis preneur. Bravo pour tout le travail déjà effectué et merci d'avance pour votre support.
Toutes mes félicitations pour ce super travail de retro!
J'ai tellement envie de faire la même chose, mais mon compteur semble avoir un nouveau type d'adresse qui est comme sur la photo suivante:
http://www.endetec.com/endetec/ressources/files/1/31837,homeriderdplaquettecompteurs.pdf
Avez vous une idée de la façon de la décoder et pensez vous que les trames sont identiques?
De plus étrangement, mon compteur est en 868Mhz alors que je pensais que c'était la fréquence US.
Merci pour votre aide.
effectivement l'etiquette n'a pas le meme format
5322/10.81.09.05.09.89 (01/2009)
contre
YY-AAAAAAA-CCC
je pencherais pour ce mapping
TYPE/AA.AA.AA.AA.YY.CC
si tu n'a pas de réponse essaye de doubler le data rate.
et sinon il te faudra faire un enregistrement au moment au le mec passe...
Super boulot! Pensez-vous que ce genre de solution pourrait être intégré au Gateway RFLink ? http://www.rflink.nl
https://www.itron.com/eu/technology/product-services-catalog/products/c/8/1/bluetooth-rf-master-433-radian
je déterre un peu mais je m’intéresse aux pollutions électromagnétiques de toutes sortes et je me suis étonné de ne rien voir quand j'approche mon analyseur de spectre (entre 430 et 440mhz) de mon EverBlu Cyble en 433mhz, du coup j'ai cherché les données techniques et ce que j'ai compris c'est ça:
1) le module RF du compteur n’émet que s'il en reçoit la "demande"
2) ce module RF vérifie toutes les 2 secondes qu'il n'est pas en train de recevoir cette demande
3) la seule façon de relever le compteur (et qu'il émette) est d'utiliser un terminal mobile de relève (je parle ici d'utilisation "normale" hein ;)
Est-ce juste?
J'ai également lu dans les commentaires qu'il existe aussi des systèmes de relèves intégrés dans dans l'environnement direct du compteur, évitant le déplacement d'un technicien. Est-ce effectivement le cas?
Merci d'avance pour vos réponse!
Cette page est une vraie mine d'or, elle regorge d'information précieuse lorsque l'on cherche à interroger son compteur. Malheureusement, elle est difficilement accessible et elle y gagnerait à avoir une partie "Mise en oeuvre" qui, en quelques étapes, explique comment en partant de rien on arrive à récupérer les données souhaitées de manière très détaillée. Je pourrai vous aider à la rédiger, mais pour cela il faudrait que je parvienne jusqu'au bout moi-même ! :)
Aujourd'hui les points qui bloquent de mon côté :
1) [Branchement CC1101 - RPi] Confirmer l'exactitude des branchements suivants :
[CC1101] <=> [RPi]
VCC PIN1
VCC -
MOSI PIN19
SCK PIN23
MISO PIN21
GDO2 PIN13
CSn PIN24
GDO0 PIN11
GND PIN25
GND -
2) [Détermination de FREQ0] Préciser les valeurs de base pour High Byte, Middle Byte et Low Byte ainsi que la méthode de recherche de ces valeurs associée. Pourriez-vous détailler cela ?
3) [Compilation] Résoudre les nombreuses erreurs qui apparaissent à la compilation (manque des #include <> dans cc1101.c apparemment). Auriez-vous la liste pour qu'il compile du premier coup ?
Merci d'avance pour votre formidable travail et en espérant que la résolution de mes difficultés puissent aider les prochains qui se lanceront dans l'aventure ! :)
Bon dimanche.
Alex
1) oui ca l'air ca regardes http://www.lamaisonsimon.fr/wiki/doku.php?id=maison2:compteur_d_eau:compteur_d_eau#schema_de_cablage
2) la détermination de FREQ0 n'est pas facile ,moi j'ai eu de la chance parce que le compteur a répondu et donc j'ai pu voir la fréquence de la réponse sur mon SDR et donc ajuster la fréquence d’émission pour être le plus proche.
je recommandais de scanner le 433.82Mhz par pas de 2-3khz en partant du centre
3) il ne faut pas compiler CC1101.c tout seul , mais radian_trc.c avec la ligne de commande suivante : gcc radian_trx.c -o radian_trx -lwiringPi -lpthread -Wall.
il y a effectivement un caractère "c" a supprimer en ligne 5 de radian_trc.c
Merci pour ces premiers éléments. Dans l'ordre :
1) Le lien que tu pointes ne donne pas directement l'information. Je ne suis malheureusement toujours pas sûr.
2) Ok, je vais tenter maintenant que ça compile, en espérant que le câblage est bon pour éviter de tout faire griller ! :)
3) Ah oui avec cette ligne de commande + la correction des coquilles cela fonctionne ! Attention, ce n'est pas un 'c' qui est à supprimer en fin de ligne 5, mais un 's'.
Merci, bon weekend.
Apparemment, le compteur réagit de mon côté, puisque je vois une "bosse" apparaître sur SDR# lorsque je lance l'outil issu de la compilation.
Cependant, je n'obtiens aucune valeur... Voici ce que j'obtiens :
./radian_trx
raspian radian trx builded:Apr 29 2018 14:18:51
command list :
exit:x ;cc1101 version:v; read config : c
m:MARCSTATE a:MCSM1_val s:full_status
H:scenario de l'outil de rel▒ve !
R:Reset CC1101
Que faut-il faire par la suite ?
Merci d'avance. Bonne semaine.
Après avoir tenté de saisir toutes les lettres possibles, aucune donnée. Je perds un peu espoir... Pourriez-vous me donner quelques pistes ?
Merci infiniment.
Bonne semaine
appuie sur H(h en majuscule) entre 9h et 17h en semaine , tu devrais voir sur ton SDR un signal qui va durer 2 secondes suivie si tu as de la chances de la réponse du compteur
J'obtiens cela, après l'avoir fait à l'instant :
HMARCSTATE : raw:0x13 0x13 free_byte:0x0F sts:0x02 sending 2s WUP...
0free_byte:0x0F sts:0x02
MARCSTATE : raw:0x0D 0x0D(RX RX)
TMO on REC
MARCSTATE : raw:0x0D 0x0D(RX RX)
TMO on REC
Comment l’interpréter ? Quelle la valeur de mon compteur ?
Merci encore pour votre aide. Bonne semaine.
travail remarquable. J'ai bien envie de tester sur mon compteur. il s'agit d'un HomeRider system G2 HRF-c à 868 Mz. Pour info, avant j'avais un ITRON (mais remplacé car plus de pile et donc plus de relevés) donc j'imagine que le nouveau doit être compatible.
l'étiquette indique:
53.22 /
50.81.17.37.0D.0D
il a été installé il y a 3 semaines et il est opérationnel car je vois mes relevés journaliers sur le site de Véolia.
Auriez-vous une idée de l'adresse de ce compteur ?
merci de votre aide, à bientôt,
Après analyse: le 17 dans mon numéro de compteur est bien l'année. En faisant des recherches sur internet, j'ai vu que les compteurs Cyble HRF on toujours ce format
53.22 / XX.81.AA.YY.YY.YY . Avec AA l'année du compteur. Je soupçonne donc que le numéro de série doit être YY.YY.YY car dans le protocole RADIAN, il faut que 3 octets pour l'adresse.
Est-ce que quelqu'un a fait ce constat ?
le nom de fichier sans l'extension
merci pour cet article et tout le travail de fourmis ayant permis ce reverse engineering !
Mon domicile étant équipé de ce compteur depuis 2007 et ayant un RPI, CC1101 et SDR j'ai essayé de les faire communiquer.
En utilisant le script radian_trx et en appuyant sur H j'ai pu observer avec SDR# que le RPI et le compteur semblaient bien communiquer ensemble. Sur cette capture d'écran : https://ibb.co/hFq2rDY on voit 3 trames. La première viens du RPI, les 2 suivantes du compteur d'eau. Malheureusement le script ne semble par arrive pas a décoder les trames envoyées en retour.
Avez-vous une idée, un conseil ?
Merci
Est-ce que qqun a écrit un script avec une sortie plus exploitable ?
Je vois dans l'article une référence à un script appelé via cron : web_tx_releve mais il n'est pas dans le zip.
voici le contenue de web_tx_releve
cpt_response=`sudo /home/pi/cpt_eau/radian_trx r`
echo $cpt_response
wget -4 -O/home/pi/cpt_eau/phpout -o/home/pi/cpt_eau/out http://www.tonserveur.com/traitement.php?data=$cpt_response
ca ne fait que envoyer les données sur un serveur , si tu veux plus de donnée tu peux essayer la sortie .\radian_trx , sans paramètre ça cause plus
pour ce qui est de la pollution RF c'est pareil qu'une clef de voiture cad rien ou presque
C'est un CC1101 USB, cela rendrait la chose bien plus simple, et accessible a tous !
Merci d'avoir publié toutes ces infos, j'ai réussi grâce à vous à lire mon compteur d'eau récemment installé.
N'ayant pas de clé TNT, j'ai ajouté une fonction qui scanne les fréquences et tente une récupération. J'ai peut être eu de la chance, mais cela a fonctionné pour trouver le réglage de Freq0
uint8_t cc1101_scan(void)
{
uint8_t ret=0;
for (uint8_t freq=0;freq<255;freq++){
halRfWriteReg(FREQ0,freq);
printf("\n\nEssai avec Freq0=%d\n",freq);
ret=scenario_releve();
if (ret!=0) {
printf("\nReponse !!!!");
show_cc1101_registers_settings();
//break;
}
}
return 1;
}
Merci, grâce à votre super taf, j'ai pu récupérer les données de mon compteur AnyQuest Cybel, reste plus qu'à l'intégrer dans Domoticz :)
La clé SDR m'a beaucoup aidé, et surtout à voir que mon CC1101 n'émettait pas : dans le schéma de câblage, il faut bien penser à connecter le 3.3V (VCC) du CC1101 au Raspberry (PIN 1 ou 17).
Je n'ai pas eu besoin de changer la fréquence, la valeur en ligne 233 (0xB7) a fonctionné direct pour moi.
Mon compteur ne communique effectivement qu'en heures ouvrées (9h 17h ? - je n'ai pas vérifié la plage)
Pour tous ceux qui se lancent dans l'aventure, ça peut faire peur mais le plus compliqué c'est de faire le câblage entre le raspberry et le CC1101 (ne pas se tromper dans les branchements !)
A+ !
Merci beaucoup pour le travail accompli. Je suis en train de me lancer dans le montage électronique mais est ce que l'un d'entre vous aurait des details sur l'intégration dans Domoticz?
Merci d'avance.
Prochaine étape : l'intégration dans Domoticz pour historiser ma conso quotidienne et mettre en place une alarme sur seuil haut pour détecter d'éventuelles fuites (ca m'est arrivé donc je sais de quoi je parle :-( )
Merci encore pour le super boulot.
pour l'intégration dans Domoticz :
1. modifier le fichier cc1101.c : ajouter les fonctions
void writeres(char *tow)
{
FILE *fptr;
char file_name[] = { "./litres.txt" };
fptr = fopen(file_name, "w");
if(fptr == NULL)
{
printf("Error!");
exit(1);
}
fprintf(fptr,"%s", tow);
fclose(fptr);
}
void display_meter_cron (uint8_t *decoded_buffer , uint8_t size)
{
char output[1000];
if (size >= 30)
{
printf("%u\n",decoded_buffer[18]+decoded_buffer[19]*256 + decoded_buffer[20]*65536 + decoded_buffer[21]*16777216);
sprintf(output,"%u",decoded_buffer[18]+decoded_buffer[19]*256 + decoded_buffer[20]*65536 + decoded_buffer[21]*16777216);
writeres(output);
}
}
et remplacer dans la fonction scenario_releve : la ligne :
else show_in_hex_one_line_GET(meter_data,meter_data_size);
par la ligne :
else display_meter_cron(meter_data,meter_data_size);
2. recompiler, mettre le programme dans le dossier /home/pi/radian/
3. dans Domoticz, créer un nouveau matériel de type "Dummy"
puis créer un nouveau capteur virtuel de type "Compteur"
Récupérer son numéro d'index dans les dispositifs (colonne Idx)
Votre compteur apparaît dans le menu des Mesures : le modifier pour mettre un type "Water" et un diviseur à 1000
4. créer sur le PI un fichier /home/pi/radian/script.sh , remplacer la valeur 167 dans le script par celle de votre numéro d'index précédemment trouvé :
#!/bin/sh
cd /home/pi/radian
FILE="/home/pi/radian/litres.txt"
HISTORY="/home/pi/radian/litres_history.txt"
dt=$(date '+%d/%m/%Y %H:%M:%S');
rm -f $FILE
/home/pi/radian/radian_trx r
if test -f "$FILE"; then
value=`cat $FILE`
echo "$value"
curl "http://localhost:8080/json.htm?type=command¶m=udevice&idx=167&svalue=$value"
echo "$dt;$value" >> $HISTORY
rm -f $FILE
fi
5. pour info, le script historise les valeurs dans le fichier /home/pi/radian/litres_history.txt avec la date et l'heure
6. Editer votre crontab (crontab -e) et ajouter :
0 9,17 * * 1-5 /home/pi/radian/script.sh
cela lance le script à 9h et 17h tous les jours ouvrés de la semaine.
7. pour supprimer de Domoticz la première valeur qui risque de fausser les tendances et la lecture, appuyer sur shift et faire un clic dessus cette valeur : vous pouvez alors la supprimer.
Reste à faire : je ne sais pas encore pourquoi mais Domoticz comptabilise mal les litres lorsqu'il n'y pas pas eu de valeur depuis un certain temps...
Une solution serait peut-être de faire un script qui se lance en dehors des heures de collecte (9h et 17h) et qui pousserait systématiquement la dernière valeur, à tester !
PS : je ne suis pas sûr que ce soit une bonne idée de lire trop régulièrement le compteur pour les détections de fuite : la batterie pourrait ne pas tenir la durée, des avis ?
++ !
1. créer le fichier /home/pi/radian/dummy.sh, remplacer la valeur 167 dans le script par celle de votre numéro d'index précédemment trouvé :
#!/bin/sh
cd /home/pi/radian
HISTORY="/home/pi/radian/litres_history.txt"
if test -f "$HISTORY"; then
value=`tail -1 $HISTORY | cut -d\; -f2`
echo "$value"
curl "http://localhost:8080/json.htm?type=command¶m=udevice&idx=167&svalue=$value"
fi
2. Editer votre crontab (crontab -e) et ajouter :
30 * * * * /home/pi/radian/dummy.sh
cela lance le script toutes les heures à 30 minutes (pour éviter le conflit à heure fixe de 9h et 17h !)
En plus du Pi0W, je pensais acquérir ce module CC1101 :
https://fr.aliexpress.com/item/4000310314726.html?spm=a2g0s.9042311.0.0.38fd6c37s7T6jA
et ce PCB :
https://netxing.files.wordpress.com/2017/09/photo_2017-09-20_22-11-18.jpg
Quelqu'un a réussi à récupérer les données du compteur d'eau HRF-C-G2 de Homeridersystems au final ?
J'hésite vraiment à me lancer car ce n'est pas très clair pour mon environnement et mon besoin en 868MHz...
Mille mercis à quiconque pourra m'apporter ses lumières !
J'ai profité du confinement pour tester et sniffer mon compteur. C'est fait grâce à la fonction de Ced pour parcourir les fréquences.
j'ai ajouté un curl juste pour envoyer le relevé via l'API Domticz
Tout marche sur Raspberry , mais impossible de faire fonctionner le CC1101 sur orange Pi zero.. a suivre
In file included from radian_trx.h:96,
from radian_trx.c:5:
cc1101.c: In function ‘scenario_releve’:
cc1101.c:685:13: warning: variable ‘TS_len_u8’ set but not used [-Wunused-but-set-variable]
uint8_t TS_len_u8;
^~~~~~~~~
is there a possibility to send the command I sniffed with this protocol when communicating gateway and heatmeter?
Tout d'abord un grand merci à tous ceux qui ont permis de trouver les solutions pour effectuer les relevés de nos compteurs d'eau : Fred, Julien, SigmaPic et puis plus récemment les autres contributeurs pour Domoticz, etc...
J'ai réussi à relever mon compteur d'eau (EverBlu Cyble Enhanced V2.1) grâce à un Raspberry Pi 4 et un petit module CC1101 ( https://www.amazon.fr/dp/B07YX92NMP?ref_=pe_3044141_248816771_302_E_DDE_dt_1 ).
La principale difficulté rencontrée a été au niveau du numéro de série de mon compteur : "0123456". J'avais saisi "0123456" dans la fonction "Make_Radian_Master_req" et ça ne fonctionnait pas. Après avoir enlevé le "0" au début, c'est à dire saisi "123456" dans la fonction "Make_Radian_Master_req", ça c'est mis à fonctionner parfaitement (sans changer les fréquences, ce qui m'arrangeait bien...). Pour l'explication sur le "0" en début de valeur en C/C++, c'est ici : https://stackoverflow.com/questions/29325822/c-int-with-preceding-0-changes-entire-value
J'ai commencé à faire quelques modifs dans le code (+ d'infos notamment) et j'aimerais peut-être le passer en C++ plutôt que C. Quelle est la licence associée au code source ?
@Fred : Est-ce que le code fait appel à des morceaux de code sous licence ?
Dernière question : étant donné que le compteur retourne un indicateur sur le nombre de lectures, il n'y a aucun risque (pas physique, mais plutôt côté "légalité") à relever souvent son compteur...? Pour ceux qui ont intégré leur compteur avec un système domotique, vous faites combien de relevés par jour/heure ?
Francois
effectivement l'exemple donnée pour le numéro série n'est pas idéal .
je n'ai pas mis de licence sur ce code peut être devrais-je , je n'y commait pas grand chose en terme de licence.
ce code a été fait en "regardant" le protocole radian qui est dit open source plus haut dans la page , je ne sais pas si ca aide ?
le compteur de lecture peut être surveillé par ton gestionnaire d'eau surtout en cas d'auto relève.
personnellement je ne fait qu'une relève par jour je n'ai pas vu d'impact sur la durée de vie de la pile intégré
J'ai réussi à tous mettre en place; par contre j'ai une interrogation sur l'automatisation du lancement de l'exe créé sur le pi.
Ce qui est donné plus haut lance-t-il l’exécutable car une execution en relève il faut bien lui indiqué le chemin H:scenario de l'outil de releve ! et le crontab demande simplement le lancement de l'exe:
"sudo crontab -e
55 9 * * * sudo /home/pi/radian_trx/web_tx_releve >/dev/null 2>&1
55 9 * * * sudo /home/pi/radian_trx/web_tx_releve >> /var/log/crontab.log"
je n'ai pas de raspberry Pi mais une arduino + CC1101.
Peut être que quelqu'un aurait développé un code sur arduino pour lire les compteurs cyble RF
On ne sait jamais
Avant de me lancer j'ai une question qui je crois n'a pas été encore évoquée :
A quelle distance de votre compteur se trouve votre système de relève et avez vous fait des tests de distance maximum ?
Tout d’abord merci pour le travail fantastique que vous avez fait.
Je partage avec vous les problèmes que j’ai eus:
1) La carte CC1101 que j’ai achetée n’a pas fonctionné correctement, je vous suggère d’acheter ceci:
https://www.amazon.es/gp/product/B07YX92NMP/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
2) La connexion à la RaspberryPi 3 n’est pas 26 broches, mais 40, s’il vous plaît noter les connexions. J’ai eu tort de relier la Csn(CC1101) - CE0(pi) et le CC1101 n’a pas fonctionné.
3) Vérifiez que le CC1101 fonctionne en exécutant le radian_trx et en choisissant l’option : v . Si la réponse n’est pas différente de 00 ou FF, c’est parce qu’ils ne communiquent pas avec cc1101.
3) La fréquence FREQ0 choisie était la fréquence défectueuse et fonctionnait correctement (halRfWriteReg(FREQ0,0x75);).
4) Le numéro de série de mon Cyble everblue a commencé à 0. Ne placez pas 0 dans le fichier cc1101.c
5) Le cyble fait paire avec le compteur physique, c’est-à-dire qu’il a une association. Cette association se fait par comptage et numéro de série, qui est lu dans la communication.
Corrections requises : le numéro de série du compteur physique est à l’envers. En d’autres termes, le dernier chiffre est le premier et ainsi de suite.
Implémentations suggérées :
1) Obtenez des informations sur les fuites d’eau - Cet appareil permet à la fuite d’eau d’être en place et doit être lu.
2) Vérifiez la possibilité de changer la paire Cyble+ compteur physique. Par exemple, j’ai acheté le compteur physique Cyble+. Alors ils font une paire. Cependant, j’ai enlevé le cyble du compteur physique et je voulais maintenant mettre dans le compteur physique de la compagnie d’eau, qui a un autre compte et un autre numéro de série. Le compte et le numéro de série doivent être possibles de changer.
Merci a tous
Trouvé ce blog par hasard et très heureux car je me demandé comment lire mon compteur ITRON Everblue Cyble V2.1 afin d'inclure les infos dans ma domotique Jeedom.
Je ne suis pas un spécialiste en programmation mais bidouille un peu. Je vais rentrer une interface TI et un PiZero. Je pense que cela devrait convenir et par la suite m'attaquer au script pour la liaison avec Jeedom (c'est la que cela va se compliquer ;-))
Y a t il eu des avancés sur le soft? Je m'arrache les cheveux pour comprendre le calcul de la fréquence. Je fais mumuse avec SmartRF Studio de TI et il semble que l'algorithme n'est pas si simple que ça, plusieurs éléments entrent en ligne de compte. On retombe sur vos suggestions FREQ0 en prenants les divers paramètres déjà actés dans l'init. Dés que j'aurais le matériel je comparerai avec un SDR, après avoir étalonné son offset(sur fréquence météo aéro..) Vous tiendrai informé de mes avancés C'est un super boulot qui a été fait, encore merci
Je serai intéressé par le soft que "sigma PIC" aurait développé sur Mbed + CC1101.
Je viens juste de dire ça.
Dommage que ce blog semble s'être endormi mais pour les curieux toujours à l'écoute, je confirme que cela marche très bien.J'ai gardé les réglages par défaut et du premier coup, j'ai obtenu les résultats. Cela m'a permis d'ailleurs de constater que la partie électronique de mon compteur,même si elle marche et revois les informations, est bloquée. Comme c'était un compteur neuf, monté à zéro, cela a permis de constater l'erreur de relevé de la mairie et de déterminer un blocage de plus de 6 mois. J'espère qu'ils vont me le remplacer car maintenant que je peux le lire et l'englober dans ma domotique.... C'est râlant ;-)
Bon, en ce qui concerne la fréquence, et bien c'est relativement simple et surtout plus précis que la méthode empirique d'essai de diverse valeur.
Je me suis inspiré de différentes librairies (Github) pour des utilisations de CC1101 avec Arduino et trouvé la méthode de calcul.
Il y en a principalement 2, une relativement lourde à mettre en oeuvre car elle est basé sur les informations en binaire avec des rotations à gauche et à droite le tout avec un re-calcul en décimal/hexa à chaque fois. On travaille sur du 32 bits donc vous voyez le boulot mais ça marche. J'ai utilisé Excel et ses diverses option pour faire un tableau.
Par contre, la deuxième est beaucoup plus simple mais nécessite également Excel pour faciliter les calculs.
Le principe utilise 7 cellules principales et trois de plus pour convertir les résultats décimal en Hexa pour les rentrer dans le programme.
Cellule 1 : 433.920 - fréquence médiane choisie
cellule 2 : 26 - fréquence du quartz du circuit (fixe)
cellule 3 : =ENT(Cel1/cel2) - FREQ2 en décimal (valeur entière)
cellule 4 : =MOD(Cel1;cel2) - Modulo de FREQ2
cellule 5 : =ENT(cel4/0,1015625) - FREQ1 en décimal la valeur du diviseur est fixe et ne me demandez pas comment on le trouve ......sait pas
cellule 6 : =MOD(cel4;0,1015625) - Modulo de FREQ1
cellule 7 : =ENT(cel6/0,00039675) - FREQ0 en décimal la valeur du diviseur est fixe et ne me demandez pas comment on le trouve
les 3 dernières cellules utilisent =DECHEX(celx) pour convertir en Hexa les valeur FREQx afin de remplir correctement le programme.
Amusez-vous bien il suffit de changer la fréquence et tout s'incrémente automatiquement.Les résultats ont été vérifiés avec Smart RF Studion de TI. C'est OK
comparez avec les valeurs empiriques et vous verrez.
@+
J'ai effectué les tests. J'ai réussi à recevoir les données. Par contre j'ai un décalage.
Compteur = 1555 reçu 1595
Commpteur = 1613 reçu 1656
Cela est-il un problème de réglage de freq ?
Je ne pense pas que cela soit un problème de fréquence car, après essais de contrôle fréquences, ou ça passe ou ça passe pas. Si à la réception la trame est complète et que donc l'affichage du résultat est en clair en dernière ligne, la différence ne peut, à mon avis, ne venir que d'un léger décalage dans la transmission mécanique (capteur visuel) Je pense avoir ce problème sur mon compteur puisque tout fonctionne sauf l'incrémentation du volume. Si vos résultats sont en litres la différence n'est pas probante entre une lecture du compteur mécanique et celle électronique.
Forum très intéressant et je souhaite faire mon montage pour le même capteur d'eau vers du Domoticz.
je ne vois pas comment s'inscrire sur ce forum et récupérer les sources :(
est-ce que quelqu'un pourrait aurait celles mentionnées par François?
s'il y a qq'un qui lit cette bouteille à la mer, n'hésitez pas à me contacter/me donner les liens utiles SVP:
harko_tank at yahoo.fr
merci en tout cas!
vincent
Pas besoin d'inscription pour les sources. Il suffit de télécharger le fichier radian_trx.zip dans la rubrique code (le password est le nom du fichier, tout simple)Avec le réglage fréquence par défaut cela marche du premier coup (chez moi..) il faut simplement rentrer le Numero du compteur sans le 0 du début et faire les 2 correction dans les fichiers comme indiqué.
Pour Domotiz, les explications sont données, pour ma part j'ai simplement fait quelques modifs pour que cela fonctionne dans un virtuel Jeedom.
Bonne bidouille
Y aurai t'il eu des améliorations afin de rendre le montage plus accessible et l'utiliser avec home assistant et pourquoi pas avec un ESP32 ?
Car après lecture attentive, j'ai pas trop compris ce qu'il faut faire exactement.
Merci.
Pour ma part, ça ne fonctionne pas pour l'instant. Pas de réponse du compteur (testé en pleine journée, un jour de semaine) malgré la fonction de scan et en testant différentes possibilités (année en décimal et en hexadécimal, numéro de série avec/sans les numéros inversés). A priori, le CC1101 fonctionne puisque je vois les deux secondes de "mise en éveil du compteur" sur SDR# via ma clé SDR.
Merci encore malgré tout.
GDO0! 00 1st synch received rssi=177 lqi=128 F_est=255
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! frame received
RAW buffer
received radian frame size=0
TMO on REC
Quelqu'un a-t-il déjà eu ce type de situation ?
Je pense qu'il s'agit soit d'un réponse fantome (mais elle apparait qu'autoir de 433,82) ou bien c'est un autre compteur qui réagit mais pas le mien..
Pas simple d'en savoir plus..
Merci !
je me commande le CC1101 sur Amazon, pour le rpi, on peut prendre un pi zero ?
@Pacific, tu as fait quel genre de modif car pareil, c'est pour l'intégrer a jeedom ?
un grand merci a celles et ceux qui ont bossé pour trouver cette solution !
J'ai un compteur itron cyble HRFv5.2 868MHz. Savez vous quelle est la bonne fréquence à écouter? Car avec la commande rtl_433 -f 868MHz ça ne donne rien même après plusieurs heures d'écoute! J'ai une clé rtl-sdr nooelec. Merci de votre aide
je suis intéressé par le fait de pouvoir relever mon compteur d'eau à distance, votre discussion est très intéressante mais on s'y perd facilement surtout pour des non-initiés comme moi.
Quelqu'un pourrait il faire un tuto détaillé pour tout expliquer, je sais j'en demande beaucoup mais se sujet intéresse beaucoup de monde ?
Je précise que j'ai aussi un compteur d'eau avec un Everblue monté dessus.
Merci pour votre aide, bien cordialement.
Phil
J'ai quelques soucis :
- Quelqu'un a-t-il une solution pour l'erreur ci-dessous :
In file included from radian_trx.h:96,
from radian_trx.c:5:
cc1101.c: In function ‘scenario_releve’:
cc1101.c:685:13: warning: variable ‘TS_len_u8’ set but not used [-Wunused-but-set-variable]
uint8_t TS_len_u8;
^~~~~~~~~
Par ailleurs, pouvez-vous expliquer ce qu'il convient de faire avec les différentes lignes FREQ ?
Merci d'avance,
I am trying for a week now to read my "AnyQuest Cyble Enchanced" -433Mhz watermeter. I have some experience with RF but this watermeter seems to be my kryptonite :).
I have the code right, I tried different frequencies, I have the correct year and serial "15" - "1052512", I tried different times of day, there is no response from it. I am watching in parallel the communication with a RTLSDR to see if message is sent correctly, and it seems it is sent ok. I just can't make it work. There is no response from the meter.
I am using Raspberry Pi zero + CC1101 module.
Wiring is done correctly (triple checked it). The message sniffing with RTL-SDR looks correct.
Any other suggestions that might help me?
Unfortunately I can't help you. It looks like you are farther than me : could you help on my previous mail ?
I tried with a rtlsdr but not sure I see messages from the watermeter.
My issues are still :
1-Did you jump into this error ? and how did you solve it ? maybe could you share your CC1101.c file around row 660 ? when compiling :
In file included from radian_trx.h:96,
from radian_trx.c:5:
cc1101.c: In function ‘scenario_releve’:
cc1101.c:685:13: warning: variable ‘TS_len_u8’ set but not used [-Wunused-but-set-variable]
uint8_t TS_len_u8;
^~~~~~~~~
2 - In your mail, it looks like you correctly deal with the frequency in file CC1101.c : could you also share it ?
3 - watermeter number : in some posts above, I understood we have to post the number from right to left. For instance if watermeter id is 123456 you have to put in CC1101.C 654321. Is it what you did ?
Also, I share with you an other tool that looks interesting, but I don't read anything from the everblu cyble watermeter at that stage (youtube : https://www.youtube.com/watch?v=m5R6sfsGmvE&list=UURJE6Yb_R3Xei-QGcy_Qwhw&index=14)
Many thanks for your help,
Regards,
https://github.com/tpacri/cyble_reader
here is my code. I added 3 more key shortcuts: 2 for increasing/decreasing the frequency by 0.2Khz as instructed to make it easier to test with different freq.
And another shortcut that starts a continuous reading every 10 seconds or so. I am using this in order to start the continuous reading (outputting the result to a file) and moving my raspberry pi closer to the watermeter just in case the transmit power was not enough).
In my code in cc1101.c line 825 replace the YY, SSSS with your own values from the watermeter reader
int msgSize = Make_Radian_Master_req(txbuffer, YY, SSSSSS);
To be noted tha as so far i was NOT able to read anything from my watermeter. Watermeter doesn't seem to react to my messages
To build it, copy my code to your raspberry pi zero, change the YY, SSSSS to your values and then ran "bash build.sh" to build your code. If no error, you can runt it and test
After doing these changes I saw with my RTLSDR a very weak response. It was a response for sure but the deviation was so small that my UniversalRadioHacker could not decoded it yet. I will try in the next days to dig in more and maybe change the raspberry pi code to make it work also. Will update here.
I ran into some compilation issues using your files. I had some errors that I was unable to understand.
But I found this, which is working based on the work done above and similar to your work : https://github.com/neutrinus/everblu-meters. Only issue was related to the wiring indications, that were wrong (do not use the numbers on the CC1101 but the names of the pin)
I have an accurate measure, and as the mqtt part is embedded, I can have the information uploaded into HA as well.
Regards,
Currently, the CC1101 is linked to a Pi4. Not the best attelage, I will maybe buy a smaller raspberry. But the watermeter is on the ground level, while the CC1101 is on the 2 level, so at least 6 meters away and the signal is correct and accurate. Maybe it depends on the CC1101 model ?
For the HA part, I am using utilities meter, but I also started to adapt this to the Itron watermeter measures. https://forum.hacf.fr/t/monitoring-electricite-avec-la-teleinfo-node-red-influxdb/4546
Regards,
Après quelques difficultés a priori je récupère des données "GDO0! frame received" avec plein de code en Hexa quand je fais la commande "H"
Comment faire pour obtenir les litres / m3 du compteur ?
Mon compteur est ITRON EverBlu CyBle 22-xxxxxxx-177
Merci
après quelques semaines a étudier cette page et faire des tests j'ai enfin pu récupérer la valeur de mon compteur avec succès !
C'est génial merci pour votre travail ! En particulier tous les commentaires plus haut.
Bon il faut maintenant que je vois si il est possible de récupérer la valeur du compteur pour les x derniers jours. Notamment pour ne pas avoir une consommation nulle les samedi et dimanche et le lundi trop importante (dans mon cas je fais une prise de mesure par jour.
Je sais que suez ou veolia avait des compteur similaire avec remonté de l'index sur leur site. Pas d'info de consommation le samedi ni dimanche mais le lundi d'après on récupérait la conso du weekend jour par jour. Donc je me dit que c'est bien enregistré dans le compteur et surement transmis d'une façon ou d'une autre... (pour ceux que ca intéressent : https://domotique.web2diz.net/recuperer-les-information-de-consommation-du-site-de-la-lyonnaise-des-eaux-sdei/)
Je vais essayer de creuser encore un peu plus mais ca va aller certainement au delà de mes limites... Si je trouve un truc je vous tiendrai au courant !
Merci encore et à très bientôt
Je suis toujours en galère.
Peux tu médire si tu as renseigné dans le code l année et le numéro du compteur comme affiche sur le compteur?
Perso, j ai un numéro commençant par zéro, j ai essayé avec et sans cela n a pas marché
Sinon à quelle distance faut-il être du compteur car le mien est dans la rue?
Merci d avance
J'ai renseigner le code sans les zero du debut :
ex si ton code est 21-02365800-123 tu renseigne 2365800
Désolé pour le delais ;)
Merci Sirus pour l'info au moins maintenant je n'ai plus de doute sur le numéro.
1/Quand je lance "H" (scénario télérelève), j'obtiens uniquement le message (en mode debug)
MARCSTATE : raw:0x13 0x13 free_byte:0x0F sts:0x02 sending 2s WUP...
50 00 00 00 03 FF FF FF FF 64 70 47 00 75 17 34
76 07 03 73 77 00 75 17 02 72 87 05 71 47 00 72
87 01 76 47 1E FF FF
189free_byte:0x0F sts:0x07
MARCSTATE : raw:0x0D 0x0D(RX RX)
TMO on REC
MARCSTATE : raw:0x0D 0x0D(RX RX)
TMO on REC
J'en conclue que je ne recois rien.....
2/ J'ai "vérifié" le CC1101 avec "v": j'obtiens
vCC1101 Partnumber: 0x00
CC1101 Version != 00 or 0xFF : 0x04
Je suppose que cela est correct.
3/ POur la config du registre, commande "c" j'obtiens
Config Register in hex:
0 1 2 3 4 5 6 7 8 9 A B C D E F
0D 2E 06 47 55 00 FF 00 00 00 00 08 00 10 AF B7
F6 83 02 00 00 15 07 00 18 1D 1C C7 00 B2 87 6B
FB B6 10 E9 2A 00 1F 41 00 59 7F 3F 81 35 09
PaTable:
60 00 00 00 00 00 00 00
Peux-tu m'indiquer ce que tu reçois pour ces commandes pour pouvoir comparer?
Si tu as une idée....
Merci d'avance
Merci aux auteurs pour leur travail de reverse engineering.
I tried yesterday your code with a Wemos and I finally I have a stable reading integrated in HomeAssistant.
Thank you!
PS: I can confirm that my Anyquest-Cyble does NOT respond in weekends nor in weekdays after 17:00 local time
merci pour ton portage sur esp8266 , ça fait plaisir de voir vivre le projet.
merci aussi aux autres commentaires
Ca faisait un longtemps que je n’était pas revenu voir les commentaires , je suis épaté par toute cette activité :-)
Désolé je ne vois ton message que maintenant.
L'instalation est en place depuis quelques semaines et je n'ai aucun probleme pour info.
j'ai eu quelques fois on ce ne marchait pas, cétait que le capteur n'etait pas assez pres. (tu peux tester à 1m pour verifier...).
Aujourd'hui il est a une 10ain de mettre et traverse une voiture et un mur en brique et ça fonctionne...
Losque je mets l'option H j'obtien :
command list :
exit:x ;cc1101 version:v; read config : c
m:MARCSTATE a:MCSM1_val s:full_status
H:scenario de l'outil de releve !
S:scan
R:Reset CC1101
HMARCSTATE : raw:0x13 0x13 free_byte:0x0F sts:0x02 sending 2s WUP...
50 00 00 00 03 FF FF FF FF 64 70 47 00 75 17 44
76 07 71 71 77 00 75 17 02 72 87 05 71 47 00 72
87 01 72 77 3E FF FF
186free_byte:0x0D sts:0x07
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! 00 1st synch received rssi=171 lqi=128 F_est=255
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! frame received
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! 00 1st synch received rssi=171 lqi=128 F_est=255
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! frame received
0x00,0xFF [puis un long message en hexa]
Pour finir par la ligne qui affiche les infos :
2/9/2022 15:6:25 264903litres Num189 113Mois 6h-18h serial:<serial de mon compteur>
j'ai addapté le script .h et fait un .sh pour ajouter les info dans domoticz automatiquement, je detailerai ça très prochainement ici https://github.com/Sirus10/consoEAU ...
Merci à tous pour vos contrubitions et votre aide !
I know it is possible, but I cant find the data format or payload to set the configurations.
Best regards,
-- Marco
I would like it to respond outside of business hours.
Pour ceux que ca intéresse, ma petite contribution, j'ai fait des cartes CC1101 directement enfichables sur un PI (c'est plus simple et joli)
https://github.com/hallard/cc1101-e07-pi
Reçues hier, testée fonctionnent impek, j'ai aussi mis à jour le code pour cette carte
https://github.com/hallard/everblu-meters-pi
D'autres à venir dont une ESP32 avec le module CC1101 directement dessus et une autre carte PI avec les modules AliExpress (pas le EBytes E07)pour que vous puissiez souder facilement.
Avec toute l'aide trouvée ici (Merci @Fred) ,
et les compléments trouvés la https://haade.fr/fr/blog/domotiser-compteur-eau-itron-everblu-cyble ( Merci @Nico @Haade)
je vais me lancer.
En attente de livraison AliExpress !
Encore merci à tous les participants du forum
Thanks
rrigues
I have an actaris cyble rf 433Mhz from 2002. I won't do anything with it.
If anyone is insterested, I can send it in France. Give what you can.
Bonjour tout le monde,
J'ai un actaris cyble rf 433Mhz de 2002. Je ne vais rien en faire.
Si quelqu'un est intéressé, je peux l'envoyer en France.
Donnez ce que vous voulez en échange.
J'ai un compteur d'eau Itron EverBlu Cyble installé par le SICOVAL.
Pouvez vous m'aidez à récupérer les informations de ce compteur, existe t-il un tuto ?
Merci par avance,
William
Je me permets de venir contribuer et poser des questions sur ce site que j’ai découvert et qui m’a vraiment permis d’avancer sur le projet de récupérer les valeurs de mon compteur d’eau.
Je ne pensais pas être capable d’arriver aussi loin dans ce projet, donc merci à tous.
Pour résumer j’arrive à émettre sur les différentes fréquences autour de 868 MHZ mais je n’arrive pas à avoir de réponse de la part du compteur.
Avez-vous des idées ?
Voici le matériel et les étapes que j’ai suivis.
Mes équipements sont les suivants :
*Compteur : Dhiel Metering
*Relève de compteur sans fil : hrl-c-g2 868 Mhz, hmeridersystems : https://ac2nb.fr/wp-content/uploads/2018/11/Birdz-Fiche-produit_G2.pdf
*Récepteur SDR : Fasizi Mini clé TV numérique portable USB 2.0 DVB-T + DAB + FM RTL2832U + R820T2 prend en charge le tuner SDR :
https://www.amazon.fr/dp/B09Z27VTFL?psc=1&ref=ppx_yo2ov_dt_b_product_details
*CC1101 868MHz : https://www.amazon.fr/dp/B07RH67FWV?psc=1&ref=ppx_yo2ov_dt_b_product_details
*Cable électronique : https://www.amazon.fr/dp/B01JD5WCG2?psc=1&ref=ppx_yo2ov_dt_b_product_details
*Raspberry pi 0 w2 : https://www.amazon.fr/dp/B08MTLHHMK?psc=1&ref=ppx_yo2ov_dt_b_product_details
*Raspian OS 32 bullseye (11)
Procédure d’installation :
*Dans un premier temps j’ai installé Raspbian OS 11 sur le raspberrypi 0 2w.
*J’ai soudé les PIN GPIO.
*J’ai téléchargé : radian_trx.zip sur le site, bizarrement, j’ai dû utiliser chrome car cela ne fonctionnait pas avec Firefox.
J’ai également suivi la procédure de Sirus10 https://github.com/Sirus10/consoEAU.git car il y a l’option scanne et je me suis dit que ça m’aiderait à trouver la trame de mon compteur.
-Installer Ksh
-Cloner https://github.com/Sirus10/consoEAU.git
-Installer wiringPi. Là j’ai un peut galéré car il n’est plus en service depuis 2019 et j’ai un Pi0.
/Pour un raspberry pi 4B : https://github.com/WiringPi/WiringPi
/Pour un Pi0 : https://www.electro-info.ovh/index.php?id=278
J’ai suivi la procédure de configuration :
*Dans CC1101c :
-CC1101.c : ligne 664 : TS_len_u8=Make_Radian_Master_req(txbuffer, 16 , 123456 );
Je pense que c’est là que j’ai un problème, mon relevé de compteur indique 53.22 / 51.81.18 XX.XX.XX, j’ai donc renseigné 18 pour l’année et XXXXXX pour le numéro du compteur.
-J’ai ajouté en première ligne après le texte #define TX_LOOP_OUT 300
-fréquence à ajuster en fonction de votre CC1101 CC1101.c : ligne 229 : halRfWriteReg(FREQ0 , ….)
J’ai utilisé un fichier excel comme décrit par Pacific, 02/202, merci à lui.
Pour la fréquence 868,983 Mhz, j’ai
/FQ0 : 0x3
/FQ1 : 0x6C
/FQ2 : 0x21
*dans le fichier radian_trx.h lignes 85 à 91
J’ai ajusté les GPIO et Wiring comme suivant :
WPP Name Header Name WPP*/
#define GDO2 8 //header 3
#define GDO1_MISO 13
#define GDO0 30 //header 27
#define MOSI 12
#define cc1101_CSn 10 ////header 24
#define LED 9 //header 5
Le schéma de câblage appliqué est le suivant :
GD02 : PIN:3 : WPP:8
GDO1_MISO : PIN:21 WPP:13
GDO0 : PIN:27 WPP:30
MOSI : PIN:19 WPP:12
cc1101_CSn : PIN:24 WPP:10
LED : PIN:5 WPP:9
Image CC1101 avec indication des ports : https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.amazon.fr%2FCC1101-Wireless-Distance-Transmission-Antenna%2Fdp%2FB07RH67FWV&psig=AOvVaw3wW3Dl_PqQRJ0RbIfEU0Gt&ust=1714042416700000&source=images&cd=vfe&opi=89978449&ved=0CBAQjRxqFwoTCLD7pN3X2oUDFQAAAAAdAAAAABAD
Une fois les différents fichiers modifiés, j’ai pu compiler avec la commande :
gcc radian_trx.c -o radian_trx -lwiringPi -lpthread -Wall
et lancer le programme avec ./radian_trx puis S
Et j’obtiens :
<Essai avec Freq0=0
MARCSTATE : raw:0x13 0x13 free_byte:0x0F sts:0x02 sending 2s WUP...
50 00 00 00 03 FF FF FF FF 64 70 47 00 75 17 24
76 07 50 F4 9F 00 75 17 02 72 87 05 71 47 00 72
87 01 72 E7 5B 7F FF
190free_byte:0x0C sts:0x07
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! TMO on REC
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! TMO on REC
Essai avec Freq0=1
MARCSTATE : raw:0x13 0x13 free_byte:0x0F sts:0x02 sending 2s WUP...
50 00 00 00 03 FF FF FF FF 64 70 47 00 75 17 24
76 07 50 F4 9F 00 75 17 02 72 87 05 71 47 00 72
87 01 72 E7 5B 7F FF
190free_byte:0x0C sts:0x07
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! TMO on REC
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! TMO on REC>
Pour vérifier si j’arrivais à émettre j’ai utilisé la clé SDR sur windows.
* Installation avec les procédures suivantes :
https://www.passion-radio.org/blog/sdr-sharp-dongle-rtl2832-r820t-e4000/76466
https://zadig.akeo.ie/
https://airspy.com/download/
https://www.nooelec.com/store/qs/#windows
J’utilise le logiciel CubicSDR.
Je vérifie bien que j’émets à 868.9 Mhz (il y a un petit décalage entre la fréquence 0 renseigné dans CC1101.c et la lecture sur CubicSDR.
Mais pas de réponse du compteur sur toutes les fréquences utilisées.
Auriez-vous une idée ?
Merci d’avance à vous en espérant avoir bien résumé les différentes étapes réalisées et si ça peut aider quelqu'un à avancer.
En attendant vos retours, bonne journée.
JOBE
Je lis avec attention les informations de votre site depuis plusieurs jours. Très intéressant. J'aimerais exploiter moi aussi les infos transmises par mon compteur mais celui-ci est un DIEHL METERING équipé d'un module radio "IZAR RC 868 i G4".
À l'aide d'un petit module SDR "NOOELEC NESDR Nano2" et du logiciel RTL_433 sur ArchLinux, je parviens à identifier et filtrer des trames provenant d'un ou plusieurs modules IZAR (je suppose que tous les compteurs du lotissement sont équipés du même module IZAR).
Dans les docs DIEHL, il est mentionné "Le module IZAR RC 868 i G4 envoie les informations en mode R3 selon la spécification OMS. Il s’agit d’un protocole de communication basé sur les normes EN13757- 3/-4). Si je comprends bien, le protocole utilisé semble différent du protocle RADIAN utilisé par votre matériel. Mon problème est donc de savoir si ce protocole OMS a déjà été étudié ... Auriez-vous des informations à ce sujet ?
Merci de votre aide,
Yan.
Mon opérateur ne propose pas de télérelève et j'ai eu une fuite (130 m3).
Je ne m'y connais pas en plomberie mais ai déjà plusieurs Raspberry pi pour les relevés électrique via TIC de linky, hombrebride ...
Je regarde pour rajouter après le compteur de mon opérateur
- Un compteur ITRON Compteur eau divisionnaire MID R100 Itron - NARVAL+ en DN 15
- Un module de télérelève ITRON - EverBlu Cyble Enhanced
+ Un raspberry Pi 3 ou 4
+ CC1101
L'ensemble me permettra t'il de récupérer les infos émise par la télérelève
Merci pour votre aide.
Je me suis lancé
Un compteur ITRON Compteur eau divisionnaire MID R100 Itron - NARVAL+
- Un module de télérelève ITRON - EverBlu Cyble Enhanced v2.1
+ Un raspberry Pi 4
+ CC1101
Super tuto merci
Après qqs essai j'obtiens
xxx
H1 MARCSTATE 1 : raw:0x13 0x13 free_byte:0x0F sts:0x02 sending 2s WUP...
50 00 00 00 03 FF FF FF FF 64 70 47 00 75 17 44
75 87 4B F5 4F 00 75 17 02 72 87 05 71 47 00 72
87 01 70 07 4F FF FF
2 184 free_byte:0x0F sts:0x07
MARCSTATE : raw:0x0D 0x0D(RX RX)
Time Out on REC1
MARCSTATE : raw:0x0D 0x0D(RX RX)
TimeOut on REC2
xxx
En scannat les fréquences j'obtiens de temps un temps une répone partielle
xxx
Essai avec Freq0=37
MARCSTATE : raw:0x13 0x13 free_byte:0x0F sts:0x02 sending 2s WUP...
50 00 00 00 03 FF FF FF FF 64 70 47 00 75 17 44
75 87 4B F5 4F 00 75 17 02 72 87 05 71 47 00 72
87 01 70 07 4F FF FF
194free_byte:0x0D sts:0x07
MARCSTATE : raw:0x0D 0x0D(RX RX)
TMO on REC
MARCSTATE : raw:0x0D 0x0D(RX RX)
GDO0! A2 1st synch received rssi=174 lqi=128 F_est=255
MARCSTATE : raw:0x0D 0x0D(RX RX)
TMO on REC
xxx
Que faut il régler ?
Merci
J'ai acheté un SDR pour calibrer la fréquence
Everblu 1 : 17 xxxxx => J'ai les mesures
Everblu 2 : 23 yyyyy => Aucune mesure
Pas de litres ... => 28/10/2024 17:18:51 0=litres Num=14 163Mois 0h-0h serial:
Une idée ?
https://github.com/psykokwak-com/everblu-meters-esp8266
https://github.com/neutrinus/everblu-meters
Merci fred
Dans tous les forks la lecture des litres est identique
"
struct tmeter_data parse_meter_report(uint8_t *decoded_buffer, uint8_t size)
.....
data.liters = decoded_buffer[18] + decoded_buffer[19] * 256 + decoded_buffer[20] * 65536 + decoded_buffer[21] * 16777216;
....
"
Mais dans decode_buffer pour un everblu de 2023 les valeurs restent à 0 !
Dans decode_buffer rien ne change quand les litres varient :-)
A noter que
data.reads_counter = decoded_buffer[48]; => Est renseigne
data.battery_left = decoded_buffer[31]; => Est renseigné
data.time_start = decoded_buffer[44]; => Reste à 0. Je peux interroger effectivement le compteur qd je veux
data.time_end = decoded_buffer[45]; => Reste à 0. Je peux interroger effectivement le compteur qd je veux
Une idée ?
Merci
Bonjour,
j'allais jeter l'éponge. J'ai positionné l'Everblu sur le compteur (il était à moins d'1m avant) et j'ai les litres qui sont apparus !!!!
I have a CC1101 receiver with an Arduino ESP8266 reading an Itron water meter through an Everblue Cyble sensor.
Everything works OK. I read it daily at 11:45 p.m.
The problem is that the Everblue Cyble sensor has a time drift and, over the months, the clock has advanced about 18 minutes.
Is there any way to update the Everblue Cyble clock with Arduino ?
I use libraries and program from https://github.com/psykokwak-com/everblu-meters-esp8266
Thank you all. This is a great forum.
salut Xavier je ne reviens que très épisodiquement sur mon site et d’ailleurs je pense le passer en statique sur free les prix d’hébergement commençant a être non négligeable.
tu peux tenter de régler mieux la fréquence avec clef TNT qui fait SDR (voir dans la doc tout en haut) ca peux jouer sur la portée
je pense que mon implementation actuel sur le CC1101 respecte les normes d’émission radio européen et peut être un peu en dessous.
voici que dit Gemini a propos des registre pour régler cette puissance
PA_TABLE: Ce registre contient une table de valeurs qui définissent les niveaux de puissance pour différentes conditions d'alimentation. En modifiant les valeurs de cette table, vous pouvez ajuster la puissance de sortie.
MCSM: Ce registre contrôle le mode de gestion de l'alimentation. Certains modes peuvent limiter la puissance maximale disponible.
FREQ: Ce registre définit la fréquence de fonctionnement. La puissance maximale peut varier en fonction de la fréquence choisie.