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.
Kopiere doch einen der neun anderen in FHEM vorhandenen Kontakte und ändere einfach die ID.
Zitat von: betateilchen am 21 März 2025, 19:57:07Kopiere 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*
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!
Anregungen: suche nochmal nach dem Topic (auch als ggf. passende regex) und ließ z.B. im Wiki mal, was eine RAW-Definition ist :) .
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.
Ich würde es mit
configdb search %Schnippsel%erledigen ;) .
Und was machen die Nutzer die configdb nicht nutzen?
search gibts auch als Fhem-Befehl. Da werden aber keine Attribute durchsucht.
ZitatGibts 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:
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>
Ja, funzt, danke.
Ich habs bei mir mehr eingeschränkt auf nur MQTT2_Devices angefangen umzusetzen:
{my @arr = devspec2array("TYPE=MQTT2_DEVICE");;
for my $device (@arr) {
if (AttrVal($device, 'readingList', 'nA') =~ /0x1234567abcdefg/) {print "$device\n";;}
}
}ZitatZu 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.
ZitatIch 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
Zitat von: TomLee am 22 März 2025, 19:24:46Ich habs bei mir mehr eingeschränkt auf nur MQTT2_Devices angefangen umzusetzen:
map { Debug $_ if $attr{$_}{readingList}=~/DEVICETOPIC/; } devspec2array("TYPE=MQTT2_DEVICE:FILTER=a:readingList!=''");
*duck-und-weg*
OT
(ich muss mich mal mit Debug beschäftigen, was der Unterschied genau zu print ist)
Zitat von: TomLee am 23 März 2025, 20:03:04(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
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)