41_OREGON.pm (Kein) Logging mit CUL

[KölnSolar]

Hi Ralf/Sidey,
ich wollte mal das Protokoll von OSV2 nachvollziehen. Sensor auf verbose=5 gesetzt und im Log passiert....Nichts Scheint ein generelles Problem zu sein.
Mit verbose=5 auf dem CUL kommen dann die Meldungen 
Das IT_Modul verhält sich da anders. Liegt das evtl. am CUL_REDIRECT U. lässt sich gar nicht ändern ?
Frohe Weihnacht
Markus

[Ralf9]

Hallo Markus,

ich und Sidey können da nicht weiterhelfen, da wir keinen CUL haben. Zu CUL_REDIRECT  kann Dir wahrscheinlich nur @bjoernh weiterhelfen.
Was ist das für ein Oregon Sensor?

Frohe Weihnachten
Gruß Ralf

[bjoernh]

Naja, aber das Redirect ändert ja nichts an den Daten. Diese werden dann einfach an das Oregon weitergeleitet.

Ich habe zwar keinen Oregon, aber damals als ich dieses mit einem Dummysensor probiert hatte, konnte ich das verbose sehen. Aber ich hatte es generell angeschaltet.

[KölnSolar]

Das ist ja blöd... Die maintainer können nicht maintainen mangels Hardware  (kein Vorwurf, ihr habt das Modul ja auch nur geerbt)

Dann probieren wir es mal anders: verbose 5 auf dem CUL liefert

Code Auswählen Erweitern

2017.12.24 15:22:49 5: CUL/RAW: /o
2017.12.24 15:22:49 5: CUL/RAW: o/mAAAAAAAB32D4CB355535532D54
2017.12.24 15:22:49 5: CUL/RAW: omAAAAAAAB32D4CB355535532D54/B552D555352D554CB4ACAA09

2017.12.24 15:22:49 4: CUL_Parse: CUL433 omAAAAAAAB32D4CB355535532D54B552D555352D554CB4ACAA09
2017.12.24 15:22:49 5: CUL433: dispatch omAAAAAAAB32D4CB355535532D54B552D555352D554CB4ACAA09
2017.12.24 15:22:49 5: CUL_REDIRECT (mAAAAAAAB32D4CB355535532D54B552D555352D554CB4ACAA09) length: 51 RSSI: -69.5
2017.12.24 15:22:49 5: CUL_REDIRECT (mAAAAAAAB32D4CB355535532D54B552D555352D554CB4ACAA09) match Manchester COODE length: 51
2017.12.24 15:22:49 5: CUL_REDIRECT decode Oregon 2 (AAAAAAAB32D4CB355535532D54B552D555352D554CB4ACAA09)
2017.12.24 15:22:49 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010100110101010100110010110101010100101101010101001011010101010101010011010100101101010101010100110010110100101011001010101000001001
2017.12.24 15:22:49 5: OSV2 protocol detected (AAAAAAAB32D4CB355535532D54B552D555352D554CB4ACAA09)
2017.12.24 15:22:49 5: CUL_REDIRECT: OSV2 protocol converted to hex: (501A2D20683018200634F7) with length (88) bits

2017.12.24 15:22:49 5: CUL433 Dispatch now to Oregon Module.
2017.12.24 15:22:49 5: converted Data to (501A2D20683018200634F7)
2017.12.24 15:22:49 5: CUL433: dispatch 501A2D20683018200634F7
2017.12.24 15:22:49 5: OREGON: decoding delay=24 hex=501A2D20683018200634F7
2017.12.24 15:22:49 5: OREGON: sensor_id=1a2d BitsMsg=80 Bits=80
2017.12.24 15:22:49 5: OREGON: checksum2 = 52 berechnet: 52
2017.12.24 15:22:49 4: THGR228N_68_2 decoded Oregon: T: 18.3 H: 62 BAT: ok
2017.12.24 15:22:49 5: CUL_REDIRECT decode Oregon 3 (AAAAAAAB32D4CB355535532D54B552D555352D554CB4ACAA09)
2017.12.24 15:22:49 5: bitdata: 10101010101010101010101010101011001100101101010011001011001101010101010100110101010100110010110101010100101101010101001011010101010101010011010100101101010101010100110010110100101011001010101000001001
2017.12.24 15:22:49 5: CUL_REDIRECT decode Hideki (AAAAAAAB32D4CB355535532D54B552D555352D554CB4ACAA09)
2017.12.24 15:22:49 5: CUL433: search in 10101010101010101010101010101011001100101101010011001011001101010101010100110101010100110010110101010100101101010101001011010101010101010011010100101101010101010100110010110100101011001010101000001001

2017.12.24 15:22:49 5: protocol does not match, ignore received package (AAAAAAAB32D4CB355535532D54B552D555352D554CB4ACAA09)
nur verbose5 auf dem device THGR228N_68_2 liefert gar nichts.

Im Sourcecode ist mir aufgefallen, dass mit $iohash z.B.

Code Auswählen Erweitern

    Log3 $iohash, 4, "$name decoded Oregon: $val";
gelogged wird. Ändere ich das auf

Log3 $name 4, "$name decoded Oregon: $val";

bekomme ich auch einen Logeintrag. 
Irgendwas stimmt also in der "Logging-Logik" nicht. Ich bin aber jetzt in meinem beschränkten Modul-Verständnis zu unbedarft, wo und was nun alles in der Kette CUL -> CUL-REDIRECT -> OREGON geändert werden müsste 
Wenn ihr mir den Weg weist, baue ich es gerne um u. teste.

@Björn: auf dem CUL-REDIRECT kann ich ja,mangels device, keinen separaten verbose-level setzen. Es wird also immer der vom übergeordneten CUL "geerbt". Richtig ?

@Ralf: müsste man also so umbauen, dass so früh möglich der device-name ermittelt wird un danach immer mit device-name gelogged wird ?

Festliche Grüße
Markus

Edit:
@Björn: Die Arbeitsweise des CUL_REDIRECT ist mir nun klarer geworden. Demnach wird ja IMMER auf OSV2, OSV3 u. Hideki geprüft. Das führt dann zu den 5 letzten Zeilen meines Logauszugs. Macht es da nicht Sinn nach der 1. erfolgreichen Erkennung(Dispatch; hier OSV2) das Parsing zu beenden und eigentlich überflüssige/irreführende Logeinträge zu vermeiden ?

[Ralf9]

Die maintainer können nicht maintainen mangels Hardware

Dies betrifft nur den CUL und die CUL_REDIRECT.
In der CUL_REDIRECT wird ähnlich wie wir es in der 00_signalduino auch machen die empfangenen Daten passend für das Oregon Modul gewandelt.
Beim OSV3 war dies recht kniffelig

Im Sourcecode ist mir aufgefallen, dass mit $iohash z.B.
    Log3 $iohash, 4, "$name decoded Oregon: $val";
gelogged wird. Ändere ich das auf
Log3 $name 4, "$name decoded Oregon: $val";

Ja, stimmt das passt so nicht richtig, wir werden es ändern.
Der Rest sieht ok aus.

müsste man also so umbauen, dass so früh möglich der device-name ermittelt wird un danach immer mit device-name gelogged wird ?

Der devicename ist in der 41_OREGON erst ab der Zeile 960 bekannt:

Code Auswählen Erweitern

  my $def = $modules{OREGON}{defptr}{"$device_name"};


Gruß Ralf

[KölnSolar]

Der Rest sieht ok aus.

Sehe ich auch (fast) so. Für meine Bedürfnisse hätte ich halt gerne die "raw" Daten gesehen ohne dass ich den CUL auf verbose 5 stellen muss. Da platzt mir sonst das Logfile. Mittlerweile hat sich das aber erledigt, da ich nun das V2.1 (fast) verstanden habe und mich an den Aufbau einer Senderoutine begeben kann.
Wenn ihr einmal dran geht: könntet ihr die Masse an Kommentarzeilen von Altversionen für die bessere Übersicht rausschmeissen ?

Beim OSV3 war dies recht kniffelig

Gefühlt ist OSV2 aber noch schlimmer durch Dopplung und Invertierung jeden bits. Auf jeden Fall ist IT Kindergeburtstag dagegen
Grüße Markus