Alternative culfw

bjoernh · 27 Dezember 2016, 19:40:05

Zitat von: Bennemannc am 27 Dezember 2016, 19:29:16
Hallo,

noch mal zum SignalDuino und CUL443Ich dachte die Decodierung wird im OREGON Modul gemacht - und das nutzen beide. Liegt es daran, das der CUL433 erst prüft, was für ein Protokoll das sein könnte? Was passiert, wenn man Protokolle abschaltet?

Gruß Christoph

Genau so ist es. Der CUL schaut nach dem Protokoll und probiert es zu empfangen. Die Bitfolge wird dann an das fhem Modul geliefert, welches die Daten schlussendlich dekoriert.
Wenn man ein Protokoll abschaltet, wird es halt nicht mehr empfangen.

Gesendet von meinem Mobile Device.

RaspiLED · 27 Dezember 2016, 20:14:21

Also bei mir ist dieses Reset Problem behoben, seit dem ich zwei PINs des FTDI Chip verlötet habe!
Hintergrund: die günstigen China Arduinos nutzen das original Referenzdesign. Dieses wurde später geändert, so dass die Test Leitung gegen Masse verbunden ist. Das sorgt dafür, dass bei einem RasPi Reboot des FTDI richtig initialisiert wird und nicht im Test Modus.
Lies mal hier:
https://ketturi.kapsi.fi/2014/04/how-to-fix-moody-arduino-nano/
Gruß Arnd

Gesendet von iPhone mit Tapatalk

Bennemannc · 27 Dezember 2016, 21:28:01

Hallo,

ZitatGenau so ist es. Der CUL schaut nach dem Protokoll und probiert es zu empfangen. Die Bitfolge wird dann an das fhem Modul geliefert, welches die Daten schlussendlich dekoriert.
Wenn man ein Protokoll abschaltet, wird es halt nicht m

Die Überlegung mit dem Abschalten war eher, das mehr von dem was man decodieren möchte durchkommt.
Die Unterschiede sind schon extrem. Der Sduino bekommt 5 Devices, CUL433 max. 3 und die noch mit aussetzern.
Kann da noch etwas an der Erkennung verbessert werden - weil ich den CUL eigentlich schöner finde.
Das habe ich noch gefunden
https://forum.fhem.de/index.php/topic,58396.60.html

Gruß Christoph

Master_Nick · 27 Dezember 2016, 21:58:14

Guten Abend,

ich habe mir netterweise von der Wetterstation meiner Mutter einen Sensor ausleihen können.
Einen THGN122N (Temperatur und Luftfeuchtigkeit).

FHEM legt ihn im Raum OREGON schon per Autocreate an, doch es kamen bisher nur einmal Werte durch. *Korrigiere er ließt regelmäßig aus!*

Gibt es neben dem THGN122N noch klar funktionierende von Oregon?

Aber was ist dieser Fehler? "2016.12.27 21:49:01 5: protocol does not match, ignore received package (AAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C) Reason: Not a hideki protocol"
Das Log sagt:

Code Auswählen


2016.12.27 21:49:01 4: CUL_Parse: nanoCUL omAAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C
2016.12.27 21:49:01 5: nanoCUL: dispatch omAAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C
2016.12.27 21:49:01 5: CUL_REDIRECT (mAAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C) length: 51 RSSI: -60
2016.12.27 21:49:01 5: CUL_REDIRECT (mAAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C) match Manchester COODE length: 51
2016.12.27 21:49:01 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C)
2016.12.27 21:49:01 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010100110101010010110010101101010011010100110011010100110101010101010101001101001101010011010101010011001100101011010100101000011100
2016.12.27 21:49:01 5: OSV2 protocol detected (AAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C)
2016.12.27 21:49:01 5: CUL_REDIRECT: OSV2 protocol converted to hex: (501A2D20EC8822804450C7) with length (88) bits 

2016.12.27 21:49:01 5: nanoCUL Dispatch now to Oregon Module.
2016.12.27 21:49:01 5: converted Data to (501A2D20EC8822804450C7)
2016.12.27 21:49:01 5: nanoCUL: dispatch 501A2D20EC8822804450C7
2016.12.27 21:49:01 5: OREGON: decoding delay=1 hex=501A2D20EC8822804450C7
2016.12.27 21:49:01 5: Triggering THGR228N_ec_2 (4 changes)
2016.12.27 21:49:01 5: Starting notify loop for THGR228N_ec_2, 4 event(s), first is temperature: 22.8
2016.12.27 21:49:01 5: GoogleCloudMessages THGR228N_ec_2: ignoring temperature, save value is 22.8, value is 22.8
2016.12.27 21:49:01 5: GoogleCloudMessages THGR228N_ec_2: ignoring humidity, save value is 48, value is 48
2016.12.27 21:49:01 5: GoogleCloudMessages THGR228N_ec_2: ignoring battery, save value is ok, value is ok
2016.12.27 21:49:01 5: GoogleCloudMessages THGR228N_ec_2: ignoring T, save value is 22.8 H: 48 BAT: ok, value is 22.8 H: 48 BAT: ok
2016.12.27 21:49:01 1: ERROR: >T: 22.8 H: 48 BAT: ok< returned by the OREGON ParseFn is invalid, notify the module maintainer
2016.12.27 21:49:01 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C)
2016.12.27 21:49:01 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010100110101010010110010101101010011010100110011010100110101010101010101001101001101010011010101010011001100101011010100101000011100
2016.12.27 21:49:01 5: CUL_REDIRECT decode Hideki (AAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C)
2016.12.27 21:49:01 5: nanoCUL: search in 10101010101010101010101010101011001100101101010011001011001101010101010100110101010010110010101101010011010100110011010100110101010101010101001101001101010011010101010011001100101011010100101000011100 

2016.12.27 21:49:01 5: protocol does not match, ignore received package (AAAAAAAB32D4CB3555354B2B5353353555534D4D54CCAD4A1C) Reason: Not a hideki protocol

Oder wäre das eher ein neues Thema

?

Ralf9 · 27 Dezember 2016, 22:58:03

Zitat von: Master_Nick am 27 Dezember 2016, 21:58:14
Code Auswählen Erweitern
2016.12.27 21:49:01 1: ERROR: >T: 22.8 H: 48 BAT: ok< returned by the OREGON ParseFn is invalid, notify the module maintainer
Oder wäre das eher ein neues Thema ?

Nein, dies ist eher ein altes Thema:
https://forum.fhem.de/index.php/topic,35064.msg540678.html#msg540678

Gruß Ralf

Master_Nick · 27 Dezember 2016, 23:05:20

Danke dir Ralf

Also muss ich die Datei nur austauschen? Oder ist die nicht längst in das Repo gewandert und schon lange bei mir drin?

Nicht falsch verstehen bitte - falls ich was frage was man erkennen hätte können sind Hinweise darauf für mich hilfreich.

*EDIT* Ach das war erst vor 16 Tagen....

Danke dir!

Master_Nick · 28 Dezember 2016, 12:06:45

Also irgendwo ist noch der Wurm drin.

Der Sensor sendet die ganze Zeit weiter und steht im Raum des nanoCUL - um 2016-12-28_07:37:05 ist der letzte Eintrag im Log vorher ging es ab 2016-12-28_02:28:17 (nachts bastelt es sich so gut

) lückenlos.

Sensorlog:

Code Auswählen


2016-12-28_07:37:05 THGR228N_cb_2 temperature: 21.6
2016-12-28_07:37:05 THGR228N_cb_2 humidity: 49
2016-12-28_07:37:05 THGR228N_cb_2 battery: ok
2016-12-28_07:37:05 THGR228N_cb_2 T: 21.6 H: 49 BAT: ok

Code Auswählen


2016.12.28 07:37:05 5: CUL/RAW: /omA
2016.12.28 07:37:05 5: CUL/RAW: omA/AAAAAAB32D4CB35553
2016.12.28 07:37:05 5: CUL/RAW: omAAAAAAAB32D4CB35553/4B34B552CD5
2016.12.28 07:37:05 5: CUL/RAW: omAAAAAAAB32D4CB355534B34B552CD5/3554D34D4CB54D2D
2016.12.28 07:37:05 5: CUL/RAW: omAAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D/4A26

2016.12.28 07:37:05 4: CUL_Parse: nanoCUL omAAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D4A26
2016.12.28 07:37:05 5: nanoCUL: dispatch omAAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D4A26
2016.12.28 07:37:05 5: CUL_REDIRECT (mAAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D4A26) length: 51 RSSI: -55
2016.12.28 07:37:05 5: CUL_REDIRECT (mAAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D4A26) match Manchester COODE length: 51
2016.12.28 07:37:05 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D4A26)
2016.12.28 07:37:05 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010100110100101100110100101101010101001011001101010100110101010101001101001101001101010011001011010101001101001011010100101000100110
2016.12.28 07:37:05 5: OSV2 protocol detected (AAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D4A26)
2016.12.28 07:37:05 5: CUL_REDIRECT: OSV2 protocol converted to hex: (501A2D20CB6021904443C6) with length (88) bits 

2016.12.28 07:37:05 5: nanoCUL Dispatch now to Oregon Module.
2016.12.28 07:37:05 5: converted Data to (501A2D20CB6021904443C6)
2016.12.28 07:37:05 5: nanoCUL: dispatch 501A2D20CB6021904443C6
2016.12.28 07:37:05 5: OREGON: decoding delay=41 hex=501A2D20CB6021904443C6
2016.12.28 07:37:05 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2016.12.28 07:37:05 5: OREGON: checksum2 = 67 berechnet: 67
2016.12.28 07:37:05 4: THGR228N_cb_2 decoded Oregon: T: 21.6 H: 49 BAT: ok
2016.12.28 07:37:05 5: Triggering THGR228N_cb_2 (4 changes)
2016.12.28 07:37:05 5: Starting notify loop for THGR228N_cb_2, 4 event(s), first is temperature: 21.6
2016.12.28 07:37:05 5: GoogleCloudMessages THGR228N_cb_2: ignoring temperature, save value is 21.6, value is 21.6
2016.12.28 07:37:05 5: GoogleCloudMessages THGR228N_cb_2: ignoring humidity, save value is 49, value is 49
2016.12.28 07:37:05 5: GoogleCloudMessages THGR228N_cb_2: ignoring battery, save value is ok, value is ok
2016.12.28 07:37:05 5: GoogleCloudMessages THGR228N_cb_2: ignoring T, save value is 21.6 H: 49 BAT: ok, value is 21.6 H: 49 BAT: ok
2016.12.28 07:37:05 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D4A26)
2016.12.28 07:37:05 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010100110100101100110100101101010101001011001101010100110101010101001101001101001101010011001011010101001101001011010100101000100110
2016.12.28 07:37:05 5: CUL_REDIRECT decode Hideki (AAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D4A26)
2016.12.28 07:37:05 5: nanoCUL: search in 10101010101010101010101010101011001100101101010011001011001101010101010100110100101100110100101101010101001011001101010100110101010101001101001101001101010011001011010101001101001011010100101000100110 

2016.12.28 07:37:05 5: protocol does not match, ignore received package (AAAAAAAB32D4CB355534B34B552CD53554D34D4CB54D2D4A26) Reason: Not a hideki protocol

Keine für micht sichtbaren Fehlermeldungen im Log - keine Exceptions nix. Diskspace ist mit 2,3 GB auch noch genug da...
Jemand ideen?

Ein shutdown restart von FHEM hat nun sofort Abhilfe gebracht, aber das kann ja nicht die Lösung sein?:

Code Auswählen

2016-12-28_12:07:00 THGR228N_cb_2 temperature: 21.8
2016-12-28_12:07:00 THGR228N_cb_2 humidity: 51
2016-12-28_12:07:00 THGR228N_cb_2 battery: ok
2016-12-28_12:07:00 THGR228N_cb_2 T: 21.8 H: 51 BAT: ok

*EDIT um 13:18 Uhr hat es erneut aufgehört... $:-\$ und es helfen nun auch keine Restarts von FHEM oder vom Raspi oder abziehen des nanoCUL. Alles andere empfängt er fleißig weiter. Der Sensor hat eine LED und zeigt auch, dass er sendet. Habe ihn nun den Sender per Reset-Button zurückgesetzt und nun wird er unter neuer ID empfangen und ist auch direkt angelegt worden. Er steigt aber weiterhin immer wieder mal aus.... und empfängt dann einfach nix mehr (im keinem Log steht mehr etwas zum Oregon). Mir scheint, dass passiert großteils wenn man andere Dinge schaltet. Als würde der nanoCUL danach nicht mehr frei gegeben werden.

Eine Sache habe ich soeben gefunden:

Code Auswählen

2016.12.28 15:45:04 3: No I/O device found for THGR228N_cb_2 habe dazu das folgende Thema gefunden und den folgenden Beitrag gefunden https://forum.fhem.de/index.php/topic,21023.msg538538.html#msg538538 - habe daraufhin das define vom nanoCUL nach ganz oben sortiert - bisher noch ohne Erfolg.

Ich werde das hier nicht los: 2016.12.28 16:24:33 3: No I/O device found for THGR228N_cb_2 nach neustart von FHEM und er empfängt/verarbeitet den Sensor auch nicht mehr dann.
Das ist ungefähr so, als würde das Attribut IODev ignoriert werden - ob ich es lösche und es nicht da ist oder es da ist - die Meldung im Log bleibt identisch.

Ich habe nun nochmal versucht den Sensor per define zum laufen zu bekommen... keine Chance. Es scheint er kann nur einmal per Autocreate angelegt werden und arbeitet dann bis zu dem Moment wo FHEM meint der IODev fehlt. Und auch nach dem löschen der von autocreate angelegten oder der selbst definierten wird kein neuer erkannt. Als wäre die Funktion dann ausgeschaltet. Werden die angelegten Sachen noch wo gespeichert wenn man sie gelöscht hat? Es scheint als würde er sie aktiv nicht erkennen...

Ralf9 · 28 Dezember 2016, 19:07:57

Wenn ich bei mir mit Deiner dispatch Nachricht das Oregon Modul aufrufe, wird es sauber verarbeitet.

Code Auswählen

2016.12.28 18:54:43.985 4: sduinoD/msg get dispatch: 501A2D20CB6021904443C6
2016.12.28 18:54:43.986 5: sduinoD: dispatch 501A2D20CB6021904443C6
2016.12.28 18:54:43.998 5: OREGON: decoding delay=0 hex=501A2D20CB6021904443C6
2016.12.28 18:54:43.998 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2016.12.28 18:54:43.998 5: OREGON: checksum2 = 67 berechnet: 67
2016.12.28 18:54:43.998 3: OREGON: Unknown device THGR228N_cb_2, please define it
2016.12.28 18:54:44.001 2: autocreate: define THGR228N_cb_2 OREGON THGR228N_cb_2
2016.12.28 18:54:44.002 2: autocreate: define FileLog_THGR228N_cb_2 FileLog ./log/THGR228N_cb_2-%Y-%m.log THGR228N_cb_2
2016.12.28 18:54:44.002 2: autocreate: define SVG_THGR228N_cb_2 SVG FileLog_THGR228N_cb_2:temp4hum4:CURRENT
2016.12.28 18:54:44.773 4: sduinoD/msg get dispatch: 501A2D20CB6021904443C6
2016.12.28 18:54:44.773 5: sduinoD: dispatch 501A2D20CB6021904443C6
2016.12.28 18:54:44.773 5: OREGON: decoding delay=1 hex=501A2D20CB6021904443C6
2016.12.28 18:54:44.773 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2016.12.28 18:54:44.774 5: OREGON: checksum2 = 67 berechnet: 67
2016.12.28 18:54:44.774 4: THGR228N_cb_2 decoded Oregon: T: 21.6 H: 49 BAT: ok

Nach dem löschen des Sensors solltest Du vor dem define fhem neustarten. Welche Fehlermeldung bekommst Du, wenn Du nach dem fhem Neustart ein define eingibst?
Verwendest Du in der fhem.cfg include Dateien.

Gruß Ralf

Master_Nick · 28 Dezember 2016, 19:17:15

Nabend Ralf,

aktuell bekomme ich keinerlei Fehlermeldung, da ich alles rausgeworfen habe und nun per Autocreate wieder anlegen lassen wollte. Pustekuchen macht er nicht

Vorher war es die Meldung kein I/O Device für den Sensor gefunden im fhem.log.

Code Auswählen

2016.12.28 19:12:35 5: CUL/RAW: /omA
2016.12.28 19:12:35 5: CUL/RAW: omA/AB2D554D2AAAD4B535001
2016.12.28 19:12:35 5: CUL/RAW: omAAB2D554D2AAAD4B535001/

2016.12.28 19:12:35 4: CUL_Parse: nanoCUL omAAB2D554D2AAAD4B535001
2016.12.28 19:12:35 5: nanoCUL: dispatch omAAB2D554D2AAAD4B535001
2016.12.28 19:12:35 5: CUL_REDIRECT (mAAB2D554D2AAAD4B535001) length: 23 RSSI: -73.5
2016.12.28 19:12:35 5: CUL_REDIRECT (mAAB2D554D2AAAD4B535001) match Manchester COODE length: 23
2016.12.28 19:12:35 5: CUL_REDIRECT decode Oregon 2 (AAB2D554D2AAAD4B535001)
2016.12.28 19:12:35 5: bitdata: 1010101010110010110101010101010011010010101010101010110101001011010100110101000000000001
2016.12.28 19:12:35 5: CUL_REDIRECT decode Oregon 3 (AAB2D554D2AAAD4B535001)
2016.12.28 19:12:35 5: bitdata: 1010101010110010110101010101010011010010101010101010110101001011010100110101000000000001
2016.12.28 19:12:35 5: CUL_REDIRECT decode Hideki (AAB2D554D2AAAD4B535001)
2016.12.28 19:12:35 5: nanoCUL: search in 1010101010110010110101010101010011010010101010101010110101001011010100110101000000000001 

2016.12.28 19:12:35 5: protocol does not match, ignore received package (AAB2D554D2AAAD4B535001) Reason: Not a hideki protocol

Kein define nix. Daher weiß ich nun auch aktuell nicht mit welchem Code ich es benennen müsste für ein manuelles define.

*EDIT*
So... nun hat er es dann auf einmal gemacht, ohne Eingriff von mir.

Code Auswählen

2016.12.28 19:16:20 5: CUL/RAW: /o
2016.12.28 19:16:20 5: CUL/RAW: o/mAAAAAAAB32D4CB35
2016.12.28 19:16:20 5: CUL/RAW: omAAAAAAAB32D4CB35/5534CB555352B5355534CD
2016.12.28 19:16:20 5: CUL/RAW: omAAAAAAAB32D4CB355534CB555352B5355534CD/4CAAB4ACD2F3

2016.12.28 19:16:20 4: CUL_Parse: nanoCUL omAAAAAAAB32D4CB355534CB555352B5355534CD4CAAB4ACD2F3
2016.12.28 19:16:20 5: nanoCUL: dispatch omAAAAAAAB32D4CB355534CB555352B5355534CD4CAAB4ACD2F3
2016.12.28 19:16:20 5: CUL_REDIRECT (mAAAAAAAB32D4CB355534CB555352B5355534CD4CAAB4ACD2F3) length: 51 RSSI: -80.5
2016.12.28 19:16:20 5: CUL_REDIRECT (mAAAAAAAB32D4CB355534CB555352B5355534CD4CAAB4ACD2F3) match Manchester COODE length: 51
2016.12.28 19:16:20 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAB32D4CB355534CB555352B5355534CD4CAAB4ACD2F3)
2016.12.28 19:16:20 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010100110100110010110101010101010011010100101011010100110101010101010011010011001101010011001010101010110100101011001101001011110011
2016.12.28 19:16:20 5: OSV2 protocol detected (AAAAAAAB32D4CB355534CB555352B5355534CD4CAAB4ACD2F3)
2016.12.28 19:16:20 5: CUL_REDIRECT: OSV2 protocol converted to hex: (501A2D200D882320453F97) with length (88) bits 

2016.12.28 19:16:20 5: nanoCUL Dispatch now to Oregon Module.
2016.12.28 19:16:20 5: converted Data to (501A2D200D882320453F97)
2016.12.28 19:16:20 5: nanoCUL: dispatch 501A2D200D882320453F97
2016.12.28 19:16:20 5: Loading ./FHEM/41_OREGON.pm
2016.12.28 19:16:20 5: OREGON: decoding delay=0 hex=501A2D200D882320453F97
2016.12.28 19:16:20 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2016.12.28 19:16:20 5: OREGON: checksum2 = 63 berechnet: 63
2016.12.28 19:16:20 3: OREGON: Unknown device THGR228N_0d_2, please define it
2016.12.28 19:16:20 5: Triggering global (1 changes)
2016.12.28 19:16:20 5: Starting notify loop for global, 1 event(s), first is UNDEFINED THGR228N_0d_2 OREGON THGR228N_0d_2
2016.12.28 19:16:20 5: data is {"deviceName": "global","changes":"state:UNDEFINED THGR228N_0d_2 OREGON THGR228N_0d_2","type":"notify","source":"gcmsend_fhem","vibrate":"false"}
2016.12.28 19:16:21 2: autocreate: define THGR228N_0d_2 OREGON THGR228N_0d_2
2016.12.28 19:16:21 5: Triggering global (2 changes)
2016.12.28 19:16:21 2: autocreate: define FileLog_THGR228N_0d_2 FileLog ./log/THGR228N_0d_2-%Y.log THGR228N_0d_2
2016.12.28 19:16:21 5: Triggering global (3 changes)
2016.12.28 19:16:21 2: autocreate: define SVG_THGR228N_0d_2 SVG FileLog_THGR228N_0d_2:temp4hum4:CURRENT
2016.12.28 19:16:21 5: Loading ./FHEM/98_SVG.pm
2016.12.28 19:16:22 5: Triggering global (4 changes)
2016.12.28 19:16:22 5: Triggering SVG_THGR228N_0d_2 (1 changes)
2016.12.28 19:16:22 5: Starting notify loop for SVG_THGR228N_0d_2, 1 event(s), first is copyGplotFile
2016.12.28 19:16:22 5: data is {"deviceName": "SVG_THGR228N_0d_2","changes":"state:copyGplotFile","type":"notify","source":"gcmsend_fhem","vibrate":"false"}
2016.12.28 19:16:22 5: Triggering global (5 changes)
2016.12.28 19:16:22 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAB32D4CB355534CB555352B5355534CD4CAAB4ACD2F3)
2016.12.28 19:16:22 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010100110100110010110101010101010011010100101011010100110101010101010011010011001101010011001010101010110100101011001101001011110011
2016.12.28 19:16:22 5: CUL_REDIRECT decode Hideki (AAAAAAAB32D4CB355534CB555352B5355534CD4CAAB4ACD2F3)
2016.12.28 19:16:22 5: nanoCUL: search in 10101010101010101010101010101011001100101101010011001011001101010101010100110100110010110101010101010011010100101011010100110101010101010011010011001101010011001010101010110100101011001101001011110011 

2016.12.28 19:16:22 5: protocol does not match, ignore received package (AAAAAAAB32D4CB355534CB555352B5355534CD4CAAB4ACD2F3) Reason: Not a hideki protocol

Fehlermeldung:
2016.12.28 19:25:18 4: name: /fhem/FileLog_logWrapper&dev=FileLog_THGR228N_0d_2&type=temp4hum4&file=THGR228N_0d_2-2016.log / RL:1496 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.28 19:25:18 4: WEB_192.168.0.2_53681 GET /fhem/SVG_showLog&dev=FileLog_THGR228N_0d_2&logdev=FileLog_THGR228N_0d_2&gplotfile=temp4hum4&logfile=THGR228N_0d_2-2016.log&pos=; BUFLEN:0
2016.12.28 19:25:18 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/98_SVG.pm line 742.
2016.12.28 19:25:18 5: plotcommand: get FileLog_THGR228N_0d_2 THGR228N_0d_2-2016.log INT 2016-12-28_00:00:00 2016-12-29_00:00:01
2016.12.28 19:25:18 5: Cmd: >{ "THGR228N_0d_2-2016.log" }<
2016.12.28 19:25:18 4: name: /fhem/SVG_showLog&dev=FileLog_THGR228N_0d_2&logdev=FileLog_THGR228N_0d_2&gplotfile=temp4hum4&logfile=THGR228N_0d_2-2016.log&pos= / RL:1980 / image/svg+xml / Content-Encoding: gzip
/
2016.12.28 19:25:18 4: WEB_192.168.0.2_53681 GET /fhem/FileLog_logWrapper&dev=FileLog_THGR228N_0d_2&type=temp4hum4&file=THGR228N_0d_2-2016.log?XHR=1&inform=type=status;filter=;since=1482949517;fmt=JSON&fw_id=133×tamp=1482949517419; BUFLEN:0
2016.12.28 19:25:19 4: Connection closed for WEB_192.168.0.2_53681: EOF
2016.12.28 19:25:19 4: WEB_192.168.0.2_53679 GET /fhem?XHR=1&inform=type=status;filter=room=OREGON;since=1482949512;fmt=JSON&fw_id=129×tamp=1482949518619; BUFLEN:0
2016.12.28 19:25:19 1: Error: >< has no TYPE, but following keys: ><

Er wirft nun unglaublich viele Fehler dieser Art beim refresh der Log-Seite im Webinterface:

Code Auswählen

2016.12.28 19:26:45 1: Error: >< has no TYPE, but following keys: ><
2016.12.28 19:26:45 1: Error: >< has no TYPE, but following keys: ><

Aktuell läuft es nun nach einem neutstart von FHEM nach dem Autocreate-Vorgang. Die Fehler mit Type bleiben weiter bestehen.

Frage: Kann man den Graphen unter Raum OREGON Gruppe FileLog unter Temp/Hum irgendwie gangbar machen? Der will irgendwie nie - nur der den ich unter Plots anpasse funktioniert (der unter diesem Link: http://xxx.xxx.xxx.xxx.:xxx/fhem/FileLog_logWrapper&dev=FileLog_THGR228N_0d_2&type=temp4hum4&file=THGR228N_0d_2-2016.log)

Master_Nick · 29 Dezember 2016, 00:31:39

Also aktuell sieht es so aus als läge es an dem Sensor den ich mir geliehen habe.

Habe vorhin eine Lieferung 2er THGR122NX bekommen - die arbeiten bisher dauerhaft sauber durch.

Gibt es eine Möglichkeit mit event-min-interval state:900, event-on-change-reading STATE und event-on-update-reading .* zu arbeiten damit nicht alle par Sekunden ins Log geschrieben wird?
Oder geht das nur über Umweg mit dummy? Habe alle 3 als Attribute bei beiden Sensoren eingefügt, bisher beachtet FHEM die nicht.

Ralf9 · 29 Dezember 2016, 00:44:43

mit
event-min-interval:.*:300
und
event-on-change-reading:.*
sollte es eigentlich funktionieren.

Gruß Ralf

Master_Nick · 29 Dezember 2016, 12:53:50

Moin,

leider loggt er, trotz der gesetzter Atrribute (event-min-interval:.*:900 und event-on-change-reading:.*), Werte die identisch sind unterhalb des Intervalls:

Code Auswählen

2016-12-29_12:28:01 Kinderzimmer_Sensor_2 T: 21.8 H: 47 BAT: ok
2016-12-29_12:29:19 Kinderzimmer_Sensor_2 temperature: 21.8
2016-12-29_12:29:19 Kinderzimmer_Sensor_2 humidity: 47
2016-12-29_12:29:19 Kinderzimmer_Sensor_2 battery: ok
2016-12-29_12:29:19 Kinderzimmer_Sensor_2 T: 21.8 H: 47 BAT: ok
2016-12-29_12:29:58 Kinderzimmer_Sensor_2 temperature: 21.8
2016-12-29_12:29:58 Kinderzimmer_Sensor_2 humidity: 47
2016-12-29_12:29:58 Kinderzimmer_Sensor_2 battery: ok
2016-12-29_12:29:58 Kinderzimmer_Sensor_2 T: 21.8 H: 47 BAT: ok
2016-12-29_12:30:37 Kinderzimmer_Sensor_2 temperature: 21.8
2016-12-29_12:30:37 Kinderzimmer_Sensor_2 humidity: 47
2016-12-29_12:30:37 Kinderzimmer_Sensor_2 battery: ok
2016-12-29_12:30:37 Kinderzimmer_Sensor_2 T: 21.8 H: 47 BAT: ok
2016-12-29_12:31:16 Kinderzimmer_Sensor_2 temperature: 21.8
2016-12-29_12:31:16 Kinderzimmer_Sensor_2 humidity: 47
2016-12-29_12:31:16 Kinderzimmer_Sensor_2 battery: ok
2016-12-29_12:31:16 Kinderzimmer_Sensor_2 T: 21.8 H: 47 BAT: ok
2016-12-29_12:31:55 Kinderzimmer_Sensor_2 temperature: 21.8
2016-12-29_12:31:55 Kinderzimmer_Sensor_2 humidity: 47
2016-12-29_12:31:55 Kinderzimmer_Sensor_2 battery: ok
2016-12-29_12:31:55 Kinderzimmer_Sensor_2 T: 21.8 H: 47 BAT: ok

KölnSolar · 29 Dezember 2016, 13:46:57

Zitatdamit nicht alle par Sekunden ins Log geschrieben wird?

log ist halt nicht genügend spezifiziert für querlesende Helfer. Bei einem Datenlog des Geräts sollte event-on.... greifen, das Systemlog lässt sich eher durch ein verbose eine Stufe niedriger auf dem betreffenden Gerät Kinderzimmer_Sensor_2 beeinflussen.
Weitere Diskussionen zum Logging wären sicherlich besser in einem separaten Thread zu führen

Master_Nick · 29 Dezember 2016, 14:42:32

Danke, hast Recht etwas unspezifisch

Ich mach mal nen neuen auf - verbose half mir nicht.

Habe es hier eröffnet: https://forum.fhem.de/index.php/topic,63643.0.html

sven.scherf · 01 Januar 2017, 19:59:38

Hallo zusammen,

zunächst an alle ein Gutes neues Jahr 2017.

@bjoernh,
ich habe nun die Bitfolge von meinen GT-8000 Funksteckdosen mit dem Oscar ermittelt.
Leider kann ich hier nicht die genaue Impulslänge/Zeit ablesen. Das Schätzchen ist schon ein wenig älter.
Die Daten die ich ermittelt habe, habe ich hier in eine Tabelle zusammen gefasst.
Hier habe ich einen breiten Impuls als 1 und einen schmalen Impuls an 0 interpretiert so nach dem Vorbild von hier http://hartgeloetet.blogspot.de/2014/05/hacking-intertec-funksteckdosen.html

Code Auswählen


Taste/Bit	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21
1 on	        0	0	1	0	0	0	0	0	0	0	0	1	1	1	1	1	0	1	1	1	0
1 off 	        0	0	1	0	0	0	0	0	0	0	0	1	1	1	1	1	1	1	1	1	1
2 on	        0	0	1	0	0	0	0	0	0	0	0	1	1	0	1	1	0	1	1	0	0
2 off	        0	0	1	0	0	0	0	0	0	0	0	1	1	0	1	1	1	1	1	0	1
3 on	        0	0	1	0	0	0	0	0	0	0	0	1	1	0	0	1	0	1	1	0	1
3 off	        0	0	1	0	0	0	0	0	0	0	0	1	1	0	0	1	1	1	1	0	0
4 on	        0	0	1	0	0	0	0	0	0	0	0	1	1	1	0	1	0	1	1	1	1
4 off	        0	0	1	0	0	0	0	0	0	0	0	1	1	1	0	1	1	1	1	1	0
grp on	        0	0	1	0	0	0	0	0	0	0	0	1	1	0	0	0	0	1	1	1	1
grp off	        0	0	1	0	0	0	0	0	0	0	0	1	1	0	0	0	1	1	1	1	0
Dim hoch	0	0	1	0	0	0	0	0	0	0	0	1	1	0	0	0	1	0	1	0	0
Dimrunter	0	0	1	0	0	0	0	0	0	0	0	1	1	0	0	0	0	0	1	0	1

Die Bits 1 - 12 stellen hier den Hauscode da. Diesr kann verändert werden wenn hier an der FB ein Taster gedrückt wird.
Dann kann man sehen, dass der Hauscode sich binär hochzählt.

Bit 13 - 16 dürfte hier der Tastencode sein.
Bit 17 = on /off
Bit 18 - 21, diese erschliessen mir nicht so recht.

Die Signallänge für die kpl. übermittlung dauert ca. 45ms
Eine Signalflanke ca. 2,x ms

Kannst Du damit was anfangen und kann man damit was in Fhem bewirken um die Steckdosen zu schalten ?

Viele Grüße

Sven