'n Abend zusammen!
Inspiriert durch ein Video (https://www.youtube.com/watch?v=AGn_QfPmk-g), das hier empfohlen wurde: https://forum.fhem.de/index.php/topic,78512.msg731365.html#msg731365 habe ich angefangen ein kleines Modul zu schreiben, dass so etwas bequemmer realisiert.
Die Idee dabei ist, keine einzelnen MQTT-Bridges für jedes zu übertragende Device erstellen zu müssen, sondern mit einem einzigen Gerät zu diesem Zweck auszukommen, die jeweiligen Einstellungen (Topics etc.) sollen dabei in den eigentlichen Quell-Geräten liegen. Letztendlich möchte ich sowohl publish, als auch subscribe unterstützen, aber soweit ist es noch lange nicht, ich bin mir nicht mal über das Format für die Attribute klar.
Hier biete ich eine erste Testversion als 'proof of concept'. Derzeit funktioniert das Publishen der Readings schon ganz gut, mit Subscribe habe ich noch gar nicht angefangen.
Definition Bridge:
defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev mqtt
attr mqttGeneric mqttTopicPrefix /test/
Beispieldefinition Gerät:
defmod test dummy
attr test mqttPubNames myreading state
attr test mqttTopic topic
attr test readingList myreading
attr test setList myreading
Setzt man jetzt irgendwas in Device 'test' 'myreading' oder 'state', das werden die Werte unter '/test/totic/myreading' bzw. '/test/totic/state' übertragen.
Freiwilligen Tester bitte vor ;) Mich interessieren Meinungen, Kritik, Verbesserungsvorschläge. Aber bitte noch nicht für etwas produktives einsetzen, die Konfigurationsattribute werden sich recht wahrscheinlich noch ändern.
Viele Grüße
Alexander
Update: neue Version angehängt
Ja sehr cool! 8)
Werde ich spätestens morgen testen könne!
zwischen Weihnachten und Neujahr ist eine gute Zeit zum Testen!
So habe heute fleißig mit der Generic MQTT Bridge gespielt.
Was mir jetzt so noch so spontan fehlte:
- mqttTopic die Variable $name nutzen könnte
- ein autoPubReadings
Läuft sonst schon echt gut :)
Kannst du deinen Anwendungsfall beschreiben? Das zweite verstehe ich leider nicht, das erste erscheint mir nicht sinnvoll, denn der Name (des Devices?) steht ja eindeutig fest.
Zitat von: hexenmeister am 23 Dezember 2017, 15:59:43
Kannst du deinen Anwendungsfall beschreiben?
Klar, das ich bei diversen Devices das mqttTopic atrr setzten kann ohne jedes einzelnes separat zu setzt :)
Zitat von: hexenmeister am 23 Dezember 2017, 15:59:43
Das zweite verstehe ich leider nicht
Das optional alle Readings Publisht werden.
Ok, für das zweite würde ich eher den gleichen attr nehmen aber mit einem * anstatt Readingname. Lässt sich leicht realisieren. Das andere ist auch nicht schwer, ich würde aber irritierend finden, wenn sich bei Umbenennungen auch die topics mit ändern.
Zitat von: hexenmeister am 23 Dezember 2017, 17:27:23Das andere ist auch nicht schwer, ich würde aber irritierend finden, wenn sich bei Umbenennungen auch die topics mit ändern.
Ja das ist ein Argument dagegen, aber wenn es nicht zu viel Arbeit macht könnte man das mit aufnehmen ;D
Hallo Hexenmeister,
ich habe es auch installiert ..
was mich verwundert ..
attr HausStromZaehler_IEC_01 mqttPubNames energy power statEnergyDay statEnergyDayLast
*bei anderen attr wird hier meist ein Komma erwartet ..
Kann an dieser Stelle auch mit .* oder regex gearbeitet werden?
Ich würde es sinnvoll finden wenn die mqttTopic mit Variablen -> $room / $group / $model /$name und ähnlichem Zusammengesetz werden könnte.
Die Probleme mit dem umbenennen oder umziehen sind nicht von der Hand zu weisen aber ich denke es ist dennoch sinnvoll da sich so jeder nach seinem Gusto die MQTT organisieren kann ..
Insgesamt super das ich nun die Readings mit viel weniger aufwand an MQTT übergeben kann da ich die "Statusanzeige" mit Node Red in Angriff genommen habe ..
Danke dir für die Arbeit die du reinsteckst :)
Andreas
Fhem kennt hier leider keinen Standard. Es gibt Leerzeichen, Kommas, Doppelpunkte als Trenner... Man muss sich halt für irgendwas entscheiden.
Room, Name, Group verstehe ich. Was ist das Model?
Regex gehen nicht. Ein * denke ich zu unterstützen, komplett finde ich übertrieben.
Ja das mit den Standards bei der Benennung ist mir schon mehrfach aufgefallen - dann ist es hier halt mit Leerzeichen ..
Das Modell (attr HueKuecheDecke model LWB004) ist mir nur reingerutscht - und beim nachdenken halte ich es jetzt auch für Unsinn diese im Topic zu nutzen ..
Was mir noch eingefallen ist - ob es möglich ist auf der mqttGeneric device Seite eine Liste mit den Geräten zu machen die mit dem Modul assoziiert sind?
Gruß
Andreas
Zitat von: AndreasR am 23 Dezember 2017, 23:44:14
Was mir noch eingefallen ist - ob es möglich ist auf der mqttGeneric device Seite eine Liste mit den Geräten zu machen die mit dem Modul assoziiert sind?
Das hatte ich bereits auf dem Schirm :)
Auch eine Möglichkeit, den Prefix für die Attribute (mqttTopic, mqttPubNames,..) anstatt 'mqtt' änderbar zu machen.
Was spricht dagegen, alle fhem- Nachrichten zu mqtt zu übertragen? Mein Ziel wäre gerade, diese vielen Experten Definitionen von fhem nicht zu benötigen. GUI ist schöner und mit GUI meine ich nicht, im Webinterface zu programmieren.
Horst
Zitatvia Node Red eine aktuelle, attraktive und pflegeleichte Ansicht für das Tablett zu generieren
Kannst Du das bitte in einem neuen Thread zeigen/presentieren, um hier nicht offtopic zu werden?
Zitat von: dev0 am 25 Dezember 2017, 11:59:19
Kannst Du das bitte in einem neuen Thread zeigen/presentieren, um hier nicht offtopic zu werden?
Habe so etwas auch noch vor, daher melde Interesse :)
Sehr interessantes Thema hier, bzw. Themen.
Ich nutze Node Red im Zusammenhang mit Google Home und zur Kommunikation mit FHEM nutze ich mqtt...
Nach den Weihnachtstagen teste ich Mal hexenmeister's Modul...
Mit Node Red die Visualisierung zu machen klingt interessant...
Tapatalk iPhone, daher kurz gehalten.
Zitat von: AndreasR am 25 Dezember 2017, 11:13:20
Daher verstehe ich deinen Wunsch nach dem Stern * - vielleicht zaubert Hexenmeister ja einen rein ..
* für alle Readings eines Gerätes habe ich (etwas widerwillig ;D ) eingbaut. Für eine Stern für "alle Geräte und alle Readings" sehen ich jedoch wirklich nicht.
Zitat von: Harst am 24 Dezember 2017, 18:24:35
Was spricht dagegen, alle fhem- Nachrichten zu mqtt zu übertragen? Mein Ziel wäre gerade, diese vielen Experten Definitionen von fhem nicht zu benötigen. GUI ist schöner und mit GUI meine ich nicht, im Webinterface zu programmieren.
Nach meinem Verständnis spricht einiges dagegen, ich möchte jedoch meine Meinung nicht als Absolute Wahrheit verkaufen, jeder hat seine Vorstellungen und eigenen Einsatzzweck.
Für mich stellt MQTT-Schicht einen neuen Abstractionslevel dar, der rein von technischen Details der unteren Schochten sein soll. Vlt. wird es an einem Beispiel deutlicher:
Bei mir laufen mehrere Gerätearten im Haus. So wurde die nachträgliche Installation per Funk mit HomeMatic realisiert (weil alles andere viel zu großen Aufwand verursacht hätte), beim Ausbau habe ich jedoch drahtgebundene Installation mit EnOcean (Eltako) gewäht. Also habe ich parallel HomeMatic und Eltako Rolladenaktoren am Werk. Dummerweise verhalten sich diese nicht gleich. EnOcean verwendet für Rolladenpostion (logischerweise) 'position'-Eigenschaft, HomeMatic besteht jedoch auf 'pct'. Dann zählen die Beiden die Prozentwerde jeweils andersrum. Ich rechne daher alles in FHEM zu einem gemeinsamen Nenner um und übertrage über MQTT die Namen und Werte (in beide Richtungen natrülich) gleichartig. So muss die drüber liegende Schicht nicht wissen, welche Art Aktor installiert ist. Für sie sind alle Rolladen (Lichter, Heizung, Sensoren,..) immer gleich.
Insgesamt ist MQTT für mich eine Integrationschicht. Für jeden Bus läuft eine eigen FHEM-Instanz (meiste davon parallel auf einem RPI3), eine Instanz für die Logik (MQTT - rein, MQTT - raus), eine für die Visualisierung. Das schöne daran, man kann auch was ganz anderes darüber einbinden, z.B. habe ich mit dem IOBrocker mit seiner fortgeschrittenen Visualisierung gespielt. Würde gut funktionieren, hatte aber Stabilitätsprobleme mit der damaligen IOBrocker-Version.
Lange Rede... ich denke, wenn man einfach alles wahlfrei nach außen trägt, dann entsteht ein verteilter Riesenmischmasch, den man nicht mehr Herr werden kann.
P.S. NodeRed werkelt hier auch noich dazwischen, wird für Szenenbildung und Alexa-Anbindung genutzt.
ZitatLange Rede... ich denke, wenn man einfach alles wahlfrei nach außen trägt, dann entsteht ein verteilter Riesenmischmasch, den man nicht mehr Herr werden kann.
Ja und nein ;) jsonlist2 "exportiert" auch alles ohne weitere Parameter und es gibt kein Chaos ;) Das hängt einfach davon ab wie man es verarbeitet. Ich benutze MQTT zur Zeit nur sehr rudimentär, aber ein vollständiger Export hört sich (ohne tiefer darüber nachgedacht zu haben) erst einmal sehr interessant an um andere Systeme anbinden zu können.
Auch mit json bleiben bei einer generischen Alles-Übertragung verschiedenen benannte Readings mit unterschiedlich interpretierten Werten. Immer noch eine monolitische Aufbau und keine saubere Integrationsschicht. Finde ich immer noch unbeherrschbar und sehe keine Vorteile.
Etwas ähnliches habe ich vor ein paar wochen in das standardmodul integriert. https://forum.fhem.de/index.php/topic,81133.0.html
vor/nachteil (je nach Sichtweise) ist, dass die Topics nicht bei den Geräten konfiguriert werden sondern über Patterns auf der Bridge.
durch die devspec https://fhem.de/commandref_DE.html#devspec hat man mehr kontrolle darüber was exportiert wird. z.B. "room=kitchen" oder TYPE=FS20 oder reguläre ausdrücke
Habe ich gesehen. Aus meiner Sicht gehört das nicht in das Bridge-Modul, sondern ggf. in ein eigenes. Zu groß ist die Änderung der vorhandenen Funktionalität. Aber das ist natürlich meine Meinung.
Was Deine Lösung für mich unbrauchbar macht, ist die Tatsache, daß Gerätenamen in Topics verwendet werden. Genau das will ich ja mit der Schichtentrennung vermeiden. Weiterhin befürchte ich, dass bei mehreren Dutzenden von Geräten jegliche Übersicht flöten geht. Daher finde ich es auch besser an dem jeweiligen Gerät zu konfigurieren. Quasi an der Quelle. Und meine GenericBrigde ist dabei ein "define and forget"-Device.
Natürlich alles Frage der Sichtweise :)
P. S. Mache doch daraus ein neues Modul. Namensvorschlag: MQTT_GROUP
Mein Patch ändert eigentlich die Funktionalität garnicht, bringt das bridgemodul nur näher an den fhem standard, drum finde ich dafür ein eigenes modul overkill (und hätte viel duplicate code). Mal sehen :)
So wie ich MQTT nutze ist eigentlich als pseudo-Layer unterhalb von FHEM, also dort wo der globale eventloop angesiedelt ist. Damit kann man dann Geräte über mehere fhem instanzen verteilen und es ist egal wo das gerät läuft. Drum ist mir der name des mqtt topics egal weil mqtt ausschließlich von fhem genutzt wird. Bei deinem modul hab ich dasselbe Problem wie mit dem derzeitigen MQTT_BRIDGE: ich muss den gerätenamen 200x öfter in der config stehen haben, was zu fehlern und arbeit bei neuen geräten erzeugt, und will ihn eigentlich nur 1x definieren.
Finde es interessant wie unterschiedlich leute das naming machen ... warum muss in deinem Usecase der topicname unterschiedlich vom gerät sein?
Die Idee hinter deinem Modul erinnert mich an die von mir gestellte Anfängerfrage: warum definiere ich einen notify als eigenes Gerät und nicht einfach als Attribut am gerät "ontoggle". Ich denke mal modularisierung ist der Grund dafür.
Damit das ganze im FHEM gut funktioniert bräuchten aber mmn solche attribute einen prefix (z.b. attr DEVICE x-mqttGenericBridge-pubNames) damit es auf keinen fall mit nativen Attributen des gerätes selbst kollidiert. Das müsste mmn eine namenskonvention für modulentwickler sein die global gilt.
Um mehrere Usecases zu bedienen sollte dein mqttTopicPrefix attribut auch perlexpressions erlauben damit ich dann dort z.b. einfach den Gerätenamen oder ein bestimmtes attribut reinlegen kann.
Das * bei den Meldungen eines Gerätes scheint mir die Lösung für die Automatisierung zu sein. Also Ok. Sobald meine Installation wieder läuft teste ich das mal bei mir aus.
Alle zu übertragen war unüberlegt, denn viele Geräte sind sinnfrei. In der Oberfläche brauche ich die (echten) Schalter(Intertechno, FS20), nicht die Empfangshardware (CUL,SDuino)
Jetzt würde mir noch eine Liste der Geräte fehlen, die man dann als Basis in Node-Red verwursten kann.
Horst
Zitat von: blecher-at am 27 Dezember 2017, 01:45:54
Mein Patch ändert eigentlich die Funktionalität garnicht, bringt das bridgemodul nur näher an den fhem standard,
FHEM-Standards sind so 'ne Sache... Es gibt zu viele davon, oder keine, wie mas's mag... ABer das wir hier ein wenig OT. Ich antworte in Deinem alten Thread weiter (https://forum.fhem.de/index.php/topic,81133.0.html).
Zitat von: blecher-at am 27 Dezember 2017, 01:45:54
Finde es interessant wie unterschiedlich leute das naming machen ... warum muss in deinem Usecase der topicname unterschiedlich vom gerät sein?
Weil sie miteinander nichts zu tun haben. Vlt. sieht man das anhand eines Beispiels:
Gerätename (EnOcean, DImmer, Adresse 000018, installiert in der Unterverteilung in der Wohnzimmer auf dem Dachgeschoss): DG_WZ_DA_ENO_A18
Topic (Zustand): /ha/dg/wz/licht/seiten/level
Topic (zum Schalten): /ha/dg/wz/licht/seiten/set
Zitat von: blecher-at am 27 Dezember 2017, 01:45:54
Damit das ganze im FHEM gut funktioniert bräuchten aber mmn solche attribute einen prefix (z.b. attr DEVICE x-mqttGenericBridge-pubNames) damit es auf keinen fall mit nativen Attributen des gerätes selbst kollidiert. Das müsste mmn eine namenskonvention für modulentwickler sein die global gilt.
Prefix ist geplant und in Arbeit.
Zitat von: blecher-at am 27 Dezember 2017, 01:45:54
Um mehrere Usecases zu bedienen sollte dein mqttTopicPrefix attribut auch perlexpressions erlauben damit ich dann dort z.b. einfach den Gerätenamen oder ein bestimmtes attribut reinlegen kann.
Genau das finde ich nicht zielführend. Wozu soll das gut sein? (für den Namen des Geräts habe ich auf Wunsch dennoch eine Unterstützung eingebaut).
ZitatGerätename (EnOcean, DImmer, Adresse 000018, installiert in der Unterverteilung in der Wohnzimmer auf dem Dachgeschoss): DG_WZ_DA_ENO_A18
Das ist aus meiner Sicht unnötig kompliziert. Hersteller und Adresse haben im Gerätenamen nichts verloren, das steht ohnehin in der definition.
Was spricht dagegen, dein Gerät einfach "DG_WZ_Licht" zu nennen?
Was bringt mir das? In den Listen der Geräte ist mir wichtiger zu sehen, wo sie installiert sind und welche Technik dahinter steckt. Wenn ich einen Aktor ersetzen muss, nehme ich den nächten freien aus der Reserve ohne was umbenennen zu müssen. Hier hat die Verwendung nicht verloren. Genausowenig wie die Technik in der Bisiness logic. Principle separation of concerns.
Ich habe das bei meinen Geräten großteils über dummys gelöst. Das Gerät das dann über MQTT raussendet hat dann bereits den logischen Namen, bei einigen Geräten muss ich den State-inhalt umschreiben oder mehrere Geräte/States auf eines zusammenfassen.
Das durch MQTT zu ersetzen so wie du es machst finde ich eine sehr interessante Idee, ich hätte aber eine extra Schicht eingezogen, das wäre in deinem Fall also Hardwaregerät -> MQTT -> Integrationsschicht -> MQTT -> Businesslogik.
Die Topics am 1. Broker haben dann den technischen namen (den ich aber dennoch hersteller-agnostisch halten würde), am 2. broker dann die logischen.
Um wieder ontopic zu werden: 8)
Dein Modul unterstützt derzeit noch kein "set". Wäre das ein 2. attribut am Gerät oder über eine konvention/einstellung am hauptgerät zu realisieren?
Dummies nutze ich eigentlich fast gar nicht. Für solche Fälle habe ich ein eigenes Spezialmodul (https://forum.fhem.de/index.php/topic,79116.msg711686.html#msg711686). Ist etwas mächtiger. Jedoch möchte ich auch davon möglichst wenige haben, daher die Idee mit GenericBridge.
Zwei MQTT-Schichten? Welcher Vorteil kann man dabei erzielen? Ich finde, es macht wenig Sinn, mehrere FHEM-Intanzen so eng aneinander zu binden, dass alle Geräte quasi iberall vorhanden sind. Was soll man mit den 'fremden' Geräten machen, wenn business logic eh darüber liegt? Das wäre doch eigentlich nur ein unnötiger Netztzwerklast.
Das Modull soll publish und auch subscribe unterstützen (letzteres möchte ich noch einbauen, hatte nur noch leider keine Zeit für gefunden. Soll ähnlich wie mit subscribe konfiguriert werden).
Was genau soll ein 'set' machen? Oder meinst Du eben 'publish'?
Zitat von: dev0 am 25 Dezember 2017, 11:59:19
Kannst Du das bitte in einem neuen Thread zeigen/presentieren, um hier nicht offtopic zu werden?
+1 ;)
Hi,
hab mich in letzter Zeit auch ziemlich viel mit fhem und mqtt beschäftigt.
hab mir zb einen sketch zurechtgebastelt, der mehrere schalter und pirs bedient und je nach zustand ein relais schaltet (dämmerung, konfigurierbares timeout etc).
was mir dabei momentan nicht wirklich gefällt, ist die trennung zwischen publish und subscribe. wäre es nicht schöner, wenn man die beiden dinge zusammenfassen könnte?
Beispiel:
publish: blablub/set 1
subscribe: blablub/get --> das wäre toll, wenn das wieder auf das set zurückgespiegelt würde (im gleichen Reading)
Cheers,
Pula
Das kannst Du bereits jetzt realisieren (zwei mal den gleiche String verwenden). Halte ich jedoch nicht für sinnvoll. Wenn so von außen etwas empfangen wird und auch gesetzt wird, wird es ja gleich wieder gepublisht. So können unschöne Schleifen entstehen. Daher ist die Trennung zwischen 'get' und 'set' durchaus sinnvoll und auch gewollt.
Ok, verstehe ich. Stimmt auch wieder, daß hier Schleifen entstehen können, Du hast recht...
Vielleicht könnte man hier ein Attribut (donotrepublish oder so) einführen, um so etwas zu unterbinden?
Wäre ja nur bedingt hilfreich (Es gibt ja ggf. auch andere Teilnehmer im MQTT-Netzt). Ich halte eine generelle Trennung von 'setzen' und 'lesen' Attributen für sinnvoll. Läuft bei mir problemlos und stabil. Wofür genau benötigst Du das?
Es läuft bei mir eh auch gut und stabil. ich denke nur, daß es komfortabler sein könnte, Dinge zusammenzufassen.
Ein Beispiel:
Ich habe ein device, bei dem das topic vz/vz_licht_pir_active den Status setzt, dass die bewegungserkennung aktiv ist (aus fhem gesetzt, weil dunkel).
Das zugehörige Reading (subscribe) heisst vz/vz_licht_motion_activate_state. Das sind jetzt zwei Readings in dem device.
Schön wäre es, wenn man es einfach setzen könnte und die Rückmeldung vom device in das Reading einfliessen würde....
verstehe. leider funktioniert das modul derzeit so nicht.
;D Guten Abend,
Hexenmeister - verstehe ich deine Herangehensweise korrekt:
Ein Device in FHEM der direkt bei veränderung das in ein definiertes Topic schreibt mit defniertem State (on/off/true/false/ ... whatever)? :-)
Also pro Device, dass mit MQTT arbeitet ein Device in FHEM.
Ja, jedes FHEM-Device soll so konfiguriert werden können, dass Änderungen per MQTT gesendet werden. Auch andersherum ist geplant.
Jetzt muss ich noch Zeit finden, zu Ende zu bringen. Bin jetzt auf ner Dienstreise in München, hoffe habe nächste Woche etwas mehr Zeit.
;) Job geht vor 8)
Erlaube mir die vorsichtige Frage, was unterscheidet dein Modul von dem hier: https://forum.fhem.de/index.php/topic,27532.0.html ?
*EDIT ich ziehe die Frage zurück! - Exakt JEDES FHEM-Device soll so konfiguriert werden können. :-)
Also aktuell geht es nur in eine Richtung? Ich sehe bei MQTT was die Devices als State haben aber kann nicht sagen nun schalte um?
Zitat von: Master_Nick am 05 Februar 2018, 10:52:26
Also aktuell geht es nur in eine Richtung? Ich sehe bei MQTT was die Devices als State haben aber kann nicht sagen nun schalte um?
Geplant sind natürlich beide Richtungen. Es kommt nur immer etwas dazwischen, wenn ich mich daran setzen will :(
;)
Keine Angst so geht es vielen. Ich hab jetzt gerade meine ersten SonOffs in MQTT drin und hab sie seit einer Woche nur in so eingesteckt statt schon an Ort und Stelle verbaut ;-)
Der Einbau von Toggle wäre auch was feines ;)
Zitat von: Master_Nick am 15 Februar 2018, 20:25:08
Der Einbau von Toggle wäre auch was feines ;)
Was soll das genau tun?
Also gehen wir z. B. von on und off aus oder true und false, dann schaltet es zwischen beiden umher ohne einen von beiden zu nennen. Einfach aufgrund des aktuellen Zustands wird der ander gewählt.
Anwendung:
Ich habe einen Flic-Button der bei Klick das Zimmer in Wach- oder Schlafmodus schaltet (Kinderzimmer mit Babyphone und Lichtautomatik über Bewegungsmelder am Tag).
Aktuell gelöst mittels aufwändigem Notify - wäre machbar mittels einem Befehl wenn es Togglen könnte.
Man bräuchte nur sagen bei Click -> Toggle.
Für native MQTT Devices kam es auch erst vor kurzem ;-)
https://forum.fhem.de/index.php/topic,82240.msg743072.html#msg743072
out of scope für diesen Modul. Seine Aufgabe ist lediglich die Readingsänderungen zu übertragen, so wie die sind. Und auch die ankommnde Werte aufzunehmen. Jegliche Logik gehört in eine andere Domäne.
AH - Stimmt! hast absolut recht :-)
Jop müsste in das Modul was den eigentlich Device versorgt. Gut erkannt! :-) 8)
Habe jetzt endlich eine neue Testversion anzubieten. Hoffe auf flesiges Testen und Fehlerberichte :)
Diese Version ist konfigurationstechnish nicht mit dem ersten Wurf kompatibel.
Senden der Werte funktioniert schon aus meiner Sicht ganz gut.
Was noch gar nicht fertig ist: Empfangen (subscribe) und zentrale generische Konfiguration (damit man an einer Stelle definieren kann, dass (bestimmte) Readings aller Geräte nach bestimmten Schema gemappt und gesendet werden).
Etwas Doku:
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 befüllt.
Die (minimal) Konfiguration der Bridge selbst ist grundsätzlich sehr einfach.
Definition:
Im einfachsten Fall reichen schon zwei Zeilen:
defmod mqttGeneric MQTT_GENERIC_BRIDGE [prefix] [devspc]
attr mqttGeneric IODev <MQTT-Device>
Alle Parameterim Define sind optional.
Der erste ist ein Prefix für die Steuerattribute, worüber die zu überwachende Geräte (s.u.)
konfiguriert werden. Dafaultwert ist 'mqtt'.
Der zweite Parameter ('devspec') erlaubt die Menge der zu überwachenden Geräten
zu begrenzen (sonst werden einfach alle überwacht, was jedoch Performance kosten kann).
s.a. https://fhem.de/commandref_DE.html#devspec
Attribute:
IODev
Dieses Attribut ist obligatorisch und muss den Namen einer funktionierenden MQTT-Modulinstanz beinhalten.
Für die überwachten Geräte wird die Liste der möglichen Attribute automatisch um mehrere weitere Einträge ergänzt,
die alle mit vorher in der Bridge definierten Prefix anfangen. Über diese wird die eigentliche MQTT-Anbindung konfiguriert.
Defaultmäßig werden folgende Attribute verwendet: mqttDefaults, mqttAlias, mqttPublish, mqttSubscribe.
Sie haben folgende Bedeutung:
mqttDefaults
Hier wird eine Liste der "key=value"-Paare erwartet. Folgende Keys sind dabei möglich:
'qos' definiert ein Default für 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 Verfügung gestellt.
Sie kann entweder Text oder eine Perl-Expression enthalten.
Perl-Expression muss in Geschweifte Klammern eingeschlossen werden.
In einer Expression können Variablen verwendet werden.
($reading = Original-Readingname, $device = Devicename, $name = Readingalias (s. mqttAlias).
Ist keine Alias definiert, ist $name=$reading).
Alle diese werte können durch vorangestelle Prefixe ('pub:' oder 'sub') in ihrer Gültigkeit
nur auf das Senden bzw. Empfangen begrenzt werden. Werte für 'qos' und 'retain' werden nur verwendet,
wenn keine explizite Angaben darüber für ein konkretes Topic gemacht worden sind.
Beispiel:
attr <dev> mqttDefaults base={"/TEST/$device"} pub:qos=0 sub:qos=2 retain=0
mqttAlias
Dieses Attribut ermöglicht Readings unter einem anderen Namen auf MQTT-Topict zu mappen.
Nur sinnvoll, wenn Topicdefinitionen Perl-Expressions mit entsprechenden Variablen sind.
Auch hier werden 'pub:' und 'sub:' Prefixe unterstützt.
Beispiel:
attr <dev> mqttAlias pub:temperature=temp
mqttPublish
Hier werden konkrette Topics definiet und den Readings zugeordnet.
Weiterhin können diese einzeln mit 'qos'- und 'retain'-Flags versehen werden.
Topics können auch als Perl-Expression mit Veriablen definiert werden ($reading, $device, $name, $base).
Wird anstatt eines Readingsnamen ein '*' verwendet, gilt diese Definition für alle Readings,
für die keine explizite Angaben gemacht worden.
Beispiel:
attr <dev> temperature:topic={"$base/$name"} temperature:qos=1 temperature:retain=0 *:topic={"$base/$name"} humidity:topic=/TEST/Feuchte
mqttSubscribe
Dieses Attribut konfiguriert das Empfangen der MQTT-Nachrichten und deren Mapping auf die Attribute.
Die Konfiguration entspricht der für das 'mqttPublish'-Attribut.
Beispiel:
TODO
Beispiele:
Bridge für alle möglichen Geräte mit dem Standardprefix:
defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev mqtt
Bridge mit dem Prefix 'mqtt' für drei bestimmte Geräte:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt sensor1,sensor2,sensor3
attr mqttGeneric IODev mqtt
Bridge für alle Geräte 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 für 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 für eine zentralle Konfiguration in der Bridge für 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 für eine zentralle Konfiguration in der Bridge für alle Devices
(wegen schlechter Übersicht und einer unnötig großen 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"}
TODOs
- Subscribe ist noch nicht implementiert.
- globale Defaults in der Bridge selbst (zentral für alle überwachte Geräte) sind nicht implementiert
- damit beim Reconnect Subscriptions sauber wieder augebaut werden, ist ein Patch für IO (00_MQTT) notwendig (client_start und client_stop weiterreichen).
:)
So! Ich schnapp mir das jetzt mal und bau mal mein Heizungsthermostat auf MQTT um :-)
Ich berichte dann.
Wenn Du heute/gestern Update gemacht hast, wird es Probleme geben (Details hier: https://forum.fhem.de/index.php/topic,81765.msg772199.html#msg772199)
Ich stelle gleich eine neue Version hier rein.
Dann warte ich eben noch :-D
Probiere bitte diese Version.
Subscribe geht noch nicht, ist aber in Vorbereitung.
;D
Soo wenn das Subscribe noch geht ist es perfekt! 8) 8)
Habe mein Thermostat im Arbeitszimmer, Wohnzimmer und Kinderzimmer mal eben so auf MQTT gebaut.
Geht wirklich super einfach und ist absolut geil, dass man es IM Device und nicht woanders machen muss. So hat man alles genau da wo es hin gehört!
Große Klasse!
Es wartet nur noch auf das Subscribe ;D ;D
Hallo,
Das Beispiel funktioniert leider nicht da die Attribute wohl anders lauten:
Beispiel für eine zentralle Konfiguration in der Bridge für 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"}
Ich habe es dann so probiert:
defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev mqtt
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=0
attr mqttGeneric globalPublish temperature:topic={"/haus/$device/$reading"}
aber es wird nichts gepublished.
Muss bei den überwachten Geräten noch was eingestellt werden?
Gruß
Carlos
Siehe Anleitung: - globale Defaults in der Bridge selbst (zentral für alle überwachte Geräte) sind nicht implementiert ;D
Scheint noch nicht nutzbar zu sein was du vor hast :-) Aber nutze doch solange einfach den Weg hier... ist pro Sensor dann halt 2 attr.
Einfach jedem Gerät, dass du in der generic bridge in der def angibst attribute setzen.
Z. B.:
Mein Device hat als attr
mqttDefaults base={"homeland/haushalt/heizung/Aussenthermometer"} pub:qos=2 sub:qos=2 retain=1
mqttPublish temperature:topic={"$base/$name"} temperature:qos=2 temperature:retain=1 humidity:topic={"$base/$name"} humidity:qos=2 humidity:retain=1
Ansonsten sehe ich in der Anleitung das ganze ohne deine globalDefaults:
Beispiel für eine zentralle Konfiguration in der Bridge für 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"}
Du hast globalPublish genutzt.
Hallo,
Ja genau, das habe ich überlesen:
- globale Defaults in der Bridge selbst (zentral für alle überwachte Geräte) sind nicht implementiert
Den anderen Weg hatte ich schon probiert, das hat funktioniert.
Ich kann warten bis das implementiert ist.
Super modul bis jetzt.
Danke
Gruß
Carlos
Was ich noch nett finden für wenn man mehre Readings übergeben könnte.
z.B.
attr xxxx mqttPublish hvs|stateLight|rgb:topic={"Testing/$device/$name"}
Versteh ich was falsch?
Ich würde sagen, dass kann man doch.
mqttPublish desiredTemperature:topic={"$base/$name"} desiredTemperature:qos=2 desiredTemperature:retain=1 boost:topic={"$base/$name"} boost:qos=2 boost:retain=1 windowOpen:topic={"$base/$name"} windowOpen:qos=2 windowOpen:retain=1
Du musst halt nur den Eintag für jedes Reading wiederholen - das Ergebnis ist aber das gleiche.
Ja das stimmt, das finde ich aber total überladen.
Daher wünschte ich mir eine sparsamere Schreibweise.
Ok - dem Stimme ich zu als nice to have. :-) 8)
Aber, da das hier alles noch so neu ist, dass das subscribe noch nicht geht - würde ich sagen erst mal alles haben dann kann Feinschliff stattfinden :-)
Ist ja auch die Frage wieviel Umstellungsarbeit das im Modulcode so bedeuten würde *g*
Wir haben da eh gut reden - Hexenmeister legt ja hier die Glanzleistung ab. ;D ;D
Zitat von: Master_Nick am 28 Februar 2018, 14:04:41
Wir haben da eh gut reden - Hexenmeister legt ja hier die Glanzleistung ab. ;D ;D
Ja das Stimmt!
Bei mir müssten halt gute 40 Geräte auf mqtt geschoben werden, daher der Wunsch mir doch etwas Schreibarbeit zu sparen und auch der Übersicht zu liebe ;)
Hehe ja ich zieh auch gerade alles was Schaltbar ist oder Werte misst rüber auf MQTT für die Verwendung mit Node-RED. Das Modul hier ist super dafür (entstand glaub ich ein Stück weit in dem Node-Red Thread von mir 8) ).
Hier ist eine Version mit der Unterstützung für Publish-Attribute in der gewünschtenForm ;)
attr <dev> mqttPublish temperature|humidity:topic={"$base/$name"} temperature|humidity:qos=1 temperature|humidity:retain=0
globalPublish etc. geht schon fast, subscribe ist schon fast angefangen ;D
Zitat von: hexenmeister am 28 Februar 2018, 23:20:36
Hier ist eine Version mit der Unterstützung für Publish-Attribute in der gewünschtenForm ;)
globalPublish etc. geht schon fast, subscribe ist schon fast angefangen ;D
Das ist ja super, danke Dir! ;D
Hallo,
Gefällt mir schon sehr gut das modul.
Da kann man schon einiges mit machen.
Wäre es möglich hier:
In einer Expression können Variablen verwendet werden.
($reading = Original-Readingname, $device = Devicename, $name = Readingalias (s. mqttAlias).
noch z.B. den Raum( $room = Raum) dazu zu nehmen?
Gruß
Carlos
Zitat von: carlos am 01 März 2018, 13:50:32
Wäre es möglich hier:
In einer Expression können Variablen verwendet werden.
($reading = Original-Readingname, $device = Devicename, $name = Readingalias (s. mqttAlias).
noch z.B. den Raum( $room = Raum) dazu zu nehmen?
Man dürfte das aber nicht in den Globalen Definitionen zulassen, da ein Device mehrere Räume haben kann.
Dann vielleicht als Attribute bei den devices mqttRoom oder so was in der Art.
Zitat von: Shojo am 01 März 2018, 13:58:11
Man dürfte das aber nicht in den Globalen Definitionen zulassen, da ein Device mehrere Räume haben kann.
Daran habe ich auch schon gedacht.
Zitat von: carlos am 01 März 2018, 14:06:53
Dann vielleicht als Attribute bei den devices mqttRoom oder so was in der Art.
Wo ist dann ein Vorteil gegenüber einer Definition mit 'base'?
Man könnte aber die Variable $room in den Devices erlauben und füllen, oder?
attr <mqttGeneric> mqttDefaults base={"Haus"} pub:qos=0 sub:qos=0 retain=0
attr <dev> mqttPublish temperature|humidity:topic={"$base/$room/$name"}
Aber große Vorteile sehe ich da nicht, aber auch keine Nachteile ;)
Kann man ja dann einfach gleich in base Definition schreiben. Ich sehe bis jetzt immer noch keinen Vorteil.
Zitat von: hexenmeister am 01 März 2018, 15:14:15
Ich sehe bis jetzt immer noch keinen Vorteil.
Ich auch nicht wirklich :D
Ich möchte nur Raum mit in die publish Anweisung aufgenommen haben, dann kann man das z.B. in nodered gleich mit verarbeiten.
Allerdings sehe ich das Problem mit mehreren Räumen, deshalb als zusatzliches attribut am Device, das man dann evtl so nutzen könnte:
attr <dev> mqttRoom Wohnzimmer
attr <dev> mqttDefaults base={"/$mqttRoom/$device/$reading"}
Keine Ahnung ob sowas implementierbar ist.
Gruß
Carlos
Inplementierbar ist alles. Aber auch jede zusätzliche Anfrage kostet Leistung. Daher möchte ich alles vermeiden, was nocht unbedingt nötig ist.
Was spricht gegen
attr <dev> mqttDefaults base={"/Wohnzimmer/$device/$reading"}
?
Edit: Es müsste auch folgendes gehen:
attr <dev> mqttDefaults base={"/".AttrVal($device,'room','')."/$device/$reading"}
Ja, so geht es.
Gute Lösung, damit kann ich leben.
Gutes modul, damit kann mann mit notered ein schönes Frontend aufbauen.
Gruß
Carlos
;D Sobald nun das subscribe geht ;-) 8)
*Bettel*
So mal eine kleine Rückmeldung... :)
Aktuell werden bei mir 126 Topic´s Publish, läuft super stabil und es ist keine erhöhte Systemlast zu bemerken. 8)
Top weiter so! :)
Nächte Version. Subscribe geht noch nicht (sorry). Dafür Publish dürfte komplett sein.
Neu:
- globale Publish-Definitionen in der Bridge für alle Devices (muss man wissen, was man tut, sonst erzeugt man u.U. eine Flut von Meldungen).
- exclude-Attribute zum Auschliessen vom Versand Geräten, Readings und Gerätetypen.
Vorläufige Doku:
# 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 befüllt.
# Es wird ein <a href="#MQTT">MQTT</a>-Gerät als IODev benötigt.
#
# Die (minimal) Konfiguration der Bridge selbst ist grundsätzlich sehr einfach.
#
# Definition:
# Im einfachsten Fall reichen schon zwei Zeilen:
# defmod mqttGeneric MQTT_GENERIC_BRIDGE [prefix] [devspec]
# attr mqttGeneric IODev <MQTT-Device>
# Alle Parameterim Define sind optional.
# Der erste ist ein Prefix für die Steuerattribute, worüber die zu überwachende Geräte (s.u.)
# konfiguriert werden. Dafaultwert ist 'mqtt'.
# Wird dieser z.B. als 'hugo' redefiniert, heissen die Steuerungsattribute entsprechend hugoPublish etc.
# Der zweite Parameter ('devspec') erlaubt die Menge der zu überwachenden Geräten
# zu begrenzen (sonst werden einfach alle überwacht, was jedoch Performance kosten kann).
# s.a. https://fhem.de/commandref_DE.html#devspec
#
# Attribute:
# IODev
# Dieses Attribut ist obligatorisch und muss den Namen einer funktionierenden MQTT-Modulinstanz beinhalten.
#
# disable
# Wert 1 deaktiviert die Bridge
#
# Beispiel:
# attr <dev> disable 1
#
# globalDefaults
# Definiert Defaults, die greifen, falls in dem jeweiligen Gerät definierte Werte nicht greifen. s.a. mqttDefaults.
#
# globalAlias
# Definiert Alias, die greifen, falls in dem jeweiligen Gerät definierte Werte nicht greifen. s.a. mqttAlias.
#
# globalPublish
# Definiert Topics für die Übertragung per MQTT. Sie greifen, falls in dem jeweiligen Gerät definierte Werte nicht greifen. s.a. mqttPublish.
#
# globalTypeExclude
# Definiert (Geräte)Typen und Readings, die nicht übertragen werden.
# Ein einzelner Wert bedeutet, dass ein Gerätetyp mit diesem Namen komplett ignoriert wird (also für alle seine Readings).
# Durch ein Doppelpunkt getrennte Paare werden als Type:Reading interptretiert.
# Das Bedeutet, dass an dem gegebenen Type die genannte Reading nicht übertragen wird.
# Ein Stern anstatt Type oder auch Reading bedeutet, dass alle Readings eines Geretätüps
# bzw. genennte Readings an jeddem Gerätetyp ignoriert werden.
#
# Beispiel:
# attr <dev> globalTypeExclude MQTT MQTT_GENERIC_BRIDGE:* MQTT_BRIDGE:transmission-state *:baseID
#
# globalDeviceExclude
# Definiert Gerätenamen und Readings, die nicht übertragen werden.
# Ein einzelner Wert bedeutet, dass ein Geräte mit diesem Namen komplett ignoriert wird (also für alle seine Readings).
# Durch ein Doppelpunkt getrennte Paare werden als Device:Reading interptretiert.
# Das Bedeutet, dass an dem gegebenen Gerät die genannte Reading nicht übertragen wird.
#
# Beispiel:
# attr <dev> globalDeviceExclude Test Bridge:transmission-state
#
#
# Für die überwachten Geräte wird die Liste der möglichen Attribute automatisch um mehrere weitere Einträge ergänzt,
# die alle mit vorher in der Bridge definierten Prefix anfangen. Über diese wird die eigentliche MQTT-Anbindung konfiguriert.
#
# Defaultmäßig werden folgende Attribute verwendet: mqttDefaults, mqttAlias, mqttPublish, mqttSubscribe.
# Sie haben folgende Bedeutung:
# mqttDefaults
# Hier wird eine Liste der "key=value"-Paare erwartet. Folgende Keys sind dabei möglich:
# 'qos' definiert ein Default für 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 Verfügung gestellt.
# Sie kann entweder Text oder eine Perl-Expression enthalten.
# Perl-Expression muss in Geschweifte Klammern eingeschlossen werden.
# In einer Expression können Variablen verwendet werden.
# ($reading = Original-Readingname, $device = Devicename, $name = Readingalias (s. mqttAlias).
# Ist keine Alias definiert, ist $name=$reading).
#
# Alle diese werte können durch vorangestelle Prefixe ('pub:' oder 'sub') in ihrer Gültigkeit
# nur auf das Senden bzw. Empfangen begrenzt werden. Werte für 'qos' und 'retain' werden nur verwendet,
# wenn keine explizite Angaben darüber für ein konkretes Topic gemacht worden sind.
#
# Beispiel:
# attr <dev> mqttDefaults base={"/TEST/$device"} pub:qos=0 sub:qos=2 retain=0
#
# mqttAlias
# Dieses Attribut ermöglicht Readings unter einem anderen Namen auf MQTT-Topict zu mappen.
# Nur sinnvoll, wenn Topicdefinitionen Perl-Expressions mit entsprechenden Variablen sind.
# Auch hier werden 'pub:' und 'sub:' Prefixe unterstützt.
#
# Beispiel:
# attr <dev> mqttAlias pub:temperature=temp
#
# mqttPublish
# Hier werden konkrette Topics definiet und den Readings zugeordnet.
# Weiterhin können diese einzeln mit 'qos'- und 'retain'-Flags versehen werden.
# Topics können auch als Perl-Expression mit Veriablen definiert werden ($reading, $device, $name, $base).
# Werte fuer mehrere Readings können auch gemeinsam gleichzeitig definiert werden,
# indem sie, mittels '|' getrennt, zusammen angegeben werden.
# Wird anstatt eines Readingsnamen ein '*' verwendet, gilt diese Definition für alle Readings,
# für die keine explizite Angaben gemacht worden.
#
# Beispiel:
# 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
#
# mqttSubscribe
# Dieses Attribut konfiguriert das Empfangen der MQTT-Nachrichten und deren Mapping auf die Attribute.
# Die Konfiguration entspricht der für das 'mqttPublish'-Attribut.
#
# Beispiel:
# TODO
#
# mqttIgnore
# Wird dieses Attribut in einem Gerät gesetzt, wird dieses Geraet vom Versand der Readingswerten ausgeschlossen.
#
# Beispiele:
# Bridge für alle möglichen Geräte mit dem Standardprefix:
# defmod mqttGeneric MQTT_GENERIC_BRIDGE
# attr mqttGeneric IODev mqtt
#
# Bridge mit dem Prefix 'mqtt' für drei bestimmte Geräte:
# defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt sensor1,sensor2,sensor3
# attr mqttGeneric IODev mqtt
#
# Bridge für alle Geräte 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 für 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 für eine zentralle Konfiguration in der Bridge für 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 für eine zentralle Konfiguration in der Bridge für alle Devices
# (wegen schlechter Übersicht und einer unnötig großen 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"}
#
#
# TODOs
# - Subscribe ist noch nicht implementiert.
# - damit beim Reconnect Subscriptions sauber wieder augebaut werden, ist ein Patch für IO (00_MQTT) notwendig (client_start und client_stop weiterreichen).
Zitat von: hexenmeister am 05 März 2018, 00:04:44
# Beispiel für eine zentralle Konfiguration in der Bridge für 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"}
Ist es hier auch möglich per Regex auf Devices zu beschränken?
attr mqttGeneric publish .*/.Licht/..*:state:topic={"/haus/$device/$reading"} temperature:topic:topic={"/haus/$device/$reading"}
Nein
Kann man später überlegen, und wenn das Vorhandene nicht ausreicht, vlt. um Filter mit devspec ergänzen. Erstmal möchte ich mich aufs 'subscribe' konzentrieren.
Ja ist voll kommen in meinen Sinne ;)
Hallo,
Bei mir funktioniert das Ganze nur teilweise.
Ich beschreibe mal meine Konfig:
Internals:
.initialized 1
DEF TYPE=FBDECT,TYPE=CUL_HM,TYPE=CUL_TCM97001,TYPE=LaCrosse
IODev mqtt_ds916
NAME mqttGeneric
NR 1477
NTFY_ORDER 50-mqttGeneric
STATE outgoing publish sent
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix mqtt
prefix_old
.attraggr:
.attrminint:
READINGS:
2018-03-08 09:59:08 transmission-state outgoing publish sent
devices:
:global:
:publish:
FBDECT_fbahahttp_08761_0003236:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
topic {$base}
FBDECT_fbahahttp_24_65_11_C1_A7_05:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
topic {$base}
LaCrosse_00:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
topic {$base}
NC_WS_87:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
humidity:
topic {$base}
temperature:
topic {$base}
bz_Thermostat_Clima:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
topic {$base}
ez_Thermostat_Clima:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
topic {$base}
fz_Thermostat_Clima:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
topic {$base}
globalDeviceExcludes:
globalReadingExcludes:
globalTypeExcludes:
FHEMWEB *
Global *
MQTT transmission-state
MQTT_BRIDGE transmission-state
MQTT_DEVICE transmission-state
MQTT_GENERIC_BRIDGE *
telnet *
message_ids:
subscribe:
subscribeExpr:
Attributes:
IODev mqtt_ds916
icon mqtt
room MQTT
stateFormat transmission-state
Am Beispiel der FBDECT device sollten doch alle readings kommen.
Es kommen aber nur bei dem einen alle readings, bei dem 2. nur 3 oder 2 oder gar nur 1 reading:
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/power 0.00 W
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/FBNAME FP546E
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/locked no
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/FBPROP powerMeter,switch
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/devicelock no
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/ID 20000
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/mode manuell
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/fwversion 06.92
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/state off
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/FBTYPE FRITZ!Powerline 546E
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/AIN 24:65:11:C1:A7:05
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/present yes
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/energy 913889 Wh
/Alexa,FBDECT/FBDECT_fbahahttp_08761_0003236/power 0.00 W
/Alexa,FBDECT/FBDECT_fbahahttp_08761_0003236/temperature 15.0 C (measured)
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/ID 20000
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/fwversion 06.92
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/mode manuell
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/state off
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/FBTYPE FRITZ!Powerline 546E
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/present yes
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/AIN 24:65:11:C1:A7:05
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/energy 913889 Wh
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/FBNAME FP546E
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/power 0.00 W
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/locked no
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/FBPROP powerMeter,switch
/40_Schlafzimmer,Alexa,FBDECT/FBDECT_fbahahttp_24_65_11_C1_A7_05/devicelock no
/Alexa,FBDECT/FBDECT_fbahahttp_08761_0003236/power 0.00 W
Desweiteren wird bei den HM Thermostaten das state reading nicht richtig übermittelt. Es fehlt das reading state im topic:
/CUL_HM,70_Fernsehzimmer/fz_Thermostat_Clima/ValvePosition 0
/CUL_HM,70_Fernsehzimmer/fz_Thermostat_Clima/boostTime -
/CUL_HM,70_Fernsehzimmer/fz_Thermostat_Clima/controlMode auto
/CUL_HM,70_Fernsehzimmer/fz_Thermostat_Clima/desired-temp 21.0
/CUL_HM,70_Fernsehzimmer/fz_Thermostat_Clima/measured-temp 23.7
/CUL_HM,70_Fernsehzimmer/fz_Thermostat_Clima/partyEnd -
/CUL_HM,70_Fernsehzimmer/fz_Thermostat_Clima/partyStart -
/CUL_HM,70_Fernsehzimmer/fz_Thermostat_Clima/partyTemp -
/CUL_HM,70_Fernsehzimmer/fz_Thermostat_Clima/T 23.7 desired: 21.0 valve: 0
Gruß
Carlos
Bei State könnte ich mir denken, wo der Fehler liegen könnte. Das andere ist nicht logisch. Sagt mir erstmal nichts. Die Bridge behandelt alles Devices gleich. Sind an dem anderen FBDECT vielleicht mittels event-on-change-... die Notifies lahmgelegt?
Ich habe dir noch ein list der beiden devices angehängt.
Bei dem habe ich sogar ein event-on-change-reading drin.
Liegts vielleicht daran?
Internals:
.lastTimepower 1520509794.58204
CFGFN /opt/fhem/FHEM/fhem.fb.cfg
DEF fbahahttp:08761_0003236 powerMeter,tempSensor,switch
IODev fbahahttp
LASTInputDev fbahahttp
MSGCNT 59
NAME FBDECT_fbahahttp_08761_0003236
NR 243
STATE State:on, Power: 0.00 W,Temp: 16.0 C (measured)
TYPE FBDECT
fbahahttp_MSGCNT 59
fbahahttp_TIME 2018-03-08 12:49:54
id 08761_0003236
props powerMeter,tempSensor,switch
.attraggr:
.attreocr:
.*
.attrminint:
power:120
READINGS:
2018-03-08 12:49:54 AIN 08761 0003236
2018-03-08 12:49:54 FBNAME FRITZ!DECT 200 #1
2018-03-08 12:49:54 FBPROP powerMeter,tempSensor,switch
2018-03-08 12:49:54 FBTYPE FRITZ!DECT 200
2018-03-08 12:49:54 ID 16
2018-03-08 12:49:54 devicelock no
2018-03-08 12:49:54 energy 626949 Wh
2018-03-08 12:49:54 fwversion 03.87
2018-03-08 12:49:54 locked no
2018-03-08 12:49:54 mode manuell
2018-03-08 12:49:54 power 0.00 W
2018-03-08 12:49:54 present yes
2018-03-08 12:49:54 state on
2018-03-08 12:49:54 tempadjust 0.0 C
2018-03-08 12:49:54 temperature 16.0 C (measured)
Attributes:
IODev fbahahttp
alexaName WaschmaschinenDose
alexaRoom Abstellraum
alias WaschmaschinenDose
event-min-interval power:120
event-on-change-reading .*
genericDeviceType thermometer
icon scene_washing_machine
mqttDefaults base={"/".AttrVal($device,'room','')."/$device/$reading"}
mqttPublish *:topic={$base}
room Alexa,FBDECT
stateFormat State:state, Power: power,Temp: temperature
Internals:
.lastTimepower 1520509794.35641
CFGFN /opt/fhem/FHEM/fhem.fb.cfg
DEF fbahahttp:24_65_11_C1_A7_05 powerMeter,switch
IODev fbahahttp
LASTInputDev fbahahttp
MSGCNT 59
NAME FBDECT_fbahahttp_24_65_11_C1_A7_05
NR 249
STATE State:off Power: 0.00 W
TYPE FBDECT
fbahahttp_MSGCNT 59
fbahahttp_TIME 2018-03-08 12:49:54
id 24_65_11_C1_A7_05
props powerMeter,switch
.attraggr:
.attrminint:
power:120
READINGS:
2018-03-08 12:49:54 AIN 24:65:11:C1:A7:05
2018-03-08 12:49:54 FBNAME FP546E
2018-03-08 12:49:54 FBPROP powerMeter,switch
2018-03-08 12:49:54 FBTYPE FRITZ!Powerline 546E
2018-03-08 12:49:54 ID 20000
2018-03-08 12:49:54 devicelock no
2018-03-08 12:49:54 energy 913889 Wh
2018-03-08 12:49:54 fwversion 06.92
2018-03-08 12:49:54 locked no
2018-03-08 12:49:54 mode manuell
2018-03-08 12:49:54 power 0.00 W
2018-03-08 12:49:54 present yes
2018-03-08 12:49:54 state off
Attributes:
IODev fbahahttp
alexaName SchlafzimmerFernseher
alexaRoom Schlafzimmer
alias Schlafzimmer TV
event-min-interval power:120
genericDeviceType switch
icon ge_wht_steckdose
mqttDefaults base={"/".AttrVal($device,'room','')."/$device/$reading"}
mqttPublish *:topic={$base}
room 40_Schlafzimmer,Alexa,FBDECT
stateFormat State:state Power: power
Edit: Tatsächlich attribut gelöst und es geht.
Gruß
Carlos
Ja, logisch. Die GenericBridge bekommt (FHEM-typisch) eine Benachrichtigung, wenn ein Event getriggert wird. Mit dem event-on-change unterbindest Du alle Events, die zu keiner Änderung führen, zusätzlich hast Du auch die Häufigkeit begrenzt. Es wird schon auch so funktionieren, die Werte kommen halt erst wenn sie zum ersten Mal geändert werden.
ich habe das Modul in der version 0.2.1 by hexenmeister laufen.
Beim Setzten des Attributes mqttDefaults bekomme ich die FM:
this attribute is not allowed here
Wieso nicht ?
;) Bitte mal etwas mehr Info.
- Wo willst du es setzen?
- List vom Device?
Du hast die Bridge so konfiguriert, dass sie alle Geräte erfasst, auch sich selbst. Also (über Global) bekommt sie leider auch diese Attrbute, die jedoch nur für die von Ihr überwachte Geräte gedacht sind. Daher sind sie hier nicht erlaubt. Für die Global-Dafaults geibt es entsprechende globalDefault Attribute.
Zitat von: hexenmeister am 08 März 2018, 22:54:02
Du hast die Bridge so konfiguriert, dass sie alle Geräte erfasst, auch sich selbst. Also (über Global) bekommt sie leider auch diese Attrbute, die jedoch nur für die von Ihr überwachte Geräte gedacht sind. Daher sind sie hier nicht erlaubt. Für die Global-Dafaults geibt es entsprechende globalDefault Attribute.
Alles klar, verstehe.
Danke und Gruß
Habe mal eine Frage/Idee zur geplanten Entwicklung zum "subscriben".
Macht das subscriben von Readings überhaupt Sinn?
Zwar kann man mit setreading Werte von FHEM Geräte setzen aber üblicherweise steuert man seine Geräte doch mit set.
haus-automatisierung.com macht das in seinem Video https://www.youtube.com/watch?v=mlbHKofniNU (https://www.youtube.com/watch?v=mlbHKofniNU) so dass er den kompletten FHEM-Befehl übergibt.
Dadurch kann er auch andere Befehle wie update all etc. übergeben. Dann muss beim Sender (z.B. Node-Red) die Logik zum Zusammenbau der Steuerbefehle liegen.
@Hexenmeister: Hast du da schon einen Ansatz? Habe ich etwas übersehen?
Also wie man am Ende seinen Device steuern muss hängt ja sehr vom genutzten oder selbst geschriebenen Programm ab.
Aktuell ist ja es so, FHEM kann selber Nicht MQTT Devices mittels der Bridge in MQTT bekannt machen/publishen aber bekommt Steuerung von außen für diese Devices nicht mit.
Wenn man nun schon andere echte MQTT Devices nutzt (SonOff etc) dann wäre es aus meiner persönlichen Sicht sehr unpraktisch da nun spezial Befehle zu nutzen.
Ggf schaust du dir mal die Steuerung von echten MQTT Devices mittels FHEM an - Ich denke und hoffe, dass hexenmeister sich da großteils in der Richtung bewegt *g* :-D
Ich steure da mit /Mein/Topic/Gerät/set on off und mappe es zu true und false oder es sind Thermostate dann gibt es Werte und wieder ein Mapping.
Sofern ich natürlich deinen Post nicht einfach falsch verstanden habe :-D
Zitat von: LuBeDa am 18 März 2018, 17:54:14
Dadurch kann er auch andere Befehle wie update all etc. übergeben. Dann muss beim Sender (z.B. Node-Red) die Logik zum Zusammenbau der Steuerbefehle liegen.
@Hexenmeister: Hast du da schon einen Ansatz? Habe ich etwas übersehen?
Das ginge jetzt schon ohne komplexe Notify-Logik.
MQTT_DEVICE unterstützt schon eine Weile direkt eine Perl-Expression in dem Subscribe Attribut.
attr <name> subscribeReading_<reading> [{Perl-expression}] [qos:?] [retain:?] <topic>
(s. https://fhem.de/commandref.html#MQTT_DEVICE)
Damit kann man natürlich Message-Inhalt an fhem(...)-Befehl übergeben.
Ob und wie das in die Bridge reinkommt... weiß ich noch nicht, vlt. auf eine ähnliche Weise.
Die Entwicklung stockts gerade ein wenig, aufgrund paar persönnlichen Umstände hatte ich noch nicht genug Zeit "am Stück" finden können. :(
Hehe :-)
So spielt das Leben - Hab gerade heute meinen Touch-Monitor endlich eingefasst und montagefertig gemacht... lag hier seit Dezember.
Moin moin,
gibt es mittlerweile was neues zum Modul? :)
Gruß
Dennis
Bin gerade leider stark anderweitig eingebunden :(
Eine brauchbare Version mit "subscribe"-Unterstützung kann ich leider noch nicht anbieten.
Es bewegt sich aber weiter, auch wenn deutlich langsamer, als ich mir wünschen würde.
Da kann man leider nicht viel machen ;)
Danke dir für die Info!
Danke für die Geduld, ich hoffe bald bessere Nachrichte zu bringen :)
Alles gut!
Wir warten geduldig - gibt halt wichtigere Dinge :-)
Ja bitte nicht stressen lassen, soll doch noch alles Spaß machen hier :)
Dank deiner Erweiterung am MQTT_DEVICE, konnte ich das so auch wunderbar umsetzt 8)
Zitat von: hexenmeister am 18 März 2018, 20:35:57
MQTT_DEVICE unterstützt schon eine Weile direkt eine Perl-Expression in dem Subscribe Attribut.
attr <name> subscribeReading_<reading> [{Perl-expression}] [qos:?] [retain:?] <topic>
Hier ist eine erste funktionsfähige Version mit Subscribe-Unterstützung. Noch keine Wildcards und sonstige Extras.
Es geht lediglich eine eindeutige Topic-Definition in Form:
attr <dev> mqttSubscribe <reading>:topic=<topic>
Mein Testbeispiel:
defmod mqGenTest dummy
attr mqGenTest mqttSubscribe test:topic=/TEST/test/state
Sendet man jetzt etwas auf den Topic '/TEST/test/state' bekommt mqGenTest ein neues Reading (falls noch nicht vorhanden) und es wird der Wert der Nachricht reingeschrieben.
Pfoaa geil! Da kommst du genau heute mit, wo ich alle Thermostate auf Nest Optik umgebaut habe :-D
GEIL teste ich morgen! 8) 8) 8) 8) 8)
Nest Optik in Node Red: 8) https://forum.fhem.de/index.php/topic,78512.msg793661.html#msg793661
Funktioniert bei mir echt super :-) 8) 8)
Freut mich :)
Wird noch besser 8)
Ich entdecke gerade ein Problem in meinem Setup, ich habe noch in direkter Nähe am nanoCUL einige IT - V1 und V3 433 Dinger. Diese in MQTT eingebunden ergeben eine Änderung bei state, aber eine Schaltung passiert aufgrund dieser Änderung nicht. Ich bin mir gerade unklar wo nun der Knackpunkt liegt IT oder fehlt noch ein Eventmap oder so :-D
Internals:
00 f0
CFGFN
DEF 000000000F FF F0
IODev nanoCUL
NAME Spot
NR 49
STATE off
TYPE IT
XMIT 000000000f
XMITdimdown 00
XMITdimup 00
XMITon ff
CODE:
1 000000000f
READINGS:
2017-02-10 17:58:18 protocol V1
2018-04-16 22:34:30 state off
Attributes:
IODev nanoCUL
alexaName Spot
alexaRoom Wohnzimmer
genericDeviceType light
group Licht
icon light_ceiling
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:topic=homeland/haushalt/elektrik/wohnzimmer/Spot/state/set
room Echo,Wohnzimmer
Mhh ich prüfe mal - nicht, dass nun ein FHEM Update was hier mit der Bridge gemacht hat... aber aktuell schaltet eine Veränderung im MQTT Topic am Ende nichts... das Reading wird verändert auf FHEM Seite aber es passiert keine Reaktion von FHEM auf das geänderte Reading und somit wird am Thermostat nix gemacht.
Das gleiche habe ich bei 433 Intertechno Geräten ja bereits beobachtet. Seltsam, beim Thermostat ging es eigentlich O_o
EDIT: Also ich habe nun alle Dateien nochmal geprüft auf aktuellen Stand. Am 26.04. wurde ja noch was ins Repo eingecheckt (Thread "Patch für mehrere Probleme mit Topics und Payload") es scheint als wäre nun irgendwas nicht mehr wie vorher.
Vorher wurde das Reading geändert über mqttSubscribe und daraufhin hatte FHEM bisher getriggert und im Modul gingen die Vorgänge los und das Thermostat wurde auf die über MQTT gesetzte Temperatur gesetzt.
Nun sehe ich lediglich ja Reading wird geändert - es kommt sogar das mqttPublish zum tragen (angezeigt wird in Node-RED alles korrekt) aber die Funktion die das Reading zum Thermometer bringt... da ist irgendwie was anders - am Modul vom Thermometer wurde nix gemacht seit geraumer Zeit. Es kommt dann dazu, dass das Thermostat in eine regelmäßigen Zeit immer zum Updatestatement angeregt wird und dann merkt man es wurde gar nichts verändert.
Leider verstehe ich das Problem so nicht. Kannst Du bitte die Konfiguration posten, damit ich das nachstellen kann?
;) Aber sicher doch ;D
Eines meiner Thermostate:
Internals:
CFGFN
DEF 00:1A:22:0C:E8:EA TouchPi3
MAC 00:1A:22:0C:E8:EA
NAME Arbeitszimmer_Thermostat
NR 136
STATE Gewünschte Temperatur: 19.0 Fenster auf/zu: 0 Boost: 0
TYPE EQ3BT
VERSION 2.0.4
loglevel 4
READINGS:
2018-02-24 15:08:25 battery ok
2018-04-29 18:57:52 bluetoothDevice hci0
2018-04-05 11:12:28 boost 0
2018-04-28 19:51:46 childlock 0
2018-04-26 11:17:46 consumption 619.074
2018-04-29 00:03:51 consumptionToday 0.000
2018-04-29 00:00:32 consumptionYesterday 0
2018-04-29 19:43:45 desiredTemperature 19.0
2018-02-24 15:08:25 ecoMode 0
2018-04-28 00:55:31 errorCount-setDesiredTemperature 0
2018-04-28 00:55:31 errorCount-updateStatus 0
2018-04-28 00:55:31 errorCount-updateSystemInformation 0
2018-04-29 20:54:10 firmware 110
2018-04-29 19:43:45 lastChangeBy FHEM
2018-02-24 15:08:25 mode Manual
2018-04-29 21:39:32 valvePosition 0
2018-03-29 12:16:18 windowOpen 0
helper:
currenthcidevice 0
handlesetDesiredTemperature 0x0411
handleupdateStatus 0x0411
handleupdateSystemInformation 0x0411
listensetDesiredTemperature
listenupdateStatus 02 01 09 00 04 26
listenupdateSystemInformation 01 6e 00 00 7f 75 81 61 67 65 60 67 60 68 9a
retryCounterHci0 0
retryCountersetDesiredTemperature 0
retryCounterupdateStatus 0
retryCounterupdateSystemInformation 0
valuesetDesiredTemperature 4126
valueupdateStatus 0312041D1527
valueupdateSystemInformation 00
hcidevices:
0
Attributes:
group Heizung
icon sani_heating
mqttDefaults base={"homeland/haushalt/heizung/$device"} pub:qos=2 sub:qos=2 retain=1
mqttPublish desiredTemperature:topic={"$base/$name"} desiredTemperature:qos=2 desiredTemperature:retain=1 boost:topic={"$base/$name"} boost:qos=2 boost:retain=1 windowOpen:topic={"$base/$name"} windowOpen:qos=2 windowOpen:retain=1
mqttSubscribe desiredTemperature:topic=homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature/set
room Arbeitszimmer,Messungen
sshHost TouchPi3
stateFormat Gewünschte Temperatur: desiredTemperature Fenster auf/zu: windowOpen Boost: boost
Die Generic Bridge:
Internals:
CFGFN
DEF mqtt Arbeitszimmer_Thermostat Wohnzimmer_Thermostat Kinderzimmer_Thermostat Schlafzimmer_Thermostat Flur_Thermostat Arbeitszimmer_Sensor_3 Badezimmer_Sensor_1 Balkon_Sensor_6 Kinderzimmer_Sensor_2 Schlafzimmer_Sensor_4 Wohnzimmer_Sensor_5 Rehau Heizungssteuerung Spot Streifen
IODev MQTT_Broker
NAME mqttGeneric
NR 141
NTFY_ORDER 50-mqttGeneric
STATE outgoing publish completed
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix mqtt
prefix_old
READINGS:
2018-04-29 21:46:38 transmission-state outgoing publish completed
devices:
Arbeitszimmer_Sensor_3:
:defaults:
pub:base {"homeland/haushalt/heizung/Arbeitszimmer_Thermostat"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/Arbeitszimmer_Thermostat"}
sub:qos 2
sub:retain 1
:publish:
humidity:
qos 2
retain 1
topic {"$base/$name"}
temperature:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
Arbeitszimmer_Thermostat:
:defaults:
pub:base {"homeland/haushalt/heizung/$device"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/$device"}
sub:qos 2
sub:retain 1
:publish:
boost:
qos 2
retain 1
topic {"$base/$name"}
desiredTemperature:
qos 2
retain 1
topic {"$base/$name"}
windowOpen:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
desiredTemperature:
topic homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature/set
topicExp ^homeland\/haushalt\/heizung\/Arbeitszimmer_Thermostat\/desiredTemperature\/set$
Badezimmer_Sensor_1:
:defaults:
pub:base {"homeland/haushalt/heizung/Badezimmer_Thermostat"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/Badezimmer_Thermostat"}
sub:qos 2
sub:retain 1
:publish:
humidity:
qos 2
retain 1
topic {"$base/$name"}
temperature:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
Balkon_Sensor_6:
:defaults:
pub:base {"homeland/haushalt/heizung/Aussenthermometer"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/Aussenthermometer"}
sub:qos 2
sub:retain 1
:publish:
humidity:
qos 2
retain 1
topic {"$base/$name"}
temperature:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
Flur_Thermostat:
:defaults:
pub:base {"homeland/haushalt/heizung/$device"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/$device"}
sub:qos 2
sub:retain 1
:publish:
boost:
qos 2
retain 1
topic {"$base/$name"}
desiredTemperature:
qos 2
retain 1
topic {"$base/$name"}
windowOpen:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
desiredTemperature:
topic homeland/haushalt/heizung/Flur_Thermostat/desiredTemperature/set
topicExp ^homeland\/haushalt\/heizung\/Flur_Thermostat\/desiredTemperature\/set$
Heizungssteuerung:
:defaults:
pub:base {"homeland/haushalt/heizung/$device"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/$device"}
sub:qos 2
sub:retain 1
:publish:
state:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
state:
topic homeland/haushalt/heizung/Heizungssteuerung/state/set
topicExp ^homeland\/haushalt\/heizung\/Heizungssteuerung\/state\/set$
Kinderzimmer_Sensor_2:
:defaults:
pub:base {"homeland/haushalt/heizung/Kinderzimmer_Thermostat"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/Kinderzimmer_Thermostat"}
sub:qos 2
sub:retain 1
:publish:
humidity:
qos 2
retain 1
topic {"$base/$name"}
temperature:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
Kinderzimmer_Thermostat:
:defaults:
pub:base {"homeland/haushalt/heizung/Kinderzimmer_Thermostat"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/Kinderzimmer_Thermostat"}
sub:qos 2
sub:retain 1
:publish:
boost:
qos 2
retain 1
topic {"$base/$name"}
desiredTemperature:
qos 2
retain 1
topic {"$base/$name"}
windowOpen:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
desiredTemperature:
topic homeland/haushalt/heizung/Kinderzimmer_Thermostat/desiredTemperature/set
topicExp ^homeland\/haushalt\/heizung\/Kinderzimmer_Thermostat\/desiredTemperature\/set$
Rehau:
:defaults:
pub:base {"homeland/haushalt/heizung/Wohnzimmer_Thermostat"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/Wohnzimmer_Thermostat"}
sub:qos 2
sub:retain 1
:publish:
voc:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
Schlafzimmer_Sensor_4:
:defaults:
pub:base {"homeland/haushalt/heizung/Schlafzimmer_Thermostat"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/Schlafzimmer_Thermostat"}
sub:qos 2
sub:retain 1
:publish:
humidity:
qos 2
retain 1
topic {"$base/$name"}
temperature:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
Schlafzimmer_Thermostat:
:defaults:
pub:base {"homeland/haushalt/heizung/$device"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/$device"}
sub:qos 2
sub:retain 1
:publish:
boost:
qos 2
retain 1
topic {"$base/$name"}
desiredTemperature:
qos 2
retain 1
topic {"$base/$name"}
windowOpen:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
desiredTemperature:
topic homeland/haushalt/heizung/Schlafzimmer_Thermostat/desiredTemperature/set
topicExp ^homeland\/haushalt\/heizung\/Schlafzimmer_Thermostat\/desiredTemperature\/set$
Spot:
:defaults:
pub:base {"homeland/haushalt/elektrik/wohnzimmer/$device"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/elektrik/wohnzimmer/$device"}
sub:qos 2
sub:retain 1
:publish:
state:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
state:
topic homeland/haushalt/elektrik/wohnzimmer/Spot/state/set
topicExp ^homeland\/haushalt\/elektrik\/wohnzimmer\/Spot\/state\/set$
Streifen:
:defaults:
pub:base {"homeland/haushalt/elektrik/wohnzimmer/$device"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/elektrik/wohnzimmer/$device"}
sub:qos 2
sub:retain 1
:publish:
state:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
state:
topic homeland/haushalt/elektrik/wohnzimmer/Streifen/state/set
topicExp ^homeland\/haushalt\/elektrik\/wohnzimmer\/Streifen\/state\/set$
Wohnzimmer_Sensor_5:
:defaults:
pub:base {"homeland/haushalt/heizung/Wohnzimmer_Thermostat"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/Wohnzimmer_Thermostat"}
sub:qos 2
sub:retain 1
:publish:
humidity:
qos 2
retain 1
topic {"$base/$name"}
temperature:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
Wohnzimmer_Thermostat:
:defaults:
pub:base {"homeland/haushalt/heizung/$device"}
pub:qos 2
pub:retain 1
sub:base {"homeland/haushalt/heizung/$device"}
sub:qos 2
sub:retain 1
:publish:
boost:
qos 2
retain 1
topic {"$base/$name"}
desiredTemperature:
qos 2
retain 1
topic {"$base/$name"}
windowOpen:
qos 2
retain 1
topic {"$base/$name"}
:subscribe:
desiredTemperature:
topic homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set
topicExp ^homeland\/haushalt\/heizung\/Wohnzimmer_Thermostat\/desiredTemperature\/set$
globalDeviceExcludes:
globalReadingExcludes:
globalTypeExcludes:
FHEMWEB *
Global *
MQTT transmission-state
MQTT_BRIDGE transmission-state
MQTT_DEVICE transmission-state
MQTT_GENERIC_BRIDGE *
telnet *
message_ids:
subscribe:
homeland/haushalt/elektrik/wohnzimmer/Streifen/state/set
homeland/haushalt/heizung/Kinderzimmer_Thermostat/desiredTemperature/set
homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature/set
homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set
homeland/haushalt/heizung/Flur_Thermostat/desiredTemperature/set
homeland/haushalt/heizung/Heizungssteuerung/state/set
homeland/haushalt/heizung/Schlafzimmer_Thermostat/desiredTemperature/set
homeland/haushalt/elektrik/wohnzimmer/Spot/state/set
subscribeExpr:
^homeland\/haushalt\/elektrik\/wohnzimmer\/Streifen\/state\/set$
^homeland\/haushalt\/heizung\/Kinderzimmer_Thermostat\/desiredTemperature\/set$
^homeland\/haushalt\/heizung\/Arbeitszimmer_Thermostat\/desiredTemperature\/set$
^homeland\/haushalt\/heizung\/Wohnzimmer_Thermostat\/desiredTemperature\/set$
^homeland\/haushalt\/heizung\/Flur_Thermostat\/desiredTemperature\/set$
^homeland\/haushalt\/heizung\/Heizungssteuerung\/state\/set$
^homeland\/haushalt\/heizung\/Schlafzimmer_Thermostat\/desiredTemperature\/set$
^homeland\/haushalt\/elektrik\/wohnzimmer\/Spot\/state\/set$
subscribeQos:
homeland/haushalt/elektrik/wohnzimmer/Spot/state/set 0
homeland/haushalt/elektrik/wohnzimmer/Streifen/state/set 0
homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature/set 0
homeland/haushalt/heizung/Flur_Thermostat/desiredTemperature/set 0
homeland/haushalt/heizung/Heizungssteuerung/state/set 0
homeland/haushalt/heizung/Kinderzimmer_Thermostat/desiredTemperature/set 0
homeland/haushalt/heizung/Schlafzimmer_Thermostat/desiredTemperature/set 0
homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set 0
Attributes:
IODev MQTT_Broker
room Technikraum
stateFormat transmission-state
Und wenn ich nun per Node-Red (oder mosquitto pub) den Wert für das Thermostat in Topic "homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set" auf 4.5 Stelle sehe ich, wie in FHEM das Reading auf 4.5 wechselt aber es wird nichts getan - kein Prozess startet. Als würde ein Set Reading gemacht ohne einen Trigger auszulösen. Es ging ja ne ganze Zeit - es muss also was geändert worden sein in FHEM (muss ja nicht mal deine Brdige sein).
Sobald dann die routinemäíge Abfrage des Status für die Thermostate erfolgt, sieht man es hat sich nix geändert und der Wert wird auch von FHEM wieder auf das gesetzt, was das Thermostat mitteilt.
Setzten der Temperatur direkt in FHEM funktioniert ohne Probleme - entweder über die GUI oder mit "set Arbeitszimmer_Thermostat desiredTemperature 4.5".
Bei meinen Funkschaltern das gleiche - Reading wird auf on gesetzt passieren tut aber nichts.
Funkschalter:
Internals:
00 f0
CFGFN
DEF 000000000F FF F0
IODev nanoCUL
NAME Spot
NR 49
STATE off
TYPE IT
XMIT 000000000f
XMITdimdown 00
XMITdimup 00
XMITon ff
CODE:
1 000000000f
READINGS:
2017-02-10 17:58:18 protocol V1
2018-04-29 21:45:08 state off
Attributes:
IODev nanoCUL
alexaName Spot
alexaRoom Wohnzimmer
genericDeviceType light
group Licht
icon light_ceiling
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:topic=homeland/haushalt/elektrik/wohnzimmer/Spot/state/set
room Echo,Wohnzimmer
So eine EQ3BT-Dingens habe ich nicht, kann daher nur mit Dummies & Co. testen. Es wird bei mir alles korrekt getriggert. Probiere mal aus, ob du die Events in dem EventMonitor sehen kannst. Ich vermute eher, dass das Gerät über haupt nichts ausführt, wen nur Reading gesetzt wird (war das Modul ja auch macht).
Probiere aus, ob folgendes Befehl etwas sinnvolles bewirkt (vermutlich nicht):
{readingsSingleUpdate($defs{'Arbeitszimmer_Thermostat'},'desiredTemperature','4.5',1)}
Ich habe bereits eine neuere Version, die nicht nur Readings setzen, sondern auch 'set'-Befehle ausführen kann. Ich muss diese noch etwas aufräumen, dann stelle ich sie hier zur Verfügung.
Wenn es früher funktioniert hat, würde ich eher Änderungen in dem EQ3BT-Modul vermuten.
Hier ist eine neue (noch sehr unreife) Testversion.
Unterstützung für subscribe soll (am Ende) folgendermaßen aussehen:
# mqttSubscribe
# Dieses Attribut konfiguriert das Empfangen der MQTT-Nachrichten und deren Mapping auf die Attribute.
# Die Konfiguration ist aehnlich der für das 'mqttPublish'-Attribut. Es können topics fuer das Setzen von Readings ('topic'),
# Aufrufe von 'set'-Befehl an dem Geraet ('stopic') und 'qos' definiert 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 tatsaechlicher Name der Reading (und ggf. des Geraetes) wird dabei durch Variablen in 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.
#
# Beispiel:
# 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"}
Ausführung von 'set' klappt schon, Wildcards funktionieren generell noch nicht korrekt.
Die letzte Version haut mir leider mein log file zu mit immer wieder kehrenden Ereignissen sobald ich es Einpflege:
'cam_alle' => {
':defaults' => {
'pub:base' => '{"/$device/$reading"}',
'sub:base' => '{"/$device/$reading"}'
},
':publish' => {
'*' => {
'topic' => '{$base}'
}
}
},
'ez_led' => {
':defaults' => {
'pub:base' => '{"/$device/$reading"}',
'sub:base' => '{"/$device/$reading"}'
},
':publish' => {
'*' => {
'topic' => '{$base}'
}
}
},
'rollo_ba' => {
':defaults' => {
'pub:base' => '{"/$device/$reading"}',
'sub:base' => '{"/$device/$reading"}'
},
':publish' => {
'*' => {
'topic' => '{$base}'
}
}
},
'rollo_bu_f' => {
':defaults' => {
'pub:base' => '{"/$device/$reading"}',
'sub:base' => '{"/$device/$reading"}'
},
':publish' => {
'*' => {
'topic' => '{$base}'
}
}
},
'rollo_bu_t' => {
':defaults' => {
'pub:base' => '{"/$device/$reading"}',
'sub:base' => '{"/$device/$reading"}'
},
':publish' => {
'*' => {
'topic' => '{$base}'
}
}
},
'rollo_ez' => {
':defaults' => {
'pub:base' => '{"/$device/$reading"}',
'sub:base' => '{"/$device/$reading"}'
},
':publish' => {
'*' => {
'topic' => '{$base}'
}
}
},
das ist nur eine kurze Ausführung
so sieht eine definition bei mir aus:
Internals:
BTN 00
DEF 243b 00
IODev CUL
NAME wz_stehlampe
NR 83
STATE off
STILLDONETIME 0
TYPE FS20
XMIT 243b
CODE:
1 243b 00
READINGS:
2018-05-01 07:56:48 state off
Attributes:
IODev CUL
comment Untoggle
follow-on-for-timer 1
genericDeviceType switch
model fs20st
mqttDefaults base={"/$device/$reading"}
mqttPublish *:topic={$base}
mqttSubscribe state:stopic=/$device/$reading *:stopic={"/TEST/$reading/value"}
room FS20,Wohnzimmer
Ist ja auch eine Testversion ;D Mit Testausgaben eben. Im Anhang eine ohne.
Die Platzhalter für Subscribe tun noch nicht korrekt.
Funktioniert es wenn Du es konkret definierst?
Zitat von: hexenmeister am 01 Mai 2018, 15:10:45
Ist ja auch eine Testversion ;D Mit Testausgaben eben. Im Anhang eine ohne.
Die Platzhalter für Subscribe tun noch nicht korrekt.
Funktioniert es wenn Du es konkret definierst?
Bin jetzt nicht zuhause. Für die neue Version.
Die alte Version hat der ob Befehl funktioniert aber der off Befehl nicht. Weiß aber auch nicht ob es an einer anderen Konfiguration bei mir liegt.
Edit: der off Befehl war wie in einer Schleife
Werde später mal testen, aber super Arbeit Danke dafür.
Mobil unterwegs!
@hexenmeister - absolut richtig es passiert nichts. Warum es dann mal eine Zeit ging - ist mir unerklärlich oder ich habe mich täuschen lassen und nie lange genug hin geschaut ;D ;D ;D
Testversion werde ich nachher einbauen (ohne Ausgabe die).
Danke vielmals für deine Arbeit! :-)
Also bei mir wird der set Befehl im loop ausgegeben bis die 1% grenze erreicht ist :(
aber den baue ich mir bestimmt selber ein durch:
mqttDefaults base={"/$device/$reading"}
mqttPublish *:topic={$base}
mqttSubscribe state:stopic=/$device/$reading *:stopic={"/TEST/$reading/value"}
Wie muss das richtig lauten?
Edit: Fehler gefunden Eingang und Ausgang dürfen nicht gleich sein :D
/$device/$reading
Zitat von: SamNitro am 01 Mai 2018, 17:45:32
Fehler gefunden Eingang und Ausgang dürfen nicht gleich sein :D
Richtig, damit habe ich mir anfangs auch eine schöne Lichtorgie im meinem Wohnzimmer gestalltet. ;D
Und verstehe ich das richtig das $device im mqttSubscribe "noch" nicht funktioniert?
Also entweder habe ich gerade ein Brett vorm Kopf oder bin senil... ich raffe nicht wie ich nun ein set desiredTemperature <value> daraus zauber, wenn sich in Topic "homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature/set" was ändert :-D
:o ;D
versuch mal
desiredTemperature:stopic=/$device/$reading *:stopic={"homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature/set/$reading/value"}
eher so:
desiredTemperature:stopic=homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature/set
8) 8) 8) GEIL!
Es läuft :-) Danke!
Bin grad mitten in Python mitm Kopf ^^ parallel das noch war anscheinend zuviel ^^
Prima!
Danke fürs Testen :)
So werden wir das nach und nach fertigstellen ;D
Find ich mega!
Vielen vielen Dank für deine Zeit und Arbeit!
Ich schätze diese Bridge sehr!
kann ich auf 2 topics lauschen frei nach dem motto
state:stopic={"/input/$device/state"}; pct:stopic={"/input/$device/pct"}
Klar, beliebig viele. Aber leerzeichengetrennt, also ohne ';'
Zitat von: hexenmeister am 01 Mai 2018, 21:11:18
Klar, beliebig viele. Aber leerzeichengetrennt, also ohne ';'
Ja Mega :)
Mobil unterwegs!
Neue Version mit halbwegs funbktionierenden Wildcards.
Also so wie das hier: *:topic={"/TEST/$reading/set"}
Was an der Stelle ($reading) im Topic gefunden wird, wird als Reading-Name verwendet. Nicht vorhandenen Readings werden ggf. angelegt.
WOW!!! Genau das was ich suche!
So kann ich endlich FHEM und ZWay "paaren"
Ich möchte nicht auf ZWay verzichten und gleichzeitig die Flexibilität von FHEM nutzen.
Habe daher zwei Raspberry 3B+ am laufen. Auf einem läuft ein Mosquitto den ich hauptsächlich für die Kommunikation mit ESP Devices nutze (auch über mehrere Immobilien hinweg).
Ich bin absolut überzeugt von MQTT umso besser wenn es jetzt auch generisch läuft!
Endlosschleife:
Liebe Community, hat jemand eine Idee zu folgendem Problem.
Wenn ich Publish allein verwende kann ich den Status setzen,
Wenn ich Subscribe allein verwende kann ich den Status lesen.
Wenn ich beides Verwende komme ich in eine Endlosschleife:
mqttPublish state:topic=pramNet/vorzimmerOG/galerie/set
mqttSubscribe state:topic=pramNet/vorzimmerOG/galerie
Ich verwende verschiedene Topics aber leider löst das Publish eine Message auch wieder ein Subscribe Event aus was wiederum zu einer Stateänderung (zumindest im Timestamp) führt und damit wieder ein Publish Event auslöst - eine klassische Endlosschleife. Gibt es eine Möglichkeit das Publish nur auszulösen wenn es eine Änderung der State-Value gibt?
Ein und Ausgang dürfen nicht gleich heißen,
ich habe bei mir ein input und ein output hinzugefügt
z.B.
mqttPublish state:topic=out/pramNet/vorzimmerOG/galerie/set
mqttSubscribe state:topic=in/pramNet/vorzimmerOG/galerie
Die Parameter sind schon unterschiedlich. Aber eine Schleife kann ich nicht nachstellen.
Beim publishen auf pramNet/vorzimmerOG/galerie wird natürlich im Device state entsprechend gesetzt un gleih postwendent auf pramNet/vorzimmerOG/galerie/set gepublisht. Wenn bei DIr dabei eine Endlosschleife entsteht, dann hast Du noch weitere Teilnehmer im Netzt die dabei beteiligt sind.
Ja bei mir ist noch ein ZWay Client im Einsatz der auf PREFIX/%RoomName%/%Device%/set reagiert und auf PREFIX/%RoomName%/%Device%/ postet.
Also genau Vice Versa.
Resultat ist dass nach einem Set der ZWay Client auch wiederum ein Publish aufgrund des veränderten Status macht.
Lösen könnte man den ganzen Loop indem die FHEM Bridge das Publish nur dann ausführt wenn sich STATE ändert.
Ich denke dieses Problem könnten mehr haben die die Bridge als Schnittstelle zwischen zwei Frontends verwenden.
Liebe Grüsse und einen schönen Sonntag!
Ich halte so eine 'über-Kreuz'-Verschränkung für ein Design-Problem. Warum muss denn das genau so sein?
Dennoch kannst Du natürlich Dein Vorschlag umsetzen, dafür ist jedoch nicht die Bridge zuständig, die verhält sich völlig korrekt und FHEM-konform. Schau Dir mal das Attribut 'event-on-change-reading' an.
Hallo,
du hast natürlich recht! Die Bridge und MQTT sollte völlig "rein" implementiert sein.
Wollte dich da nicht in negativer weise beeinflussen ;)
Mit event-on-change funktioniert es des Loop zu durchbrechen, ich weiss nur noch nicht ob das nicht noch weitere Nebenwirkungen hat aber bisher schaut es gut aus.
Nochmal ein herzliches Danke für die Arbeit die du hier als Entwickler aber auch in der Community leistest!
Liebe Grüsse
Christoph
@hexenmeister
Da ich mehr und mehr auf mqtt umsteige beobachte ich schon länger diesen Thread.
Im Zusammenhang mit der Android APP "MQTT Dash" habe ich gestern das Modul "Generic MQTT Bridge" aktiviert
und bin begeistert. :) :) :)
Es hat zwar ein Weilchen gedauert, aber ich möchte mich ganz offiziell für deine tolle Arbeit bedanken.
Gruß Billy
Moin Hexenmeister :-)
Ich hab nun noch NICHT die Version vom 01.05. bei mir - sehe die gerade erst.
Habe aber mit der davor was entdecken können.
Starte ich FHEM neu spammt FHEM einmal mit den Devices den Broker zu wo die MQTTBridge arbeitet - aber nicht einfach einmal jeder Wert sondern x fach.
Und es handelt sich nicht um eine Schleife da ich es gemäß MQTT Standart mache:
Status selber wird nur von FHEM befüllt: homeland/haushalt/heizung/Heizungssteuerung/state
Schaltbefehle Node-Red und wer weiß was: homeland/haushalt/heizung/Heizungssteuerung/state/set
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/heizung/Heizungssteuerung/state on
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/elektrik/wohnzimmer/Streifen/state off
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
homeland/haushalt/elektrik/wohnzimmer/Spot/state off
Das war mir aufgefallen, weil "Spot" nach einem Reboot einfach immer mal an ging (oder nach Stromverlust).
Mittlerweile macht er es nun auf off - schon mal angenehmer - aber generell sollte ja gar nichts gemacht werden da ich QOS 2 und Retain 1 nutze.
Somit sollte es schweigen beim Reboot wäre mein Gedanke :-) FHEM intern darf es gern was es will - aber nicht auf MQTT :-D Oder 8) ;D :D
Beste Grüße und ich teste es nun direkt mit der neusten Version erneut.
Die besten Fehler, sind die, die mit der Version die man beim Reporten eines Fehlers vorfindet, gefixed sind :-D GEIL!
Kann es nicht mehr nachstellen.
Danke euch, es freut mich, dass meine Arbeit jemanden nützlich ist :)
Zitat von: hexenmeister am 16 Mai 2018, 21:47:54
Danke euch, es freut mich, dass meine Arbeit jemanden nützlich ist :)
Ja für mich sogar sehr nützlich. Endlich kann ich Node Red als Dashboard nutzen :)
:) ;)
Der Marsch von Node-Red ist dank Hexenmeisters Arbeit ein unaufhaltsamer :-)
Zitat von: hexenmeister am 01 Mai 2018, 23:22:18
Neue Version mit halbwegs funbktionierenden Wildcards.
Also so wie das hier: *:topic={"/TEST/$reading/set"}
Was an der Stelle ($reading) im Topic gefunden wird, wird als Reading-Name verwendet. Nicht vorhandenen Readings werden ggf. angelegt.
Wie kriegt man das zum laufen???
Bei Eingabe von "defmod mqttGeneric MQTT_GENERIC_BRIDGE" kommt die Meldung:
2018.05.21 20:26:38 1: reload: Error:Modul 10_MQTT_GENERIC_BRIDGE deactivated: Too many arguments for MQTT::parseParams at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 629, near "undef)"
2018.05.21 20:26:38 0: Too many arguments for MQTT::parseParams at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 629, near "undef)"
Ich tippe auf veraltete Version von 00_MQTT.pm. Mache ein Update.
Danke. Das war der Grund.
Edit: Hatte leider Zeit nur eine Homematic Steckdose MQTT fähig zu machen und in Node Red einzurichten. Aber es hat sehr gut geklapt. Tolle Arbeit Hexenmeister und vielen Dank dafür :) :) :) :) :) :) :)
Hoffe das kommt bald als offizielles Fhem Modul :)
Hallo, liebe MQTT-ler,
ich lese schon einige Zeit in diesem Thread mit, konnte jedoch keine Antwort auf meine Frage herauslesen
"Kann mit dem Modul zwischen 2 Raspberry Pi FHEM-MQTT-Installationen eine Brücke erstellt werden"?
Wenn es möglich ist, wie müssen die define in den jeweiligen FHEM's aussehen?
MMn müsste einer der beiden Raspi die Rolle des Client übernehmen.
Ich habe in den FHEM's die Module "00_MQTT.pm" , "10_MQTT_BRIDGE", "10_MQTT_DEVICE" und
"10_MQTT_GENERIC_BRIDGE" installiert.
Die Publish- und Subscribe-Kommunikation der jeweiligen FHEM-MQTT-Inst. mit ihren Clients (ESP8266) funktioniert wie gewünscht, auch über die MQTT_GENERIC_BRIDGE.
Besten Dank für Eure Hilfe
Klausi
Moin!
Man kann auch so eine Art Brücke damit erstellen. Sowohl unidirektional (Server->Client) - indem man an einer Seite 'publish' definiert und an der anderen 'subscribe".
Aber auch biderektional ist möglich - man definiert jeweils beides und unterbindet die Schleifen durch event-on-change. Alles hängt von dem jewiligen Einsatszenario ab.
Grüße
Alexander
Hallo Alexander,
danke für Deine schnelle Antwort.
Mir genügt eine unidirektionale Verbindung.
Mein Szenario stellt sich wie folgt dar:
Auf der einen Seite entsteht eine Wintergartensteuerung (bisher im Versuchsaufbau) mit kabelgebundenen Sensoren und Aktoren, die über Relais die Steuerung durchführen. An diesen "Wiga-Raspi" ist über mqtt (ESP8266) ein TFT-Display mit touch angeschlossen, auf dem verschiedene Info-Screens erstellt sind.
Die Daten der Sensoren werden auf dem "Sensor-Screen" und die der Aktoren auf dem "Aktor-Screen" angezeigt.
Auf der anderen Seite habe ich in meiner Elektro-Verteilung einen 2.Raspi verbaut, der mir die Daten eines Smart-Meters (Q3D) erfasst.
Ich möchte nun die Daten, die der "Q3D-Raspi" ermittelt, zum "Wiga-Raspi" übertragen, sodass auch diese Daten auf dem TFT-Display auf einem "Q3D-Screen" angezeigt werden.
Ich habe bisher im Q3D-Raspi eine
define Q3D_Meter MQTT_BRIDGE SWU_Q3D
attr Q3D_Meter IODev Mosquitto
definiert, die z.B über
attr publishReading_powerL1 /SWU_Q3D/power_L1
die Leistung der Phase L1 published.
Das funktioniert, ich sehe zyklisch
transmission-state outgoing publish sent
und auch in MQTTfx kann ich sehen, dass die Daten published werden.
Im Wiga-Raspi habe ich ein
define Q3D_Meter MQTT_DEVICE
attr Q3D_Meter IODev Mosquitto
attr Q3D_Meter subscribeReading_power /SWU_Q3D/power_L1
erstellt.
Die Daten kommen jedoch nicht im Wiga-Raspi an. Auch wenn ich den Wiga-Raspi mit MQTTfx beobachte sehe ich keine Q3D-Daten.
Wo liegt mein Gedankenfehler?
lg
Klausi
Hallo Klausi,
in diesem Thread geht es um ein anderes Modul: MQTT_GENERIC_BRIDGE. Du verwendest jedoch konventionelle MQTT_BRIDGE und MQTT_DEVICE. Erstelle ein neues.
Hier nur kurz: Wenn Deine Sendeseite funktioniert, dann muss man natürlich auf der Empfängerseite suchen. Was ich jedoch nicht verstehe, was meinst Du denn mit
ZitatAuch wenn ich den Wiga-Raspi mit MQTTfx beobachte sehe ich keine Q3D-Daten.
Wenn es gesendet wird, dann sind die Daten überall verfübar. Man kann mit einem Client nicht gezielt ein anderes 'beobachten'. Ich vermute, Du hast irgendein Problem mit der Deiner Infrastruktur.
Beschreibe das Problem genau in einem neuen Thread.
Grüße
Alexander
Hallo Alexander,
vielen herzlichen Dank für Deine Arbeit!
Vor gut einer Woche bin ich über Node-RED gestolpert und war begeistert von der Einfachheit. Bei meiner Recherche hier im Forum bin ich dann auf Dein Modul gestoßen und konnte so auf einen halben Tag ein funktionierendes Dashboard erstellen welches mir in FHEM zu umständlich war. Ich bin Begeistert.
Nochmal vielen Dank und weiter so!
Grüße Willi
Dem kann ich mich nur anschließen.
Alexander, dein Modul ist Gold wert !
Zitat von: Willi66 am 14 Juni 2018, 14:01:19
Hallo Alexander,
vielen herzlichen Dank für Deine Arbeit!
Vor gut einer Woche bin ich über Node-RED gestolpert und war begeistert von der Einfachheit. Bei meiner Recherche hier im Forum bin ich dann auf Dein Modul gestoßen und konnte so auf einen halben Tag ein funktionierendes Dashboard erstellen welches mir in FHEM zu umständlich war. Ich bin Begeistert.
Nochmal vielen Dank und weiter so!
Grüße Willi
Kannst du bitte mal ein paar Bilder posten.
Gruß Christian
Gesendet von iPhone mit Tapatalk
Hallo Christian,
wenn mal alles so läuft wie ich möchte gern. Derzeit komme ich aber auch nicht dazu aber da nötigste funktioniert.
Gruß
Willi
Zitat von: mrbreil am 15 Juni 2018, 21:27:00
Kannst du bitte mal ein paar Bilder posten.
Gruß Christian
Ich habe mal ein kleines Video von Steuerung vom Handy gemacht.
https://youtu.be/UuBnA_2GGrs (https://youtu.be/UuBnA_2GGrs)
Vielen Dank.
Versuche jetzt auch schon seit ner Woche mir mit dem Nodered Dashboard UI zu Basteln, da TabletUI immer und immer langsamer wird.
Mir gefällt aber das Ergebnis noch so gar nicht. Könntest du vielleicht deine Flows exportieren und anfügen. Da könnte ich mir dort ein bisschen was abschauen.
Zitat von: mrbreil am 01 Juli 2018, 10:50:32
Vielen Dank.
Versuche jetzt auch schon seit ner Woche mir mit dem Nodered Dashboard UI zu Basteln, da TabletUI immer und immer langsamer wird.
Mir gefällt aber das Ergebnis noch so gar nicht. Könntest du vielleicht deine Flows exportieren und anfügen. Da könnte ich mir dort ein bisschen was abschauen.
Bitte dafür hier weitermachen..
https://forum.fhem.de/index.php?topic=78512.0 (https://forum.fhem.de/index.php?topic=78512.0)
Hallo
Mit Sensoren klappt das bei mir schon gut mit dem Modul spart man sich die Bridge.Nur wenn ich was schalten will hier bei mir Yeelight Lampen klappt es nicht erste Versuche landeten in einer Endlosschleife.Bin leider noch ziemlich Anfänger bei Mqtt und bräuchte etwas hilfe.
Inesa
Nun ja, was hast Du ausprobiert? Ist FHEM aktuell? Welche Modul-Version? So können wir nur raten...
Fhem ist aktuell das modul ist das letzte was hier gepostet wurde.
Was ich will ich habe hier bei mir zu Hause zwei fhem installationen auf der ersten Pi1 sind meine Lampen
definiert die ich auf dem zweiten Pi2 mit Mqtt schalten will.
Dazu habe ich auf Pi2 ein mqtt Device angelegt
define mqtt_device_yeelight MQTT_DEVICE
attr mqtt_device_yeelight IODev mqtt
attr mqtt_device_yeelight eventMap on:on 70:bright 20:dimup 10:dimdown off:off
attr mqtt_device_yeelight icon mqtt
attr mqtt_device_yeelight publishSet on off switch:on,off level:slider,0,1,100 Smarthome/licht/Yeelight_flur/set
attr mqtt_device_yeelight retain 1
attr mqtt_device_yeelight room MQTT
attr mqtt_device_yeelight stateFormat level
attr mqtt_device_yeelight subscribeReading_level Smarthome/licht/Yeelight_flur/level
attr mqtt_device_yeelight subscribeReading_power Smarthome/licht/Yeelight_flur/power
attr mqtt_device_yeelight webCmd on:bright:dimup:dimdown:off:level
Auf Pi1 habe ich beim Licht dein Modul definiert.
mqttDefault base={"Smarthome/licht/$device/$reading"}
mqttPublish *:topic={$base}
mqttSubscribe state:topic=Smarthome/licht/Yeelight_flur/power/set
Funktioniert leider nicht nicht so..
Inesa
Ich habe Yeelights nicht, kann daher nicht direkt nachstellen. Auf den ersten Blick würde ich vermuten, dass Yeelight-Modul beim Setzen einer Reading (publish mit ':topic=') nichts schalten wird (ist eigenlich IMHO bei jedem Modul so). Hier müsste wirklich ein 'set'-Befehl aufgelöst werden. Ersetze 'topic' durch 'stopic', dann wird anstatt Reading zu aktualisierung, ein 'set' abgesetzt:
mqttSubscribe state:stopic=Smarthome/licht/Yeelight_flur/power/set
Nicht ganz nachvollziehen kann ich, dass es zu einer Endlosschleife kommt. Sehe gerade nicht, wodurch sie ausgelöst sein könnte, vlt. ist es heute schon einfach zu spät ;D
Probiere in diesem Fall ggf. stateFormat rauszunehmen, auch wenn ich gerade nicht glaube, dass es daran liegt.
Mit retain sollte man ggf. vorsichtig sein: beim Restart von FHEM wird der letzte Wert wieder empfangen und der letzte Schaltbefehl wiederholt. Kann egal sein, in manchen Fällen ('toggle' z.B.) aber auch Probleme verursachen.
Grüße
Alexander
Ich habe hier noch eine mqtt Bridge in Betrieb wo das schalten ja soweit funktioniert vieleicht liegt es ja daran werde die mal deaktivieren. Möchte gern alle mqtt Bridge loswerden und durch dein Modul ersetzen ist viel übersichlicher.
So ist die bridge und device definiert
defmod mqtt_device_flur MQTT_DEVICE
attr mqtt_device_flur DbLogExclude .*
attr mqtt_device_flur IODev Mosquito
attr mqtt_device_flur eventMap on:on 50:bright 20:dimdown 10:dimup off:off
attr mqtt_device_flur icon mqtt
attr mqtt_device_flur publishSet on off switch:on,off level:slider,0,1,100 Smarthome/licht/flurlicht/set
attr mqtt_device_flur retain 1
attr mqtt_device_flur room Mqtt
attr mqtt_device_flur stateFormat level
attr mqtt_device_flur subscribeReading_bright Smarthome/licht/flurlicht/bright
attr mqtt_device_flur subscribeReading_level Smarthome/licht/flurlicht/level
attr mqtt_device_flur subscribeReading_power Smarthome/licht/flurlicht/set
attr mqtt_device_flur subscribeReading_state Smarthome/licht/flurlicht/state
attr mqtt_device_flur webCmd on:bright:dimup:dimdown:off:level
defmod mqtt_bridge_flur_licht MQTT_BRIDGE Yeelight_flur
attr mqtt_bridge_flur_licht IODev mqtt
attr mqtt_bridge_flur_licht icon mqtt
attr mqtt_bridge_flur_licht publishReading_bright Smarthome/licht/flurlicht/level
attr mqtt_bridge_flur_licht publishReading_power Smarthome/licht/flurlicht/power
attr mqtt_bridge_flur_licht publishReading_state Smarthome/licht/flurlicht/state
attr mqtt_bridge_flur_licht publishState Smarthome/licht/flurlicht
attr mqtt_bridge_flur_licht retain 1
attr mqtt_bridge_flur_licht room MQTT
attr mqtt_bridge_flur_licht stateFormat transmission-state
attr mqtt_bridge_flur_licht subscribeSet Smarthome/licht/flurlicht/set
damit geht es.
Übertragen wird Smarthome/licht/flurlicht/power on
und mit deinen Modul
Smarthome/licht/Yeelight_flur/set on
Inesa
Ziemlich still hier im Thread .
Mein licht kann ich soweit schalten
funktioniert ,möchte aber gern noch mehr
wie dimmen farbe scene u.s.w
Wäre nett wenn hier jemand ein paar Beispiele
posten könnte im thread kann man leider
nichts finden dazu.
Inesa
Es läuft jetzt mit meinen Yeelight licht
defmod mqtt_device_inesalicht MQTT_DEVICE
attr mqtt_device_yeelight DbLogExclude .*
attr mqtt_device_yeelight IODev Mosquito
attr mqtt_device_yeelight eventMap on:on off:off
attr mqtt_device_yeelight genericDeviceType light
attr mqtt_device_yeelight icon mqtt
attr mqtt_device_yeelight publishSet on off switch:on,off bright:slider,0,1,100 Smarthome/licht/Yeelight_inesa/set
attr mqtt_device_yeelight publishSet_bright Smarthome/licht/Yeelight_inesa/bright
attr mqtt_device_yeelight retain 1
attr mqtt_device_yeelight room Mqtt
attr mqtt_device_yeelight stateFormat transmission-state
attr mqtt_device_yeelight subscribeReading_bright Smarthome/licht/Yeelight_inesa/bright
attr mqtt_device_yeelight subscribeReading_hsv Smarthome/licht/Yeelight_inesa/hsv
attr mqtt_device_yeelight subscribeReading_power Smarthome/licht/Yeelight_inesa/power
attr mqtt_device_yeelight subscribeReading_state Smarthome/licht/Yeelight_inesa/state
attr mqtt_device_yeelight webCmd rgb:bright:ct:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
attr mqtt_device_yeelight widgetOverride bright:colorpicker,BRI,0,1,100 ct:colorpicker,CT,1700,10,6500 rgb:colorpicker,RGB
attr Yeelight_inesa mqttDefaults base={"Smarthome/licht/$device/$reading"}
attr Yeelight_inesa mqttPublish *:topic={$base}
attr Yeelight_inesa mqttSubscribe state:stopic=Smarthome/licht/Yeelight_inesa/set bright:stopic=Smarthome/licht/Yeelight_inesa/bright
hue:stopic=Smarthome/licht/Yeelight_inesa/hue rgb:stopic=Smarthome/licht/Yeelight_inesa/rgb
Sieht zwar nicht sehr elegant aus geht bestimmt besser aber es funktioniert
soweit
Mahlzeit :-) lange nicht gelesen.
Ich habe ein Sache festgestellt, da ich ja Devices nutze mit true und false (SonOffs mit Homie) mappe ich das ja schon so um
{ dev=>{ 'true'=>'on', 'false'=>'off' }, usr=>{ '^on$'=>'true', '^off$'=>'false' }, fw=>{ '^on$'=>'on', '^off$'=>'off' } }
Nun habe ich dann mal irgendwann über alexa-fhem gefragt wie mein Couchtisch geschaltet ist... tjaa er war irgendwie immer an.
Liegt daran, dass intern weiter das true und false verarbeitet wird. Also bei alexa-fhem kommt false und true an.
Kann man das nun noch so am Device um mappen oder muss man aktiv werden in alexa-fhem :-D ?
Mappen wäre halt einfacher.
Genutzt wird wohl wirklich der state - daher glaub ich fast.... ;-) es wir haarig.
Ich danke euch :-)
Hallo,
bei meinem Umbau auf dieses Modul, das alles (für mich) viel übersichtlicher löst, insbesondere bei Kopplung mehrerer Instanzen, ist mir aufgefallen, dass bei manchen Modulen set-Befehle mit weiteren Argumenten nicht korrekt verarbeitet werden (mqttSubscribe mit stopic).
Nach ein paar Experimenten denke ich, dass ich das Problem lokalisieren konnte. In der onmessage-Sub wird DoSet aufgerufen, allerdings ohne dass $message in ein Array zerlegt wird.
Versuchsweise habe ich das wie folgt ersetzt:
if(($reading eq '') or ($reading eq 'state')) {
# $err = DoSet($device,$message);
$err = fhem("set $device $message");
} else {
# $err = DoSet($device,$reading,$message);
$err = fhem("set $device $reading $message");
}
und siehe da, das Problem war verschwunden. Da die Module wohl die Argumente in der SetFn unterschiedlich verarbeiten, ist das auch nicht bei allen aufgetreten.
Hoffe, das hilft.
Grüße,
a-p-s
Hi,
danke für die Analyse und eine Lösung. Der Aufruf von 'fhem' würde ich gerne vermeiden (vor allem Performance).
Daher habe ich das jetzt (zugegeben auf die Schnelle) die Variable $message in ein Array zerlegt. Kannst Du bitte in Deinem EInsatzszenario ausprobieren?
Viele Grüße
Alexander
Das ging ja mal wieder super schnell.
Kurze Rückmeldung: für meine beiden Testfälle (WINCONNECT und DOIF) hat das einwandfrei funktioniert.
Grüße,
a-p-s
Danke :)
@hexenmeister
wo finde ich die aktuelle 10_MQTT_GENERIC_BRIDGE.pm?
Wird die mal offiziell eingecheckt oder habe ich da was übersehen?
Das Modul verbessert die Übersicht erheblich, danke.
Gruß Billy
Wenn ich damit fertig bin, kann ich sie einchecken. Fehlt derzeit an freien Zeit.
Die letzten Versionen sind hier im Forum. Musst auch 00_MQTT von hier nehmen.
Bin derzeit unterwegs, kann leider keine hochladen.
Wäre es nicht sinnvoll die letzten Versionen einfach im 1. Beitrag als Ergänzung anzuhängen? Sowie deine Vorläufige Doku vom 05.03. ;)
Für Neueinsteiger sicher Sinnvoll?
Danke für deine schnelle Antwort :D
Gruß Billy
Gebe ich dir recht. Es sind jedoch immer noch Testversionen. Doku fehlt fast komplett. Etc.
Ich will versuchen, in der nächsten Woche einiges nachzuholen.
Mach dir nicht zuviel Stress, einfach das was es schon gibt in den ersten Beitrag
das wäre schon eine große Erleichterung.
Billy
Das kann ich auch erst machen, wenn ich einen vernünftigen Rechner habe, vom Handy komme ich an die Dateien nicht dran.
Hey habe auf Rudi's MQTT2 umgestellt und jetzt startet FHEM nicht mehr mit deinem Modul
Hier der log auzug:
Undefined subroutine &MQTT::GENERIC_BRIDGE::client_subscribe_topic called at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 910.
Moin!
Mein Modul funktioniert mit dem neuen MQTT2 nicht. Zumindest nicht direkt. Wenn du den MQTT2_SERVER nutzen möchtest, dann lege noch die 'alte' MQTT-Modul-Instanz wieder an. Damit sich diese mit dem neuen Server (auf localhost) verbinden kann. Dann sollte auch die Bridge wieder funktionieren.
Kannst du das mal bitte genauer erklären, meinst du über mosquitto? den habe ich schon deinstalliert. und sobald ich dein Modul ins Verzeichnis kopiere, stürzt FHEM ab.
ok hat sich erledigt. Danke :)
Nein, mosquitto brauchst Du dann nicht mehr, stattdessen übernimmt MQTT2_SERVER die Arbeit.
Die alten MQTT-Module und auch meine GenericBridge können jedoch mit dem neuen Modul nichts anfangen (werden vermutlich auch nie können, die Impelentierung ist zu unterschiedlich). Die Verbindung sollte jedoch über einen Umweg möglich sein: das alte Client-Modul (MQTT) stellt eine Verbindung zum Server her. Ihm sollte egal sein, ob das Mosquitto oder MQTT2_SERVER sein wird. Die GenericBridge kann dann über den MQTT-Client die Daten mit dem MQTT2_SERVER austauschen.
Getestet habe ich das Ganze jedoch nicht. An einer direkten Unterstützung habe ich auch keine Interesse, da mir MQTT2_SERVER von seiner Funktionalität her nicht ausreicht. Ich benötige schon einen 'echten' Mosquitto. U.a. als Bridge zu anderem MQTT-Server im Cloud.
Ich bin endlich soweit, dass ich eine Version habe, die aus meiner Sicht nutzbar ist und freigegeben werden kann. 8)
An dieser Stelle vielen Dank an alle,die fleißig getestet haben! :)
Die letzte Version habe ich im Erstbeitrag angehängt und auch ins offizielle RePo eingecheckt (also ab morgen per Update).
Zwecks etwas besseren Übersicht erstelle ich gleich einen neuen Thread mit der aktuellen Beschreibung.
Geile Sache!
Vielen Danke deiner vielen Mühe, Arbeit und vor allem der Zeit! 8) 8) ;) ;) :D :D
Gern :)
Neues Thema hier: https://forum.fhem.de/index.php?topic=90735.new#new
Hallo, ich finde den Ansatz mit generischem MQTT toll, komme aber mit der Anwendung / Syntax noch nicht zurecht.
Ich habe in fhem.cfg:
#defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt
defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev mqtt
attr mqttGeneric mqttDefaults sub:qos=2 pub:qos=0 retain=0
attr mqttGeneric mqttPublish *:topic={"/haus/$device/$reading"}
Ist mqtt in defmod notwendig und ist es der HostName meines mqtt-Brokers?
was ist mqtt bei der IODev-Zeile, der Name meines mqtt-Brokers?
Wie kann ich Ports definieren, z. B. mit wasser:1884 ?
Muss es sein publish oder mqqtPublish? Ich sehe verschiedenen n Dokus.
Syntome:
In mosquitto_sub -d -v -h wasser -t '#'
sehe ich zwar die
Client mosqsub/3783-kvm2 received PUBLISH (d0, q0, r0, m0, 'fhem/temperatur/zimmer4', ...
die ich mit dem zusaetzlichen MQTT_BRIDGE definiert habe,
aber keinerlei von der MQTT_GENERIC_BRIDGE.
FHEM 5.8;
10_MQTT_GENERIC_BRIDGE.pm mit version 0.2.1 by hexenmeister,
1776 7214 72993 10_MQTT_GENERIC_BRIDGE.pm gross.
Log:
2018.09.01 19:59:39.793 3: No I/O device found for mqttGeneric
2018.09.01 19:59:39.815 1: client device hash no IODev provided
Danke
Wie direkt vor Deinem Post angegeben, die neue Version ist jetzt offiziell in Repo und dort sollen auch die Probleme diskutiert werden. Hier ging es um Konzeption und Entwicklung.
https://forum.fhem.de/index.php?topic=90735.new#new
Dort ist auch die Beschreibung (jetzt auch im Commandref) zu finden, die hoffentlich alle Deine Fragen benatwortet.
In jedem Fall ist Deine Version schon veraltet, mache zunächst ein Update.
Dann wäre wichtig zu verstehen, dass die GenericBridge nichts mit dem MQTT-Server zu tun hat. Den musst Du mit dem MQTT-Modul ins FHEM anbinden. Die Bridge stellt dann eine Möglichkeit zur Verfügung, die MQTT-Übertragung einzelnen Werte direkt in den Devices zu definieren, wo diese entstehen, bzw. gebraucht werden. Von alleine macht die Bridge jedoch nichts. Definiere entsprechende Attribute in den Devices.