[Gelöst ]Tipps zur Fehlersuche Zigbee2MQTT.Anbindung an FHEM gesucht

[pcbastler]

Hallo zusammen,
ich habe einen Proxmox-Server mit einem Z2M- und einem FHEM-LXC. 99% der Geräte sind korrekt eingebunden. Jetzt hab ich aber ein Problem mit einem Aquara MCCGQ11LM (Fenstekontakt). im Z2M ist der sauber drin (einer von 10), Fhem weigert sich aber hartnäckig den mittels autocreate einzubinden. Im MQTT-Traffic taucht das Gerät auch auf, aber es wird nicht neu angelegt. Wenn ich das manuell versuche (define MQTT2_DEVICE) fehlt das Template zigbee2mqtt_ContactSensor.
Wo kann ich mit der Fehlersuche beginnen?
PS: Es könnte sein, das der Sensor mit der identischen ID unter einem anderen Namen schon mal im Fhem eingebunden war, aber ich finde da nichts.

[betateilchen]

Kopiere doch einen der neun anderen in FHEM vorhandenen Kontakte und ändere einfach die ID.

[Beta-User]

Kopiere doch einen der neun anderen in FHEM vorhandenen Kontakte und ändere einfach die ID.

Dann müsste man aber wissen, unter welchem topic der Kontakt zu finden ist...

Und die readingList des anderen Devices säubern, das im Moment das Abo hat, kann auch nicht schaden.

*Duckundweg*

[pcbastler]

autocreate hat's nicht geschafft, also hab ich mir die komplette Definition eines anderen Sensors aus der fhem.cfg geholt, einmal Suchen+Ersetzen gemacht und dann alles außer setuuid ausgeführt. Und siehe da: Das Teil ist da
Danke für alle Tipps!

[Beta-User]

Anregungen: suche nochmal nach dem Topic (auch als ggf. passende regex) und ließ z.B. im Wiki mal, was eine RAW-Definition ist .

[TomLee]

Eine Frage. Gibts es in FHEM bisher wirklich keine bereits vorhandene Möglichkeit, anhand des Topics, die Devices zu ermitteln, die das Thema abonniert haben?
Es mag nicht die Aufgabe eines MQTT-Servers sein diese Information bereit zu stellen, das Feature hab ich aber, wenn ich darüber nachdenke, in der Vergangenheit in FHEM bereits vermisst.
Mir ist schon klar das man sich selbst eine Schleife über alle MQTT2_Devices und deren readingList basteln kann.

[Beta-User]

Ich würde es mit

Code Auswählen Erweitern

configdb search %Schnippsel%erledigen .

[TomLee]

Und was machen die Nutzer die configdb nicht nutzen?
search gibts auch als Fhem-Befehl. Da werden aber keine Attribute durchsucht.

[rudolfkoenig]

Gibts es in FHEM bisher wirklich keine bereits vorhandene Möglichkeit, anhand des Topics, die Devices zu ermitteln, die das Thema abonniert haben?

Zu welchem Zweck waere so eine Anzeige sinnvoll?

Vorschlag:

Code Auswählen Erweitern

fhem> defmod rl cmdalias rl .* AS { my @res;; foreach my $d (keys %defs) { push(@res, $d) if(AttrVal($d,"readingList","") =~ m/$EVENT/) };; join("\n",@res) }
fhem> rl D44128
MQTT2_DVES_D44128
fhem>


[TomLee]

Ja, funzt, danke.

Ich habs bei mir mehr eingeschränkt auf nur MQTT2_Devices angefangen umzusetzen:

Code Auswählen Erweitern

{my @arr = devspec2array("TYPE=MQTT2_DEVICE");;
for my $device (@arr) {
if (AttrVal($device, 'readingList', 'nA') =~ /0x1234567abcdefg/) {print "$device\n";;}
}
}

Zu welchem Zweck waere so eine Anzeige sinnvoll?

Ich verstehe das Thema bisher so, das pcbastler mit deinem gezeigten cmdalias jetzt mit nur Angabe der ID die zwei Geräte ermitteln kann, die den Topic seines Fensterkontakt abonniert haben.

[rudolfkoenig]

Ich habs bei mir mehr eingeschränkt auf nur MQTT2_Devices angefangen umzusetzen:

Welche Geraete haben sonst ein readingList?

Edit: ich sehe gerade: ein ganze Menge

[betateilchen]

Ich habs bei mir mehr eingeschränkt auf nur MQTT2_Devices angefangen umzusetzen:

Code Auswählen Erweitern

map { Debug $_ if $attr{$_}{readingList}=~/DEVICETOPIC/; } devspec2array("TYPE=MQTT2_DEVICE:FILTER=a:readingList!=''");

*duck-und-weg*

[TomLee]

OT

(ich muss mich mal mit Debug beschäftigen, was der Unterschied genau zu print ist)

[betateilchen]

(ich muss mich mal mit Debug beschäftigen, was der Unterschied genau zu print ist)

Das ist einfach erklärt:

Debug() ist eine FHEM-interne Funktion und schreibt über Log() ins Logfile

Code Auswählen Erweitern

Log 1, "DEBUG>" . $msg;

print() ist eine perl Funktion, die auf ein Filehandle schreibt. Falls kein spezielles Filehandle geöffnet ist, erfolgt die Ausgabe auf stdout (Betriebssystemebene).

Da FHEM die Ausgabe von stdout auf das FHEM-Systemlog umleitet, landen auch die Meldungen von print() im Regelfall im FHEM-Log. Das ist aber eher "Zufall" und eben spezifisch für FHEM.


Übrigens:

• Debug() ruft Log() auf
• Log() ruft Log3() auf
• Log3() schreibt mit print() in das offene FileHandle des FHEM Logs, falls ein solches existiert.
• Log3() schreibt mit print() auf stdout, falls kein FileHandle existiert (z.B. weil kein Log definiert ist)