Dispatch an weiteres Modul.

Begonnen von bjoernh, 25 Oktober 2015, 13:17:53

Vorheriges Thema - Nächstes Thema

bjoernh

Hallo,

folgendes Problem:
Ich habe in der a-culfw die Empfangsroutine so erweitert, dass diese die Oregon2 empfängt.
Die funktioniert auch so weit.
Nun möchte ich das Rad nicht nochmal neu erfinden und habe mir gedacht ich leite die Empfangenen Daten an das Oregon Modul weiter.
Hierzu habe ich das 00_CUL Modul testweise um den Prefix o..... erweitert.
Diese Pakete werden anschließend an mein neues Modul CUL_OTHER (ist angehängt) weitergeleitet.
Das CUL_OTHER Modul bereitet die Daten auf und bringt die Empfangene Daten in das Format wie es das Oregon Modul erwartet.
So weit funktioniert alles.
Nun soll das CUL_OTHER Modul per "dispatch" die Daten an das Oregon Modul weiterreichen.
(Siehe CUL_OTHER Zeile 129)

Leider funktioniert dies nicht. Der Dispatch wird an das 00_CUL Modul weiter geleitet und das CUL Modul sagt anschließend Unknown code.

Wie kann ich am einfachsten diese Weiterleitung an das Oregon Modul erreichen?

Vorab schon mal vielen Dank für die Hilfe

Gruß
Björn

rudolfkoenig

Damit Dispatch funktioniert, muessen die Clients/MatchList und Match Felder in den beiden Modulen (Aufrufer/Aufgerufene) gepflegt werden.

herrmannj

#2
Hi,

geht aber auch "hacky", schau mal in das TechemHKV Modul. Da hab ich das gerade gemacht.

Im Prinzip die Clients des CUL zur Laufzeit erweitert und im Client die Matchlist gesetzt. In Deinem Fall wäre das die middleware. Von da aus könntest Du die _parse vom Oregon direkt aufrufen ohne über dispatch zu gehen.

Btw, Orgeon wird von Oregon und TRX_Weather bedient.

vg
joerg

Nebenwirkung: kein autocreate.

bjoernh

Zitat von: rudolfkoenig am 25 Oktober 2015, 13:42:12
Damit Dispatch funktioniert, muessen die Clients/MatchList und Match Felder in den beiden Modulen (Aufrufer/Aufgerufene) gepflegt werden.
Hallo Rudi,

das habe ich soweit ich es im Forum gelesen habe auch verstanden,  aber mir fehlt ein konkretes Beispiel.
Ich stehe irgendwie auf dem Schlauch wie das du funktionierten soll.

Gruß Björn

bjoernh

Zitat von: herrmannj am 25 Oktober 2015, 13:48:33
Nebenwirkung: kein autocreate.
Genau das ist ja eigentlich doof, bei den Orgeon 2 Temp/Hum Sensoren würde ich mir schon ein Autocreate wünschen.

Irgendwie muss das doch einfach gehen  :-\

rudolfkoenig

Warum?

Versuch mal MatchList und Clients in deinem Modul zu fuellen.

herrmannj

Naja schon. Wenn Du über dispatch gehst musst Du den Absender "fälschen". Oregon erwartet ja einen TRX als IO.

Deine Middleware müsste also gleichzeitig logisches device sein (um die Daten vom CUL zu bekommen) und als physikalisches device auftreten (um an Oregon weiterzuleiten). Sollte doch gehen. Schönder ist es - ob das einfacher ist ;-) ?

vg
joerg

bjoernh

Zitat von: rudolfkoenig am 25 Oktober 2015, 14:01:57
Warum?

Versuch mal MatchList und Clients in deinem Modul zu fuellen.
Geht leider nicht:
Habe jetzt im Initialize

$hash->{MatchList} = \%matchList_CUL_OTHER,
$hash->{Clients} = ":OREGON:";
---------------------------
## default regex match List for dispatching message to logical modules, can be updated during runtime because it is referenced
my %matchList_CUL_OTHER = (
     "1:OREGON"                  => "^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*",                           
);

Aber er macht es nicht.

2015.10.25 14:06:10 1: CUL_OTHER: OSV2 protocol converted to hex: (501A2D20CB201120053400) with length (88) bits

2015.10.25 14:06:10 1: converted Data to (501A2D20CB201120053400)
2015.10.25 14:06:10 5: CUL1 dispatch 501A2D20CB201120053400
2015.10.25 14:06:10 5: Loading ./FHEM/10_UNIRoll.pm
2015.10.25 14:06:10 5: Triggering CUL1 (1 changes)
2015.10.25 14:06:10 5: Notify loop for CUL1 UNKNOWNCODE 501A2D20CB201120053400
2015.10.25 14:06:10 3: CUL1: Unknown code 501A2D20CB201120053400, help me!



Sidey

Also für mich sieht das so aus, also ob in der matchlist vom 00 CUL Modul keine passende Weiterleitung gefunden wird.
Deshalb geht es nicht.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

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

bjoernh

So, ich glaube jetzt habe ich es, zwar nicht so sauber aber es geht.
Ich erweitere jetzt die Clients und die MatchList vom 00_CUL dynamisch:

my $OregonClientMatch=index($hash->{Clients},"OREGON");
if ($OregonClientMatch == -1) {
    # Patch clients
    $hash->{Clients} = $hash->{Clients}.":OREGON:";
    $hash->{MatchList}{"1:OREGON"} = "^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*";
}


Jetzt habe ich nur noch ein Problem. Das 00_CUL Modul meint noch
CUL1: Unknown code 501A2D20CB201120053400, help me!

2015.10.25 14:58:19 5: OSV2 protocol detected (996A659AAA9A59A5AA9A6A6AAA9A66AAA65AAAAAF1)
2015.10.25 14:58:19 5: CUL_OTHER: OSV2 protocol converted to hex: (501A2D20CB201120053400) with length (88) bits

2015.10.25 14:58:19 5: converted Data to (501A2D20CB201120053400)
2015.10.25 14:58:19 5: CUL1 dispatch 501A2D20CB201120053400
2015.10.25 14:58:19 5: OREGON: decoding delay=15 hex=501A2D20CB201120053400
2015.10.25 14:58:19 5: Triggering THGR228N_cb_2 (4 changes)
2015.10.25 14:58:19 5: Notify loop for THGR228N_cb_2 temperature: 11.2
2015.10.25 14:58:19 5: Triggering CUL1 (1 changes)
2015.10.25 14:58:19 5: Notify loop for CUL1 UNKNOWNCODE 501A2D20CB201120053400
2015.10.25 14:58:19 3: CUL1: Unknown code 501A2D20CB201120053400, help me!

rudolfkoenig

Du darfst nicht undef in deiner ParseFn zurueckliefern, sonst sucht Dispatch weiter nach Abnehmer. Ueblich ist der Name des betroffenen Endgeraetes als return-Wert, da aber die Nachricht schon von dem OREGON erfolgreich verarbeitet wurde, musst du "" zurueckliefern.

bjoernh

Zitat von: rudolfkoenig am 25 Oktober 2015, 15:25:30
Du darfst nicht undef in deiner ParseFn zurueckliefern, sonst sucht Dispatch weiter nach Abnehmer. Ueblich ist der Name des betroffenen Endgeraetes als return-Wert, da aber die Nachricht schon von dem OREGON erfolgreich verarbeitet wurde, musst du "" zurueckliefern.

Geht leider nicht:
2015.10.25 16:01:16 5: CUL1 Dispatch now to Oregon Module.
2015.10.25 16:01:16 5: converted Data to (501A2D20CB201120053400)
2015.10.25 16:01:16 5: CUL1 dispatch 501A2D20CB201120053400
2015.10.25 16:01:16 5: OREGON: decoding delay=0 hex=501A2D20CB201120053400
2015.10.25 16:01:16 5: Triggering THGR228N_cb_2 (4 changes)
2015.10.25 16:01:16 5: Notify loop for THGR228N_cb_2 temperature: 11.2
2015.10.25 16:01:16 5: Loading ./FHEM/10_UNIRoll.pm
2015.10.25 16:01:16 5: Triggering CUL1 (1 changes)
2015.10.25 16:01:16 5: Notify loop for CUL1 UNKNOWNCODE 501A2D20CB201120053400
2015.10.25 16:01:16 3: CUL1: Unknown code 501A2D20CB201120053400, help me!
2015.10.25 16:01:16 5: Return ""


Das Unknown vom CUL kommt bereits bevor ich aus meinem Modul mit "" zurückkehre.



bjoernh

Noch ein Problem,

wenn ich den Sensor wieder lösche funktioniert das Autocreate nicht:

2015.10.25 16:50:52 5: CUL1 Dispatch now to Oregon Module.
2015.10.25 16:50:52 5: converted Data to (501A2D20CB201120053400)
2015.10.25 16:50:52 5: CUL1 dispatch 501A2D20CB201120053400
2015.10.25 16:50:52 5: OREGON: decoding delay=46 hex=501A2D20CB201120053400
2015.10.25 16:50:52 3: OREGON: Unknown device THGR228N_cb_2, please define it
2015.10.25 16:50:52 5: Triggering CUL1 (1 changes)
2015.10.25 16:50:52 5: Notify loop for CUL1 UNKNOWNCODE 501A2D20CB201120053400
2015.10.25 16:50:52 3: CUL1: *********Unknown code 501A2D20CB201120053400, help me!
2015.10.25 16:50:52 5: Return ""


Irgendetwas passt da noch nicht, noch einen Tipp?

betateilchen

Auch nach einem Neustart nicht?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

bjoernh