Willkommen im Loxone Community Forum. Um alle Funktionen nutzen und sehen zu können, registriere dich bitte zuerst. Dies gilt auch für das herunterladen von Dateien.
Bitte im Titel immer zuerst den Namen des Plugins hinschreiben
you can’t send MQTT messages directly to the client. The client has to subscribe itself bei the MQTT Broker for the interested messages. Maybe here is the mistake?
Do you see your messages in the plugins overview?
Hi svethi,
All clients are subscribed to topic ebusd/# I tested with an external MQTT client to post the messages before doing it from the Miniserver UDP -> MQTT plugin -> MQTT Client eBusd, the message looks perfectly on all clients, but the format is not correct, since it does not establish any value.
The MQTT eBusd client, if it detects the /set prefix, will pass that information to the ebus, but I can not make it recognize it.
Could you show some actual examples of what you get from the subscription in any MQTT client and in the MQTT plugin, and explain what you meant with “format is not correct”.
Is setting values working with another MQTT client?
Bislang habe ich MQTT ausschliesslich für Sensoren verwendet. Steuert irgend jemand Leuchten wie z.B. Philips Hue mittels MQTT? “On” / “off” / “toggle” ist ja einfach, aber mit Dimmung und Farbe (RGBW) sieht die Welt wohl etwas anders aus und da kenne ich mich zu wenig aus. Womöglich liesse sich das PiccoC Skript umschreiben damit es die Ausgaben als mqtt anstatt http rest an die Hue Bridge macht? Oder hat jemand eine andere Idee resp. andere Erfahrungen?
AlexAn Wie handhabst Du das Dimmen und die Farbwahl? svethi Nein, die Hue Bridge unterstützt nach meinem Wissen MQTT nicht. Dafür braucht es ein zusätzliches Gateway oder eines was die Hue Bridge ersetzt. Loxberry mit MQTT Plugin habe ich bereits erfolgreich im Einsatz. Wie beschrieben sehe ich keine Probleme darüber Messages für “on” / “off” / “toggle” zu implementieren. Für das stufenlose Dimmen und die Farbwahl z.B. über die Visu sieht es aber schon etwas anders aus. Die MQTT Messages resp. dessen Werte müssten ja dann quasi dynamisch analog zu den Ausgaben des Beleuchtungsbausteins angepasst werden oder sehe ich das etwa falsch?
Die HA Bridge hat zumindest die Möglichkeit den MQTT Broker anzugeben, aber ich hab das noch nicht getestet!
Dimmen per MQTT z.B. wird hier beschrieben für eine andere Anwendung: https://blog.ex-store.de/content/wifidimmer-ha-bridge
Die Frage ist halt wie man die einzelnen Befehle der Kanäle herausfindet bzw. ob es eine Doku dazu gibt.
Wie ich das mit der Bulb über MQTT mache hab ich im Wiki dokumentiert.
Muss aber sagen dass ich Alexa nur klassisch als Eingang für die Loxone benutze und die Geräte von der Lox aus über den MQTT Broker aktiviere und nicht von Alexa direkt auf die Geräte.
HA Bridge 5.2.2 RC3 und Loxberry MQTT Verbindung lebt schon mal:
Anlegen in der Bridge Control:
Topic in der MQTT Message anlegen z.B. Alexa (eigentlich Schwachsinn als Sprachbefehl )
Befehle dann bei Bridge Device - Edit/Copy abändern.
Test wie üblich in der Bridge
Wenn Alexa nicht brav ist musst du:
MQTT Variante dem Loxberry den Netzwerkstecker ziehen/oder Topic löschen
Virtuellen Eingängen/uuidAction kannst du dem Benutzer "Alexa" in der Config zentral den Stöpsel/Berechtigung entziehen wenn er damals richtig angelegt worden ist.
svethi Es geht darum alle Zigbee Geräte in einem Netz zusammenzufassen anstatt mehrere Netze (und damit Gateways) laufen zu lassen. Ausserdem hat dies den Charme, dass man mehr Kontrolle über die Devices gewinnt und in Zusammenhang mit einer Heimautomatisierung eine sehr hohe Flexibilität ergibt. Z.B. habe ich heute schon die Hue Motion Sensoren über den Zigbee Gateway in Loxone eingebunden und kann damit Use Cases abbilden, welche über die Hue Bridge nicht möglich wären. Ausserdem würde man mit den Hue Leuchten eine massiv bessere Abdeckung und Kapazität erhalten, da diese in einem vereinten Netz als Router (Repeater) dienen würden. Dies hat nach meiner Ansicht praktisch nur Vorteile (Strahlenbelastung, Stromverbrauch, Betriebsaufwand, Abdeckung und Skalierbarkeit des Zigbee Netzes usw.) und einzige Nachteile wären, dass kein Firmware Upgrade darüber möglich sein wird und man auf Sonderfunktionen wie z.B. Lichteffekte passend zur Musik (3rd Party Hue Apps) verzichten muss. Um dieses Szenario aber ohne zusätzliche Kompromisse eingehen zu müssen, wäre eine schlaue Ansteuerung der RGBW Leuchten (In diesem Fall Hue, aber nach meiner Auffassung nicht wirklich relevant) aus Loxone notwendig und meine spontane Idee war halt eben das bestehende und in meinem Fall hoch bewährte PicoC Skript anzupassen oder erweitern (natürlich bin ich für alternative oder gar bessere Lösungswege offen). Dieses Szenario dürfte m.E. für Jedermann mit Zigbee Komponenten von unterschiedlichen Herstellern (oder dem Bedürfnis nach mehr Flexibilität) zutreffen und dank MQTT auch für andere Leuchten (auch mit anderen Funkprotokollen inkl. WLAN) oder Dimmer wie z.B. Shelly, Tasmota, Dresden Elektronik, Osram, Ikea usw. zutreffen. Ich hoffe damit die Ausgangslage etwas besser erläutert zu haben und die Idee damit besser verständlich gemacht zu haben.
Zuletzt geändert von Imperator; 01.05.2019, 14:11.
Das Problem dabei ist, dass Du Dir das wohl etwas zu einfach vorstellst. MQTT ist rein eine Infrastruktur zum Übermitteln von Nachrichten. MQTT selbst steuert nichts. Es steuern stets die Clients, die sich an das MQTT „ranhängen“. So sind auch die Nachrichten stets so aufzubauen wie der entsprechende Client sie erwartet. So sind auch die Nachrichten von Client zu Client anders. Das PicoC Script für HUE ist für die Kommunikation mit der HUE Bridge und dessen API Kommunikation entwickelt. Das kann man nicht einfach so auf MQTT umsetzen. Die MQTT Nachrichten müssten schon speziell für den entsprechenden Client angepasst werden. Für einen anderen Client müssten die Nachrichten dann schon wieder ganz anders aussehen. Das Script für MQTT anzupassen würde für mich nur Sinn machen, wenn HUE nativ MQTT unterstützen würde und somit auch der Nachrichtenaufbau klar und gleich wäre. Du kannst aber Deinen Wunsch im entsprechenden Thread aber auch einreichen. Da kann sich der Programmierer dann dazu äußern. Mit dem MQTT Gateway Plugin brauchst Du aber auch gar keine PicoC mehr, denn dann kannst Du die Daten ja auch per UDP an das Plugin senden.
svethi Ich dachte die Struktur für Hue und Shelly waren praktisch gleich. Ich habe noch einen Shelly RGBW2 und werde das gerne demnächst mal gerne testen. Werde auch mal den Request bezüglich PicoC Skript stellen, da ich mir vorstellen könnte, dass es noch andere gibt welche nicht mehrere Zigbee Netze / Gateways betreiben wollen. Allerdings habe ich nicht ganz verstanden was Du hiermit meintest: "Mit dem MQTT Gateway Plugin brauchst Du aber auch gar keine PicoC mehr, denn dann kannst Du die Daten ja auch per UDP an das Plugin senden." Könntest Du das näher erlautern? Zur Erinnerung, es geht nicht darum der Leuchte einfach nur on / off / toggle zu senden, sondern vollständig in die Visu einzubinden, so dass darüber z.B. nach Lust und Laune gedimmt oder Farbe gewechselt werden kann.
Was meinst Du mit stufenlos dimmen? Richtiges Fading? Das solltest Du ja auch schon im PicoC Baustein vermeiden. Die Belastung über einen Zeitraum ohne Unterbrechung Daten zu senden ist schon nicht zu verachten. Auch kann gar nicht garantiert werden, dass das ruckelfrei geht.
Miniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-)
Ich meine die Möglichkeit z.B. über die Visu den Schieber für die Helligkeit beliebig verschieben zu können und die Leuchte reagiert entsprechend. Klappt zur Zeit mit dem PicoC Skript, der Hue Bridge und über 25 Leuchten perfekt.
Bislang habe ich MQTT ausschliesslich für Sensoren verwendet. Steuert irgend jemand Leuchten wie z.B. Philips Hue mittels MQTT? “On” / “off” / “toggle” ist ja einfach, aber mit Dimmung und Farbe (RGBW) sieht die Welt wohl etwas anders aus und da kenne ich mich zu wenig aus. Womöglich liesse sich das PiccoC Skript umschreiben damit es die Ausgaben als mqtt anstatt http rest an die Hue Bridge macht? Oder hat jemand eine andere Idee resp. andere Erfahrungen?
Was haltet Ihr von der Idee das PicoC Skript auf MQTT anzupassen oder seht Ihr einen anderen/besseren/einfacheren Lösungsweg? Wer versteht eigentlich wie das PicoC Skript für die Hue Bridge genau funktioniert?
I have detected that the entries from the MQTT Gateway to the Miniserver using UDP entries are received much more quickly than if I use the ones recommended by HTTP.
Would it be possible to add a start command that sent all the HTTP entries to start them?
I had already established that reconect, but I thought that it was only for the MQTT service, not for the sending of the HTTP entries.
Anyway I have detected that between the MiniServer was connected some values were modified and were not updated with this reconnect,
I can continue testing, but I understand that when the miniserver is restarted the cache should be deleted (and all the values that appear in "Incoming overview "should be cleared is correct??
On 'reconnect', the memory cache of the plugin (that is also shown in the Overview) as well as the ramdisk cache of the LoxBerry library is cleared, and the connection to the broker is dropped and reconnected, to re-fetch all retain messages from the broker.
A reconnect therefore DOES NOT SEND data that only were published without retain flag, as they are not stored on the broker.
What you can try is to set a delay of e.g. 30 seconds between the "Reboot" pulse of the Miniserver and the UDP 'reconnect' command.
Ich habe die APC-USV über NodeRed und MQTT (v0.7.1) implementiert. Vielen Dank AlexAn. Ein PicoC-Block weniger!
Ich versuche, eine Konvertierung für apc_STATUS zu verwenden. Der MQTT-Wert ist entweder ONLINE oder ONBATT oder COMMLOST. Entsprechende Text-zu-Wert-Konvertierungen werden eingegeben -
ONLINE=0
ONBATT=1
COMMLOST=2
Speichern und Übernehmen, dann Neustart ebenfalls ausgewählt.
Es bleibt immer noch auf ONLINE oder ONBATT oder COMMLOST.
Hallo Tico
im JSON, das von APC kommt, steht der Status so drin:
Code:
"STATUS":"ONLINE "
Hier ist nach ONLINE ein Leerzeichen, deswegen wird der String nicht erkannt.
Probier mal, ob du in den Conversions hinten ein Leerzeichen anfügen kannst, ich bin aber nicht sicher, ob ich das nicht weg-trimme.
Bzw. hast du Einfluss auf die Sende-Seite, dass hier kein Leerzeichen hinten dran kommt?
Danke Christian. Das war ein guter Fund, um den Leerzeichen nach ONLINE zu sehen.
Kein Glück damit, ein Leerzeichen in die Conversions zu setzen. Ich versuche, den entsprechenden Code auf der Senderseite im APC-Plugin zu finden. Vielleicht injiziert NodeRed auch einen Leerzeichen?
Ich spreche kein Deutsch. Gib Google Translate die Schuld, wenn ich unverständlich bin.
Unfortunately no success with that. The Last value shows 'null'. I tried with both space and without space -
ONLINE =0
ONBATT =1
COMMLOST =2
and also
ONLINE=0
ONBATT=1
COMMLOST=2
I've also searched through every file in the APC_UPS plugin zip file. There is no mention of ONLINE, ONBATT or COMMLOST in any of the files in any folder?
Wir verarbeiten personenbezogene Daten über Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen, Werbung zu personalisieren und Websiteaktivitäten zu analysieren. Wir können bestimmte Informationen über unsere Nutzer mit unseren Werbe- und Analysepartnern teilen. Weitere Einzelheiten finden Sie in unserer Datenschutzrichtlinie.
Wenn Sie unten auf "Einverstanden" klicken, stimmen Sie unserer Datenschutzrichtlinie und unseren Datenverarbeitungs- und Cookie-Praktiken wie dort beschrieben zu. Sie erkennen außerdem an, dass dieses Forum möglicherweise außerhalb Ihres Landes gehostet wird und Sie der Erhebung, Speicherung und Verarbeitung Ihrer Daten in dem Land, in dem dieses Forum gehostet wird, zustimmen.
Kommentar