Guten Abend allerseits,
schon vor langer Zeit aus einer Idee geboren, entwickelt, gemeinsam diskutiert und getestet (https://forum.fhem.de/index.php/topic,81418.0.html) und jetzt endlich als ausreichend stabil zu bezeichnen.
Hier ist ein Modul, das die Integration von MQTT-Geräteschaften in FHEM vereinfacht (heute in das offizielle Verzeichnis übernommen, ab morgen per Update verfügbar).
Der Grundgedanke dabei ist auf die zusätzlichen MQTT-DEVICE/BRIDGE Module möglichst zu verzichten und die beliebigen FHEM-Geräte direkt um die MQTT-Fähigkeiten zu erweitern. Die GenericBridge muss nur einmal definiert werden, dabei bekommen andere Geräte ein paar zusätzlichen Attribute, mit deren Hilfe alle Readings des jeweiligen Gerätes per MQTT versendet bzw. vom MQTT-Server gespeist werden können.
Hier ist die Beschreibung aus dem Commandref incl. ein Paar Beispiele:
MQTT_GENERIC_BRIDGE
Dieses Modul ist eine MQTT-Bridge, die gleichzeitig mehrere FHEM-Devices erfasst und deren Readings per MQTT weiter gibt bzw. aus den eintreffenden MQTT-Nachrichten befuellt oder diese als 'set'-Befehl an dem konfigurierten FHEM-Geraet ausfuert.
Es wird ein MQTT-Geraet als IODev benoetigt.
Die (minimale) Konfiguration der Bridge selbst ist grundsaetzlich sehr einfach.
Definition:
Im einfachsten Fall reichen schon zwei Zeilen:
defmod mqttGeneric MQTT_GENERIC_BRIDGE [prefix] [devspec]
attr mqttGeneric IODev
Alle Parameter im Define sind optional.
Der erste ist ein Prefix fuer die Steuerattribute, worueber die zu ueberwachende Geraete (s.u.) konfiguriert werden. Defaultwert ist 'mqtt'. Wird dieser z.B. als 'hugo' redefiniert, heissen die Steuerungsattribute entsprechend hugoPublish etc.
Der zweite Parameter ('devspec') erlaubt die Menge der zu ueberwachenden Geraeten zu begrenzen (sonst werden einfach alle ueberwacht, was jedoch Performance kosten kann). s.a. devspec
get:
- version
Zeigt Modulversion an.
- devlist [<name (regex)>]
Liefert Liste der Namen der von dieser Bridge ueberwachten Geraete deren Namen zu dem optionalen regulaerem Ausdruck entsprechen. Fehlt der Ausdruck, werden alle Geraete aufgelistet.
- devinfo [<name (regex)>]
Gibt eine Liste der ueberwachten Geraete aus, deren Namen zu dem optionalen regulaerem Ausdruck entsprechen. Fehlt der Ausdruck, werden alle Geraete aufgelistet. Zusätzlich werden bei 'publish' und 'subscribe' verwendete Topics angezeigt incl. der entsprechenden Readinsnamen.
readings:
- device-count
Anzahl der ueberwachten Geraete
- incoming-count
Anzahl eingehenden Nachrichten
- outgoing-count
Anzahl ausgehende Nachrichten
- updated-reading-count
Anzahl der gesetzten Readings
- updated-set-count
Anzahl der abgesetzten 'set' Befehle
- transmission-state
letze Uebertragunsart
Attribute:
folgende Attribute werden unterstuetzt:
- IODev
Dieses Attribut ist obligatorisch und muss den Namen einer funktionierenden MQTT-Modulinstanz enthalten. Modul MQTT2_SERVER wird nicht unterstuetzt.
- disable
Wert 1 deaktiviert die Bridge
Beispiel:
attr <dev> disable 1
- globalDefaults
Definiert Defaults. Diese greifen in dem Fall, wenn in dem jeweiligen Geraet definierte Werte nicht zutreffen. s.a. mqttDefaults.
- globalAlias
Definiert Alias. Diese greifen in dem Fall, wenn in dem jeweiligen Geraet definierte Werte nicht zutreffen. s.a. mqttAlias.
- globalPublish
Definiert Topics/Flags fuer die Uebertragung per MQTT. Diese werden angewendet, falls in dem jeweiligen Geraet definierte Werte nicht greifen oder nicht vorhanden sind. s.a. mqttPublish.
Fuer die ueberwachten Geraete wird eine Liste der moeglichen Attribute automatisch um mehrere weitere Eintraege ergaenzt. Sie fangen alle mit vorher in der Bridge definiertem Prefix an. Ueber diese Attribute wird die eigentliche MQTT-Anbindung konfiguriert.
Defaultmaessig werden folgende Attributnamen verwendet: mqttDefaults, mqttAlias, mqttPublish, mqttSubscribe.
Die Bedeutung dieser Attribute wird im Folgenden erklaert.
- mqttDefaults
Hier wird eine Liste der "key=value"-Paare erwartet. Folgende Keys sind dabei moeglich:
-- 'qos'
definiert ein Defaultwert fuer MQTT-Paramter 'Quality of Service'.
-- 'retain'
erlaubt MQTT-Nachrichten als 'retained messages' zu markieren.
-- 'base'
wird als Variable ($base) bei der Konfiguration von konkreten Topics zur Verfuegung gestellt. Sie kann entweder Text oder eine Perl-Expression enthalten. Perl-Expression muss in geschweifte Klammern eingeschlossen werden. In einer Expression koennen folgende Variablen verwendet werden: $reading = Original-Readingname, $device = Devicename und $name = Readingalias (s. mqttAlias. Ist kein Alias definiert, ist $name=$reading).
Alle diese Werte koennen durch vorangestelle Prefixe ('pub:' oder 'sub') in ihrer Gueltigkeit auf nur Senden bzw. nur Empfangen begrenzt werden (soweit sinnvoll). Werte fuer 'qos' und 'retain' werden nur verwendet, wenn keine explizite Angaben darueber fuer ein konkretes Topic gemacht worden sind.
Beispiel:
attr <dev> mqttDefaults base={"/TEST/$device"} pub:qos=0 sub:qos=2 retain=0
- mqttAlias
Dieses Attribut ermoeglicht Readings unter einem anderen Namen auf MQTT-Topic zu mappen. Eigentlich nur sinnvoll, wenn Topicdefinitionen Perl-Expressions mit entsprechenden Variablen sind. Auch hier werden 'pub:' und 'sub:' Prefixe unterstuetzt (fuer 'subscribe' gilt das Mapping quasi umgekehrt).
Alias fuer subscribe ist derzeit nicht implementiert!
Beispiel:
attr <dev> mqttAlias pub:temperature=temp
- mqttPublish
Hier werden konkrette Topics definiet und den Readings zugeordnet (Format: <reading>:topic=<topic>). Weiterhin koennen diese einzeln mit 'qos'- und 'retain'-Flags versehen werden.
Topics koennen auch als Perl-Expression mit Variablen definiert werden ($reading, $device, $name, $base).
Werte fuer mehrere Readings koennen auch gemeinsam gleichzeitig definiert werden, indem sie, mittels '|' getrennt, zusammen angegeben werden.
Wird anstatt eines Readingsnamen ein '*' verwendet, gilt diese Definition fuer alle Readings, fuer die keine explizite Angaben gemacht wurden.
Es koennen auch Expressions (reading:expression=...) definiert werden.
Die Expressions koenne sinnvollerweise entweder Variablen ($value, $topic, $qos, $retain, $message) veraendern, oder einen Wert != undef zurrueckgeben.
Der Rueckhgabe wert wird als neue Nachricht-Value verwendet, die Aenderung der Variablen hat dabei jedoch Vorrang.
Ist der Rueckgabewert undef, dann wird das Setzen/Ausfuehren unterbunden.
Ist die Rueckgabe ein Hash (nur 'topic' und 'stopic'), werden seine Schluesselwerte als Topic verwendet, die Inhalte der Nachrichten sind entsprechend die Werte aus dem Hash.
Option 'resendOnConnect' erlaubt eine Speicherung der Nachrichten, wenn keine Verbindung zu dem MQTT-Server besteht. Die zu sendende Nachrichten in einer Warteschlange gespeichet. Wird die Verbindung aufgebaut, werden die Nachrichten in der ursprungichen Reihenfolge verschickt.
Moegliche Werte:
none - alle verwerfen
last - immer nur die letzte Nachricht speichern
first - immer nur die erste Nachricht speichern danach folgende verwerfen
all - alle speichern, allerdings existiert eine Obergrenze von 100, wird es mehr, werden aelteste ueberzaelige Nachrichten verworfen.
Beispiele:
attr <dev> mqttPublish temperature:topic={"$base/$name"} temperature:qos=1 temperature:retain=0 *:topic={"$base/$name"} humidity:topic=/TEST/Feuchte
attr <dev> mqttPublish temperature|humidity:topic={"$base/$name"} temperature|humidity:qos=1 temperature|humidity:retain=0
attr <dev> mqttPublish *:topic={"$base/$name"} *:qos=2 *:retain=0
attr <dev> mqttPublish *:topic={"$base/$name"} reading:expression={"message: $value"}
attr <dev> mqttPublish *:topic={"$base/$name"} reading:expression={$value="message: $value"}
attr <dev> mqttPublish *:topic={"$base/$name"} reading:expression={"/TEST/Topic1"=>"$message", "/TEST/Topic2"=>"message: $message"}
- mqttSubscribe
Dieses Attribut konfiguriert das Empfangen der MQTT-Nachrichten und die entsprechenden Reaktionen darauf.
Die Konfiguration ist aehnlich der fuer das 'mqttPublish'-Attribut. Es koennen Topics fuer das Setzen von Readings ('topic') und Aufrufe von 'set'-Befehl an dem Geraet ('stopic') definiert werden.
Mit Hilfe von zusaetzlichen auszufuehrenden Perl-Expressions ('expression') kann das Ergebnis vor dem Setzen/Ausfueren noch beeinflusst werden.
In der Expression sind folgende Variablen verfügbar: $device, $reading, $message (initial gleich $value). Die Expression kann dabei entweder Variable $value veraendern, oder einen Wert != undef zurueckgeben. Redefinition der Variable hat Vorrang. Ist der Rueckgabewert undef, dann wird das Setzen/Ausfuehren unterbunden (es sei denn, $value hat einen neuen Wert).
Ist die Rueckgabe ein Hash (nur fuer 'topic' und 'stopic'), dann werden seine Schluesselwerte als Readingsnamen bzw. 'set'-Parameter verwendet, die zu setzenden Werte sind entsprechend die Werte aus dem Hash.
Weiterhin kann das Attribut 'qos' angegeben werden ('retain' macht dagegen keinen Sinn).
In der Topic-Definition koennen MQTT-Wildcards (+ und #) verwendet werden.
Falls der Reading-Name mit einem '*'-Zeichen am Anfang definiert wird, gilt dieser als 'Platzhalter'. Der tatsaechliche Name der Reading (und ggf. des Geraetes) wird dabei durch Variablen aus dem Topic definiert ($device (nur fuer globale Definition in der Bridge), $reading, $name). Im Topic wirken diese Variablen als Wildcards, macht natuerlich nur Sinn, wenn Reading-Name auch nicht fest definiert ist (also faengt mit '*' an).
Die Variable $name wird im Unterschied zu $reading ggf. ueber die in 'mqttAlias' definierten Aliases beeinflusst. Auch Verwendung von $base ist erlaubt.
Bei Verwendung von 'stopic' wird das 'set'-Befehl als 'set <dev> <reading> <value>' ausgefuert. Fuer ein 'set <dev> <value>' soll als Reading-Name 'state' verwendet werden.
Beispiele:
attr <dev> mqttSubscribe temperature:topic=/TEST/temperature test:qos=0 *:topic={"/TEST/$reading/value"}
attr <dev> mqttSubscribe desired-temperature:stopic={"/TEST/temperature/set"}
attr <dev> mqttSubscribe state:stopic={"/TEST/light/set"} state:expression={...}
attr <dev> mqttSubscribe state:stopic={"/TEST/light/set"} state:expression={$value="x"}
attr <dev> mqttSubscribe state:stopic={"/TEST/light/set"} state:expression={"R1"=>$value, "R2"=>"Val: $value", "R3"=>"x"}
- mqttDisable
Wird dieses Attribut in einem Geraet gesetzt, wird dieses Geraet vom Versand bzw. Empfang der Readingswerten ausgeschlossen.
Beispiele:
Bridge fuer alle moeglichen Geraete mit dem Standardprefix:
defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev mqtt
Bridge mit dem Prefix 'mqtt' fuer drei bestimmte Geraete:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt sensor1,sensor2,sensor3
attr mqttGeneric IODev mqtt
Bridge fuer alle Geraete in einem bestimmten Raum:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=Wohnzimmer
attr mqttGeneric IODev mqtt
Einfachste Konfiguration eines Temperatursensors:
defmod sensor XXX
attr sensor mqttPublish temperature:topic=/haus/sensor/temperature
Alle Readings eines Sensors (mit ihren Namen wie sie sind) per MQTT versenden:
defmod sensor XXX
attr sensor mqttPublish *:topic={"/sensor/$reading"}
Topicsdefinition mit Auslagerung von dem gemeinsamen Teilnamen in 'base'-Variable:
defmod sensor XXX
attr sensor mqttDefaults base={"/$device/$reading"}
attr sensor mqttPublish *:topic={$base}
Topicsdefinition nur fuer bestimmte Readings mit deren gleichzeitigen Umbennenung (Alias):
defmod sensor XXX
attr sensor mqttAlias temperature=temp humidity=hum
attr sensor mqttDefaults base={"/$device/$name"}
attr sensor mqttPublish temperature:topic={$base} humidity:topic={$base}
Beispiel fuer eine zentralle Konfiguration in der Bridge fuer alle Devices, die Reading 'temperature' besitzen:
defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev mqtt
attr mqttGeneric defaults sub:qos=2 pub:qos=0 retain=0
attr mqttGeneric publish temperature:topic={"/haus/$device/$reading"}
Beispiel fuer eine zentralle Konfiguration in der Bridge fuer alle Devices
(wegen einer schlechten Übersicht und einer unnoetig grossen Menge eher nicht zu empfehlen):
defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev mqtt
attr mqttGeneric defaults sub:qos=2 pub:qos=0 retain=0
attr mqttGeneric publish *:topic={"/haus/$device/$reading"}
Beispiel für Zerlegung einer JSON-Kodierten Nachricht in EInzelreadings.
Sendet man jetzt z.B. folgende JSON: {"jtest1":"jval1","jtest2":"jval2"} dann werden zwei Readings (jtest1 und jtest2) entsprechend angelegt/aktualisiert.
xyz:topic=/TEST/json xyz:expression={json2nameValue($message)}
Einschraenkungen:
- Wenn mehrere Readings das selbe Topic abonieren, sind dabei keine unterschiedlichen QOS moeglich.
- Wird in so einem Fall QOS ungleich 0 benoetigt, sollte dieser entweder fuer alle Readings gleich einzeln definiert werden, oder allgemeinguetltig ueber Defaults. Ansonsten wird beim Erstellen von Abonements der erst gefundene Wert verwendet.
- Abonements werden nur erneuert, wenn sich das Topic aendert, QOS-Flag-Aenderung alleine wirkt sich daher erst nach einem Neustart aus.
- Nicht kompatibel mit neuen Modulen MQTT2_SERVER / MQTT2_DEVICE (Schleife über MQTT2_SERVER->MQTT->MQTT_GENERIC_BRIDGE ist vermutlich möglich, jedoch nicht sinnvoll, da ineffizient)
Danke :)
(zum mitlesen)
Zitat von: hexenmeister am 31 August 2018, 20:53:56
Der Grundgedanke dabei ist auf die zusätzlichen MQTT-DEVICE/BRIDGE Module möglichst zu verzichten und die beliebigen FHEM-Geräte direkt um die MQTT-Fähigkeiten zu erweitern.
Vielen Dank für Deine Mühe.
ZitatLimitations:
If several readings subscribe to the same topic, no different QOS are possible.
If QOS is not equal to 0, it should either be defined individually for all readings, or generally over defaults.
Otherwise, the first found value is used when creating a subscription.
Subscriptions are renewed only when the topic is changed, so changing the QOS flag onnly will only work after a restart of FHEM.
Habe ich richtig verstanden, dass die bisherigen MQTT-DEVICE/BRIDGE Module diese Einschränkung nicht haben?
Gruß Billy
Eher doch. Bei dem Nr. 1. bin ich mir nicht sicher, dass es dort funktioniert, die 2. ist keine wirkliche Einshränkung, muss man ggf. nur beachten, ist jedoch spezifisch für GenericBridge. Die 3. gilt für alte Module meines Wissens genauso.
Hatte ich schon fast vermutet, dass die Einschränkung auch für die alten Module gilt.
Die Frage ist nun: Braucht man die alten Module noch, oder ist mit deiner Weiterentwicklung alles erschlagen?
Billy
Die Frage kann nur jeder für sich beantworten ;D
Das neue Modul macht praktisch dsas gleiche, nur anders (und aus meiner sicht etwas einfacher und bequemer).
Zitat von: hexenmeister am 01 September 2018, 12:05:47
Das neue Modul macht praktisch das gleiche, nur anders (und aus meiner sicht etwas einfacher und bequemer).
Das deckt sich mit meinen Erfahrungen mit Deinem Modul. :)
Ich wollte das von dir als Fachmann bestätigt haben damit es Neueinsteiger einfacher haben.
Hilfreich wäre in der Commandref der Satz: dieses Modul vereinigt die Funktionalität der
Mqtt-Device und Mqtt-Bridge Module.
Billy
Danke für die Idee, trage ich nach. :)
Hey,
danke für das Modul.
Leider habe ich einen Bug entdeckt.
Das Modul scheint ein Problem mit ":" im Publish-Payload zu haben.
Ich habe ein "at" für einen Wecker. Da wollte ich das Reading "state" publishen. Im Falle von "inactive" klappt das auch. Im Fall von "Next: 08:15" nicht.
Durch das Attribut:
*:topic={"zuHause/System/Wecker/$reading"}
habe ich in MQTT.fx rausgefunden, dass in Falle von "Next: 08:15" das Topic "Next" ist und nicht wie erwartet "state".
Genauso verhält es sich mit einem Dummy, der eine Zeit für die Laufzeit des Weckers beinhaltet.
Wenn ich den Dummy auf "Test" setze, kommt das ganze mit dem (End-)Topic "state" an. Besitzt der Dummy aber den Wert "02:10:00" heisst das Topic "02" und der Payload ist nur noch ":10:00".
Das gleiche Verhalten scheint bei der MQTT-Bridge vorzuliegen.
Kann man da was gegen tun?
Viele Grüße,
Ingo
Ich konnte den Fehler nachstellen. Versuche in den nächsten Tage die Ursache finden.
Teste mal bitte die angehängte Version
Hallo Hexenmeister,
mit der Version die Heute im Update verteilt wird werden die readings beim Subscript nicht mehr aktualisiert.
Nach dem einspielen der vorherigen Version Funktioniert es wieder Problemlos.
Anbei eine Beispiel Geräte Definition.
Internals:
NAME WS_Buero
NR 385
STATE T: 22.66° H: 50%<br>P: 990.46
TYPE dummy
Helper:
DBLOG:
battery:
NAS1DB:
TIME 1535975734.04262
VALUE 2.977
humidity:
NAS1DB:
TIME 1535975720.86372
VALUE 50
pressure:
NAS1DB:
TIME 1535975734.08432
VALUE 990.46
temperature:
NAS1DB:
TIME 1535975720.82657
VALUE 22.66
READINGS:
2018-09-03 13:55:34 battery 2.977
2018-09-03 13:55:34 humidity 50
2018-09-03 13:55:34 pressure 990.46
2018-09-03 13:55:33 temperature 22.66
Attributes:
DbLogExclude state
event-on-change-reading .*
genericDeviceType thermometer
icon temperature_humidity
mqttSubscribe *:topic={"Home/Ruuvi/Buero/$reading"}
room Büro
stateFormat T: temperature° H: humidity%<br>P: pressure
Gruß,
Peter
Hey,
Zitat von: hexenmeister am 02 September 2018, 23:17:31
Teste mal bitte die angehängte Version
Damit funktioniert's, danke!
Viele Grüße,
Ingo
Zitat von: kpl am 03 September 2018, 14:08:16
mit der Version die Heute im Update verteilt wird werden die readings beim Subscript nicht mehr aktualisiert.
Gesucht->gefunden-gefixt->eingecheckt ;)
Habe einen Bug zu berichten?
Habe auf meinem Testsytem die neue Version von gestern eingespielt
$Id: 10_MQTT_GENERIC_BRIDGE.pm 17262 2018-09-03 20:06:15Z hexenmeister $
und folgendes festgestellt:
Sobald ich nach dem : define mqttGeneric MQTT_GENERIC_BRIDGE
das Attribut für IODev setzte stürzt FHEM ab! :-\
Mit der alten Version $Id: 10_MQTT_GENERIC_BRIDGE.pm 17241 2018-08-31 16:37:38Z hexenmeister $
ist das nicht der Fall.
Gruß Billy
Zitat von: Billy am 04 September 2018, 20:53:35
Habe einen Bug zu berichten?
Ja. Danke fürs Testen!
Nach dem Update sollte weg sein :)
Mit der neuen Version habe ich auch Probleme!
FHEM stürzt zwar nicht mehr ab, aber schalten geht nicht mehr.
Habe ein Dummy als Schalter definiert.
define sonoff_8 dummy
attr sonoff_8 eventMap ON:on OFF:off
attr sonoff_8 mqttPublish *:topic=cmnd/sonoff_8/POWER1
attr sonoff_8 webCmd on:off
Mit der alten Version schaltet der Sonoff problemlos,
mit der neuen Version $Id: 10_MQTT_GENERIC_BRIDGE.pm 17274 2018-09-04 20:26:40Z hexenmeister $
geht nichts. Oder habe ich was falsch verstanden?
Gruß Billy
Sonoff habe ich nicht, kann ich nicht direkt ausprobieren. Dein Beispielcode senden jedoch brav Werte, die ich in mqtt-spy sehen kann (on und off). Was ist jedoch nicht verstehe, ist Dein eventMap Attribut. So tut er gar nichts. Wenn sonoff die ON / OFF inb Großbuchtaben erwatet, dann könnte das die Erklärung sein. In diesem Fall müssen die Angaben "ungedreht" werden.
Probiere mit einem Client wie mqtt-spy, mqtt-fx etc. nachzusehen, ob was wirklich gesendet wird.
Zitat von: hexenmeister am 05 September 2018, 16:42:59
Probiere mit einem Client wie mqtt-spy, mqtt-fx etc. nachzusehen, ob was wirklich gesendet wird.
Ich teste generell alles mit mqtt-spy!
Fakt ist, dass mit dieser Konfiguration
Internals:
NAME sonoff_8
NR 126
STATE off
TYPE dummy
READINGS:
2018-09-05 17:15:47 Licht OFF
2018-09-05 17:18:18 state ON
Attributes:
disable 0
eventMap ON:on OFF:off
icon hue_filled_br30
mqttPublish state:topic=cmnd/sonoff_8/POWER1
mqttSubscribe Licht:stopic=stat/sonoff_8/POWER
readingList Licht
room MQTT
stateFormat Licht
webCmd :mit der Version --> $Id: 10_MQTT_GENERIC_BRIDGE.pm 17241 2018-08-31 16:37:38Z hexenmeister $
alles funktioniert (publish + subscribe) die topics in mqtt-spy erscheinen,
mit der Version $Id: 10_MQTT_GENERIC_BRIDGE.pm 17274 2018-09-04 20:26:40Z hexenmeister $ geht nichts, d.h. weder publish noch subscribe.
Ich sehe also vom publish nichts in mqtt-spy
und vom subscribe kommt im Dummy auch nichts an. :-\
Das ist seltsam, da es ja bei Dir geht.
d.h. sobald ich $Id: 10_MQTT_GENERIC_BRIDGE.pm 17274 2018-09-04 20:26:40Z hexenmeister $ aktiviere natürlich shutdown restart
gibt es keine Reaktion mehr. Ich habe das mehrfach getestet.
Sorry: der subscribe Pfad geht!
Im Event Monitor sieht das so aus!
Einschalten mit altem Modul
2018-09-05 18:11:48 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-09-05 18:11:48 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 30
2018-09-05 18:11:48 dummy sonoff_8 on
2018-09-05 18:11:48 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2018-09-05 18:11:48 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 82
2018-09-05 18:11:48 dummy sonoff_8 Licht: on
2018-09-05 18:11:48 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 82
Ausschalten mit altem Modul
2018-09-05 18:11:56 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-09-05 18:11:56 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 31
2018-09-05 18:11:56 dummy sonoff_8 off
2018-09-05 18:11:56 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2018-09-05 18:11:56 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 83
2018-09-05 18:11:56 dummy sonoff_8 Licht: off
2018-09-05 18:11:56 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 83
2018-09-05 18:11:57 MQTT Broker_BB17 connection: active
#############################################################################################################
Einschalten mit neuem Modul
2018-09-05 18:16:52 dummy sonoff_8 on
d.h. keine Reaktion der Bridge?
Ausschalten mit altem Modul
2018-09-05 18:16:54 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-09-05 18:16:54 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 34
2018-09-05 18:16:54 dummy sonoff_8 off
2018-09-05 18:16:55 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2018-09-05 18:16:55 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 88
2018-09-05 18:16:55 dummy sonoff_8 Licht: off
2018-09-05 18:16:55 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 88
Die Frage ist warum geht alt oder habe ich da eine Bug eingebaut den die alte Version schluckt? :-[
Ein guter Beispiel, warum man den Konfig komplett angeben sollte. Ohne stateFormat (wie Du zuerst beschrieben hast) funktioniert das. Warum das mit nicht geht (eher warum das früher damit ging) - das muss ich noch anschauen.
Noch was ist mir aufgefallen!
Ist es eigentlich erwünscht, dass alle der MQTT_GENERIC_BRIDGE zugeordneten Devices im attr global userattr auftauchen?
attr global userattr T5,T7,Schalter_1BEA79,Brunnen_20C4F6,BM_1A8215,HM_69F161,HM_69F136Alias:textField-long T5,T7,Schalter_1BEA79,Brunnen_20C4F6,BM_1A8215,HM_6 usw.
Teilweise mehrfach? :-\
Gruß Billy
Nein, sollte eigentlich so nicht sein.
Wie ist die Gridge definiert?
Ich weiß mittlerweile warum das mit dem state nicht geht, nur leider keine Lösung. Es ist nicht ohne weiteren in einer Notify-Routine ersichtlich, welche reading sich geändert hat. Normalerweise bekommt man READINGNAME:VALUE. Aber nicht bei state. Dort kommt nur VALUE. In der alten Version habe ich auf den Doppelpunkt geprüft. Das funktioniert aber nicht, wenn in dem Wert ein Doppelpunkt drin ist. Habe noch keine Lösung :/
Da gibt es doch was... :)
Zitat von: hexenmeister am 05 September 2018, 22:12:26
Nein, sollte eigentlich so nicht sein.
Wie ist die Bridge definiert?
So,
define mqttGeneric MQTT_GENERIC_BRIDGE T5,T7,Schalter_1BEA79,Brunnen_20C4F6,BM_1A8215,HM_69F161,HM_69F136
attr mqttGeneric IODev Broker_BB17
attr mqttGeneric room MQTT
Natürlich haben schon Tausende vor mir so ein Problem gahabt und natürlich gibt es bereits eine Lösung ;D
Das 'Schaltproblem' checke ich gleich ein, die global-Sache schaue ich mir morgen an.
Danke, gute Nacht
Seit dem update auf die neue Version schaltet bei mir nichts mehr
Internals:
DEF 192.168.178.47
DeviceName 192.168.178.47:55443
FD 14
HOST 192.168.178.47
ID 192.168.178.47
NAME Yeelight_i
NOTIFYDEV global
NR 67
NTFY_ORDER 50-Yeelight_i
PARTIAL
PORT 55443
PROTO 1
STATE opened
TYPE YeeLight
READINGS:
2018-09-06 09:27:42 bright 54
2018-09-06 09:27:42 color_flow off
2018-09-06 09:27:42 color_mode RGB
2018-09-06 09:27:42 ct 4000
2018-09-06 09:27:42 flow_params
2018-09-06 09:27:42 hue 138
2018-09-06 09:27:42 music_mode off
2018-09-06 09:27:42 name
2018-09-06 09:28:19 power off
2018-09-06 09:27:42 rgb ff0000
2018-09-06 09:27:42 rgb_blue 0
2018-09-06 09:27:42 rgb_green 0
2018-09-06 09:27:42 rgb_red 255
2018-09-06 09:27:42 sat 100
2018-09-06 09:27:42 sleeptimer 0
2018-09-06 09:27:31 state opened
helper:
CommandSet on off toggle on-for-timer off-for-timer intervals bright dimup dimdown name default:noArg reopen:noArg statusrequest:noArg hsv hue sat rgb color ct start_cf stop_cf scene circlecolor:noArg blink
AnsQue:
{"id":1, "result":["off","54","4000","16711680","138","100","1","0","0","","0",""]}
ErrQue:
SendQue:
Attributes:
devStateIcon {my $power=ReadingsVal($name,"power","off");my $mode=ReadingsVal($name,"color_mode","RGB");if($power eq "off"){Color::devStateIcon($name,"rgb","rgb","power");}else{if($mode eq "RGB"){Color::devStateIcon($name,"rgb","rgb","bright");}elsif($mode eq "color temperature"){Color::devStateIcon($name,"rgb",undef,"bright");}}}
event-on-change-reading .*
mqttDefaults base={"Smarthome/licht/$device/$reading"}
mqttPublish *:topic={$base}
mqttSubscribe state:stopic=Smarthome/licht/Yeelight_i/set bright:stopic=Smarthome/licht/Yeelight_i/bright hue:stopic=Smarthome/licht/Yeelight_i/hue rgb:stopic=Smarthome/licht/Yeelight_i/rgb
room Licht,YeeLight
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
webCmd rgb:bright:ct:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
widgetOverride bright:colorpicker,BRI,0,1,100 ct:colorpicker,CT,1700,10,6500 rgb:colorpicker,RGB
internals:
.eventMapCmd on:noArg off:noArg
IODev Mosquito
NAME mqtt_device_ilicht
NR 766
STATE 33
TYPE MQTT_DEVICE
retain *:1
.attraggr:
.attrminint:
.qos:
* 0
.retain:
* 1
READINGS:
2018-09-06 09:27:50 bright 54
2018-07-26 21:40:33 ct 4930
2018-09-06 09:27:50 hue 138
2018-07-26 21:53:33 level 33
2018-09-06 09:23:03 power off
2018-09-06 09:27:50 rgb ff0000
2018-09-06 09:29:34 state on
2018-07-25 17:46:39 switch off
2018-09-06 09:29:34 transmission-state outgoing publish sent
message_ids:
publishSets:
:
topic Smarthome/licht/Yeelight_i/set
values:
on
off
bright:
topic Smarthome/licht/Yeelight_i/bright
values:
bright:slider,0,1,100
hsv:
topic Smarthome/licht/Yeelight_i/hsv
values:
hue:
topic Smarthome/licht/Yeelight_i/hue
values:
rgb:
topic Smarthome/licht/Yeelight_i/rgb
values:
sets:
bright bright:slider,0,1,100
hsv
hue
off
on
rgb
subscribe:
Smarthome/licht/Yeelight_i/bright
Smarthome/licht/Yeelight_i/ct
Smarthome/licht/Yeelight_i/hsv
Smarthome/licht/Yeelight_i/hue
Smarthome/licht/Yeelight_i/power
Smarthome/licht/Yeelight_i/rgb
Smarthome/licht/Yeelight_i/state
subscribeExpr:
^Smarthome\/licht\/Yeelight_i\/bright$
^Smarthome\/licht\/Yeelight_i\/ct$
^Smarthome\/licht\/Yeelight_i\/hsv$
^Smarthome\/licht\/Yeelight_i\/hue$
^Smarthome\/licht\/Yeelight_i\/power$
^Smarthome\/licht\/Yeelight_i\/rgb$
^Smarthome\/licht\/Yeelight_i\/state$
subscribeQos:
Smarthome/licht/Yeelight_i/bright 0
Smarthome/licht/Yeelight_i/ct 0
Smarthome/licht/Yeelight_i/hsv 0
Smarthome/licht/Yeelight_i/hue 0
Smarthome/licht/Yeelight_i/power 0
Smarthome/licht/Yeelight_i/rgb 0
Smarthome/licht/Yeelight_i/state 0
subscribeReadings:
Smarthome/licht/Yeelight_i/bright:
cmd
name bright
Smarthome/licht/Yeelight_i/ct:
cmd
name ct
Smarthome/licht/Yeelight_i/hsv:
cmd
name hsv
Smarthome/licht/Yeelight_i/hue:
cmd
name hue
Smarthome/licht/Yeelight_i/power:
cmd
name power
Smarthome/licht/Yeelight_i/rgb:
cmd
name rgb
Smarthome/licht/Yeelight_i/state:
cmd
name state
Attributes:
DbLogExclude .*
IODev Mosquito
eventMap on:on off:off
icon mqtt
publishSet on off Smarthome/licht/Yeelight_i/set
publishSet_bright bright:slider,0,1,100 Smarthome/licht/Yeelight_i/bright
publishSet_hsv Smarthome/licht/Yeelight_i/hsv
publishSet_hue Smarthome/licht/Yeelight_i/hue
publishSet_rgb Smarthome/licht/Yeelight_i/rgb
retain 1
room Mqtt
stateFormat level
subscribeReading_bright Smarthome/licht/Yeelight_i/bright
subscribeReading_ct Smarthome/licht/Yeelight_i/ct
subscribeReading_hsv Smarthome/licht/Yeelight_i/hsv
subscribeReading_hue Smarthome/licht/Yeelight_i/hue
subscribeReading_power Smarthome/licht/Yeelight_i/power
subscribeReading_rgb Smarthome/licht/Yeelight_i/rgb
subscribeReading_state Smarthome/licht/Yeelight_i/state
webCmd rgb:bright:ct:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
widgetOverride bright:colorpicker,BRI,0,1,100 ct:colorpicker,CT,1700,10,6500 rgb:colorpicker,RGB
Wenn ich die alte von Ende Juni zurückspiele funktioniert es wieder
Ines
Zitat von: inesa394 am 06 September 2018, 09:39:40
Seit dem update auf die neue Version schaltet bei mir nichts mehr
zurückspiele funktioniert es wieder
Ines
Muß ich leider bestätigen, also liegt es nicht nur an meiner Konfiguration. ;)
Übrigens habe ich nicht nur den Nebeneffekt dass die attr global userattr befüllt werden,
in meinem Hauptsystem werden die Helligkeitswerte nicht mehr ge-published mit dem Effekt dass meine Rolladen gestern abend nicht geschlossen wurden.
Werde jetzt mal zuerst wieder im Hauptsystem auf 10_MQTT_BRIDGE.pm zurückgehen, bis 10_MQTT_GENERIC_BRIDGE.pm auf dem Testsystem stabil läuft.
Billy
@Ines
Bitte Version der Bridge angeben und auch die entsprechende Konfig.
Ich verstehe nicht ganz, was die zweite Listing damit zu tun hat. Ist doch ein MQTT_DEVICE?
@Billy
Es funktionier also auch mit der Version aus heutigem Update auch nicht? Wie sieht die Konfiguration für deine Helligkeitswerte aus?
Zitat von: hexenmeister am 06 September 2018, 10:54:32
@Billy
Es funktionier also auch mit der Version aus heutigem Update auch nicht? Wie sieht die Konfiguration für deine Helligkeitswerte aus?
Nein, es funktioniert mit der Version aus heutigem Update nicht!
Ich hatte einfach die Bridge auf meinem Produktiv System mit einem Homematic Motion/Helligkeitssensor verbunden und
diese attr aktiviert
attr BM_1A8215 mqttDefaults base={"/$device/$name"}
attr BM_1A8215 mqttPublish attr sensor mqttPublish brightness:topic={$base} motion:topic={$base}Die Werte wurden dann bis zum gestrigen update auch gesendet.
Habe jetzt aber die MQTT_GENERIC_BRIDGE auf meinem Produktivstem gelöscht, mein attr global userattr bereinigt und die
10_MQTT_BRIDGE.pm wieder aktiviert. Jetzt sendet der Sensor wieder Helligkeits und Motion Werte über Mqtt an den Brooker.
Billy
Das ist meine Bridge
Internals:
DEF TYPE=TASMOTA_DEVICE,TYPE=XiaomiSmartHome,TYPE=XiaomiSmartHome_Device,TYPE=YeeLight,TYPE=dummy,TYPE=MilightDevice,TYPE=MilightBridge,TYPE=WifiLight
IODev mqtt
NAME mqttGeneric
NR 179
NTFY_ORDER 50-mqttGeneric
STATE outgoing publish sent
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix TYPE=TASMOTA_DEVICE,TYPE=XiaomiSmartHome,TYPE=XiaomiSmartHome_Device,TYPE=YeeLight,TYPE=dummy,TYPE=MilightDevice,TYPE=MilightBridge,TYPE=WifiLight
READINGS:
2018-09-06 09:27:42 device-count 0
2018-09-06 09:27:39 incoming-count 0
2018-09-06 09:27:39 outgoing-count 0
2018-09-06 09:26:59 transmission-state outgoing publish sent
2018-09-06 09:27:39 updated-reading-count 0
2018-09-06 09:27:39 updated-set-count 0
devices:
globalDeviceExcludes:
globalReadingExcludes:
globalTypeExcludes:
FHEMWEB *
Global *
MQTT transmission-state
MQTT_BRIDGE transmission-state
MQTT_DEVICE transmission-state
MQTT_GENERIC_BRIDGE *
telnet *
message_ids:
subscribe:
subscribeExpr:
subscribeQos:
Attributes:
IODev mqtt
icon mqtt
room MQTT
stateFormat transmission-state
version 0.9.5
Dann hab ich wohl die funktionweise deines Moduls falsch interpretiert. Wollte über mein lokales lan
like fhem2fhem mein licht schalten mit hilfe deiner Bridge. Dazu habe ich dieses mqtt-device auf meinen
entfernten fhem Server definiert ???. Hat ja irgenwie auch alles funktioniert bis ich dein Modul geupdatet
hatte.Na ja dann muss wohl erst mal bei der kombination Mqtt-Device Mqtt-Bridge bleiben.
Problem gefunden, Lösung noch nicht.
Nach einem Restart geht nichts. Definiert man die Bridge im laufendem Betrieb, oder disconnected man kurz die MQTT-Instanz mit anschliessendem connect, geht wieder alles. Irgendwo habe ich da ein Problem in der Initialisierung eingebaut. Ich gehe malk auf die Suche...
Zitat von: hexenmeister am 07 September 2018, 20:52:05
Problem gefunden, Lösung noch nicht.
Ich gehe mal auf die Suche...
Lass dir Zeit. Eine Frage hätte ich noch.
Ich würde wenn es wieder läuft MQTT_GENERIC_BRIDGE nur für die Anbindung bestehender FHEM-Devices
benutzen in Verbindung mit Mqtt-Device für Anbindung externer MQTT Quellen. (Wie Sonoff etc.)
Das müsste doch problemlos gehen?
Billy
Gibt es hier schon was neues? Rudi plant ein FHEM 5.9 Release.
Da hier eine Version eingecheckt ist die nicht richtig läuft wollte ich mal nachfragen..
Gruß Patrick
Habe gerade eine Version eingecheckt, die bei mir ganz gut läuft. Kann gern getestet werden ;)
Im Anhang für alle Fälle nochmal.
Bei mir läuft alles 👍
Sehr gut! Jetzt muss ich nur noch keine Fehler mehr einbauen, bei den Restarbeiten, die ich noch machen will ;D
funktioniert bei mir leider nicht.
Das habe ich eingegeben (korrigiert):
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt licht_aussen,licht_kueche,licht_terrasse,BewegungT,BewegungV
attr mqttGeneric IODev myBroker
myBroker ist so definiert:
define myBroker MQTT 127.0.0.1:1883
attr myBroker room Kommunikation,MQTT
Wenn ich im mqttGeneric die devinfo oder devlist aufrufe, bekomme ich nur: "no devices found"
Wo ist jetzt mein Denkfehler? Muss das in den Geräten erst noch jeweils aktiviert werden?
Hallo aisberg
hier meine Difiniton bei einem Device:
attr denise_hms100tf mqttPublish *:topic={"/SmartHome/$device/$reading"}
Grüße
Rainer
ah, dann habe ich es jetzt verstanden, ich stelle das dann bei den jeweiligen Geräten ein!
Teste ich gleich mal.
Ich bin ja voll begeistert!!!! Das funktioniert ja wie am Schnürchen! Perfekt!
Vielen Dank.
eine dumme Anfänger-Frage habe ich nun aber doch noch:
Es war ein Denkfehler von mir, ein Reading meiner Schalter zu ändern, denn dadurch werden die Schalter nicht geschaltet. Ich denke, die Schalter benötigen ein explizites set on oder set off oder alternativ set toogle. Wie mache ich das über MQTT?
Also das hier ist falsch:
attr licht_aussen mqttSubscribe *:topic={"/SmartHome/$device/$reading/value"}
denn dann wird ja nur das Reading geändert, ohne dass sich der Homematic-Schalter wirklich ändert.
Ich habe in kleines Problem:
Mein Dymmy-Device:
defmod tempGefrierschrank dummy
attr tempGefrierschrank userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long
attr tempGefrierschrank genericDeviceType thermometer
attr tempGefrierschrank mqttSubscribe state:topic={"/Esp1wire@14211345/28.ff9b3b811402.f1/Temperature"}
Im Log steht:
2018.09.16 18:42:36 1: PERL WARNING: Possible unintended interpolation of @14211345 in string at (eval 19888) line 1.
Offensichtlich gibt es eine Unschärfe wenn ein Ampersand im Topic verwendet wird. Kann ich das selbst korrigieren ohne meine Esp's neu flashen zu müssen?
Hinweis: Wenn ich das Device als MQTT_DEVICE definiere funktioniert alles klaglos.
Grüße
Rainer
Zitat von: aisberg am 16 September 2018, 18:55:45
...
attr licht_aussen mqttSubscribe *:topic={"/SmartHome/$device/$reading/value"}
denn dann wird ja nur das Reading geändert, ohne dass sich der Homematic-Schalter wirklich ändert.
versuche mal:
attr licht_aussen mqttSubscribe *:
stopic={"/SmartHome/$device/$reading/value"}
Hallo aisberg,
ja, "stopic" verwende ich auch. Zusätzlich hat ein Schalter hat bei mir auch immer ein Publish:
defmod wz_schrank FS20 af5f 05
attr wz_schrank userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long
attr wz_schrank DbLogExclude .*
attr wz_schrank IODev CUNO
attr wz_schrank alexaName schrank
attr wz_schrank alexaRoom alexa
attr wz_schrank alias schrank
attr wz_schrank genericDeviceType switch
attr wz_schrank group _Steckdose_
attr wz_schrank model fs20st
attr wz_schrank mqttPublish *:topic={"/SmartHome/$device/$reading"}
attr wz_schrank mqttSubscribe state:stopic={"/SmartHome/$device/set"}
attr wz_schrank room 01_wohnzimmer,alexa
Grüße
Rainer
@SamNitro
was so ein kleines "s" für set doch ausmacht - perfekt!
Vielen Dank!!
topic / stopic / atopic... wieso habe ich denn nur so fleißig die Texte für Commandref geschrieben ??? ;)
Übrigens, es können auch 'verständlichere' Namen verwendet werden:
topic = readings-topic
stopic = set-topic
atopic = attr-topic
(Diesbezüglich muss ich die Doku noch anpassen).
Zitat von: ergerd am 16 September 2018, 19:01:35
defmod tempGefrierschrank dummy
attr tempGefrierschrank userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long
attr tempGefrierschrank genericDeviceType thermometer
attr tempGefrierschrank mqttSubscribe state:topic={"/Esp1wire@14211345/28.ff9b3b811402.f1/Temperature"}
Offensichtlich gibt es eine Unschärfe wenn ein Ampersand im Topic verwendet wird. Kann ich das selbst korrigieren ohne meine Esp's neu flashen zu müssen?
Moin!
Du verwendest {} im Topic. Das ist ein Hinweis für das Modul, das Topic kein Text, sondern eine Perl-Expression ist. Daher kommt auch das Problem. Man könnte das Zeichen Maskieren (mit \), aber in Deinem Fall gibt es da nichts zu interpretieren. Entferne die Klammern und auch die Anführungzeichen.
Danke hexenmeister!
Du machst deinem Namen alle Ehre :-)
Ich liebe dieses Modul!
Grüße
Rainer
@Hexenmeister
Habe mir heute deine neueste Version $Id: 10_MQTT_GENERIC_BRIDGE.pm 17363 2018-09-17 12:58:39Z hexenmeister $
eingespielt.
Vorab, läuft hervorragend, die Ansteuerung meiner Sonoff klappt. :)
Ich musste allerdings die userattr zum Device von Hand anlegen. Habe also
mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long
einfach in userattr des Device reinkopiert.
Vermutlich liegt das aber an mir, da ich die global userattr gelöscht hatte.
Das also nur am Rande.
Ich vermute, dass das bei einer kompletten Neuanlage funktioniert oder habe ich da was übersehen?
Vielen Dank für deine Arbeit, jetzt ist das ziemlich rund.
Gruß Billy
Was ich jetzt bezüglich userattr nachstellen konnte sieht so aus.
Wenn ich die Bridge z.B. mit
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt myTest1 myTest2
definiere
wird nur beim ersten Device das userattr angelegt.
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long
mit defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt myTest2
kann ich dann auch für das Device myTest2 das userattr anlegen.
Ist das so gewollt?
Billy
Das soll natürlich nicht sein. Ich sehe mir das an.
Workaround bis dahin: gar keine Geräte angeben (dann wird im global definiert), oder eben per Hand erstellen.
Zitat von: hexenmeister am 19 September 2018, 19:38:55
Das soll natürlich nicht sein. Ich sehe mir das an.
Workaround bis dahin: gar keine Geräte angeben (dann wird im global definiert), oder eben per Hand erstellen.
Ich für mich bevorzuge das Erstellen per Hand ab dem 2ten Device im userattr.
Dann habe ich mehr Übersicht.
Ansonsten wie schon erwähnt bin ich mit der Funktionalität sehr zufrieden. :)
Die userattr funktionieren wieder, wie sie sollen. :)
Außerdem sind in morgigen Update folgende Änderungen enthalten:
- Topics-Ausgabe (subscribe in devinfo) jetzt alphabetisch sortiert
- Trennung der zu ueberwachenden Geraete ist jetzt mit Kommas, Leezeichen, Kommas mit Leerzeichen oder einer Mischung davon moeglich.
- Unterstuetzung (fast) beliebiger variablen in defaults / global defaults (und nicht nur $base). Ansonsten ist die Verwendung wie bei $base. z.B. hugo wird zum $hugo in Topics/Expression
- Neue Option: resendOnConnect für mgttPublish Bewirkt, dass wenn keine mqtt-Connection besteht, die zu sendende Nachrichten in einer Warteschlange gespeichet werden. Wird die Verbindung aufgebaut, werden die Nachrichten verschickt.
Moegliche Optionen:
-- none - alle verwerfen,
-- last - immer nur die letzte Nachricht speichern,
-- first - immer nur die erste Nachricht speichern, danach folgende verwerfen,
-- all - alle speichern, allerdings existiert eine Obergrenze von 100, wird es mehr, werden aelteste ueberzaelige Nachrichten verworfen.
Beispiel: attr genericBridge globalPublish *:resendOnConnect=last
- zusätzlich zu 'topic' und 'stopic' gibt es jetzt 'atopic' - damit können Inhalte von gesetztenm Attributen gesendet und auch enpfangen werden.
- anstatt topic, stopic, atopic können jetzt auch etwas sprechendere Bezeichner verwendet werden: reading-topic, set-topic und attr-topic
Bei mir funktioniert das Modul super. Sehr viel angenehmer als die alte MQTT_BRIDGE! :-)
Eine Frage zur Verwendung von Wildcards bei mqttSubscribe.
Kann ich mit einer Zeile alle set-Befehle eines Devices via MQTT verfügbar machen? Bsp. ein als Bilderrahmen fungierendes AMAD-Device ist bei mir derzeit wie folgt konfiguriert:
attr AMAD_Kueche mqttSubscribe state:stopic={"/fhem/AMAD_Kueche/set"}\
bluetooth:stopic={"/fhem/AMAD_Kueche/bluetooth/set"}\
screen:stopic={"/fhem/AMAD_Kueche/screen/set"}\
volume:stopic={"/fhem/AMAD_Kueche/volume/set"}\
volumeNotification:stopic={"/fhem/AMAD_Kueche/volumeNotification/set"}
Kann ich die unteren vier Zeilen ersetzen durch sowas in der Art von
attr AMAD_Kueche mqttSubscribe *:stopic={"/fhem/AMAD_Kueche/$irgendwas/set"}\
oder besser noch
attr AMAD_Kueche mqttSubscribe *:stopic={"/fhem/AMAD_Kueche/$irgendwas/set"}\
*:atopic={"/fhem/AMAD_Kueche/$irgendwas/aset"}
Geht sowas bereits mit dem bestehenden Modul? Ich hab es mit $reading versucht aber das hat nicht geklappt.
Zitat von: hexenmeister am 22 September 2018, 23:34:14
Die userattr funktionieren wieder, wie sie sollen. :)
Kann ich bestätigen. Danke! :)
Zitat von: hopgeq am 23 September 2018, 22:22:20
attr AMAD_Kueche mqttSubscribe *:stopic={"/fhem/AMAD_Kueche/$irgendwas/set"}\
*:atopic={"/fhem/AMAD_Kueche/$irgendwas/aset"}
Geht sowas bereits mit dem bestehenden Modul? Ich hab es mit $reading versucht aber das hat nicht geklappt.
Sollte eigentlich.
Folgendes gerade ausprobiert:
*:topic={"/XTEST/$reading/ttt"}Dann auf '/XTEST/mynew/ttt' gesendet. Reading wurde anlgelegt.
auch mit:
*:atopic={"/XTEST/$reading/aaa"} und senden an '/XTEST/group/aaa' funktioniert.
Das Device muss natürlich einen entsprechenden Attribut überhaupt zulassen.
Welche Version setzt Du ein?
Jetzt funktioniert es bei mir auch. Nach Update auf neuste Version. Wunderbar!
Die Beispiele könnten vielleicht mit in die Doku für mqttSubscribe? Also
höre auf beliebigen set-Befehl mit Parameter, z.B. /fhem/MeinDevice/volume/set 10
attr MeinDevice mqttSubscribe *:stopic={"/fhem/MeinDevice/$reading/set"}
höre auf beliebigen set-Befehl ohne Parameter, z.B. /fhem/MeinDevice/set statusRequest
attr MeinDevice mqttSubscribe state:stopic={"/fhem/MeinDevice/set"}
höre auf beliebigen attr-Befehl, z.B. /fhem/MeinDevice/room/attr Bad (vielleicht nicht wirklich klug)
attr MeinDevice mqttSubscribe *:atopic={"/fhem/MeinDevice/$reading/attr"}
höre auf beliebigen setreading-Befehl, z.B. /fhem/MeinDevice/currentMedia/setreading DVD
attr MeinDevice mqttSubscribe *:topic={"/fhem/MeinDevice/$reading/setreading"}
Zunächst vielen Dank für das neue Modul, welches ich als sehr praktisch einschätze.
Leider habe ich ein Problem bei der Definition des Moduls mit den zu nutzenden Geräten [devspec]
Ich nutze structure für die Zusammenfassung von mehreren Geräten, z.B. stat_eg.
1. Wenn ich alle Geräte [devspec,devspec,...] definierte und später etwas ergänze, werden die Attribute mqttPublish in allen Geräten gelöscht und ich muss sie neu angeben.
2. Wenn ich die Geräteangaben bei der Definition von MQTT_GENERIC_BRIDGE weglasse, funktioniert es zwar, aber es werden die Attribute wie z.B. mqttPublish mit auf die Elternelemente von structure vererbt. Das will ich nicht.
3. Wenn ich als workaround nur ein Gerät angebe und die anderen Geräte über das manuelle Hinzufügen von userattr konfiguriere, funktioniert es zwar, aber bei einem Neustart sind die Attribute (mqttPublish) wieder entfernt.
Hab ich etwas übersehen?
Kann ich bestätigen.
Hätte ich heute auch noch gemeldet.
Beim neuen verknüpfen eines device mit der Bridge sind die attr der anderen devices gelöscht.
Nachvollzogen, gefunden, gefixt. Morgen per Update :)
Die Steuerattribute werden jetzt auch beim entfernen des Gerätes aus der Liste nicht angefast. Nach dem Restart sind sie natürlich dann weg.
Ach ja, in der neuen Version wird es jetzt verhindert, dass die Readings-Änderungen durch Empfang per MQTT sofort weitergepublisht werden. Damit kann publish und subscribe mit derselben Readings verwendet werden, ohne dass es zu Loops kommt.
So kann man dann aus dummies leicht Steuergeräte in einer anderen FHEM-Instanz basteln, so eine Art FHEM2FHEM-Ersatz. Diese sehen aus und verhalten sich dann eben wie auch eigentliche Gerätschaften.
Beispiele:
- Switch:
defmod DG_WZ_Licht_Top dummy
attr DG_WZ_Licht_Top devStateIcon off:light_light_dim_00@gray on:light_light_dim_100@#FF5722 .*:hourglass
attr DG_WZ_Licht_Top eventMap {usr=>{'an'=>'on','aus'=>'off'}}
attr DG_WZ_Licht_Top group Beleuchtung
attr DG_WZ_Licht_Top icon light_ceiling
attr DG_WZ_Licht_Top mqttPublish state:topic=dg/wz/licht/top/set
attr DG_WZ_Licht_Top mqttSubscribe state:topic=dg/wz/licht/top/state
attr DG_WZ_Licht_Top room Wohnzimmer
attr DG_WZ_Licht_Top setList on off
attr DG_WZ_Licht_Top webCmd an:aus
- Dimmer:
defmod DG_WZ_Licht_Hoch dummy
attr DG_WZ_Licht_Hoch devStateIcon off:light_light_dim_00@gray 0:light_light_dim_00@gray dark:light_light_dim_10@#FF5722 \d:light_light_dim_10@#FF5722 1\d:light_light_dim_20@#FF5722 2\d:light_light_dim_30@#FF5722 3\d:light_light_dim_40@#FF5722 4\d:light_light_dim_50@#FF5722 5\d:light_light_dim_60@#FF5722 half:light_light_dim_60@#FF5722 6\d:light_light_dim_70@#FF5722 7\d:light_light_dim_80@#FF5722 bright:light_light_dim_80@#FF5722 8\d:light_light_dim_90@#FF5722 9\d:light_light_dim_100@#FF5722 100:light_light_dim_100@#FF5722 on:light_light_dim_100@#FF5722 .*:hourglass
attr DG_WZ_Licht_Hoch eventMap {dev=>{'on'=>'100','off'=>'0'}, \
usr=>{'an'=>'on','aus'=>'off','dunkel'=>'15','hell'=>'70','halb'=>'50'}}
attr DG_WZ_Licht_Hoch group Beleuchtung
attr DG_WZ_Licht_Hoch icon light_ceiling
attr DG_WZ_Licht_Hoch mqttPublish level:topic=dg/wz/licht/hoch/set\
state:topic=dg/wz/licht/hoch/set
attr DG_WZ_Licht_Hoch mqttSubscribe level:topic=dg/wz/licht/hoch/level\
state:topic=dg/wz/licht/hoch/state
attr DG_WZ_Licht_Hoch readingList level
attr DG_WZ_Licht_Hoch room Wohnzimmer
attr DG_WZ_Licht_Hoch setList on off level:slider,0,1,100
attr DG_WZ_Licht_Hoch sortby 10wz_20
attr DG_WZ_Licht_Hoch stateFormat level
attr DG_WZ_Licht_Hoch webCmd an:hell:halb:dunkel:aus:level
Zitat von: hopgeq am 25 September 2018, 00:35:12
Die Beispiele könnten vielleicht mit in die Doku für mqttSubscribe? Also
Eher in wiki. Irgendwann wollte ich Zeit suchen, so einen Artikel zu erstellen ;D
Zitat von: hexenmeister am 27 September 2018, 22:49:46
Ach ja, in der neuen Version wird es jetzt verhindert, dass die Readings-Änderungen durch Empfang per MQTT sofort weitergepublisht werden. Damit kann publish und subscribe mit derselben Readings verwendet werden, ohne dass es zu Loops kommt.
Bei meinen Lampen funktioniert das auch ganz gut. Aber bei meinem HM_Rolladen nicht.
2018.09.27 23:57:54 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_80, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:17 3: CUL_HM set rollo_ez stop
2018.09.27 23:59:17 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_stop, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:42 3: CUL_HM set rollo_ez 100
2018.09.27 23:59:42 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_100, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:50 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument deviceMsg, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:50 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument level, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:50 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument motor, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:51 3: CUL_HM set rollo_ez pct 100
2018.09.27 23:59:51 3: CUL_HM set rollo_ez on
2018.09.27 23:59:51 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_100, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.28 00:07:09 3: CUL_HM set rollo_ez pct 100
2018.09.28 00:07:09 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_100, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
EDIT:
allerdings lausche ich komplett alles..
attr rollo_ez mqttPublish *:topic={"/$device/$reading"}
attr rollo_ez mqttSubscribe *:stopic={"/$device/$reading"}Der Befehl geht an /rollo_ez/pct (0-100)
Zitat von: hexenmeister am 27 September 2018, 22:38:51
Nachvollzogen, gefunden, gefixt. Morgen per Update :)
Die Steuerattribute werden jetzt auch beim entfernen des Gerätes aus der Liste nicht angefast. Nach dem Restart sind sie natürlich dann weg.
passt!
Zitat von: hexenmeister am 27 September 2018, 22:49:46
Ach ja, in der neuen Version wird es jetzt verhindert, dass die Readings-Änderungen durch Empfang per MQTT sofort weitergepublisht werden. Damit kann publish und subscribe mit derselben Readings verwendet werden, ohne dass es zu Loops kommt.
So kann man dann aus dummies leicht Steuergeräte in einer anderen FHEM-Instanz basteln, so eine Art FHEM2FHEM-Ersatz. Diese sehen aus und verhalten sich dann eben wie auch eigentliche Gerätschaften.
Super, bin zwar gerade auf Kreta habe mich aber per VPN auf mein Testsystem eingeloggt und mit Test-Dummies getestet.
Scheint jetzt alles zu laufen. :)
Danke
Zitat von: SamNitro am 28 September 2018, 00:10:08
allerdings lausche ich komplett alles..
attr rollo_ez mqttPublish *:topic={"/$device/$reading"}
attr rollo_ez mqttSubscribe *:stopic={"/$device/$reading"}
Der Befehl geht an /rollo_ez/pct (0-100)
Ich rate dringend davon, das so zu tun. In diesem Fall werden alle Readings gepublisht und dann wieder empfangen und als SET-Befehl abgesetzt. Das kann nicht passen und wird unweigerlich zu Fehlermeldungen (und ggf. auch zum unerwünschten Verhalten) führen. Es gibt ja (vor allem bei HomeMatic) viele Readings und relativ wenig gültige SET-Befehle.
Außerdem ist hier die Richtung anders. Es wird derzeit verhindert, dass _empfangene_ Nachrichten weiter gepublisht werden, jedoch nicht, dass _gesendete_ wieder empfangen werden. Ist auch nicht so einfach zu verhindern, da in diesem Fall der MQTT-Server beteiligt ist. Eine saubere Lösung würde vermutlich auch Änderungen in 00_MQTT-Modul erfordern (ClientID durchreichen, ich weiß gerade nicht, ob die Verwendete Bibliothek das schon kann).
Ok dann werde ich es so lassen wie bisher. So läuft ja alles.
Mobil unterwegs!
Habe doch noch ein kleines problem.
Für Node-Red benötige ich die Rückmeldung. Entweder bekomme ich ein loop oder keine Rückmeldung.
Spricht was dagegen, zwei verschiedene Topics dafür zu nehmen?
jetzt ist überall der wurm drin. Bin im Hausumbau Stress jetzt noch Flitterwochen und jetzt Funktioniert nicht mal mehr der normale Rolladenschalter weil da Rückmeldungen über MQTT kommen die da nicht hin sollen....
Habe versucht 2 topics zu nehmen aber gerade klappt einfach nix mehr. ich versuche auf eine alte version zurück zu kehren
Wenn ich noch verstehen würde, was bei Dir nicht klappt...
Habe gerade mit einem HM Rolladenaktor nachgestellt.
Funktionierendes Beispiel mit zwei (eigentlich sogar 3) Topics.
Steuerdummy:
defmod OG_BZ_Rollo dummy
attr OG_BZ_Rollo devStateIcon runter:fts_shutter_100 \d(.\d)*:fts_shutter_100 hoch:fts_shutter_10 100:fts_shutter_10 1\d(.\d)*:fts_shutter_90 2\d(.\d)*:fts_shutter_80 3\d(.\d)*:fts_shutter_70 4\d(.\d)*:fts_shutter_60 5\d(.\d)*:fts_shutter_50 6\d(.\d)*:fts_shutter_40 schatten:fts_shutter_40 7\d(.\d)*:fts_shutter_30 8\d(.\d)*:fts_shutter_20 9\d(.\d)*:fts_shutter_10 nacht:fts_shutter_10
attr OG_BZ_Rollo eventMap {usr=>{'oeffnen'=>'100','schliessen'=>'0','halb'=>'60','schatten'=>'80','dunkel'=>'30'}}
attr OG_BZ_Rollo group Beschattung
attr OG_BZ_Rollo icon fts_shutter
attr OG_BZ_Rollo mqttPublish position:topic=og/bz/rollo/all/set state:topic=og/bz/rollo/all/set
attr OG_BZ_Rollo mqttSubscribe position:topic=og/bz/rollo/all/position state:topic=og/bz/rollo/all/state
attr OG_BZ_Rollo readingList position
attr OG_BZ_Rollo room Badezimmer
attr OG_BZ_Rollo setList position:slider,0,1,100
attr OG_BZ_Rollo stateFormat position
attr OG_BZ_Rollo webCmd oeffnen:schatten:halb:dunkel:schliessen:positionHM-Aktor:
defmod bz_rollo CUL_HM xxxxxx
attr bz_rollo model HM-LC-Bl1PBU-FM
...
attr bz_rollo mqttPublish pct:topic=og/bz/rollo/all/position state:topic=og/bz/rollo/all/state
attr bz_rollo mqttSubscribe pct:stopic=og/bz/rollo/all/set
Die Bridge kann eine Übersicht ausgeben, wo man gut sehen kann, welche Topics verwendet werden:
Aktor:
Zitat
bz_rollo
publish:
pct => og/bz/rollo/all/position (mode: R; qos: 0)
state => og/bz/rollo/all/state (mode: R; qos: 0)
subscribe:
pct <= og/bz/rollo/all/set (mode: S)
Dummy:
Zitat
OG_BZ_Rollo
publish:
position => og/bz/rollo/all/set (mode: R; qos: 0)
state => og/bz/rollo/all/set (mode: R; qos: 0)
subscribe:
position <= og/bz/rollo/all/position (mode: R)
state <= og/bz/rollo/all/state (mode: R)
Bei mir ist es die Kommunikation zwischen NodeRed und FHEM
z.B. meine wz_stehlampe
attr wz_stehlampe mqttPublish *:topic={"/out/$device/$reading"}
attr wz_stehlampe mqttSubscribe *:stopic={"/in/$device/$reading"}
[/out/wz_stehlampe/state]--------[Schalter]----------------[/in/wz_stehlampe/state]
[Alexa-Stehlampe]---------[/in/wz_stehlampe/state]
oder so
attr wz_stehlampe mqttPublish *:topic={"/out/$device/$reading"}
attr wz_stehlampe mqttSubscribe state:stopic={"/in/$device/set"}
[/out/wz_stehlampe/state]--------[Schalter]----------------[/in/wz_stehlampe/set]
[Alexa-Stehlampe]---------[/in/wz_stehlampe/set]
Das problem ist NodeRed da lasse ich mir einen Schalter anzeigen: der Zeigt mir logischerweise den status vom Input an
Entweder zeigt er mir nicht den richtigen status an oder er lässt sich nich korrekt schalten
Sieht nicht falsch aus. Poste mal die Node-Red Export.
So ist der alte Stand der mit der alten Version Läuft:
[{"id":"af1a4b9a.2f1ac8","type":"alexa-home","z":"9d8c568.24a8628","devicename":"Stehlampe","inputtrigger":false,"x":410,"y":600,"wires":[["110aabab.12ef8c"]]},{"id":"16968764.a59469","type":"mqtt in","z":"9d8c568.24a8628","name":"","topic":"/out/wz_stehlampe/state","qos":"2","broker":"65613e0a.ef6478","x":130,"y":560,"wires":[["a1339df4.6c78c8"]]},{"id":"110aabab.12ef8c","type":"mqtt out","z":"9d8c568.24a8628","name":"","topic":"/in/wz_stehlampe/state","qos":"","retain":"","broker":"65613e0a.ef6478","x":670,"y":560,"wires":[]},{"id":"a1339df4.6c78c8","type":"ui_switch","z":"9d8c568.24a8628","name":"","label":"Stehlampe","group":"df58a679.8acae","order":1,"width":0,"height":0,"passthru":false,"decouple":"true","topic":"","style":"","onvalue":"on","onvalueType":"str","onicon":"","oncolor":"","offvalue":"off","offvalueType":"str","officon":"","offcolor":"","x":410,"y":560,"wires":[["110aabab.12ef8c"]]},{"id":"65613e0a.ef6478","type":"mqtt-broker","z":"","name":"","broker":"localhost","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","closeTopic":"","closeRetain":"false","closePayload":"","willTopic":"","willQos":"0","willRetain":"false","willPayload":""},{"id":"df58a679.8acae","type":"ui_group","z":"","name":"Schalter","tab":"dbb46b72.63ce3","order":2,"disp":true,"width":"6","collapse":false},{"id":"dbb46b72.63ce3","type":"ui_tab","z":"","name":"Home","icon":"dashboard","order":1}]
Problem verstanden. Ich lasse mir was einfallen.
Zitat von: hexenmeister am 28 September 2018, 22:08:39
Problem verstanden. Ich lasse mir was einfallen.
Du bist mega ;)
Hatte schon "angst" es nicht gut genug zu erklären :D
Schade ist das ich kein Test-System habe und bei mir gerade alles sehr gut läuft.
Habe nicht bedacht, dass zwar an einer Stelle lieber nicht weitergesendet werden soll, an der Aktor-Seite ist jedoch genau das notwendig. Ich überlege nur, wie ich das konfigurierbar machen kann. Automatische Erkennung wird vermutlich nicht einfach.
Testsysteme sind beim Einsatz von Entwicklungsversionen sehr von Vorteil. Ich habe mittlerweile mehrere ;D
Zitat von: hexenmeister am 28 September 2018, 22:19:14
Testsysteme sind beim Einsatz von Entwicklungsversionen sehr von Vorteil. Ich habe mittlerweile mehrere ;D
Ja das stimmt, aber wie gesagt momentan habe ich viele andere Sachen im Kopf.. damit das haus FHEM kompatibel ist :D
Kann man hier evtl einen weiteren Topic dafür nehmen? (einer gibt weiter der andere nicht)
atopic
stopic
topic
xytopic
Ja, so in dem Dreh hatte ich schon gedacht. Es gibt sogar schon ein (undokumentiertes) Subscribe-Topic, der weitertriggert, allerdings nur für topic, nicht für stopic. Derzeit überlege ich, ob es mehr Sinn macht, einen zusätzlichen Flag beim publish einzuführen. So was wie 'attr xyz mqttPublish state:topic=whatever *:forward-on-receive=true'.
Das musst letztendlich du entscheiden was einfacher ist umzusetzen. Ich weiß nur nicht ob ein zusätzliches Flag zu unübersichtlich wird.
ftopic wäre noch frei ;D
Darf man sich kurz einmischen? ;) ich habe mit Mqtt noch keine Berührungspunkte gehabt. Hab mich heute aber eingelesen. Nun möchte ich meine 2 Fhem Instanzen mit deinem Modul nutzen. Ich habe auf meinen beiden Raspi3 bereits mosquitto installiert. In deinem Wiki finde ich zur Verbindung zweier Instanzen kkeine Beschreibung. Hier in deinem thread hast du dies aber erwähnt.
- muss auf beiden instanzen dein Modul laufen?
- wenn ja, dann kann nur eine von den beiden das IoDev sein, oder
Danke.
Zitat von: SamNitro am 28 September 2018, 22:44:51
Das musst letztendlich du entscheiden was einfacher ist umzusetzen. Ich weiß nur nicht ob ein zusätzliches Flag zu unübersichtlich wird.
ftopic wäre noch frei ;D
Ich denke, ich weiß mittlerweile, wie ich das machen werde, muss natürlich noch umgesetzt werden. Bis dahin habe ich einen kleinen QuickFix, damit die selbe Version bei Dir und auch für mich funktioniert. :)
Zitat von: choetzu am 30 September 2018, 22:38:53
Darf man sich kurz einmischen? ;) ich habe mit Mqtt noch keine Berührungspunkte gehabt. Hab mich heute aber eingelesen. Nun möchte ich meine 2 Fhem Instanzen mit deinem Modul nutzen. Ich habe auf meinen beiden Raspi3 bereits mosquitto installiert. In deinem Wiki finde ich zur Verbindung zweier Instanzen kkeine Beschreibung. Hier in deinem thread hast du dies aber erwähnt.
- muss auf beiden instanzen dein Modul laufen?
- wenn ja, dann kann nur eine von den beiden das IoDev sein, oder
Danke.
Mosquitto benötigst Du nur einmal. Als IODev brauchst du MQTT an beiden Seiten, jeweils (die gleiche!) IP des mosquitto-Server anzugeben.
Die GenericBridge brauchst Du natürlich auch auf beien Seiten, mit der MQTT-Instanz als IODev.
Jetzt ist die große Frage, was Du unter 'zwei Instanzen verbinden' vorstellst. Automatisch wird da nichts synchrinisiert, Du musst entscheiden, was geschehen soll und entsprechend definieren.
guten Morgen, herzlichen Dank für deine Antwort.
Mein Vorhaben. Genau so wie du will ich meine zwei Instanzen insofern von einander trennen, dass auf dem einen die Aktoren, Sensoren und zu schaltenden Devices sind und auf dem anderem der Rest sowie die Logik. Zudem will ich einige Reading via notify vom einen zum anderen übertragen
Ich will also Befehle und Reading hin und her "schiessen". Für das ist doch MQTT geeignet, oder?
lg c
Zitat von: choetzu am 01 Oktober 2018, 06:37:17
Mein Vorhaben. Genau so wie du will ich meine zwei Instanzen insofern von einander trennen, dass auf dem einen die Aktoren, Sensoren und zu schaltenden Devices sind und auf dem anderem der Rest sowie die Logik. Zudem will ich einige Reading via notify vom einen zum anderen übertragen
Ich will also Befehle und Reading hin und her "schiessen". Für das ist doch MQTT geeignet, oder?
lg c
Um Readings oder Befehle via mqtt zu übertragen brauchst du beim Einsatz der MQTT_GENERIC_BRIDGE kein notify!
Und ja
ZitatIch will also Befehle und Reading hin und her "schiessen".
Dafür ist MQTT geeignet.
Zitat;) ich habe mit Mqtt noch keine Berührungspunkte gehabt.
Ich würde dir empfehlen mit z.B. dem Tool
mqtt-spy zu-plotten was da zum Brooker ge-published wird.
Du kannst z.B auf einer Instanz
einen Sensor mit der Bridge verbinden, die gewünschen zu übertragenden Readings (Befehle)
auswählen und erst mal mit mqtt-spy schauen was am Brooker ankommt.
Dann kannst du auf der 2ten Instanz z.B. ein Dummy-Device oder ein bestehendes Device an die Bridge der 2ten Instanz hängen und per subscribe Attribute die Readingswerte (Befehle) dem Device zuordnen.
Steht zwar alles in der commandref aber Versuch macht kluch. ;)
Gruß Billy
Ich denke, es wird langsam Zeit, häufige Anwendungsfälle und dazugehötige Config an einer Stelle zu sammeln. Kann später vlt. ins Wiki.
Ich habe schon mal einen neuen Thread angelegt und werde im Laufe des Tages ein Paar Konfigurationsbeispiele dort anlegen: https://forum.fhem.de/index.php/topic,91642.msg841367.html#msg841367
Moin mal ne Frage zu de HowTo aus der ersten Seite zum Punkte Subscribe und QOS:
attr <dev> mqttSubscribe temperature:topic=/TEST/temperature test:qos=0 *:topic={"/TEST/$reading/value"}
attr <dev> mqttSubscribe desired-temperature:stopic={"/TEST/temperature/set"}
Ich habe exakt das Beispiel aus der 2. Zeile ;-)
Würde ich nun mit: desired-temperature:qos=2 das auf QOS 2 setzen?
Beim Beispiel aus der ersten Zeile mit "test:qos=0" ist mir irgendwie unklar woher das "test" kommt.
In der Sammlung konnte ich dazu kein Beispiel finden. :-)
Ja, damit würdest Du QOS für desired-temperature auf 2 setzen.
Beispiel aus der Zeitle 1 ist leicht irreführend. QOS wird hier auf 0 für Reading namens 'test' gesetzt. Dieser kann per Topic '/TEST/test/value' gesetzt werden, dies ist implizit durch *:topic={"/TEST/$reading/value"} definiert.
Ah okay Danke! :-)
Cool dann hab ich es ja bereits korrekt.
herzlichen dank. ich mache grad die ersten Schritte.
Auf Master-Raspi habe ich nun mosquitto, mqtt Modul und Mqtt_generic_bridge modul installiert
gemäss Bally muss ich auf dem RemoteRaspi (also Raspi2) kein mosquitto installieren. Ich gehe aber davon aus, dass ich dort ebenfalls die generic bridge installieren muss mit der IP des Master-Raspi, damit ich auch die attr für die Devices erhalte. ist dies korrekt? Ich habe kein testsystem, deshalb die Frage ;)
Richtig, auf beiden Systemen je ein MQTT Modul (mit der IP von mosquitto) und je eine GenericBrigde.
Hallo,
ich habe das gleiche Problem wie SamNitro und NodeRed. Damit sind wir schon mal 2.
PS: Danke für das tolle Modul.
Meinst Du, dass die Schalter in NoeRED nicht funktionieren? Sollte mit der aktuellen Version richtig laufen. Tut es bei mir auch. Ansonsgten poste mal die relevante Konfiguration.
ja, genau das. Hatte vorher eine wahrscheinlich recht ältere Entwicklungsversion die ich über Fhem "update" aktualisiert habe. Danach haben die Rückmeldungen in Nodered wie von SamNitro beschrieben, nicht mehr funktioniert.
Ist irgendwo eine Konfigurationsleiche übrig geblieben?
version 0.9.9 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 17444 2018-09-30 21:30:54Z hexenmeister $
define MqttGenericBridge MQTT_GENERIC_BRIDGE
attr MqttGenericBridge IODev MQTTBroker
attr MqttGenericBridge room System
define SzEnableMotionDetection dummy
attr SzEnableMotionDetection devStateIcon on:on:off off:off:on
attr SzEnableMotionDetection genericDeviceType switch
attr SzEnableMotionDetection mqttPublish state:topic={"stat/$device/$reading"} *:retain=1
attr SzEnableMotionDetection mqttSubscribe state:stopic={"cmnd/$device/$reading"}
attr SzEnableMotionDetection room Schlafzimmer
attr SzEnableMotionDetection webCmd on:off
Auch wenn ich mit MQTT.fx ein "off" oder "on" auf "cmnd/SzEnableMotionDetection/state" publishe erhalte ich auf die topic "stat/SzEnableMotionDetection/state" keine Rückmeldung.
Das hier funktioniert allerdings wie vorgesehen:
define HM_2F66F2 CUL_HM 2F66F2
attr HM_2F66F2 IODev nanoCUL868
attr HM_2F66F2 IOgrp VCCU:nanoCUL868
attr HM_2F66F2 alias LED_Lampe
attr HM_2F66F2 autoReadReg 4_reqStatus
attr HM_2F66F2 expert 2_raw
attr HM_2F66F2 firmware 2.4
attr HM_2F66F2 group Licht
attr HM_2F66F2 model HM-LC-SW1-PL2
attr HM_2F66F2 mqttPublish *:topic={"stat/$device/$reading"} *:retain=1
attr HM_2F66F2 mqttSubscribe *:stopic={"cmnd/$device/$reading"}
attr HM_2F66F2 room Alexa,Licht,Schlafzimmer
attr HM_2F66F2 serialNr LTK0069478
attr HM_2F66F2 subType switch
attr HM_2F66F2 webCmd statusRequest:toggle:on:off
Hm....ja. Das hier ist das selbe Problem nur andersrum.
Wenn man an zweien Instanzen zwei Geräte verbindet, dürfen nicht beide alle ankommende Nachrichten gleich weiter durchleiten - das führt zu einer Endlosschleife. Daher ist das jetzt so implementiert, dass alle Geräte außer Dummies die Nachrichten weiterleiten können. Dummy eignet sich al 'Schalter', daher solcher Hack. Ich überlege immer noch, wie ich es saubersten einstellbar machen kann.
Bei Dir ist aber Dummy als eine Art Aktor verwendet (falls ich Deine Logik richtig verstanden habe)... Ich habe paar Ideen, fürchte aber mit vielen zusätzlichen Parameter nur den Benutzer zu verwirren :/
Zitat von: hexenmeister am 08 Oktober 2018, 21:53:54
Bei Dir ist aber Dummy als eine Art Aktor verwendet (falls ich Deine Logik richtig verstanden habe)...
joah.. kommt hin. Mein Dummy dient als Merker und ist an sich ein Aktor. Dieser wird uber mqtt/nodeRed ein und ausgeschaltet. DOIF Schleifen fragen den Zustand ab und werten somit aus ob für den Bewegungsmelder eine Freigabe vorliegt oder nicht.
Vielleicht kann man das als default so lassen aber das alte Verhalten über irgendein Parameter (zb Attribut "mqttDoAllways") auswählbar lassen. Ein Parameter mehr oder weniger kompliziert die Sache nicht viel mehr wenn es gut dokummentiert ist.
Meine Überlegungen bis jetzt:
1. einen neuen "Topic"-Typ einführen. So wie atopic, stopic etc. Finde jedoch nicht wirklich intuitiv.
2. An der Bridge selbst Typen der Geräte angeben, die so oder anders agieren. Ist jedoch nicht flexibel genug.
3. Ein Parameter an der Gerät. So wie Dein Vorschlag.
4. Wie 3. nur für jedes Topic getrennt. Vermutlich oversized.
Bin derzeit eher bei 3.
Frage 1: Probleme bzw Hilfeanfrage hier oder in nem anderen Thread?
Erledigt -> Hilfe/Probleme etc Thread zum MQTT_GENERIC_BRIDGE Modul: https://forum.fhem.de/index.php/topic,91984.0.html
Frage2: Der folgende Device will auf einmal (es ging vor Tagen noch) nicht mehr auf Befehle von NodeRed auf dem /state/set topic hören:
--> Moved https://forum.fhem.de/index.php/topic,91984.msg844833.html#msg844833
Internals:
CFGFN
NAME Streifen
NR 94
STATE on
TYPE dummy
READINGS:
2018-10-11 14:37:58 newstate on
2018-10-11 14:37:58 state on
Attributes:
alexaName Streifen
alexaRoom Wohnzimmer
genericDeviceType light
group Licht
homebridgeMapping Brightness=state,cmd=
icon light_led_stripe_rgb
mqttDefaults base={"homeland/haushalt/elektrik/wohnzimmer/$device"} pub:qos=2 sub:qos=2 retain=1
mqttPublish state:topic={"$base/$name"} state:qos=2 state:retain=1
mqttSubscribe state:stopic=homeland/haushalt/elektrik/wohnzimmer/Streifen/state/set state:qos=2
room Echo,Wohnzimmer
setList state:slider,0,1,100 on off
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long
webCmd state
Jemand eine Idee? :o
Ich habe noch genau son Teil und da geht alles - unterschied ist nur die homebridge Sache und es ist kein dummy..
zu 1.: ist mir relativ egal. vlt. wäre sogar ein neuer 'Problem-Thread' angebracht...
zu 2.: Das Device ist ja eigentlich ein Dummy. Was soll dabei geschehen? Nur state im Dummy umgesetzt, oder auch die Nachricht weitergeleitet? Letzteres habe ich für Dummies erstmal unterdrückt, da sonst bei der Verwendung der Dummies als Schalt-Element (analog Deinem Dashboard im NodeRed) Endlosklreise entstehen. Ich überlege immer noch, wie man das am besten konfigurierbar macht.
Verstehe den Endlos Gedanken nicht gerade.
Ich habe zum schalten und antworten 2 Topics.
NodeRed zeigt am Schalter an was im topic /state anliegt und schaltet selber das topic /state/set
FHEM subscribed das topic /state/set und published in /state
Wo ist das nun der Loop? Genau so hab ich es bei allen Geräten :-)
Und vorhaben - was bisher auch ging bis zum Update zu einer der letzten Versionen (es fällt ja immer erst nach ner Weile auf) war eben, dass der Dummy im STATE auf on/off geschaltet wird.
Richtig hart trifft mich das bei meinem Dummy "Heizungssteurung" - der ist ein rein logischer Schalter für einige DOIFs :-D und nun geht er nicht mehr.
Vermutlich wird dein Dummy schon geschaltet, nur meldet es sein Status nicht mehr.
Kreise entstehen bei dir nicht. Aber in dem Fall, wenn man einen Aktor mit einem Dummy als Schaltelement verwendet. In deinem Fall müssen empfangene Nachrichten weiter geleitet werden, in dem anderen Fall eben nicht. Daher muss das konfiguriert werden können. Bin dran.
;D Mich wundert, dass es in einer alten Version (ich hab leider echt keine Ahnung welche Sprünge ich gemacht habe in den Versionen) tadellos funktionierte :-D
Es war ja laufendes System hier. 8)
Danke dir! :-*
Wegen entstandenen Endlosschleifen habe ich die Speere für Dummies eingebaut. Früher ging das, dafür was anderes nicht.
Wäre ne schaltbare Sperre nen Deal 8) ?
Genau das habe ich vor. Bin mir nur noch nicht sicher wie das am besten zu machen ist. Habe paar Beiträge höher über die möglichen Varianten geschrieben.
Hab dann mal nen Hilfe/Probleme etc Thread auf gemacht: https://forum.fhem.de/index.php/topic,91984.0.html
PS: Wäre für --> 3. Ein Parameter im Gerät.
Einfach ein Flag mit leitet weiter oder net :-) 1/0 ganz stumpf
Seit dem update am 20 Oktober funktionieren meine Sensoren nicht mehr
ein zurückspielen der alten behebt das Problem
Ines
Ja, in dem anderen thread wäre der Beitrag besser aufgehoben. Und bitte mit allen Details zum nachstellen. So kann ich leider nichts dazu sagen. Bei mir funktioniert ja alles.
Hallo
Erstmal ein großes Lob an den Entwickler dieses Moduls. Echt klasse.
Ich kapier nur eines nicht ganz und zwar:
Wie bekomme ich es jetzt hin dass ein fhem device (z. B. SZ_LICHT) den Befehl 'on' bekommt also 'set SZ_LICHT on' wenn der Befehl 'on' im Topic meinZuhause/SZ_LICHT reinkommt? Was bzw. wie muss ich das beim device SZ_LICHT attr mqttSubscribe angeben?
Mahlzeit, nutz doch bitte den Hilfe/Probleme Thread: https://forum.fhem.de/index.php/topic,91984.0.html
Mahlzeit :)
Ok sorry
Hallo hexenmeister,
ich hoffe, du liest hier noch mit.
Ich möchte den Inhalt eines Readings eines Fhem-Devices publishen.
Der Inhalt des Readings ist variabel, deshalb kann ich nicht einfach einen Wert publishen, da dieser zwar vorhanden und auch geloggt wird, aber ansonsten als Wert nicht verfügbar ist.
Ich hoffe ich habe mich bisher nicht zu verschwurbbelt ausgedrückt.
Um ein konkretes Beispiel zu geben, ich möchte den Inhalt des Readings <temperature> des Devices <TH.Kuhlmannweg8> publishen.
Entweder jedesmal, wenn sich der Wert des Readings ändert, oder in festen Zeitabständen, das ist mir eigentlich egal.
Da ich verschiedene MQTT-Devices mit unterschiedlichen Firmwares laufen habe, ist mir das Thema MQTT nicht unbekannt.
defmod TH.Kuhlmannweg8 CUL_HM 20E202
attr TH.Kuhlmannweg8 .devInfo 030100
attr TH.Kuhlmannweg8 .mId 003D
attr TH.Kuhlmannweg8 .stc 70
attr TH.Kuhlmannweg8 IODev myHmUARTLGW1
attr TH.Kuhlmannweg8 IOgrp VCCU:myHmUARTLGW1
attr TH.Kuhlmannweg8 actCycle 024:00
attr TH.Kuhlmannweg8 actStatus alive
attr TH.Kuhlmannweg8 autoReadReg 0_off
attr TH.Kuhlmannweg8 event-min-interval 600
attr TH.Kuhlmannweg8 event-on-change-reading state,temperature,humidity,dewpoint
attr TH.Kuhlmannweg8 expert 2_full
attr TH.Kuhlmannweg8 firmware 1.3
attr TH.Kuhlmannweg8 group Sensoren
attr TH.Kuhlmannweg8 icon temperature_humidity
attr TH.Kuhlmannweg8 model HM-WDS10-TH-O
attr TH.Kuhlmannweg8 peerIDs 00000000,
attr TH.Kuhlmannweg8 room CUL_HM,Heizung,Weather
attr TH.Kuhlmannweg8 serialNr KEQ0175095
attr TH.Kuhlmannweg8 stateFormat T:temperature H:humidity D:dewpoint
attr TH.Kuhlmannweg8 subType THSensor
attr TH.Kuhlmannweg8 userReadings dewpoint:temperature.* {urDewpoint($name)}
setstate TH.Kuhlmannweg8 T:23.2 H:60 D:15.0
setstate TH.Kuhlmannweg8 2019-07-16 14:18:29 .D-devInfo 030100
setstate TH.Kuhlmannweg8 2019-07-16 14:18:29 .D-stc 70
setstate TH.Kuhlmannweg8 2019-07-18 20:39:38 .protLastRcv 2019-07-18 20:39:38
setstate TH.Kuhlmannweg8 2019-07-17 22:45:19 Activity alive
setstate TH.Kuhlmannweg8 2019-07-16 14:18:29 D-firmware 1.3
setstate TH.Kuhlmannweg8 2019-07-16 14:18:29 D-serialNr KEQ0175095
setstate TH.Kuhlmannweg8 2019-07-18 20:39:38 battery ok
setstate TH.Kuhlmannweg8 2019-07-18 20:32:02 dewpoint 15.0
setstate TH.Kuhlmannweg8 2019-07-18 20:39:38 humidity 60
setstate TH.Kuhlmannweg8 2019-07-18 20:39:38 state T: 23.2 H: 60
setstate TH.Kuhlmannweg8 2019-07-18 20:39:38 temperature 23.2
Ich habe deshalb folgendes Device definiert, in der Annahme, dass ich das obige Problem lösen kann:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt
attr mqttGeneric IODev MyBroker
Wenn ich get mqttGeneric devinfo oder devlist eingebe, dann erhalte ich: "no devices found".
Ich mache wohl was grundlegendes falsch.
Um meine Frage nochmals zu wiederholen:
Wie kann ich den Inhalt eines Readings publishen?
Kann das auch ein Reading eines Typs MQTT-DEVICE sein oder muss es ein Reading eines beliebigen anderen Typs sein?
Viele Grüße Gisbert
Moin. Schau mal 2 Posts über deinem #110.
Und zu deinem Problem: Heisst dein mqtt Broker denn wirklich MyBroker?
Das reading kann mEn sein was es will. Das ist ja das schöne bei der GB.
Gruß
Zitat von: Maui am 18 Juli 2019, 20:58:23
Moin. Schau mal 2 Posts über deinem #110.
Und zu deinem Problem: Heisst dein mqtt Broker denn wirklich MyBroker?
Das reading kann mEn sein was es will. Das ist ja das schöne bei der GB.
Gruß
Hallo Maui,
danke für den Hinweis, ich war mir nicht bewusst, dass es einen eigenen Hilfe-Thread gibt.
mein MQTT-Broker heißt tatsächlich MyBroker, was ist so ungewöhnlich an dem Namen?
In der Zwischenzeit habe ich eine total simple Lösung (selbst) gefunden.
Das Publishen eines Readings eines beliebigen Devices geht wohl so (getestet):
set publish <MQTT device> [<device>:<reading>]Viele Grüße Gisbert
Nix ist ungewöhnlich dran. War bloß auf Fehlersuche.
Mit deinem Befehl nutzt du allerdings nicht mehr die Generic Bridge ;)
Ich verstehe ehrlich gesagt das Problem nicht. Einfach in dem gewünschten Device mittels Attribute 'mqttPublish' (s. Commandref) die gewünschtre Reading einem Topic zuordnen und schon taucht dieses Gerät in der Bridge auf.
ZitatEinfach in dem gewünschten Device mittels Attribute 'mqttPublish' (s. Commandref) die gewünschtre Reading einem Topic zuordnen und schon taucht dieses Gerät in der Bridge auf.
Dieser Hinweis hat geholfen; jetzt funktioniert das Bridge-Device.
Viele Grüße Gisbert
Hallo,
super Modul, macht genau was es soll.
Meistens. Manchmal , ich habe leider noch kein System erkennen können, (siehe Edit unten) "verliert" die Bridge alle Devices, device-count
ist dann plötzlich "0" und die Devices reagieren nicht mehr auf die per Subscribe abonnierten Topics.
Sobald ich das Attribut mqqtSubscribe einmal neu speichere, ohne etwas zu ändern, registriert die Bridge das Device wieder, und alles klappt wieder.
Muss ich dann mit jedem Subscriber-Device einmal machen.
Eine Idee, woran das liegt?
Edit: Ich stelle grad fest, das es nachstellbar immer dann passiert, wenn ich ein "rereadcfg" absetze.
Viele Grüße
Marc
Mh konnte ich unter normalem Einsatz noch nie erleben.
Hast Du mal rereadcfg gemacht?
(Falls nicht, lass es auch lieber, falls das wirklich ein Bug sein sollte ist das maximal lästig, da Du dann alle Devices einmal durchgehen musst.)
Naja macht man vorher ein save und hat die configdb und dann ist alles wieder da.
Alternativ einmal richtiges Backup vom gesamten Ordner. :-D
Ich schau nachher mal rein.
Aber ich glaub generell war das mal so gedacht, dass so etwas hier hin soll: https://forum.fhem.de/index.php/topic,91984.0.html
Alle Devices neu einlesen, hier sollte solgendes helfen: In dem GenericBridge device Attribut debug auf 1 setzen. Dann gibt es ein neues Befehl in dem set-Combobox: 'debugReinit'. Das liesst alles neu ein. Aber... rereadcfg funktioniert schon lange nicht nebenwirkungsfrei. Nicht nur in der Bridge. Ein richtig konfiguriertes fhem startet innerhalb von Sekunden. Daher... => Verwende nie rereadcfg.
Danke für das Feedback und den Tipp, klappt, und ich lass nun die Finger vom rereadcfg.
Da blieb mir der Chaostest erspart ;-) *puh* ;)