Hallo,
ich möchte MQTT nutzen und möchte hierzu das Modul MQTT anlegen.
Gemäß Wiki-Artikel (https://wiki.fhem.de/wiki/MQTT) werden hierfür 2 Perl-Module benötigt:
MQTT::Simple
MQTT::Constants
Wenn ich versuche, diese Module zu installieren, dann erhalte ich diese Fehler:
$ sudo cpan install Net::MQTT::Simple
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/root/.cpan/Metadata'
Database was generated on Wed, 20 Jan 2021 16:55:48 GMT
Running install for module 'Net::MQTT::Simple'
Checksum for /root/.cpan/sources/authors/id/J/JU/JUERD/Net-MQTT-Simple-1.24.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring J/JU/JUERD/Net-MQTT-Simple-1.24.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::MQTT::Simple
Writing MYMETA.yml and MYMETA.json
JUERD/Net-MQTT-Simple-1.24.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for J/JU/JUERD/Net-MQTT-Simple-1.24.tar.gz
JUERD/Net-MQTT-Simple-1.24.tar.gz
make -- NOT OK
No such file or directory
$ sudo cpan install Net::MQTT::Constants
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/root/.cpan/Metadata'
Database was generated on Wed, 20 Jan 2021 16:55:48 GMT
Running install for module 'Net::MQTT::Constants'
Checksum for /root/.cpan/sources/authors/id/B/BE/BEANZ/Net-MQTT-1.163170.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring B/BE/BEANZ/Net-MQTT-1.163170.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::MQTT
Writing MYMETA.yml and MYMETA.json
BEANZ/Net-MQTT-1.163170.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for B/BE/BEANZ/Net-MQTT-1.163170.tar.gz
BEANZ/Net-MQTT-1.163170.tar.gz
make -- NOT OK
No such file or directory
Die Debian-Pakete
libmodule-pluggable-perl
mosquitto-clients
python3-paho-mqtt
habe ich zuvor installiert.
Was ist die Ursache für den Fehler?
Wo finde ich Log-Infos, die Hinweise zur Ursache liefern?
THX
Sorry, wenn ich nicht direkt was zur Lösung des cpan-Problems beitragen kann...
Gibt es einen tieferen Grund, warum du das mit MQTT/MQTT_DEVICE machen willst und nicht mit MQTT2_CLIENT/MQTT2_DEVICE? Rudi hat die letzteren Module v.a. auch deswegen entwickelt, um Usern diese Art Hackel zu ersparen, und erfahrungsgemäß ist MQTT2_DEVICE auch in der Anwendung einfacher zu verstehen als das manuelle Anlegen von MQTT_DEVICE-Attributen.
Was Beta-User sagt. Schau aber auch mal ins Wiki (https://wiki.fhem.de/wiki/CPAN) zum Thema CPAN und verwende dann lieber cpanm.
Zitat von: Beta-User am 20 Januar 2021, 21:32:22
Sorry, wenn ich nicht direkt was zur Lösung des cpan-Problems beitragen kann...
Gibt es einen tieferen Grund, warum du das mit MQTT/MQTT_DEVICE machen willst und nicht mit MQTT2_CLIENT/MQTT2_DEVICE? Rudi hat die letzteren Module v.a. auch deswegen entwickelt, um Usern diese Art Hackel zu ersparen, und erfahrungsgemäß ist MQTT2_DEVICE auch in der Anwendung einfacher zu verstehen als das manuelle Anlegen von MQTT_DEVICE-Attributen.
Der einzige Grund, warum ich versuche das Modul MQTT zu installieren ist, dass hier (https://ownsmarthome.de/2020/05/07/loxone-mit-raspberry-pi-mqtt-fhem-aufbohren/) ebenfalls verwendet wird.
Ich habe natürlich auch den [urlhttps://wiki.fhem.de/wiki/MQTT]Wiki-Artikel zu MQTT[/url] gelesen und mich gefragt, was der Unterschied zwischen den Modulen MQTT und MQTT2_CLIENT ist, aber keine klare Antwort gefunden.
Der Haken mit etlichen solcher "externen" Links ist, dass die Autoren ueber Ihre Erfahrungen berichten, nicht hier im Forum nachfragen, und damit suboptimale Loesungen zeigen. Weiterhin geht bei FHEM die Entwicklung dauernd weiter, und die Blogs selten aktualisiert werden. Letzteres ist selbst in unserem Wiki ein Problem.
Die MQTT2 Familie ist entstanden, weil ich die Probleme der FHEM-Neulinge mit MQTT gesehen habe, MQTT als fuer FHEM wichtiges Protokoll eingestuft habe, und deswegen versucht habe diese Probleme zu loesen:
- keine Abhaengigkeit von externen CPAN Modulen
- kein externer MQTT Server notwendig (define m2s MQTT_SERVER 1883 global)
- automatisches Anlegen der MQTT2_DEVICE FHEM Instanzen (direkt mit MQTT2_SERVER, und ueber ein attrTemplate Anweisung bei MQTT2_CLIENT)
- automatisches Erzeugen von FHEM-Readings/Events aus MQTT-Daten, automatische JSON Dekodierung (wiederum ohne externe Perl-Module)
- mit attrTemplate eine Moeglichkeit, bei bekannten Geraeten die Befehle und andere Parameter einfach zu konfigurieren
- schnelle Unterstuetzung bei Problemen.
Zitat von: Christoph Morrison am 20 Januar 2021, 21:51:40
Was Beta-User sagt. Schau aber auch mal ins Wiki (https://wiki.fhem.de/wiki/CPAN) zum Thema CPAN und verwende dann lieber cpanm.
Das Problem mit der Installation der Perl-Module Net::MQTT::Simple und Net::MQTT::Constants ist gelöst mit der Installation der Pakete
cpanminus
make
Ich gehe davon aus, dass das Paket make die sog. Root Cause war, weil ich erst durch cpanminus erfahren habe, dass der 'Make' fehlschlägt.
Gruß
Thomas
Trotzdem solltest du DRINGEND davon Abstand nehmen, diesen Weg weiter zu gehen! Vermutlich ist in der Anleitung auch noch das "SYS_MQTT-notify" enthalten...
Du kannst mir evtl. im Moment nicht folgen, aber evtl. ist MAX Thermostate und MQTT - Readings und Steuerung über FHEM verfügbar machen (https://forum.fhem.de/index.php/topic,117423.0.html) ein guter Startpunkt, um dich auf einen sehr aktuellen Stand zu bringen?
Ich kann anbieten, dich etwas an der Hand zu nehmen und das dann auf die sichere Weise mit MQTT2_CLIENT+MQTT_GENERIC_BRIDGE (wo erforderlich, sonst MQTT2_DEVICE) aufzugleisen...
Ansonsten habe ich den betreffenden Wiki-Artikel jetzt auch auf den aktuellen Stand gebracht, auch was clientOrder/autocreate angeht.
@Rudi: Wäre nett, wenn du kurz drüberschaust, nicht, dass ich da die Syntax missverstanden habe, ist grade nur etwas Trockenübung...
Zitat@Rudi: Wäre nett, wenn du kurz drüberschaust, nicht, dass ich da die Syntax missverstanden habe, ist grade nur etwas Trockenübung...
Weiss nicht genau, welche Teile du meinst. Hab versucht von oben mich durchzuarbeiten, und habe festgestellt, dass auf meinem Linux-Rechner kein Befehl service gibt, das heisst seit langem systemctl :)
Der clientOrder Abschnitt enthaelt nichts Falsches.
Insgesamt finde ich den Wiki-Beitrag ueberladen, es ist abschreckend/verwirrend fuer die, die "nur mal schnell" was einbinden wollen, dadurch dass so viele Moeglichkeiten beschrieben werden.
Ich wuerde ich am Anfang durch kurze Beispiele zeigen, dass MQTT in FHEM nichts Schreckliches ist:
- define m2s MQTT2_SERVER 1883 global
- am MQTT-Endgeraet den FHEM-Server angeben
- schau mal in attrTemplate der neu angelegten MQTT2_DEVICE, ob was passendes fuer Dich da ist
Na ja, man kann sich auch über die "Versionsgeschichte" nur die Änderungen anzeigen lassen.
systemctl ist jetzt auch da drin, bei mir funktioniert aber auch auf allen Linuxen noch der service-Befehl, und ich bin halt auch ein Gewohnheitstier...
Habe jetzt zu Beginn das "für Eilige" eingefügt, mal schauen, wie viele trotzdem lieber auf "externe Experten" vertrauen...
Und ja, "überladen" ist wohl einigermaßen treffend... Habe nur im Moment keine Idee, wie es einfacher ginge.
@cmonty14:
Kannst du den Beitrag https://forum.fhem.de/index.php/topic,91642.msg1124076.html#msg1124076 (https://forum.fhem.de/index.php/topic,91642.msg1124076.html#msg1124076) bitte einfach wieder löschen und stattdessen hier einfach mal ein list von dem Aktor zeigen (da fehlt schlicht "alles", siehe Unbedingt vor dem ersten Post lesen) (https://forum.fhem.de/index.php/topic,71806.0.html)
Und wir können das ganze Thema auch gerne in Bidirektionale Kommunikation FHEM-Loxone: was wird benötigt FHEM -> Loxone? (https://forum.fhem.de/index.php/topic,117745.msg1121502.html#msg1121502) vertiefen, aber bitte nicht die (im Prinzip unveränderte?) Frage über das ganze Forum verteilen...?
Zitat von: Beta-User am 21 Januar 2021, 10:02:22
Trotzdem solltest du DRINGEND davon Abstand nehmen, diesen Weg weiter zu gehen! Vermutlich ist in der Anleitung auch noch das "SYS_MQTT-notify" enthalten...
Du kannst mir evtl. im Moment nicht folgen, aber evtl. ist MAX Thermostate und MQTT - Readings und Steuerung über FHEM verfügbar machen (https://forum.fhem.de/index.php/topic,117423.0.html) ein guter Startpunkt, um dich auf einen sehr aktuellen Stand zu bringen?
Ich kann anbieten, dich etwas an der Hand zu nehmen und das dann auf die sichere Weise mit MQTT2_CLIENT+MQTT_GENERIC_BRIDGE (wo erforderlich, sonst MQTT2_DEVICE) aufzugleisen...
Ansonsten habe ich den betreffenden Wiki-Artikel jetzt auch auf den aktuellen Stand gebracht, auch was clientOrder/autocreate angeht.
Hallo,
vielen Dank für diese Info.
Ich habe mich auch gefragt, warum nicht das Modul MQTT2_CLIENT verwendet wird, weil ich diese Probleme mit der Installation der Perl-Module hatte. Diese Frage habe ich dann an den Autor des Blogs weitergeleitet.
Und ich habe auch ein Device mit dem Modul MQTT2_CLIENT angelegt:
define lb_mqtt MQTT2_CLIENT <loxberry IP>:1883 loxberry <deinMQTTPasswort>Allerdings habe ich dann ein Authorisierungsproblem, das im Log dokumentiert ist.
Deshalb würde ich dein Angebot zur Unterstützung annehmen und würde nochmals von vorne beginnen.
(Die aktuelle FHEM Konfiguration verwendet die Devices MQTT, MQTT_GENERIC_BRIDGE und MQTT_DEVICE und funktioniert soweit, d.h. es werden Nachrichten an den MQTT-Broker gesendet. Dies bestätigt, dass die Kommunikation zwischen FHEM und MQTT-Broker grundsätzlich funktioniert.)
Gruß
Thomas
Zitat von: Beta-User am 21 Januar 2021, 13:05:53
@cmonty14:
Kannst du den Beitrag https://forum.fhem.de/index.php/topic,91642.msg1124076.html#msg1124076 (https://forum.fhem.de/index.php/topic,91642.msg1124076.html#msg1124076) bitte einfach wieder löschen und stattdessen hier einfach mal ein list von dem Aktor zeigen (da fehlt schlicht "alles", siehe Unbedingt vor dem ersten Post lesen) (https://forum.fhem.de/index.php/topic,71806.0.html)
Und wir können das ganze Thema auch gerne in Bidirektionale Kommunikation FHEM-Loxone: was wird benötigt FHEM -> Loxone? (https://forum.fhem.de/index.php/topic,117745.msg1121502.html#msg1121502) vertiefen, aber bitte nicht die (im Prinzip unveränderte?) Frage über das ganze Forum verteilen...?
Ich habe den Beitrag gelöscht.
Den Thread "Bidirektionale Kommunikation FHEM-Loxone: was wird benötigt FHEM -> Loxone?" habe ich speziell für das Modul LOXONE2FHEM (https://forum.fhem.de/index.php/topic,65219.0.html) geöffnet.
Ich war der Auffassung, dass ich nur so zwischen den Systemen FHEM und Loxone kommunizieren kann.
Dies ist aber offensichtlich ein Irrtum, und ich würde MQTT bevorzugen unter der Voraussetzungen, dass das (sauber & sicher) funktioniert.
Allerdings kann ich diesen Thread wg. fehlender Berechtigung nicht löschen.
Ich werde diesen Thread auf "solved" stellen, den das ursprüngliche Problem ist ja gelöst.
Für die Probleme im Zusammenhang mit Modul MQTT2_CLIENT werde ich dann ggf. einen neuen Thread öffnen.
Die Syntax bei MQTT2_CLIENT ist etwas anders, wie du über help MQTT2_CLIENT auch gut in Erfahrung bringen kannst:
define lb_mqtt MQTT2_CLIENT <loxberry IP>:1883
attr lb_mqtt username loxberry
set lb_mqtt password <deinMQTTPasswort>
attr lb_mqtt clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
Dann schaust du dir bitte noch die anderen Attribut-Optionen an wie ClientID und diese LWT-Sachen (ist aber nicht so dringend).
(für die Formatierung bitte den #-Button benutzen).
Dann wirst du MQTT_GENERIC_BRIDGE benötigen, nur eben mit dem obigen "lb_mqtt" als IODev.
Du brauchst dann aber weder dieses SYS_MQTT-Device noch ein notify, das darauf lauscht. Das geht alles direkt mit der MQTT_GENERIC_BRIDGE (MGB).
Hier mal ein Beispiel:
defmod mgb1 MQTT_GENERIC_BRIDGE
attr mgb1 IODev lb_mqtt
Dann lädst du die .template aus dem Anhang und speicherst sie (mit den passenden Rechten!) unter fhem/FHEM/lib/AttrTemplate ab und führst (in FHEMWEB) diesen Befehl aus:
{AttrTemplate_Initialize()}
Dann sollte folgendes gehen:
set mgb1 attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE
Im Ergebnis hast du dann separate Topics in Sende- und Empfangsrichtung konfiguriert. Das Ergebnis sollte so aussehen:
attr mgb1 globalDefaults sub:base={"FHEM/MQTT_2FHEM/$device"} pub:base={"FHEM/FHEM_2MQTT/$device"} pub:qos=0 sub:qos=2 retain=0
Wenn du das soweit hast, können wir uns um deinen Rollladen in Senderichtung kümmern, damit du alle _relevanten_ Readings auf den Broker bekommst. Wie geschrieben, bräuchte ich dafür ein list oder eine RAW-Definition (letzteres wäre mir persönlich lieber).
Eine Warnung in dem Zusammenhang: das ganze ist noch nicht wirkich ausgegoren, was die Frage der "sinnvollen" Vorbelegung von $base angeht, wer es also nachmacht, sollte ggf. nachsehen, ob sich dann später was geändert hat...! (Funktionieren wird es aber trotzdem!)
Auf der Loxone-Seite wirst du das Kommando auch anders zusammenbauen müssen, wie zeige ich dir dann auch noch...
Was den anderen Thread angeht: Bitte (ausnahmsweise!) schließen, _nachdem_ du ihn als [anders gelöst] gekennzeichnet und einen Link nach hierhin gesetzt hast.
Du kannst auch diesen Thread hier gerne so umbenennen (ggf. auch, wenn wir fertig sind), dass man erkennen kann, dass es um Loxone geht; du bist nämlich gefühlt der 4. in 2 Wochen, der vor der Frage steht, wie er Loxone sauber anbinden kann, von daher wäre mir dran gelegen, das ganze nicht allzuoft wiederholen zu müssen...
Zitat von: Beta-User am 21 Januar 2021, 13:35:08
Dann schaust du dir bitte noch die anderen Attribut-Optionen an wie ClientID und diese LWT-Sachen (ist aber nicht so dringend).
(für die Formatierung bitte den #-Button benutzen).
Was ist das Äquivalent zu
attr mqtt last-will retain:1 system/<fhem-name>/connection/status connection lost
attr mqtt on-connect retain:1 {Log3("mqtt",3,"connected to MQTT server");;1} system/<fhem-name>/connection/status connected
attr mqtt on-disconnect retain:1 {Log3("mqtt",3,"disconnected from MQTT server");;1} system/<fhem-name>/connection/status disconnectedfür das Modul MQTT2_CLIENT?
Zitat von: cmonty14 am 21 Januar 2021, 15:24:45
Was ist das Äquivalent zu
attr mqtt last-will retain:1 system/<fhem-name>/connection/status connection lost
attr mqtt on-connect retain:1 {Log3("mqtt",3,"connected to MQTT server");;1} system/<fhem-name>/connection/status connected
attr mqtt on-disconnect retain:1 {Log3("mqtt",3,"disconnected from MQTT server");;1} system/<fhem-name>/connection/status disconnected
für das Modul MQTT2_CLIENT?
Ungetestet (ich komme bisher mit ausschließlich M2_Server gut klar):
attr lb_mqtt lwt system/<fhem-name>/connection/status connection lost
attr lb_mqtt lwtRetain 1
attr lb_mqtt msgAfterConnect -r system/<fhem-name>/connection/status connected
attr lb_mqtt msgBeforeDisconnect -r system/<fhem-name>/connection/status disconnectedDas loggen in FHEM müsstest du checken. Ich vermute, dass die Log3-Anweisungen nur deswegen da sind, weil das MQTT-alt-Modul das nicht per default macht, aber afaik schreibt M2_CLIENT sowas automatisch ins Log und - Bonus! - du solltest bei diesen Log-Einträgen dann auch eher rausbekommen, warum das der Fall war ;) .
Ob es sinnvoll ist, diese drei Meldungen auf denselben Topic zu schreiben: k.A.. die letzten beiden vermutlich schon.
Zitat von: Beta-User am 21 Januar 2021, 16:02:18
Ungetestet (ich komme bisher mit ausschließlich M2_Server gut klar):
attr lb_mqtt lwt system/<fhem-name>/connection/status connection lost
attr lb_mqtt lwtRetain 1
attr lb_mqtt msgAfterConnect -r system/<fhem-name>/connection/status connected
attr lb_mqtt msgBeforeDisconnect -r system/<fhem-name>/connection/status disconnectedDas loggen in FHEM müsstest du checken. Ich vermute, dass die Log3-Anweisungen nur deswegen da sind,
Hallo,
wo wird der sog.
<fhem-name> definiert, der hier verwendet wird?
Danke.
Zitat von: Beta-User am 21 Januar 2021, 13:35:08
Hier mal ein Beispiel:
defmod mgb1 MQTT_GENERIC_BRIDGE
attr mgb1 IODev lb_mqtt
Dann lädst du die .template aus dem Anhang und speicherst sie (mit den passenden Rechten!) unter fhem/FHEM/lib/AttrTemplate ab und führst (in FHEMWEB) diesen Befehl aus:
{AttrTemplate_Initialize()}
Dann sollte folgendes gehen:
set mgb1 attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE
Im Ergebnis hast du dann separate Topics in Sende- und Empfangsrichtung konfiguriert. Das Ergebnis sollte so aussehen:
attr mgb1 globalDefaults sub:base={"FHEM/MQTT_2FHEM/$device"} pub:base={"FHEM/FHEM_2MQTT/$device"} pub:qos=0 sub:qos=2 retain=0
Ich habe die Datei mqtt_generic_bridge.template (aus dem Anhang) auf den FHEM Server kopiert und als diese Datei gespeichert: /opt/fhem/FHEM/AttrTemplate
Somit sind jetzt 2 Dateien mit ähnlichem Namen vorhanden:
$ ll /opt/fhem/FHEM/Attr*
-rw-r--r-- 1 fhem dialout 5926 Jan 21 19:19 /opt/fhem/FHEM/AttrTemplate
-rw-r--r-- 1 fhem dialout 11772 Okt 31 15:51 /opt/fhem/FHEM/AttrTemplate.pm
Nach Ausführen von
{AttrTemplate_Initialize()} steht im Log:
2021.01.21 19:36:40 2: AttrTemplates: got 218 entriesWenn ich dann
set mqttGenericBridge attrTemplate base_settings_to_MQTT_GENERIC_BRIDGEausführe erhalte ich diesen Fehler im WebUI:
Unknown template_entry_name base_settings_to_MQTT_GENERIC_BRIDGE
Das liegt jetzt aber nicht daran, dass ich einen anderen Namen für das Device verwende?
Soll ich die original
/opt/fhem/FHEM/AttrTemplate.pm entfernen?
Ok, mit der letzten Aktion hast du was kaputt gemacht...
Reparaturanleitung:
{ Svn_GetFile("FHEM/AttrTemplate.pm", "FHEM/AttrTemplate.pm") }
{ Svn_GetFile("FHEM/lib/AttrTemplate/general_use.template", "FHEM/lib/AttrTemplate/general_use.template") }
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", "FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", sub(){ AttrTemplate_Initialize() }) }Danach sollte es klappen, aber die base-Werte etwas anders sein als gestern angekündigt.
Zu der ersten Frage: Angaben in spitzen Klammern, also "<sowas>" sind in der Regel so gemeint: Überleg dir hier was eigenes (und lass die spitzen Klammern weg)...
Ansonsten:
Was du hier geschrieben hattest, hat mAn. noch nichts mit der MGB zu tun, da ist noch irgendwas anderes (ein notify aus früheren Versuchen?) am Werk. Das solltest du suchen und LÖSCHEN, denn am Ende bringt uns das nur durcheinander...
Zitat von: cmonty14 am 21 Januar 2021, 21:27:49
Von dem Device HM-LC-Bl1PBU-FM diese Readings im Broker abrufbar:
fhem_KU.rollladen_commState CMDs_done
fhem_KU.rollladen_deviceMsg 100% (to HMUART)
fhem_KU.rollladen_level 100
fhem_KU.rollladen_motor stop:100%
fhem_KU.rollladen_pct 100
fhem_KU.rollladen_state 1
Weiter verstehe ich das wording nicht, ein MQTT-Server (aka Broker) hat keine "Readings", er bietet topic/payload Infos zum Abruf an. Was du als "Reading" interpretierst, dürfte also jeweils ein "Topic" sein und das ganze ist eigentlich ein gutes Beispiel dafür, dass es wohl sehr sinnvoll ist, etwas Zeit in die Frage zu investieren, was uns eigentlich davon "irgendwo anders" interessiert. Meine Meinung:
- "pct" ODER "level";
- "stop" (oder "up" "down"), aber nicht der Wert in %;
(- vielleicht: commState)
- state (da scheinst du eine Übersetzung zu haben? In FHEM ist das afaik "on", "0.5-99.5" oder "off" oder evtl. ein "set_.*").
Würde vorschlagen, wir bereinigen erst mal die Basis, sonst macht jedenfalls mir das keinen Spaß.
Falls es ein notify ist, das du rauswerfen mußt, solltest du dieses finden mit
list DEF=.*publish.*PS: Kann schon sein, dass ich hin und wieder Typos etc. in meinen Posts habe, aber in der Regel sind das nicht so gravierende Abweichungen, dass man gleich ganz andere Verzeichnisse hat wie angegeben und die Dateinamen ganz anders sind... Bitte an der Stelle lieber rückfragen, reparieren ist immer vergleichsweise aufwändig, und hier hat mich das vor der Zeit in Zugzwang gebracht >:( .
Zitat von: Beta-User am 22 Januar 2021, 08:20:39
Ok, mit der letzten Aktion hast du was kaputt gemacht...
Reparaturanleitung:
{ Svn_GetFile("FHEM/AttrTemplate.pm", "FHEM/AttrTemplate.pm") }
{ Svn_GetFile("FHEM/lib/AttrTemplate/general_use.template", "FHEM/lib/AttrTemplate/general_use.template") }
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", "FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", sub(){ AttrTemplate_Initialize() }) }
Danach sollte es klappen, aber die base-Werte etwas anders sein als gestern angekündigt.
Ich habe noch nicht verstanden, welche Datei
$ ll /opt/fhem/FHEM/Attr*
-rw-r--r-- 1 fhem dialout 5926 Jan 21 19:19 /opt/fhem/FHEM/AttrTemplate
-rw-r--r-- 1 fhem dialout 11772 Okt 31 15:51 /opt/fhem/FHEM/AttrTemplate.pmich behalten soll?
Wenn es geplant war, das AttrTemplate einmalig und nur für diesen Zweck zu initialisieren, dann wäre es richtig gewesen, die Original-Datei
AttrTemplate.pm zu entfernen und an deren Stelle die Datei
mqtt_generic_bridge.template zu setzen, oder?
In Bezug auf die Korrektur habe ich folgende Frage:
Welche Dateien müssen für die Korrektur vorhanden sein? Beide? Oder nur eine? Wenn eine, welche?
Zitat
Ansonsten:
Was du hier geschrieben hattest, hat mAn. noch nichts mit der MGB zu tun, da ist noch irgendwas anderes (ein notify aus früheren Versuchen?) am Werk. Das solltest du suchen und LÖSCHEN, denn am Ende bringt uns das nur durcheinander... Weiter verstehe ich das wording nicht, ein MQTT-Server (aka Broker) hat keine "Readings", er bietet topic/payload Infos zum Abruf an. Was du als "Reading" interpretierst, dürfte also jeweils ein "Topic" sein und das ganze ist eigentlich ein gutes Beispiel dafür, dass es wohl sehr sinnvoll ist, etwas Zeit in die Frage zu investieren, was uns eigentlich davon "irgendwo anders" interessiert. Meine Meinung:
- "pct" ODER "level";
- "stop" (oder "up" "down"), aber nicht der Wert in %;
(- vielleicht: commState)
- state (da scheinst du eine Übersetzung zu haben? In FHEM ist das afaik "on", "0.5-99.5" oder "off" oder evtl. ein "set_.*").
Vermeintlich habe ich mich nicht klar genug ausgedrückt.
FHEM sendet verschiedene Topics an den MQTT-Broker. Im Fall des Devices HM-LC-Bl1PBU-FM entsprechen die Topics von "fhem_KU.rollladen" den Device-Readings.
Ich hoffe jetzt ist verständlicher, was ich gemeint habe.
Wäre es möglich, alle Aktivitäten / Massnahmen / etc., die im Zusammenhang mit dem Device
HM-LC-Bl1PBU-FM stehen, in diesem dedizierten Thread (https://forum.fhem.de/index.php/topic,117997.msg1124281.html#msg1124281) zu behandeln?
Dann würde ich den Thread hier ausschließlich für die saubere und korrekte Konfiguration von MQTT verwenden und dann auf
solved stellen, wenn dies abgeschlossen ist.
Gruß
Thomas
Also:
1. Diese kannst du LÖSCHEN:
-rw-r--r-- 1 fhem dialout 5926 Jan 21 19:19 /opt/fhem/FHEM/AttrTemplate
(Ist aber eigentlich egal, wenn die unter dem Namen da liegen bleibt, ist halt eine unverwendete Altlast...)
2. Dann bitte (nur) diese beiden Zeilen über FHEMWEB ausführen:
{ Svn_GetFile("FHEM/lib/AttrTemplate/general_use.template", "FHEM/lib/AttrTemplate/general_use.template") }
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", "FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", sub(){ AttrTemplate_Initialize() }) }
Die AttrTemplate.pm hattest du ja nicht überschrieben, daher brauchen wir die nicht zu reparieren, sorry, da hatte ich was falsch interpretiert.
Wie danach bzw. nach "set mgb1 attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE" die Basis-Topic-Struktur (grundsätzlich) aussieht, ist hier beschrieben: https://forum.fhem.de/index.php/topic,117987.msg1124408.html#msg1124408
3. Bitte suche das Device, das diese komischen Infos an den Broker schickt! Das musst du unbedingt Löschen, wir machen das mit der MGB und werden das dann auch für das konkrete Device in der Tat in deinem separaten Thread machen. Aber erst muss aufgeräumt sein...
Es kann auch sein, dass insbesondere die "1" von der Loxone-Seite her kommt. Bitte stelle auch erst mal sicher, dass du keine publishes von dieser Seite her an den Broker machst.
Falls es da nirgends was gibt, sind das ggf auch schlicht Altlasten, die sich mit publishes von leeren payloads auf die Topics beseitigen lassen sollten. Ein Beispiel (unterstellt, dein MQTT2_CLIENT heißt immer noch lb_mqtt):
set lb_mqtt publish fhem_KU.rollladen_commState
Wenn du das soweit sauber hast und hier dann ein RAW-list von deiner MQTT_GENERIC_BRIDGE gezeigt hast, können wir in dem anderen Thread weiter machen :) .
Falls du irgendwas in Richtung Download aus dem svn gemacht hast: Bitte direkt nochmal, da hat sich ein kleines, aber wichtiges Detail geändert!
Ich habe jetzt folgende Schritte ausgeführt:
1. Die Datei /opt/fhem/FHEM/AttrTemplate gelöscht
2. Die Datei /opt/fhem/FHEM/AttrTemplate.pm wiederhergestellt (das Original ist wieder zurück)
Der Verzeichnisinhalt sind dann so aus:
$ ll /opt/fhem/FHEM/Attr*
-rw-r--r-- 1 fhem dialout 11772 Okt 31 15:51 /opt/fhem/FHEM/AttrTemplate.pm
3. Den Befehl { Svn_GetFile("FHEM/lib/AttrTemplate/general_use.template", "FHEM/lib/AttrTemplate/general_use.template") } ausgeführt
4. Den Befehl { Svn_GetFile("FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", "FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", sub(){ AttrTemplate_Initialize() }) } ausgeführt
Die Dateien befinden sich dann im Verzeichnis /opt/fhem/FHEM/lib/AttrTemplate/:
$ ll /opt/fhem/FHEM/lib/AttrTemplate/
insgesamt 448
-rw-r--r-- 1 fhem dialout 7780 Jan 22 16:37 general_use.template
-rw-r--r-- 1 fhem dialout 2333 Okt 4 08:01 hmccu.template
-rw-r--r-- 1 fhem dialout 70537 Jan 20 19:43 httpmod.template
-rw-r--r-- 1 fhem dialout 4953 Okt 4 08:01 huedevice.template
-rw-r--r-- 1 fhem dialout 4671 Okt 4 08:01 max.template
-rw-r--r-- 1 fhem dialout 302245 Jan 20 19:43 mqtt2.template
-rw-r--r-- 1 fhem dialout 6646 Jan 22 16:37 mqtt_generic_bridge.template
-rw-r--r-- 1 fhem dialout 5625 Okt 4 08:01 mysensors.template
-rw-r--r-- 1 fhem dialout 10478 Okt 4 08:01 speechcontrol.template
-rw-r--r-- 1 fhem dialout 24410 Nov 12 14:52 zwave.template
5. Den Befehl {AttrTemplate_Initialize()} ausgeführt
Im FHEM-Log stehen diese Einträge:
2021.01.22 16:37:00 1: SVN download of FHEM/lib/AttrTemplate/general_use.template to FHEM/lib/AttrTemplate/general_use.template finished
2021.01.22 16:37:49 1: SVN download of FHEM/lib/AttrTemplate/mqtt_generic_bridge.template to FHEM/lib/AttrTemplate/mqtt_generic_bridge.template finished
2021.01.22 16:37:50 2: AttrTemplates: got 218 entries
2021.01.22 16:41:41 2: AttrTemplates: got 218 entries
6. Den Befehl set mqttGenericBridge attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE ausgeführt
Ich erhalte (weiterhin) den Fehler in der WebUI:
Unknown template_entry_name base_settings_to_MQTT_GENERIC_BRIDGE
Hmm, seltsam. Eigentlich sollte sich die Zahl geändert haben, es müßten ein oder zwei mehr sein...
Das Device "
mqttGenericBridge" war ja definiert, als du den Initialize-Befehl abgesetzt hast, oder? (Sonst tut sich da nüscht und du musst das nochmal anschubsen).
Was sagt version MQTT_GENERIC_BRIDGE?
Ich bekomme da (u.A.):
Zitat10_MQTT_GENERIC_BRIDGE.pm 23561 2021-01-19 23:13:31Z hexenmeister
Ich habe keine Änderung an den Devices vorgenommen, d.h. das Device
define lb_mqtt_broker MQTT2_CLIENT <IP MQTT-Broker>:1883 und
define mqttGenericBridge MQTT_GENERIC_BRIDGE
existiert seit gestern unverändert.
Hier die Ausgabe von version MQTT_GENERIC_BRIDGE:
File Rev Last Change
10_MQTT_GENERIC_BRIDGE.pm 23561 2021-01-19 23:13:31Z hexenmeister
doif.js 15546 2017-12-03 09:57:42Z Ellert
fhemweb.js 23453 2021-01-01 18:10:12Z rudolfkoenig
Kann man den Befehl set mqttGenericBridge attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE debuggen?
Immer noch komisch. Anders gefragt: siehst du denn den Befehl attrTemplate in der Detailansicht von "mqttGenericBridge" und hast du eine dropdown-Liste mit diversen attrTemplate?
Wenn ja, mach' es bitte über diesen Weg.
EDIT: das sollte in etwa so aussehen wie auf dem screenshot...
Ich habe keine Dropdown-Liste.
OK, also die Datei ist da wo sie hin soll und sie hat die richtigen Rechte sowie (in etwa) die richtige Größe.
Da fällt mir grade nur noch die Windows-Methode ein: einmal (FHEM) neu starten, bitte...
Zitat von: Beta-User am 22 Januar 2021, 17:37:14
OK, also die Datei ist da wo sie hin soll und sie hat die richtigen Rechte sowie (in etwa) die richtige Größe.
Da fällt mir grade nur noch die Windows-Methode ein: einmal (FHEM) neu starten, bitte...
Weil ich den Service fhem bereits neu gestartet habe, habe ich jetzt einen Reboot des Servers (Raspi) ausgeführt.
In der WebUI gibt es allerdings immer noch kein Drop-down Menü.
Update:Das Dropdown-Menü ist jetzt verfügbar.
Damit sind alle Probleme im Zusammenhang mit MQTT2_CLIENT und MQTT_GENERIC_BRIDGE gelöst und ich stelle den Status dieses Threads auf "solved".