Quand un compteur domestique se met à parler sur 868 MHz
Dans un précédent article, j’expliquais comment hacker le monde réel avec les ondes radio et les capteurs permettait de rendre visibles des signaux qui, la plupart du temps, nous entourent sans que nous y prêtions attention. Il était alors question d’ondes radio, de capteurs, d’objets qui parlent en silence, et de cette idée assez simple qui consiste à observer le réel avec d’autres outils que ceux que l’on nous fournit d’ordinaire.
Cette fois, je vous propose de continuer exactement dans cette direction, mais avec un cas beaucoup plus domestique : mon compteur d’eau.
Il y a plusieurs années, je m’étais acheté une clé RTL-SDR afin de capter des émissions radio. Et puis, comme souvent avec ce genre d’objet, elle a fini dans un tiroir après quelques expérimentations et un article.
L’année dernière, un agent du gestionnaire de l’eau de mon quartier est venu m’installer un nouveau compteur équipé d’un système de télérelève. Au cours de l’échange, il m’explique que la relève se fait désormais par radio, sans même sortir du véhicule chargé de la collecte.
L’information est restée quelque part dans un coin de ma tête.
Quelques mois plus tard, je retombe sur la clé SDR. Du coup, LA question est revenue : est-il possible de collecter moi-même les données émises par le compteur, ne serait-ce que pour détecter plus rapidement une fuite dans le logement, ou pire, en amont, entre le compteur et la maison ?
Et pour la faire courte : oui, c’est possible. Et on va voir comment.
L’objectif de cet article est donc assez simple : identifier le compteur, trouver la bonne fréquence, vérifier le protocole utilisé, déterminer le bon driver dans wmbusmeters, comprendre si le chiffrement est réellement bloquant, récupérer les données dans un format exploitable pour la domotique, puis devenir riche.
Identifier le compteur avant d’écouter dans le vide
La première étape, et probablement celle qui vous fera gagner le plus de temps pour la suite, consiste à identifier précisément le compteur et surtout son module radio.
Chez moi, il s’agit d’un compteur Diehl. Il est équipé d’un module de communication portant un sticker DME-7B-07 Ti only ainsi qu’un numéro qui semble être l’identifiant du module radio.
A ce moment, ces informations ne me parlent pas du tout mais elles sont loin mais très loin d’être anodines.
En cherchant le module sur le site de Diehl, je tombe sur le module IZAR RC i G4 qui ressemble très fortement à mon module.
Chez Diehl, comme vous le savez tous sans avoir à lancer 10 recherches google, l’IZAR RC i G4 est le module radio OMS destiné à la gamme inductive Ti / Ha+Ti.
Côté wmbusmeters, deux familles m’ont l’air de correspondre :
dme_07qui correspond justement au Diehl IZAR RC i G4izarqui correspond plutôt aux anciens IZAR RC 868 I R4 PL / R3 sur protocole non standard
Autrement dit, à ce stade, j’ai deux plans :
- plan A :
dme_07, parce que le stickerDME-7B-07pointe déjà très fort dans cette direction ; - plan B :
izar, au cas où l’étiquette serait trompeuse ou parce que d’autres modules Diehl de la famille IZAR fonctionnent avecizar.
Pour la partie radio, la documentation du constructeur donne aussi une information précieuse : en version 868 MHz, le module émet sur 868,95 MHz en mode R3 et sur 868,30 MHz en mode R4. Il fonctionne en liaison unidirectionnelle, avec une émission toutes les 12 secondes en R3 et toutes les 15 minutes en R4.
Du coup, je suis censé avoir un résultat assez rapidement. Et si ce n’est pas le cas, c’est peut-être que j’écoute au mauvais endroit, ou pas assez près.
Pour l’exploration, la stratégie est donc la suivante :
- écouter d’abord 868,95 MHz
- tester ensuite 868,30 MHz
- et garder un peu de patience pour le mode R4, beaucoup moins bavard
Installer les bons outils
Pour la suite, nous allons utiliser deux outils qui vont faire tout le travail :
rtl_433, un logiciel libre qui permet de recevoir et décoder un grand nombre de signaux radio avec une clé SDR ;wmbusmeters, qui sait interpréter les trames M-Bus / Wireless M-Bus émises par de nombreux compteurs et les convertir en données exploitables.
À l’origine, rtl_433 est surtout connu pour les équipements grand public sur 433,92 MHz : stations météo, capteurs de température, prises télécommandées, détecteurs, etc.
Mais il sait aussi très bien travailler ailleurs, à condition de lui indiquer la bonne fréquence et le bon décodeur.
wmbusmeters, de son côté, fait exactement ce qu’on attend de lui : il récupère les relevés de compteurs M-Bus ou Wireless M-Bus, puis peut les afficher, les journaliser, les injecter dans une base, les envoyer vers une API REST ou les publier en MQTT.
Pour le coup, M-Bus, je connaissais, parce que j’avais déjà tenter d’écouter un précédent compteur, il y a quelques années. Fun-fact : Il était filaire.
Sur macOS, j’ai installé tout ce petit monde avec brew :
brew update
brew install librtlsdr rtl_433 git
brew install wmbusmetersVérifier que la clé fonctionne
Avant de parler compteur, il faut déjà vérifier que la clé SDR est bien reconnue.
rtl_test -tChez moi, cela donne ceci :
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.Parfait.
Ce que vous voulez voir, c’est essentiellement :
- une ligne
Found 1 device(s) - le tuner détecté
- pas d’erreur d’ouverture USB
Si vous avez un message du type device busy, c’est généralement qu’une autre application SDR a déjà pris la main sur la clé.
Commencer par écouter, avant de vouloir tout décoder
Dans un premier temps, on ne va pas encore chercher à décoder quoi que ce soit. On va d’abord chercher à répondre à une simple question : est-ce que le compteur émet bien, et est-ce que je suis capable de suiffer de la trame ?
rtl_433 expose plusieurs décodeurs Wireless M-Bus utiles ici :
-R 104: Wireless M-Bus Mode C&T, 100 kbps, 868.95 MHz, 1200k-R 105: Wireless M-Bus S, 32.768 kbps, 868.3 MHz, 1000k-R 238: Wireless M-Bus Mode TT, 32.768 kbps, 868.3 MHz, 1000k
On peut aussi tenter :
-R 106: Wireless M-Bus Mode R, 4.8 kbps, 868.33 MHz-R 107: Wireless M-Bus Mode F, 2.4 kbps
Dans mon cas, ces deux derniers s’éloignent un peu de ce qui est documenté pour le module Diehl. Je les garde donc au cas où.
Les commandes à lancer sont donc les suivantes :
rtl_433 -R 104 -f 868.95M -s 1200k -M time:iso -M levelrtl_433 -R 105 -R 238 -f 868.30M -s 1000k -M time:iso -M levelEt si cela ne donne rien :
rtl_433 -R 106 -f 868.33M -M time:iso -M levelrtl_433 -R 107 -f 868.30M -M time:iso -M levelTrouver le compteur dans le bruit
J’ai plutôt eu de la chance car dès cette commande :
rtl_433 -R 104 -f 868.95M -s 1200k -M time:iso -M levelj’obtiens ceci :
rtl_433 version 25.12 (2025-12-12) inputs file rtl_tcp RTL-SDR with TLS
New defaults active, use "-Y classic -s 250k" if you need the old defaults
Found Rafael Micro R820T tuner
[SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
[R82XX] PLL not locked!
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : 2026-04-05T21:47:30
model : Wireless-MBus Mode : T Manufacturer: DME ID : 12345678
Version : 123 Device Type: 0x07 Device Type String: Water Control : 0x44 Data Length: 63 Data : 3e44a5222413460407b077a882b3005711f87fbda13254cdfd19588c5f3ed7e18fbaee36c0ac7c5c86a8013623e45d0166679f
Integrity : CRC
Control Info: 0x7A Access number: 0x88 Device Type: 0x2B Configuration Word: 0x0530 Payload Encrypted: 1
Modulation: FSK Freq1 : 868.9 MHz Freq2 : 869.0 MHz
RSSI : -2.5 dB SNR : 12.8 dB Noise : -15.3 dB
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _Et surtout, j’obtiens cette trame plusieurs fois, à environ 12 secondes d’intervalle, toujours avec le même identifiant.
À partir de là, on peut déjà tirer quelques conclusions très simples :
- Constat n°1 : un compteur émet bien.
- Constat n°2 : l’ID correspond au numéro présent sur l’étiquette de mon compteur.
- Constat n°3 : je ne capte pas d’autres émissions parasites de compteurs voisins.
Donc :
- mon compteur émet bien ;
- je suis suffisamment proche pour le recevoir proprement ;
- et suffisamment éloigné des autres pour ne pas polluer la capture.
Si, chez vous, vous ne captez rien, la première hypothèse n’est pas forcément « cela ne marche pas », mais simplement « je ne suis pas assez près du compteur ».
Fréquence, driver, chiffrement : c’est le moment d’affiner
À ce stade, plusieurs choses se recoupent.
D’abord, on reçoit bien plusieurs trames valides du même compteur sur 868,95 MHz. En pratique, pour mon installation, c’est donc la bonne fréquence d’écoute.
Ensuite, le log remonte :
Manufacturer: DMEID: 12345678Device Type: 0x07Version: 123
Le Version: 123 correspond à 0x7b, ce qui est intéressant, car cela colle parfaitement avec le sticker du module : DME-7B-07.
Autrement dit, l’étiquette, la trame radio et l’identification du compteur racontent toutes la même histoire :
DME0x7B0x07
À ce stade, tout pointe donc très fortement vers dme_07, et beaucoup, mais beaucoup moins vers izar.
Jusqu’ici, les résultats de l’enquête s’emboîtent les uns avec les autres sans se contredire. Je ne vais pas bouder mon plaisir. Sauf que…
Le chiffrement, lui, risque de compliquer l’histoire
Le point qui se corse, c’est évidemment celui-ci :
Payload Encrypted: 1Dit autrement : les trames sont annoncées comme chiffrées.
Sur le papier, ce n’est pas très encourageant. Sans clé, on ne pourra valider que la fréquence, l’ID, le protocole, mais pas à lire l’index, ce qui est l’objectif in fine.
Et pourtant.
Vérifier si le chiffrement est réellement bloquant
Pour aller plus loin, j’ai repris une trame capturée et je l’ai soumise à wmbusmeters --analyze.
HEX="3e44a512345678977a882b3005711f87fb4da4ebe806aa4dd70ba83a70dc803f71e74def15676815fd18fbaee36cd0166679f"
wmbusmeters --analyze "$HEX"Résultat :
(TPL) warning: aes-cbc-iv decryption received less bytes than expected for decryption! Got 16 bytes but expected at least 48 bytes since num encr blocks was 3.
Auto driver : dme_07
Similar driver : hydrodigit 12/53
Using driver : dme_07 00/00
000 : 3e length (62 bytes)
001 : 44 dll-c (from meter SND_NR)
002 : a511 dll-mfct (DME)
004 : 51346040 dll-id (12345678)
008 : 7b dll-version
009 : 07 dll-type (Water meter)
010 : 7a tpl-ci-field (EN 13757-3 Application Layer (short tplh))
011 : 88 tpl-acc-field
012 : 2b tpl-sts-field (ALARM PERMANENT_ERROR)
013 : 3005 tpl-cfg 0530 (AES_CBC_IV nb=3 cntn=0 ra=0 hc=0 )
015 : 2f2f decrypt check bytes (OK)
017 : 04 dif (32 Bit Integer/Binary Instantaneous value)
018 : 13 vif (Volume l)
019 C!: 96340000 ("total_m3":13.462)
023 C?: 0F manufacturer specific data A5220100010100000000000031123456781B030000000000000000000012300002B0E81230000
{
"_":"telegram",
"media":"water",
"meter":"dme_07",
"name":"",
"id":"12345678",
"total_m3":13.462,
"timestamp":"2026-04-05T20:32:41Z"
}Le résultat est contre-intuitif, mais très intéressant.
D’un côté, cela confirme sans ambiguïté le driver à utiliser : dme_07.
De l’autre, cela montre que l’index total_m3 remonte malgré tout.
Je reste prudent sur l’interprétation exacte. Je ne vais pas ici prétendre expliquer pourquoi cela passe : clé connue, clé de chiffrement vide, partie exploitable non réellement bloquante, particularité du format, autre subtilité du protocole… À ce stade, je constate simplement le résultat :
- la trame est marquée comme chiffrée ;
wmbusmetersreconnaîtdme_07;- et l’index sort bien.
Je dois avouer que je suis plutôt chanceux. Et cela montre aussi quand on vous annonces que la porte est fermée, il faut toujours vérifier si la clé n’est pas dans la serrure, et même si la serrure a été installée.
Bilan intermédiaire
À ce stade, je peux résumer la situation comme ceci :
- Ça émet : oui
- Fréquence : 868,95 MHz
- ID compteur : 12345678
- Driver probable :
dme_07 - Chiffré : oui, en apparence
- Bloquant pour l’index : pas dans mon cas
Autrement dit, on peut passer à l’étape suivante : industrialiser la récupération des données.
Transformer les trames en données utiles
L’idée est désormais d’utiliser rtl_433 pour recevoir les trames, puis wmbusmeters pour les interpréter proprement.
Produire un flux brut
Voici la commande de base utilisée pour sortir les trames en CSV :
rtl_433 -R 104 -f 868.95M -s 1200k -F csvChez moi, cela donne par exemple :
time,msg,codes,model,mode,id,version,type,type_string,CI,AC,ST,CW,sn,knx_ctrl,src,dst,l_npci,tpci,apci,crc,M,C,data_length,data,mic,temperature_C,average_temperature_1h_C,average_temperature_24h_C,humidity,average_humidity_1h,average_humidity_24h,minimum_temperature_1h_C,maximum_temperature_1h_C,minimum_temperature_24h_C,maximum_temperature_24h_C,minimum_humidity_1h,maximum_humidity_1h,minimum_humidity_24h,maximum_humidity_24h,switch,counter_0,counter_1
2026-04-05 22:56:16,,,Wireless-MBus,T,12345678,123,7,Water,122,141,43,1296,,,,,,,,,DME,68,31,1e41160407b077a8d2b100532eca5e17f3347dd001702e35fd975d2,CRC,,,,,,,,,,,,,,,,,
2026-04-05 22:56:29,,,Wireless-MBus,T,12345678,123,7,Water,122,141,43,1296,,,,,,,,,DME,68,31,1e41160407b077a8d2b10050ac79abe56bc1a4622d11d18095a870b,CRC,,,,,,,,,,,,,,,,,
^CSignal caught, exiting!On voit bien passer les trames brutes du compteur.
Décoder les données brutes avec wmbusmeters
La commande que j’ai utilisée est la suivante :
wmbusmeters --ignoreduplicates=false --format=json \
'rtl433:CMD(rtl_433 -R 104 -f 868.95M -s 1200k -F csv)' \
MonEau dme_07 12345678 NOKEYJ’ai ajouté --ignoreduplicates=false pour des raisons de test, afin de voir passer toutes les émissions et non seulement les changements utiles.
Le résultat ressemble à ceci :
{"_":"telegram","media":"water","meter":"dme_07","name":"MonEau","id":"12345678","total_m3":13.498,"status":"ERROR_FLAGS_10","timestamp":"2026-04-05T22:12:47Z","device":"rtl433[cmd_0]","rssi_dbm":999}
{"_":"telegram","media":"water","meter":"dme_07","name":"MonEau","id":"12345678","total_m3":13.498,"status":"ERROR_FLAGS_10","timestamp":"2026-04-05T22:13:00Z","device":"rtl433[cmd_0]","rssi_dbm":999}Et là, nous avons exactement ce qu’il nous fallait depuis le début :
- un identifiant de compteur ;
- un
total_m3exploitable ; - un timestamp ;
- le tout dans un format JSON très simple à réinjecter ailleurs.
En clair, le compteur n’est plus seulement un objet muet relevé de loin par un tiers. Il devient une source de données que l’on peut observer soi-même.
Envoyer la consommation vers Jeedom
À partir de là, la suite est assez naturelle.
L’idée est d’envoyer ce flux vers un logiciel de domotique comme Jeedom ou Home Assistant, par exemple via MQTT.
Le principe est simple : à chaque trame décodée, on publie la valeur utile dans un topic dédié.
Par exemple :
mosquitto_pub -r -h $IP_MQTT_IP -u $USER -P $PASSWD_MQTT \
-t maison/eau/total_m3 \
-m $VALEUR_EN_M3On peut évidemment aller plus loin :
- publier aussi le
status - historiser les index
- calculer les écarts entre deux relevés
- déclencher une alerte en cas de consommation nocturne anormale
- détecter une fuite lente
- distinguer une anomalie dans le logement d’un problème situé entre le compteur et la maison
Autrement dit, une fois la chaîne de réception en place, l’intérêt ne se limite plus au simple fait de capter de la radio. Il devient très concret.
Conclusion
Ce que j’aime dans ce genre d’expérience, c’est qu’elle prolonge exactement l’intuition du précédent article : autour de nous, une partie du monde parle déjà. Il faut simplement trouver le bon outil pour l’écouter.
Dans mon cas, le bilan est finalement très positif :
- le compteur émet bien ;
- la fréquence utile est 868,95 MHz ;
- le compteur est identifié comme 12345678 ;
- le bon driver est
dme_07; - les trames sont signalées comme chiffrées ;
- mais l’index de consommation est tout de même récupérable dans ce contexte.
Le plus intéressant, au fond, n’est peut-être pas que le compteur parle.
C’est qu’il parle suffisamment pour devenir un objet que l’on peut observer soi-même.
Et la suite logique est déjà toute trouvée : installer cette clé sur un Raspberry Pi Zero W survitaminé, la laisser écouter en quasi-continu, puis alimenter automatiquement Jeedom avec la consommation d’eau.
Cette petite expérimentation radio quitte finalement le terrain du simple hack amusant pour devenir un vrai dispositif de suivi domestique, discret, autonome, et surtout utile au quotidien. Et pourquoi pas l’étendre à d’autres usages.
Il ne me reste du coup plus qu’à acheter une nouvelle clé RTL-SDR, en v4 cette fois-ci. Et en 10 ans, le prix de cette clé a doublé. Ouch !
Laisser un commentaire