Hallo, kennt jemand zufällig diesen Diffusor oder ein anderes Modell von dem Hersteller?
https://www.amazon.de/gp/product/B07QPR8W3F/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1 (https://www.amazon.de/gp/product/B07QPR8W3F/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1)
Falls ja, wäre ich an Infos interessiert wie ihr ihn in Fhem eingebunden habt, die Angaben in Amazon sagen sowohl ZigBee-Unterstützung als auch das immer angegebene 2,4 Gh-Netzwerk.
Wo steht da was von Zigbee?
Ich hab auch nix zu Zigbee finden können.
WLAN und BT ist genannt...
Vielleicht hilft das weiter: https://forum.fhem.de/index.php/topic,106668.msg1005202.html#msg1005202
Ist das nicht der? Oder zumindest so ähnlich?
EDIT: ok, wohl nicht "der" aber ähnlich (zumindest für meine "müden Augen" auf den ersten Blick) ;)
Gruß, Joachim
Beim durchlesen der Seite (weiß selbst nicht mehr ob es in der Beschreibung oder den Kommentaren stand) hatte ich gelesen Unterstütz ZigBee und bei den Bewertungen hatte ich das Gegenteil gelesen.
Also ist definitiv ein anderes Gerät. Wie kann man denn das Gerät über das WLan in Fhem anbinden, kann dazu jemand was sagen?
Naja ctrl+f auf der Seite und dann Zigbee liefert zumindest nichts...
Gruß, Joachim
Diffusor ist endlich angekommen.
Also soweit ich gesehen habe ist nichts mit ZigBee. Hätte es erleichtert.
aber ich habe das Gerät am laufen, Verbindung mit dem WLan funktioniert recht einfach.
Über die Handy-App Smart-Life geht die Steuerung einfach und unkompliziert. Es lassen sich auch Timer etc. setzen.
Trotzdem würde ich das Ding natürlich gerne in meinen Fhem-Server integrieren.
Soweit ich es verstehe sollte die Anbindung über MQTT2 funktionieren, ähnlich wie bei den Shelly2.5er.
Aber ich habe anders als bei den Shellys keine Weboberfläche gefunden, kann auch nicht die IP herausfinden mit der das Gerät im Heimnetz verbunden ist.
Es wird aber ein eigener Webserver angeboten, zumindest heißt es in der Bedienungsanleitung, das man sich bei Problemen mit der SSID des Gerätes verbinden soll.
Kann mir jemand den grundlegenden Prozess erläutern wie ich das Gerät identifizieren muss, welche Devices ich in Fhem anlegen muss und wie diese dann mit dem Gerät verbunden werden.
Wiki und CommandRef hab ich mir durchgelesen, aber ehrlich gesagt versteh ich nicht was da geschrieben steht. Da gibt's so viel Varianten, da blicke ich nicht durch.
Wie du kannst nicht rausfinden welche IP er in DEINEM Netzwerk hat?
Was hast du für einen Router?
Wo läuft DHCP bei dir?
Normalerweise kann man das in jedem (mir bekannten DHCP) irgendwo sehen welche Geräte welche IP haben (der vergibt sie ja)...
Mit der SSID des Gerätes verbinden bedeutet (verm.) der spannt ein eigenes WLAN auf (wie z.B. Echos, Shellys, ... bei der Ersteinrichtung)...
Normalerweise verbindet man die dann per App oder Webinterface (Shelly) mit dem eigenen Netz...
Die verlinkte Seite hat nicht geholfen?
Ansonsten: keine Ahnung...
Bzw.: wenn er sich mit Alexa steuern lässt, dann kannst du ihn mittels echodevice-Modul "integrieren" bzw. zumindest steuern...
Gruß, Joachim
Ich habe eine Fritzbox 6490 (ja, ich weiß, dass die bei zu vielen Geräten Ärger machen soll)
Ich habe allen Geräten feste IP's zugewiesen, DHCP läuft quasi nur für die Erstverbindung.
Klar gibt mir die Fritzbox eine Liste der benutzen IP's, aber leider sind da alle neuen Gerät mit PC-xxx-xxx-xxx-xxx benannt, was mich nicht weiterbringt, denn die IP weiß ich ja auch so. Nur die Verknüpfung welches Gerät welche IP hat ist nicht erkenntlich. Und da mehrere Verbindungen dieser Art angezeigt werden, kann ich sie nicht manuell zuordnen. Ein Aufruf der jeweiligen IP läuft ins Leere, so dass mir das auch nicht weiterhilft bei der Identifizierung.
ZitatMit der SSID des Gerätes verbinden bedeutet (verm.) der spannt ein eigenes WLAN auf (wie z.B. Echos, Shellys, ... bei der Ersteinrichtung)...
Normalerweise verbindet mal die dann per App oder Webinterface (Shelly) mit dem eigenen Netz...
Ja, so verstehe ich die Anleitung. Muss ich aber noch probieren.
Die verlinkte Seite bezieht sich ja auf das Flashen, das will ich ja eigentlich gar nicht. Mir reicht es völlig, das Ding im Originalzustand anzusprechen wenn das geht.
Ich nutze kein Alexa, bei mir wird ausschließlich Google Assistant genutzt. Was genau meinst du mit echodevice?
Naja, also wie vergibst du fixe IPs?
Direkt in jedem Gerät?
Schlechte Idee, wenn zusätzlich ein DHCP läuft.
Bzw. dann halt: dein "manueller Bereich" außerhalb des DHCP-Bereiches...
Also ich kenne (und mache) das so: Gerät bekommt per DHCP eine Adresse. Dann sehe ich doch welche neu vergeben wurde. Dann weise ich DIESEM Gerät auf dem DHCP meine "Wunschadresse" zu und vergebe (sofern das der DHCP kann / die FB kann das) einen "sprechenden" Namen.
Wenn ich/man das so macht, dann weiß man doch wer wer ist...
Naja wie so oft bei solchen Geräten arbeiten die halt auf ihre "eigene Weise" mit "ihrem Anbieter".
Ob man da einfach so dazwischen kommt?
Was spricht gegen OTA flashen?
Wo ist das Risiko?
Entweder die Software geht drauf oder eben nicht...
...dann ist halt die "alte" wieder da (sollte, wenn der FW-Updatemechanismus halbwegs "vernünftig" implementiert ist)...
Mit echodevice meinte ich wie geschrieben das echodevice-Modul.
Damit kannst du eben die Alexa-Echos "steuern".
U.a. eben auch set ECHO_XXX textcommand schalte Irgendwas ein/aus
Also quasi wie wenn du zu dem Echo sprechen würdest nur halt ohne, dass du sprichst ;)
Du lässt praktisch fhem für dich sprechen ;)
Gruß, Joachim
Normalerweise vergebe ich die IP's direkt in der Fritz-Oberfläche. Sobald das Gerät neu gestartet wurde (Stecker kurz gezogen) ist die IP übernommen.
Klar vergebe ich meine IP's außerhalb des DHCP-Bereichs, wobei ich mir allmählich was einfallen lassen muss, denn die Anzahl verfügbarer Adressen wird immer kleiner.
Besonders da ich mit Bereichsgruppen arbeite. Also von ... bis ... für Netzwerkgeräte, von ... bis ... für Multimedia etc.. Meistens immer so mit 50 IP's pro Block.
Da gibt es dann natürlich Bereiche die fast leer sind und andere die fast voll sind.
ZitatAlso ich kenne (und mache) das so: Gerät bekommt per DHCP eine Adresse. Dann sehe ich doch welche neu vergeben wurde. Dann weise ich DIESEM Gerät auf dem DHCP meine "Wunschadresse" zu und vergebe (sofern das der DHCP kann / die FB kann das) einen "sprechenden" Namen.
Grundsätzlich mache ich das auch so, aber seit einiger Zeit habe ich halt 4 Gerät mit dieser kriptischen PC-... Benennung in der Liste. Keine Ahnung woher die kommen oder was sie sind. Eine Weboberfläche ist bei allen Geräten nicht durch die IP erreichbar.
Entweder hab ich irgendwann mal vergessen Geräte umzubenennen oder es sind "tote" Geräte oder ein Gerät hat mehrere IP's in Beschlag (was ich mir eigentlich nicht vorstellen kann).
ZitatNaja wie so oft bei solchen Geräten arbeiten die halt auf ihre "eigene Weise" mit "ihrem Anbieter".
Ob man da einfach so dazwischen kommt?
Wie müsste ich denn vorgehen um zu versuchen dazwischen zu kommen?
ZitatWas spricht gegen OTA flashen?
Wo ist das Risiko?
Entweder die Software geht drauf oder eben nicht...
...dann ist halt die "alte" wieder da (sollte, wenn der FW-Updatemechanismus halbwegs "vernünftig" implementiert ist)...
Unkenntnis, bisher nie gemacht, Garantieverlust, defektes Gerät bei Fehlschlag - das spricht erstmal gegen diese Option wenn es auch anders geht.
Ok, hatte echo auf den echo-Befehl (wie er in einigen Programmiersprachen vorkommt) bezogen, nicht auf die Alexa-Speaker. Damit ist das für mich nicht nutzbar, es sei denn es gibt was vergleichbares für Google Assistant. Nutze schon Fhem connect, aber das ist ja ziemlich eingeschränkt leider. So wie ich den Wiki-Eintrag verstanden habe sollte damit doch auch naturell Speak gehen, also Befehle in natürlichen Sätzen. Leider bekomme ich nicht mehr als on/off hin mit dem Modul.
Zitat von: Superposchi am 18 Januar 2021, 13:39:38
Wie müsste ich denn vorgehen um zu versuchen dazwischen zu kommen?
Naja Netzwerkverkehr mitschneiden...
Im Internet suchen, ob das schon jemand gemacht hat...
...
Gruß, Joachim
Mal ganz dumm gefragt, was macht das MQTT2-Device genau?
Ich bin davon ausgegangen, dass es einfach nur die Signale wie von der benutzen App von Fhem aus absendet bzw. empfängt.
Ist das falsch?
https://wiki.fhem.de/wiki/MQTT
Aber nur, wenn eben tatsächlich "echtes" mqtt verwendet wird (irgendwo wurde bei einem Gerät mal festgestellt: sieht aus wie mqtt ist aber nicht wirklich mqtt) und die Kommunikation nicht verschlüsselt ist...
(oder man eben die Schlüssel kennt/anpassen kann)
Gruß, Joachim
Ich nutze für meine Shelly's ja den in Fhem integrierten MQTT2_Server. Was mir nicht klar ist und auch aus den ganzen Wiki's nicht hervorgeht ist die Frage wie identifiziert Fhem das richtige Gerät.
Soweit ich das überblicke wird nirgends eine IP hinterlegt. es gibt nur das Server-Device und für jeden Shelly-Akotor ein MQTT2_Device-Device. Aber wie werden diese unterschieden/zugeordnet?
Wenn ich alles richtig verstehe, müsste ich zusätzlich zum internen MQTT2_Server-Device eine MQTT_GENERIC_BRIDGE-Device erstellen, oder?
Zitat von: Superposchi am 18 Januar 2021, 14:15:18
Wenn ich alles richtig verstehe, müsste ich zusätzlich zum internen MQTT2_Server-Device eine MQTT_GENERIC_BRIDGE-Device erstellen, oder?
Mit ziemlicher Sicherheit nicht!
Dieses Gerät scheint seine Daten "irgendwie" (vermutlich - wie von MadMax-FHEM bereits ausgeführt - verschlüsselt im MQTT-Protokoll (!)) an einen Server "irgendwo da draußen" (vermutlich in China, Stichwort "Tuya"), und deine "App" macht das im Prinzip genauso.
Das hat NICHTS mit dem zu tun, was in FHEM an MQTT(2)-Modulen verfügbar ist. Wenn du a) die credentials zu dem chinesischen Server und b) die Topics kennen würdest, könntest du ggf. mit MQTT2_CLIENT versuchen, dich da reinzuhängen (00_MQTT.pm kann afaik keine verschlsselten Zugänge).
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.
Ansonsten ist das ziemlich aussichtslos...
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?
ZitatSo 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.
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.
ZitatDie 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.
Zitatkannst 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?
ZitatAnsonsten 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.
Zitat von: Superposchi am 19 Januar 2021, 09:46:48
darauf wolltest du doch wohl hinaus, oder?
;)
Zitat
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...
ZitatAuch 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.
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...
[OT]
Zitatx_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:
setstate MQTT2_shelly4pro_355132_CH1 2019-11-15 23:35:20 relay_1 offWie gesagt und jetzt erst vor zwei Tagen, allerdings aus der Shelly-Oberfläche, das update gemacht.
[/OT]
Zitat von: TomLee am 19 Januar 2021, 11:09:23
[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 ;D . 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 ;D .
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...)