[solved] Fehler bei Installation der Perl-Pakete MQTT::Simple MQTT::Constants

[cmonty14]

Hallo,

ich möchte MQTT nutzen und möchte hierzu das Modul MQTT anlegen.
Gemäß Wiki-Artikel werden hierfür 2 Perl-Module benötigt:
MQTT::Simple
MQTT::Constants

Wenn ich versuche, diese Module zu installieren, dann erhalte ich diese Fehler:

Code Auswählen Erweitern

$ 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

Code Auswählen Erweitern

$ 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

[Beta-User]

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.

[Christoph Morrison]

Was Beta-User sagt. Schau aber auch mal ins Wiki zum Thema CPAN und verwende dann lieber cpanm.

[cmonty14]

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 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.

[rudolfkoenig]

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.

[cmonty14]

Was Beta-User sagt. Schau aber auch mal ins Wiki 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

[Beta-User]

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 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...

[rudolfkoenig]

@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

[Beta-User]

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.

[Beta-User]

@cmonty14:

Kannst du den Beitrag 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)
Und wir können das ganze Thema auch gerne in Bidirektionale Kommunikation FHEM-Loxone: was wird benötigt FHEM -> Loxone? vertiefen, aber bitte nicht die (im Prinzip unveränderte?) Frage über das ganze Forum verteilen...?

[cmonty14]

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 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

[cmonty14]

@cmonty14:

Kannst du den Beitrag 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)
Und wir können das ganze Thema auch gerne in Bidirektionale Kommunikation FHEM-Loxone: was wird benötigt FHEM -> Loxone? 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 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.

[Beta-User]

Die Syntax bei MQTT2_CLIENT ist etwas anders, wie du über help MQTT2_CLIENT auch gut in Erfahrung bringen kannst:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

{AttrTemplate_Initialize()}

Dann sollte folgendes gehen:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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...

[cmonty14]

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

Code Auswählen Erweitern

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?

[Beta-User]

Was ist das Äquivalent zu

Code Auswählen Erweitern

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):

Code Auswählen Erweitern

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.