OREGON THGN132N wird nicht angelegt

Begonnen von t1me2die, 05 Januar 2017, 17:34:22

Vorheriges Thema - Nächstes Thema

t1me2die

Hallo liebe Community,

ich habe mittlerweile ein OREGON THGR228N erfolgreich in FHEM eingebunden. Dieses Gerät wurde direkt erkannt und angelegt via autocreate.

Nun habe ich mir noch ein OREGON THGN132N besorgt, dies soll laut https://wiki.fhem.de/wiki/RFXtrx auch funktionieren.
Leider wird dies nicht automatisch angelegt und im Eventmonitor sehe ich leider auch nichts.

Muss ich noch irgendwas einstellen oder muss ich dies evtl. manuell anlegen?

Gruß
Mathias

KölnSolar

schon mal einen Blick in die fhem-Doku, also commandref geworfen ? ::)
Natürlich nicht  :'( Dort findest Du das device nicht  :'(
Aber: bei THGR228N steht, dass das THGN132 als THGR228N angelegt wird. Vielleicht hast Du Glück, dass es auch mit dem xxxN geht. Hast Du einen anderen Kanal als beim THGR228N oder gar longids gewählt ? Bei dem selben Kanal KÖNNTE es sein, dass beide Sensoren an das bereits definierte device senden. Wenn das nicht hilft beschreibst Du bitte mal welche Kanäle Du eingestellt hast und stellst ein list des THGR228N ein, bevor ich weiter meine Glaskugel quäle.  ::)
Steht nichts im Log ?
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

t1me2die

Ja, in der commandref steht, dass das Gerät THN132N per autocreate angelegt wird.
Ich habe aber ein THGN132N, ich mag nicht ausschließen, dass ich mich hier einfach nur verlesen habe. Ich war der Meinung, hier würde es sich um ein und dasselbe Gerät handeln.
Ich habe versucht das THGN132N einmal auf dem selben Channel laufen zu lassen wie der THGR228 und einmal auf einem anderen Channel, ohne Erfolg.

THGR228 läuft auf Channel 1.
Hier ein list von dem Gerät, welches problemlos funktioniert.
Zitat
Internals:
   CODE       THGR228N_3a_1
   DEF        THGR228N_3a_1
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     4
   NAME       temp_Balkon
   NR         232
   STATE      T: -5.2 H: 50 BAT: ok
   TYPE       OREGON
   nanoCUL_DMSG 501A2D103A20050805320F
   nanoCUL_MSGCNT 4
   nanoCUL_RAWMSG mAAAB32D4CB3554D532B55534CD555354CD5534B4AB541B
   nanoCUL_TIME 2017-01-05 21:46:08
   Readings:
     2017-01-05 21:46:08   battery         ok
     2017-01-05 21:46:08   humidity        50
     2017-01-05 21:46:08   state           T: -5.2 H: 50 BAT: ok
     2017-01-05 21:46:08   temperature     -5.2
Attributes:
   IODev      nanoCUL
   room       Wetter

THGN132 läuft z.Z. auf Channel 2. Im Eventmonitor sehe ich das Gerät gar nicht. Nun habe ich verbose auf 5 gestellt vom CUL und sehe nun mehrere Logs, die mich nicht weiterbringen.

Zitat
2017.01.05 21:53:40 4: CUL_Parse: nanoCUL omAAAAAAAAAAAAAAAAA032
2017.01.05 21:53:40 5: nanoCUL: dispatch omAAAAAAAAAAAAAAAAA032
2017.01.05 21:53:40 5: CUL_REDIRECT (mAAAAAAAAAAAAAAAAA032) length: 21 RSSI: -49
2017.01.05 21:53:40 5: CUL_REDIRECT (mAAAAAAAAAAAAAAAAA032) match Manchester COODE length: 21
2017.01.05 21:53:40 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAAAAAAAAAAA032)
2017.01.05 21:53:40 5: bitdata: 10101010101010101010101010101010101010101010101010101010101010101010000000110010
2017.01.05 21:53:40 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAAAAAAAAAAA032)
2017.01.05 21:53:40 5: bitdata: 10101010101010101010101010101010101010101010101010101010101010101010000000110010
2017.01.05 21:53:40 5: CUL_REDIRECT decode Hideki (AAAAAAAAAAAAAAAAA032)
2017.01.05 21:53:40 5: nanoCUL: search in 10101010101010101010101010101010101010101010101010101010101010101010000000110010

2017.01.05 21:53:40 5: protocol does not match, ignore received package (AAAAAAAAAAAAAAAAA032) Reason: Not a hideki protocol

2017.01.05 21:54:21 5: CUL/RAW: /omAAAAAAAAAAAAAAAAAAA834

2017.01.05 21:54:21 4: CUL_Parse: nanoCUL omAAAAAAAAAAAAAAAAAAA834
2017.01.05 21:54:21 5: nanoCUL: dispatch omAAAAAAAAAAAAAAAAAAA834
2017.01.05 21:54:21 5: CUL_REDIRECT (mAAAAAAAAAAAAAAAAAAA834) length: 23 RSSI: -48
2017.01.05 21:54:21 5: CUL_REDIRECT (mAAAAAAAAAAAAAAAAAAA834) match Manchester COODE length: 23
2017.01.05 21:54:21 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAAAAAAAAAAAAA834)
2017.01.05 21:54:21 5: bitdata: 1010101010101010101010101010101010101010101010101010101010101010101010101010100000110100
2017.01.05 21:54:21 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAAAAAAAAAAAAA834)
2017.01.05 21:54:21 5: bitdata: 1010101010101010101010101010101010101010101010101010101010101010101010101010100000110100
2017.01.05 21:54:21 5: CUL_REDIRECT decode Hideki (AAAAAAAAAAAAAAAAAAA834)
2017.01.05 21:54:21 5: nanoCUL: search in 1010101010101010101010101010101010101010101010101010101010101010101010101010100000110100

2017.01.05 21:54:21 5: protocol does not match, ignore received package (AAAAAAAAAAAAAAAAAAA834) Reason: Not a hideki protocol

2017.01.05 21:55:02 4: CUL_Parse: nanoCUL omAAAAAAAAAAAAA831
2017.01.05 21:55:02 5: nanoCUL: dispatch omAAAAAAAAAAAAA831
2017.01.05 21:55:02 5: CUL_REDIRECT (mAAAAAAAAAAAAA831) length: 17 RSSI: -49.5
2017.01.05 21:55:02 5: CUL_REDIRECT (mAAAAAAAAAAAAA831) match Manchester COODE length: 17
2017.01.05 21:55:02 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAAAAAAA831)
2017.01.05 21:55:02 5: bitdata: 1010101010101010101010101010101010101010101010101010100000110001
2017.01.05 21:55:02 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAAAAAAA831)
2017.01.05 21:55:02 5: bitdata: 1010101010101010101010101010101010101010101010101010100000110001
2017.01.05 21:55:02 5: CUL_REDIRECT decode Hideki (AAAAAAAAAAAAA831)
2017.01.05 21:55:02 5: nanoCUL: search in 1010101010101010101010101010101010101010101010101010100000110001

2017.01.05 21:55:02 5: protocol does not match, ignore received package (AAAAAAAAAAAAA831) Reason: Not a hideki protocol

2017.01.05 21:55:13 5: CUL/RAW: /omAAAB32D4CB3554D532B554B4CD5553
2017.01.05 21:55:13 5: CUL/RAW: omAAAB32D4CB3554D532B554B4CD5553/54CD54B4B4D2D41C

2017.01.05 21:55:13 4: CUL_Parse: nanoCUL omAAAB32D4CB3554D532B554B4CD555354CD54B4B4D2D41C
2017.01.05 21:55:13 5: nanoCUL: dispatch omAAAB32D4CB3554D532B554B4CD555354CD54B4B4D2D41C
2017.01.05 21:55:13 5: CUL_REDIRECT (mAAAB32D4CB3554D532B554B4CD555354CD54B4B4D2D41C) length: 47 RSSI: -60
2017.01.05 21:55:13 5: CUL_REDIRECT (mAAAB32D4CB3554D532B554B4CD555354CD54B4B4D2D41C) match Manchester COODE length: 47
2017.01.05 21:55:13 5: CUL_REDIRECT decode Oregon 2 (AAAB32D4CB3554D532B554B4CD555354CD54B4B4D2D41C)
2017.01.05 21:55:13 5: bitdata: 1010101010101011001100101101010011001011001101010101010011010101001100101011010101010100101101001100110101010101010100110101010011001101010101001011010010110100110100101101010000011100
2017.01.05 21:55:13 5: OSV2 protocol detected (AAAB32D4CB3554D532B554B4CD555354CD54B4B4D2D41C)
2017.01.05 21:55:13 5: CUL_REDIRECT: OSV2 protocol converted to hex: (501A2D103A300508053319) with length (88) bits

2017.01.05 21:55:13 5: nanoCUL Dispatch now to Oregon Module.
2017.01.05 21:55:13 5: converted Data to (501A2D103A300508053319)
2017.01.05 21:55:13 5: nanoCUL: dispatch 501A2D103A300508053319
2017.01.05 21:55:13 5: OREGON: decoding delay=233.991256952286 hex=501A2D103A300508053319
2017.01.05 21:55:13 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2017.01.05 21:55:13 5: OREGON: checksum2 = 51 berechnet: 51
2017.01.05 21:55:13 4: temp_Balkon decoded Oregon: T: -5.3 H: 50 BAT: ok
2017.01.05 21:55:14 5: CUL_REDIRECT decode Oregon 3 (AAAB32D4CB3554D532B554B4CD555354CD54B4B4D2D41C)
2017.01.05 21:55:14 5: bitdata: 1010101010101011001100101101010011001011001101010101010011010101001100101011010101010100101101001100110101010101010100110101010011001101010101001011010010110100110100101101010000011100
2017.01.05 21:55:14 5: CUL_REDIRECT decode Hideki (AAAB32D4CB3554D532B554B4CD555354CD54B4B4D2D41C)
2017.01.05 21:55:14 5: nanoCUL: search in 1010101010101011001100101101010011001011001101010101010011010101001100101011010101010100101101001100110101010101010100110101010011001101010101001011010010110100110100101101010000011100

2017.01.05 21:55:14 5: protocol does not match, ignore received package (AAAB32D4CB3554D532B554B4CD555354CD54B4B4D2D41C) Reason: Not a hideki protocol
2017.01.05 21:55:14 5: CUL/RAW: /om996A659AAA6A995AAA5A66AAA9AA66
2017.01.05 21:55:14 5: CUL/RAW: om996A659AAA6A995AAA5A66AAA9AA66/AA5A5A696A8016

2017.01.05 21:55:14 4: CUL_Parse: nanoCUL om996A659AAA6A995AAA5A66AAA9AA66AA5A5A696A8016
2017.01.05 21:55:14 5: nanoCUL: dispatch om996A659AAA6A995AAA5A66AAA9AA66AA5A5A696A8016
2017.01.05 21:55:14 5: CUL_REDIRECT (m996A659AAA6A995AAA5A66AAA9AA66AA5A5A696A8016) length: 45 RSSI: -63
2017.01.05 21:55:14 5: CUL_REDIRECT (m996A659AAA6A995AAA5A66AAA9AA66AA5A5A696A8016) match Manchester COODE length: 45
2017.01.05 21:55:14 5: CUL_REDIRECT decode Oregon 2 (996A659AAA6A995AAA5A66AAA9AA66AA5A5A696A8016)
2017.01.05 21:55:14 5: bitdata: 10011001011010100110010110011010101010100110101010011001010110101010101001011010011001101010101010101001101010100110011010101010010110100101101001101001011010101000000000010110
2017.01.05 21:55:14 5: OSV2 protocol detected (996A659AAA6A995AAA5A66AAA9AA66AA5A5A696A8016)
2017.01.05 21:55:14 5: CUL_REDIRECT: ERROR: To short: OSV2 protocol converted to hex: (581A2D103A30050805331960) with length (96) bits

2017.01.05 21:55:14 5: CUL_REDIRECT decode Oregon 3 (996A659AAA6A995AAA5A66AAA9AA66AA5A5A696A8016)
2017.01.05 21:55:14 5: bitdata: 10011001011010100110010110011010101010100110101010011001010110101010101001011010011001101010101010101001101010100110011010101010010110100101101001101001011010101000000000010110
2017.01.05 21:55:14 5: CUL_REDIRECT decode Hideki (996A659AAA6A995AAA5A66AAA9AA66AA5A5A696A8016)
2017.01.05 21:55:14 5: nanoCUL: search in 10011001011010100110010110011010101010100110101010011001010110101010101001011010011001101010101010101001101010100110011010101010010110100101101001101001011010101000000000010110

2017.01.05 21:55:14 5: protocol does not match, ignore received package (996A659AAA6A995AAA5A66AAA9AA66AA5A5A696A8016) Reason: Not a hideki protocol

Gruß
Mathias

Ps.: Ich war mir nicht sicher, in welches Unterforum diese Frage am besten passt, daher ausersehen der Doppelpost.

Sidey

Also zum einen unterstützt das Oregon Modul den THGN132N Sensor nicht.

Ich weiss auch nicht, ob die a-culFW die Daten 1:1 übergibt, sieht mir irgendwie so aus, als ob das die Preamble vom Oregon Protokoll fehlt.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

KölnSolar

Bei 82 Beiträgen solltest Du aber doch die 4 oberen Themen im Anfängerfragen-Subforum gelesen haben  ::)
Da steht dann auch, dass man nicht nur nicht doppelt posten soll, sondern auch dass "Auszüge" in code tags zu packen sind(das # Zeichen neben dem Zitat-Zeichen). Hol das bitte noch nach.
Der Logauszug zeigt mir nur, dass Du einen nanoCUL hast, der Oregon-messages empfangen hat. Und jetzt dämmerts mir: Du hast gar keinen RFXTRX ?  :o IODEV=nanoCUL bestätigt meine These :(
Dann wärst Du ja hier völlig falsch. Wär dann aber ein exzellentes Beispiel, wie man nicht posten sollte  :(
ZitatIch war der Meinung, hier würde es sich um ein und dasselbe Gerät handeln.
Das kann ich nachvollziehen. Die Bezeichnungen der Oregon-Sensoren sind unterirdisch. Würd mir die mal gerne erklären lassen  ;)
Außer, dass der THGR228N um 21:55:13 gesendet hat, erkenne ich leider auch nicht mehr.  :(
Und was kann ich Dir nun noch mit auf den Weg geben ... :-[
Im Internet fand ich, dass der THGN132N das Protokoll 2.1 nutzt. Nicht kompatibel zu dem THGR228N, welcher ...find nix  :-[
Dann anders: Ralf hat sich mit dem OREGON-Modul auseinandergesetzt und mit Sidey(aktueller maintainer des Moduls) weiterentwickelt. Alles im Rahmen des SIGNALduino-Projekts. Mittlerweile müssten die Anpassungen auch im offiziellen fhem-development-branch vorhanden sein. Hast Du fhem auf dem aktuellen Stand ?
Wenn nicht, erst einmal updaten und noch einmal probieren.
Ansonsten könntest Du Dich VORSICHTIG vielleicht an diesen Beitrag https://forum.fhem.de/index.php/topic,60170.105.html hängen. Mit vorsichtig meine ich, den Hinweis, dass Du keinen Signalduino, sondern einen nanoCUL hast, der Dir mit verbose5  das Log für einen THGN132N erzeugt hat.
Puh, das war jetzt echt hart  ;)
Ja, da hatte Sidey Dich selbst hier gefunden und war schneller als mein langer Beitrag, den ich aber jetzt trotzdem poste.

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt