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
Wenn du die Schaltbefehle von Tasmota via MQTT nicht herausbekommst (wie gesagt, ich kenne sie auch nicht), dann schalte Tasmota einfach vom MS direkt (http oder wie auch immer).
Das Status-Update bekommst du via mqtt ja trotzdem mit.
Und in einer ruhigen Stunde erklärt das vielleicht mal jemand, der selbst Tasmota nutzt.
btw, wenn du konkrete Hilfe brauchst, musst du hier konkreter beschreiben, was genau du wie probiert hast. Sonst kann niemand sagen, was daran falsch und was richtig ist.
Ich tendiere dazu, sehr ausführlich zu sein und da das in "meinem" Modellbau-Forum nicht gut ankommt (bin dort nur Moderator), bin ich teilweise vorsichtig bei zu detailierten Fehlerbeschreibungen usw. Man möge mir dieses verzeihen. Bei weiteren Problemen werde ich darauf achten :-)
Ich habe nun nochmals hier im Thread angefangen alles durchzulesen und wurde auf Seite 3 fündig. War zwar nicht genau das Problem was ich hatte, dachte mir aber dass ich den Befehl des Kollegen mal ausprobiere. Nachdem ich dann mit diversen Endungen ausprobiert hatte, habe ich nun endlich den passenden MQTT-Befehl gefunden der Shelly schaltet wie es sich gehört. Sollte jemand ebenfalls Shelly 1 mit Tasmota in Gebrauch haben und sich ebenso "dämlich" anstellen: Befehl für EIN/AUS sind wie folgt:
cmnd/<Topic>/POWER 1
cmnd/<Topic>/POWER 0
Auch wenn in der Konsole stat/<topic>/power = on / off ausgegeben werden, ist dies "falsch" bzw. nicht funktionierend wenn man versucht mit entsprechenden Befehlen bei Shelly mit Tasmota etwas auszulösen. Ich hoffe dass mein Beitrag vielleicht irgendjemandem weiterhelfen wird und ihr euch nun nicht an die Stirn klatscht und denkt "Das war so oder so logisch du Depp!" ;-)
Sollte auch nicht belehrend sein von mir. Ich nehme mich da auch nicht zu 100% aus von.
Habe dir trotzdem den Link geteilt, weil man ja nie den Stand des anderen kennt.
Alles gut! Kam schon so rüber wie es rüberkommen sollte ;-) Als Hilfe und nicht als Belehrung. Bin ja um jede Hilfe dankbar gewesen und werde es auch in Zukunft sein. Das Schaltproblem ist ja jetzt gelöst. Ich finde aber sicher noch 10 Sachen die ich einbauen will bei denen ich wieder nicht klar komme ;-)
Christian Fenzl Das dachte ich mir ;-) Spass bei Seite! Bin echt dankbar für das was du , sowie jeder Andere hier, an Arbeit leistet. Ich wiederhole mich immer und immer wieder. Aber ich hoffe dass ich eines Tages auch Hilfeleistender sein werde und nicht nur Fragestellender ;-) Aber dank dir, geht mein MQTT-Setup nun und wird es wohl auch weiterhin schaffen! Echt Klasse was du da zusammenprogrammiert hast! Und der Wiki-Eintrag -> TOP!
Als erstes mal vielen Dank für die tolle Arbeit und das prima Plugin.
Zur Zeit läuft es bei mir auf einem Test LoxBerry.
Da ich schon vor diesem Plugin einen MQTT-Broker laufen hatte, wird statt dem lokalen eben dieser verwendet.
Das funktioniert auch gut.
Jetzt möchte ich das Plugin auf meinem produktiven LoxBerry einrichten.
Nun zu meiner Frage:
Da ich den lokalen MQTT Broker auf dem LoxBerry ja nicht nutze, besteht denn die Möglichkeit, rein das MQTT Gateway zu installieren?
Dadurch müsste dann nicht "unnötig" der Mosquitto installiert werden und laufen.
Das habe ich nicht vorgesehen - KISS (Keep it Simple and Stupid).
Wenn du den Mosquitto nicht brauchst, kannst du ihn mit systemctl mosquitto disable abdrehen.
Aber wenn du ihm nichts zu tun gibst, tut er auch nicht viel.
Du kannst im UI in der Overview direkt das Hackerl für erweiterte Infos setzen, und dann mit dem Button löschen. Am Broker werden sie dabei sofort gelöscht.
Wenn du danach "Restart" im Gateway machst, sind die Meldungen auch in der Gateway-Overview weg.
Wenn du die Retain-Datenbank von Mosquitto direkt löschen willst, machst du dich in der Shell zum root, und
systemctl stop mosquitto
rm /var/lib/mosquitto/mosquitto.db
systemctl start mosquitto
Erstmal meinen herzlichen Dank für dieses sehr gelungene Plugin.
Dank dessen, dass ich mich nun mal mit MQTT beschäftige, habe ich nun endlich meinen Smappee in Loxone einbinden können.
Erster Grdanke natürlich: Verbrauchszähler.
Dummerweise kommen die aktuellen Werte sekündlich über das Netz.
Davon abgesehen, dass ich da gar nicht so genau wissen muss, lese ich immer wieder, dass UDP ja den Miniserver belasten soll.
Gibt es hier Erfahrungswerte, was zu viel und was OK ist und wie sich zuviel Last bemerkbar macht?
I've replaced 60+ UDP inputs and will convert another 80 inputs when this is released. It's working quite well. I'm using an existing broker (VerneMQ over IPv6).
I suggest MQTT QOS should be set to 2, both for subscriptions and messages sent. Otherwise make it configurable, with QOS 2 being the default for sure.
Sorry, but QoS is not supported by the MQTT library, and would make further problems:
Neither I can guarantee that the Miniserver is receiving the payload (udp message dropped, or VI does not exist), nor I can confirm the Miniserver is really sending it's payload.
So even if the lib would support QoS, it only guarantees the communication between the Gateway and the broker, but never between the Miniserver and the gateway, as there is no level of response from the Miniserver.
The second problem would be caching. The gateway uses caching to reduce the load to the Miniserver. It checks every 5 minutes if the Miniserver was rebooted, and in the case of a reboot, it resubmits all subscription retain messages. But in normal operation, on cached and equal payload, there is no transfer to the Miniserver at all.
In the http mode, it would be possible to implement an own kind of QoS (send message to MS, then query VI). This would create incredible load to the Miniserver, and does not solve the issue, that you may not want all payload created on the MS as VI's, that would create a resubmit loop problem (currently this is silently igoned).
To solve most of the issues:
- Use the loxberry_mqttgateway_keepaliveepoch VI: The gateway publishes this to the broker, and automatically subscribes to it, relaying it to the MS. Therefore, this checks both the gateway AND broker connection (updated every minute).
- Use the connection state of all devices to the broker (possibly with conversion to convert to 1 and 0) and check it in the Miniserver.
- Configure LWT on all devices - if it is customizable, it should set the connection state from above to Disconnected or 0.
- To check the Gateway connection state from the MQTT side, check for loxberry/mqttgateway/status to be "Connected". This is also Gateway's LWT topic, set to "Disconnected" on failure, or something in between (e.g. "Joining")
That all makes sense. I was specifically referring to the MQTT part only, as I understand the other "challenges" of the miniserver. I did not realize you were using Net::MQTT::Simple and I can now see that the MQTT libraries available for Perl are few and not very modern. In the node.js world, it's trivial, as QoS is handled by the libraries. In any case, thanks again. This is really useful!
As this plugin started with prototyping and something around 25 lines of code (see #1), I never switched to the fully implemented Net::MQTT library. I also never had QoS in focus, as with the Miniserver I have no counterpart that would make sense to implement QoS.
Together with a contributor of Net::MQTT::Simple, we enhanced the lib to support lwt, auth and tls (all together), as all available MQTT::Simple enhancements only supported this or that, but not all together.
For LB developers we will ship the enhanced Net::MQTT::Simple library with LB1.4.1, and it is quite easy to use (in contrast to Net::MQTT).
Ich bin daran zu versuchen den Xiaomi Cube in die Loxone einzubinden und bin hier über ein paar Probleme gestolpert:
Zuerst zu meinen Einstellungen:
Settings: Expand JSON
MQTT Subscriptions: zigbee2mqtt/#
Irgendiwe macht er hier ein durcheinander beim zerpflücken der JSON strings. zigbee2mqtt über mittelt immer das gleiche
Hallo rani22
Das ist "by design" durch das Caching.
Wenn du genau die Befehlserkennungen aus der Overview verwendest, bekommst du die richtigen Daten herein. Mach dir Conversions für rotate_right (und rotate_left und was es sonst so gibt), um die Richtungen als Werte in den MS zu bekommen.
Ich empfehle aber grundsätzlich die Verwendung von http statt udp.
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