Verbindungsmöglichkeiten des Geräts

[Superposchi]

Irgendwie ist da für mich zu viel MQTT-irgendwas im Spiel. Ich hab da keinen Überblick mehr mit -Server, -Bridge, -Device etc..

Wieso denkst du es wäre ein chinesischer Server? Die App ist aus Deutschland und damit meine ich nicht die Sprache, sondern den Hersteller.
Was nennst du credentials?

So würde ich empfehlen, entweder den Dispenser umzuflashen (so bei "Tasmota"/blakadder was passendes zu finden ist...), oder ggf. zu versuchen, die "Tuya-Cloud"-Lösung von dominik (?) auch dafür herzunehmen, die du afaik bereits für die Xiaomi-BT-etc- Gadgets im Einsatz hast.

Da verwechselst du mich wohl, ich nutze gar keine XIAOMI-Geräte, hab alles in die Ecke gepackt weil es viel zu kompliziert ist mit öffnen, löten und was weiß ich. Wie gesagt, das mit dem Umflashen ist sicherlich möglich, soll aber aus genannten Gründen die letzte Möglichkeit bleiben.

Die Frage wie MQTT(2) die Geräte identifiziert wäre da doch schon wichtig, denke ich.

[Beta-User]

Na ja, praktisch alles, was an "günstigen Gadgets mit App" kommt, bringt intern einen WLAN-Chip mit, der mit Fernost "telefoniert". Ist für die "Hersteller" am einfachsten, Tuya bietet dafür ein "framework" für die "App-Entwicklung" an, mit dem das "jeder" "Hersteller" kann...

Kann natürlich sein, dass das Ding nur im heimischen WLAN (insbesondere über UDP) erreichbar ist, dann evtl. nicht (kannst du das Ding mit der App erreichen, wenn du mit dem Handy/dem Gerät für die App nicht im WLAN bist?).

Ansonsten sind mit "credentials" Zugangsdaten gemeint, und es kann natürlich auch sein, dass du "die große Ausnahme" gezogen hast, was die Firmware und die Zusammenarbeit mit der App angeht.

Die Frage wie MQTT(2) die Geräte identifiziert wäre da doch schon wichtig, denke ich.

Und es gibt keine wirkliche Frage dazu: Die Geräte _müssen_ sich laut Spezifikation mit einer (zumindest je Sitzung eindeutigen!) ClientID anmelden, MQTT2_SERVER macht dann (vereinfacht gesagt) je ClientID ein Gerät daraus.

Für MQTT ist aber eigentlich der Topic-Pfad wichtiger. Tipp zur Einarbeitung: beschaffe dir einen (fast beliebigen) Shelly und stelle ihn auf MQTT um, dann wird das ganze ggf. nachvollziehbarer. Weitere Erläuterungen zu MQTT werde ich hier nicht vornehmen, zumindest nicht als "Trockenübung". Das bringt nämlich nichts, und besser erklären als in dem von MadMAx-FHEM bereits verlinkten Artikel kann ich es vermutlich auch nicht.

[Superposchi]

kannst du das Ding mit der App erreichen, wenn du mit dem Handy/dem Gerät für die App nicht im WLAN bist?

Lässt wohl darauf schließen, dass du Recht hast und irgendwo ein Server die Kommunikation überträgt - darauf wolltest du doch wohl hinaus, oder?

Ansonsten sind mit "credentials" Zugangsdaten gemeint, und es kann natürlich auch sein, dass du "die große Ausnahme" gezogen hast, was die Firmware und die Zusammenarbeit mit der App angeht.

Naja, hatte beim Kauf eben extra darauf geachtet ein Gerät von einem deutschen Hersteller zu kaufen. Die App hat von Aufbau aber schon große Ähnlichkeit mit der MI-App.

Muss heute mal schauen mich mit dem AP des Diffusors zu verbinden. Hab ich gestern nicht geschafft. Hege da noch die Hoffnung (auch wenn sehr gering), dass dort genau wie bei den Shellys eine Option für MQTT aktiviert werden kann. Ansonsten bleibt wohl wirklich nur das flashen.

[Beta-User]

darauf wolltest du doch wohl hinaus, oder?

Naja, hatte beim Kauf eben extra darauf geachtet ein Gerät von einem deutschen Hersteller zu kaufen. Die App hat von Aufbau aber schon große Ähnlichkeit mit der MI-App.

Muss heute mal schauen mich mit dem AP des Diffusors zu verbinden. Hab ich gestern nicht geschafft. Hege da noch die Hoffnung (auch wenn sehr gering), dass dort genau wie bei den Shellys eine Option für MQTT aktiviert werden kann. Ansonsten bleibt wohl wirklich nur das flashen.

Die Shelly sind in der Beziehung die rühmliche Ausnahme, fast alles andere scheint über den genannten "China-Cloud-Server" zu laufen, und deren Betreiber sind nicht unbedingt daran interessiert, die Wahl des MQTT-Brokers ins Belieben der User zu stellen... (Auch bei den Shelly läuft das unter "Experten-Mode", und updates bekommt man dann auch keine!). Von Seiten der China-Cloud-Betreiber wird jedenfalls eher versucht, das Umflashen zu verhindern.

Und dass ein D-"Hersteller" zu diesem Preis ein "datenschutzmäßiges Sorglos-Produkt" anbieten könnte oder wollte, na ja, das würde ich mal unter "Wunschdenken" verbuchen...

[TomLee]

Auch bei den Shelly läuft das unter "Experten-Mode", und updates bekommt man dann auch keine!

Das nicht richtig, hab mich bisher nur wenig mit den Shellys beschäftigt, aber zufällig sah ich vor zwei Tagen in der Oberfläche meines Shelly 4 das ein update möglich sei, was ich dann auch problemlos anstossen konnte.

[Beta-User]

OK, dann scheint das neu zu sein...

Mein Test-Shelly (integriert irgendwann im Frühsommer 2020) hatte jedenfalls keine Meldung gegeben, bis ich neulich aus Neugierde mal kurz die Cloud wieder eingeschaltet hatte. Dann erst kam der Hinweis, dass ein update möglich sei, das ich dann auch gemacht habe, damit ich ggf. wieder bei den attrTemplate-Fragen "mitreden" kann...

Na ja, er lief ja eigentlich auch so...

[TomLee]

[OT]

x_update:noArg shellies/xxx/command update_fw

Habs nie ausprobiert, wozu habt ihr denn den setter in die Templates aufgenommen, wenns damals nicht möglich gewesen wäre ?

Bei mir ist die Cloud seit Inbetriebnahme ausgeschaltet und zufällig hab ich noch ein Reading (ist mir jetzt aufgefallen) welches ich schon lange nicht gelöscht habe:

Code Auswählen Erweitern

setstate MQTT2_shelly4pro_355132_CH1 2019-11-15 23:35:20 relay_1 off

Wie gesagt und jetzt erst vor zwei Tagen, allerdings aus der Shelly-Oberfläche, das update gemacht.

[/OT]

[Beta-User]

[OT]
wozu habt ihr denn den setter in die Templates aufgenommen, wenns damals nicht möglich gewesen wäre ?
[/OT]

Also: zu der Zeit, als die templates entstanden sind, hatte ich genau "0" Shelly  . Wenn mir dann jemand zuruft, dass das geht und die API das hergibt, ist es logisch, dass es jetzt da steht... Und beschwert hast sich bisher auch keiner, evtl. habe ich schlicht ein "Ausnahmegerät" geliefert bekommen .

Fakt ist jedenfalls: Weder via MQTT noch im WEB-Interface war das fragliche eine update zu sehen, das ging erst, nachdem ich die Cloud aktiviert hatte. K.A., ob es irgendeine Backdoor gibt, mir im Prinzip auch egal. Jedenfalls lag es wohl nicht an meinen lokalen Netzwerkeinstellungen, sondern hing an irgendwas auf dem Shelly...
(Kann sein, dass ich alle Einstellungen im AP-Mode gemacht hatte und er daher nie an der cloud hing; die Einrichtung ist lange her und die update-Frage war auch nicht wichtig...)