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

Begonnen von cmonty14, 20 Januar 2021, 20:51:37

Vorheriges Thema - Nächstes Thema

cmonty14

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

cmonty14

#16
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 entries

Wenn ich dann
set mqttGenericBridge attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE
ausfü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?

Beta-User

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 >:( .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

cmonty14

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

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

Beta-User

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 :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

Falls du irgendwas in Richtung Download aus dem svn gemacht hast: Bitte direkt nochmal, da hat sich ein kleines, aber wichtiges Detail geändert!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

cmonty14

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

Beta-User

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.):
Zitat
10_MQTT_GENERIC_BRIDGE.pm 23561 2021-01-19 23:13:31Z hexenmeister
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

cmonty14

#23
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?

Beta-User

#24
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

cmonty14


Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

cmonty14

#27
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".