MD-210R Atlantic et mise à jour du 26/11/2020

Bonjour,

J’ai fait la mise à jour aujourd’hui, et pas de soucis particuliers sur une 15aine de modules, sauf un capteur d’ouverture de porte MD-210R.

Le capteur est mal configuré, même après suppression et réinclusion : Le status est devenu une valeur numérique (alors qu’on attend un booléen pour une porte) et la batterie retourne une valeur entre 0 et 9 (à la place d’un pourcentage).

Quelques données brute :

[2020-11-28 16:58:24][DEBUG] : Message: 082008b8ded3db0279
[2020-11-28 16:58:24][DEBUG] : Decode : 082008b8ded3db0279
[2020-11-28 16:58:24][DEBUG] : Test message: 082008b8ded3db0279
[2020-11-28 16:58:24][DEBUG] : PacketType: 0x20
[2020-11-28 16:58:24][DEBUG] : Length: 9
[2020-11-28 16:58:24][DEBUG] : Start decoding packet type 0x20
[2020-11-28 16:58:24][DEBUG] : Subtype = Meiantech,Atlantic
[2020-11-28 16:58:24][DEBUG] : Data : {'packetlen': '0x08', 'packettype': '0x20', 'subtype': '0x08', 'seqnbr': '0xB8', 'id1': '0xDE', 'id2': '0xD3', 'id3': '0xDB', 'status': 2, 'battery': 9, 'rssi': 7}
[2020-11-28 16:58:24][DEBUG] : Decoded info : {'packettype': '0x20', 'subtype': '0x08', 'id': 'DED3DB', 'status': 2, 'battery': 9, 'rssi': 7}
[2020-11-28 16:58:24][DEBUG] : Device is known id : DED3DB
[2020-11-28 16:58:24][DEBUG] : Send to jeedom : {'devices': {'DED3DB20': {'packettype': '0x20', 'subtype': '0x08', 'id': 'DED3DB', 'status': 2, 'battery': 9, 'rssi': 7}}}
[2020-11-28 16:58:24][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2020-11-28 16:58:24][DEBUG] : {"devices":{"DED3DB20":{"packettype":"0x20","subtype":"0x08","id":"DED3DB","status":2,"battery":9,"rssi":7}}}

status=2 pour porte ouverte

[2020-11-28 16:59:01][DEBUG] : Message: 082008c4ded3db0079
[2020-11-28 16:59:01][DEBUG] : Decode : 082008c4ded3db0079
[2020-11-28 16:59:01][DEBUG] : Test message: 082008c4ded3db0079
[2020-11-28 16:59:01][DEBUG] : PacketType: 0x20
[2020-11-28 16:59:01][DEBUG] : Length: 9
[2020-11-28 16:59:01][DEBUG] : Start decoding packet type 0x20
[2020-11-28 16:59:01][DEBUG] : Subtype = Meiantech,Atlantic
[2020-11-28 16:59:01][DEBUG] : Data : {'packetlen': '0x08', 'packettype': '0x20', 'subtype': '0x08', 'seqnbr': '0xC4', 'id1': '0xDE', 'id2': '0xD3', 'id3': '0xDB', 'status': 0, 'battery': 9, 'rssi': 7}
[2020-11-28 16:59:01][DEBUG] : Decoded info : {'packettype': '0x20', 'subtype': '0x08', 'id': 'DED3DB', 'status': 0, 'battery': 9, 'rssi': 7}
[2020-11-28 16:59:01][DEBUG] : Device is known id : DED3DB
[2020-11-28 16:59:01][DEBUG] : Send to jeedom : {'devices': {'DED3DB20': {'packettype': '0x20', 'subtype': '0x08', 'id': 'DED3DB', 'status': 0, 'battery': 9, 'rssi': 7}}}
[2020-11-28 16:59:01][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2020-11-28 16:59:01][DEBUG] : {"devices":{"DED3DB20":{"packettype":"0x20","subtype":"0x08","id":"DED3DB","status":0,"battery":9,"rssi":7}}}

status=0 porte fermée

Notez la valeur de la batterie à 9 alors qu’elle est neuve :slight_smile:

Egalement, le status passe à 128 lors d’une détection de sabotage + porte fermée et 130 avec sabotage + porte ouverte.

Ma question est la suivante : Comment décomposer la valeur status pour en extraire 2 infos : l’état de la porte et l’état du sabotage ? Faut il passer par un virtuel ?

Idem pour la batterie qui évolue de 0 à 9, comment convertir la valeur en % ? Faut il passer par un virtuel ?

Merci la team !

Cela correspond à 100%
vérifie dans analyse, équipements …

Merci pour ton retour Doubledom,

Alors non, justement, 9 est la valeur brute remontée par le plugin rfxcom. Mais ce n’est pas un pourcentage. Jeedom l’interprète comme un pourcentage :
Sans titre

Je précise que j’ai réinclus le module et changé la batterie aujourd’hui.

Concernant l’état de la porte, si je met le status comme info binaire, en un sens, ça règle le problème, j’ai bien l’info porte ouverte ou porte fermée. Mais je perd donc l’info sabotage.

Ma question est autour de la transformation des données brutes du plugin :
1/ Le status est clairement exploitable avec des bitmask pour en extraire à minima un booléen pour l’état de la porte et un autre booléen pour l’état du sabotage.
2/ La valeur de la batterie brute n’est pas un pourcentage pour ce module, comment la transformer sans passer par un virtuel ?

Apres, cette question c’est pour aller plus loin, mais ce n’est pas indispensable :slight_smile:

Il faut passer par un « event »
Mais a mon avis c’est problème de décodage trame ,

Erratum: j’ai annoncé avoir supprimé le module puis reinclusion. Ce n’est pas ce que j’ai fait. J’ai reinclus le module puis copié le nouvel id sur l’ancien.

Je vais refaire un test propre dans la soirée. C’est sans doute la source de mon problème.

Pour la batterie le calcul se fait depuis cette valeur « 9 » partie droite du dernier octet , comme préconisé

Normalement (valeur +1) *10 pour toi devrait faire 100%

J’ai donc refait une inclusion au propre (suppression + inclusion).

Toujours le même soucis pour la batterie :

[2020-11-28 20:50:46][DEBUG] : Message: 082008e3ded3db8279
[2020-11-28 20:50:46][DEBUG] : Decode : 082008e3ded3db8279
[2020-11-28 20:50:46][DEBUG] : Test message: 082008e3ded3db8279
[2020-11-28 20:50:46][DEBUG] : PacketType: 0x20
[2020-11-28 20:50:46][DEBUG] : Length: 9
[2020-11-28 20:50:46][DEBUG] : Start decoding packet type 0x20
[2020-11-28 20:50:46][DEBUG] : Subtype = Meiantech,Atlantic
[2020-11-28 20:50:46][DEBUG] : Data : {'packetlen': '0x08', 'packettype': '0x20', 'subtype': '0x08', 'seqnbr': '0xE3', 'id1': '0xDE', 'id2': '0xD3', 'id3': '0xDB', 'status': 130, 'battery': 9, 'rssi': 7}
[2020-11-28 20:50:46][DEBUG] : Decoded info : {'packettype': '0x20', 'subtype': '0x08', 'id': 'DED3DB', 'status': 130, 'battery': 9, 'rssi': 7}
[2020-11-28 20:50:46][DEBUG] : Device is known id : DED3DB
[2020-11-28 20:50:47][DEBUG] : Send to jeedom : {'devices': {'DED3DB20': {'packettype': '0x20', 'subtype': '0x08', 'id': 'DED3DB', 'status': 130, 'battery': 9, 'rssi': 7}}}
[2020-11-28 20:50:47][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2020-11-28 20:50:47][DEBUG] : {"devices":{"DED3DB20":{"packettype":"0x20","subtype":"0x08","id":"DED3DB","status":130,"battery":9,"rssi":7}}}

Je comprend bien qu’il doit y avoir un calcul fait quelques part. Mais pas là :thinking:

A titre de comparaison, si je regarde les logs pour un THGN122 :

[2020-11-28 20:50:18][DEBUG] : Message: 0a5201da7e0400cf2f0179
[2020-11-28 20:50:18][DEBUG] : Decode : 0a5201da7e0400cf2f0179
[2020-11-28 20:50:18][DEBUG] : Test message: 0a5201da7e0400cf2f0179
[2020-11-28 20:50:18][DEBUG] : PacketType: 0x52
[2020-11-28 20:50:18][DEBUG] : Length: 11
[2020-11-28 20:50:18][DEBUG] : Start decoding packet type 0x52
[2020-11-28 20:50:18][DEBUG] : Subtype = TH1 is THGN122/123, THGN132, THGR122/228/238/268
[2020-11-28 20:50:18][DEBUG] : Data : {'packetlen': '0x0A', 'packettype': '0x52', 'subtype': '0x01', 'seqnbr': '0xDA', 'id1': '0x7E', 'id2': '0x04', 'temperaturesign': '', 'temperature': 207, 'humidity': 47, 'humidity_status': 1, 'battery': 100, 'rssi': 7}
[2020-11-28 20:50:18][DEBUG] : Decoded info : {'packettype': '0x52', 'subtype': '0x01', 'id': '7E04', 'temperature': '20.7', 'humidity': 47, 'humidity_status': 1, 'battery': 100, 'rssi': 7}
[2020-11-28 20:50:18][DEBUG] : Device is known id : 7E04
[2020-11-28 20:50:18][DEBUG] : Send to jeedom : {'devices': {'7E0452': {'packettype': '0x52', 'subtype': '0x01', 'id': '7E04', 'temperature': '20.7', 'humidity': 47, 'humidity_status': 1, 'battery': 100, 'rssi': 7}}}

Là, j’ai bien 100%

Je pense avoir trouvé le problème. Le calcul que mentionne Doubledom n’est pas implémenté.

Dans /plugins/rfxcom/resources/rfxcomd/RfxPacket/0x20.py, appliquer ce patch :

53c53
<       'battery' : int("{0:08b}".format(message[8])[4:],2),
---
>       'battery' : (int("{0:08b}".format(message[8])[4:],2)+1)*10,

Un restart du démon et la valeur pour la batterie est ok.

J’ai eu le cas aussi sur un détecteur de présence atlantic, ta solution fonctionne ?

Il faudrait peut être voir avec @Loic

Bonjour @loic,

Je ne sais pas comment ça ce passe ici pour proposer un patch, je me lance sur ce thread :slight_smile:

Il s’agit d’un correctif pour la remontée des batteries pour les modules rfxcom de la famille 0x20 (Security1 (X10, KD101, Visonic, Meiantech, SA30, SA33, RM174RF). Ici, le problème est rencontré en particulier sur les modules « Meiantech,Atlantic ». Mais le correctif touche toute la famille 0x20, donc il y a peut être des régressions pour d’autres modules de cette famille.

Est il possible de proposer ce patch sur une beta du plugin ?

Dans /plugins/rfxcom/resources/rfxcomd/RfxPacket/0x20.py, appliquer ce patch :

53c53
<       'battery' : int("{0:08b}".format(message[8])[4:],2),
---
>       'battery' : (int("{0:08b}".format(message[8])[4:],2)+1)*10,

Merci.

Et au passage, bravo pour la refonte du plugin !

Merci pour le retour j’ai fait une correction plus global ça sera dans la bêta de demain