Hi,
Ich hab da in einem FHEM2FHEM RAW setup "unerwünschte/ungeplante" Log msg's von der remote FHEM Instanz...
Setup:
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
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?
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.
Hallo Rudi!
ZitatWas 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.
ZitatSowas 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
Hallo Rudi,
Test ok,
zur info: ich weiß jetzt auch, wo/wie die Msg's mit 0x00 zustande kommen, und zwar aus MQTT2_Client:
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:
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
Danke fuer die Details, habs gefixt.