FHEM2FHEM Log-msg: Remote command response:cloudmqtt/owntracks/....

[erwin]

Hi,
Ich hab da in einem FHEM2FHEM RAW setup "unerwünschte/ungeplante"  Log msg's von der remote FHEM Instanz...
Setup:

Code Auswählen Erweitern

Internals:
   .FhemMetaInternals 1
   Clients    KNX
   DEF        192.168.5.69:7073 RAW:myKNXIO_R
   FD         18
   FUUID      61c0b105-f33f-0e08-4baa-3079d77b2df47186
   FVERSION   93_FHEM2FHEM.pm:0.257030/2022-02-18
   Host       192.168.5.69:7073
   NAME       myF2F_KNXIO_MH_RPI_21
   NR         222
   PARTIAL   
   STATE      connected
   TYPE       FHEM2FHEM
   cmdResponse 2 days, 19:35:41
   eventCount 23
   informType RAW
   rawDevice  myKNXIO_R
   MatchList:
     1:KNX      ^C.*
Attributes:
   addStateEvent 1
   excludeEvents KNX_05.*
   group      KNX-IO
   keepaliveInterval 60
   reportConnected 1
Das funktioniert alles Bestens, auf der remote FHEM-Instanz ist ein KNXIO-device (myKNXIO_R) definiert, dessen msgs an die lokale Instanz durchgereicht werden - in beiden Richtungen...

Zusätzlich hab ich jetzt auf der remote FHEM-Instanz ein MQTT2_Client / MQTT2_DEVICE definert, welches wiederum für sich auch problemlos funktioniert!
Allerdings: Falls in einer MQTT-msg ein 0x00 vorkommt (und das passiert hier ab und zu), dann wird das auf der lokalen FHEM-Instanz von FHEM2FHEM als (unvollständiger) cmd reply interpretiert, und ab da wird es problematisch, weil die msg auch nach $hash->{PARTIAL} kopiert wird... Das allerdings blockiert dann alle weiteren validen msg's!

Patch-Vorschläg: verschärfen des "envelopes" für cmd-reply msgs.
l.g. & danke erwin 

[rudolfkoenig]

Ich will den Fix in Eigenregie entwickeln, sonst habe ich ein Problem mit dem Support spaeter.
Aus diesem Grund brauche ich eher eine Beschreibung, wie ich das Problem nachstellen soll.

Was ich in diesem Fall nicht verstehe: wieso werden die Nachrichten von MQTT2_Client und MQTT2_Device mit einem FHEM2FHEM der Sorte RAW:myKNXIO_R weitergeleitet?

[rudolfkoenig]

Ich habe jetzt die Uebertragung der MQTT2_CLIENT / MQTT2_SERVER Nachrichten ueber eine FHEM2FHEM RAW Verbindung gefixt.

Sowas bleibt aber meiner Ansicht nach eine sinnlos komplizierte Art, eine direkte MQTT2_CLIENT Verbindung waere die richtige Wahl.

[erwin]

Hallo Rudi!

Was ich in diesem Fall nicht verstehe: wieso werden die Nachrichten von MQTT2_Client und MQTT2_Device.....

das hab ich mich auch gefragt, das kommt offensichtlich von einem Mqtt AUTOCREATE... - subsciption set im MQTT2_Client, autocreate=no, received topic matched in keinem MQTT2_DEVICE.
Oder auch daher, dass "inform RAW $regex" , das $regex nicht berücksichtigt...Ob das gewollt/notwendig ist, hab ich nicht untersucht.

Sowas bleibt aber meiner Ansicht nach eine sinnlos komplizierte Art, eine direkte MQTT2_CLIENT Verbindung waere die richtige Wahl.

Da hast du mich falsch verstanden, ich will sicher keine MQTT2_Client <-> MQTT2_DEVICE Verbindung zwischen den beiden FHEM's haben, eher das Gegenteil.
Die MQTT Story war nur der auslöser, vermutlich hätte jeder beliebige event mit 0x00 im content das Problem verursacht!
Mein setup ist ein KNXIO <-> KNX Verbindung.
Danke für den fix, kann erst heute abend testen!
l.g. erwin

[erwin]

Hallo Rudi,
Test ok,
zur info: ich weiß jetzt auch, wo/wie die Msg's mit 0x00 zustande kommen, und zwar aus MQTT2_Client:

Code Auswählen Erweitern

Dispatch($hash, "autocreate=$ac\0$cid\0$tp\0$val", undef, $ac eq "no");

Eine Kleinigkeit noch:
ein "set <F2Fdev> cmd foo" setzt das INTERNAL cmdResponse korrekt, allerdings kommt im Log:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value $rname in string ne at ./FHEM/93_FHEM2FHEM.pm line 237.
... weil die cmd-reply msg "standalone" (ohne event-msg) received wurde und daher $rmsg undef od. leer ist.
das hatte ich in meine patch-Vorschlag auch berücksichtigt.
Danke für deinen support.
erwin

[rudolfkoenig]

Danke fuer die Details, habs gefixt.