Globaltronics GT-WT-02 buitensensor herkend als 4 verschillende devices afhankelijk van de Temp/Hum waarde

[aXion]

Hoi,

Ik zit al tijden met het volgende: De buitensensor (Globaltronics GT-WT-02 Temp/Hum) van een Aldi/Lidl weerstation (Globaltronics GT-WS-09s) wordt door de RF link herkend, maar afhankelijk van de waarde van de temperatuur en de luchtvochtigheid, steeds als een verschillende device (in domoticz).

Indien de hum > 90% wordt de sensor gezien als een Lacrosse TX3 temp sensor. Het weerstation geeft bij hum >90% ook HH aan dus waarschijnlijk geeft de buitensensor de hum niet door boven de 90%
Indien de hum < 90% is wordt de sensor gezien als een WTGR800 (Temp/Hum). Als ik de debug aanzet in de rf link loader staat er overigens nu Globaltronics. Waarschijnlijk is de plugin ooit aangepast en heeft domoticz de oude namen onthouden. Ik draai op de r45 firmware momenteel en zal de devices nog eens verwijderen en opnieuw aanmaken

Indien de Temp < 0 is, dan verandert ook het ID van de sensor (geen batterijen vervangen oid)

Hieronder twee screenshots uit Domoticz. Ik was van plan zelf in de code te duiken maar kon op het internet alleen maar hele oude versies vinden. Het lijkt me een klein bugje in het decoderen van het protocol. Kan iemand mij van de laatste plugin code voorzien of op een andere manier helpen?

Mocht er nog debug data nodig zijn, dan kan ik de sensor naar binnen halen en wat met de humidity spelen.

[aXion]

Hierbij nog wat debug gegevens:

Hum > 90% (HH op display sensor en basisstation
20;FF;DEBUG;Pulses=76;Pulses(uSec)=600,1860,480,1860,450,3900,420,3930,420,3930,420,3930,420,3960,420,3960,390,1920,390,1950,390,1950,360,1980,360,1980,360,1980,330,1980,330,2010,330,2010,330,2040,300,2040,300,2040,300,4050,300,4050,300,2010,300,2040,300,4050,300,4050,330,2010,330,4020,330,4020,330,4020,360,1980,330,3990,330,4080,360,1980,360,3990,360,4020,360,3990,360,6990;
20;00;GlobalTronics;ID=003f;TEMP=000c;BAT=OK;

Hum < 90%
20;CC;DEBUG;Pulses=76;Pulses(uSec)=570,1860,480,1890,450,3900,450,3930,450,3930,450,3930,420,3930,420,3960,420,1920,420,1920,420,1950,420,1950,420,1950,390,1950,420,1950,390,1950,390,3990,390,1950,390,3990,390,1950,390,1950,390,1950,390,3990,390,3960,390,3990,390,1950,390,1980,390,3990,390,3990,390,1950,390,1950,390,3990,390,4050,390,1950,390,1980,390,1980,390,1950,390,6990;
20;CD;GlobalTronics;ID=003f;TEMP=00a3;HUM=76;BAT=OK;

[aXion]

Hierbij nog gegevens wanneer de temperatuur < 0 is, Hierbij verandert dus ook de ID

20;10;DEBUG;Pulses=76;Pulses(uSec)=600,1830,420,1920,420,3900,420,3930,390,3930,420,3930,420,3960,390,3990,390,1950,390,1980,360,1980,360,1980,330,4020,360,4080,330,4020,360,3990,360,3960,360,3990,360,3990,360,3990,360,4020,360,1980,360,1980,330,4020,330,4020,360,1980,360,1980,330,2010,330,2040,330,2010,330,2010,330,2010,330,2010,330,1980,330,2010,330,2010,330,4020,330,6990;
20;11;GlobalTronics;ID=033f;TEMP=8007;HUM=64;BAT=OK;

20;98;DEBUG;Pulses=76;Pulses(uSec)=480,1890,420,1920,420,3960,420,3960,390,3960,420,3930,390,3930,450,3930,420,1950,360,1980,360,1980,360,1950,330,4020,360,4050,330,4020,360,3960,360,4020,330,4020,360,3990,360,3960,360,4020,360,1950,360,3990,360,3990,360,1980,330,4020,360,3990,360,3960,360,4050,360,3960,360,3990,390,1950,390,3960,360,1950,360,1980,360,1980,360,1980,360,6990;
20;99;GlobalTronics;ID=033f;TEMP=8005;HUM=63;BAT=OK;

Hier een link naar een protocol definitie van de GT-WT-02.. Volgens deze beschrijving wordt er blijkbaar een hum van 110% gestuurd indien de hum > 90% (HH op display) en van 10% indien deze kleiner is dan 20% (LL op display)
https://github.com/merbanan/rtl_433/blo ... gt_wt_02.c

[aXion]

De link die ik plaatste naar een beschrijving van het protocol lijkt me correct te zijn.
Ik heb een aantal paketten handmatig nagelopen en wanneer de rflink geen hum doorgeeft, wordt er daadwerkelijk een hum van 110% doorgestuurd (wat HH zou moeten voorstellen). Het bereik van de sensor ligt nl tussen 20-90%

Alleen snap ik nog niet hoe je aan de foutieve rolling code (ID) van 0x33F komt wanneer de temp < 0 is. De eerste 8-bits zijn altijd 0x3F

voorbeeld van pakket met hum > 90% (zelfde pakket als hierboven gepost)

Hum > 90% (HH op display sensor en basisstation
20;FF;DEBUG;Pulses=76;Pulses(uSec)=

// rolling code = 0x3F
600,1860,0
480,1860,0
450,3900,1
420,3930,1
420,3930,1
420,3930,1
420,3960,1
420,3960,1

// Battery 0=OK
390,1920,0

// Manual send button pressed, 0=not pressed
390,1950,0

// Channel 00=CH!
390,1950,0
360,1980,0

// 12-bit temp = 12 (0x0C) / 10 = 1,2 Celsius
360,1980,0
360,1980,0
330,1980,0
330,2010,0

330,2010,0
330,2040,0
300,2040,0
300,2040,0
300,4050,1
300,4050,1
300,2010,0
300,2040,0

// 7-bit humidity = 110% -> HH
300,4050,1
300,4050,1
330,2010,0
330,4020,1
330,4020,1
330,4020,1
360,1980,0

// checksum
330,3990,
330,4080,
360,1980,
360,3990,
360,4020,
360,3990,
360,6990;
20;00;GlobalTronics;ID=003f;TEMP=000c;BAT=OK;

[Stuntteam]

2 dingen die mis lijken te gaan..:
1. De ID gaat inderdaad mis.. niet doordat het protocol er niet goed in zou zitten, want dat valt wel mee..
maar door de selectie van device type en hoe dat af te handelen.
Ik moet even naar je data kijken in combinatie met de code om te zien wat er mis gaat.

2)
20;00;GlobalTronics;ID=003f;TEMP=000c;BAT=OK;
20;CD;GlobalTronics;ID=003f;TEMP=00a3;HUM=76;BAT=OK;

Is er geen geldige humidity dan word dit door RFLink ook niet doorgegeven.
De basisunit doet die filtering voor je en geeft dan HH.
Zou RFLink een humidity van 110% of een andere ongeldige waarde doorgeven dan is er voor Domoticz/Jeedom/HA enz. geen manier om te weten te komen of dit wel of niet een geldige waarde is.
Dus op zich klopt het wat RFLink doet.
Helaas maakt Domoticz er in dat geval verschillende devices van. 1 waarbij je een temp+humidity hebt en 1 met alleen een temperatuur.