Alexa findet kein Gerät #1
Comments
|
Hi, Im seriellen Portmonitor werden empfangene Multicast-Pakete angezeigt, die Alexa beim Suchen nach Geräten ins Netzwerk schickt. Wenn hier die IP deines Echos nicht erscheint, kann es eventuell daran liegen, das die WLan-Client-separierung im AccessPoint eingeschaltet ist. In der Fritzbox heisst der Punkt "die unten angezeigten aktiven wlan-geräte dürfen untereinander kommunizieren" und ist in den Einstellungen bei WLAN->Sicherheit zu finden. Wie auch immer der Punkt in der Konfiguration heisst, es ist auf jeden Fall sicher zu stellen, das der esp8266 sicher mit dem Echo unterhalten kann, also eine separierung abgeschaltet ist. Falls der AccessPoint eine Firewall hat, ist darauf zu achten, das udp-pakete (port 1900) und tcp (port 80-96) gesendet und empfangen werden können. |
|
Wow das ging ja schnell !! |
|
Danke... Bei Fernsteuerungen ohne Dip-Schalter müssen die sogenannten TriState-Codes eingelesen werden. Dazu benötigt man ein Empfängermodul und das Beispielsketch aus der rc-switch-library "ReceiveDemo_Advance". Dieser Sketch gibt die TriState Codes aus, die dann in die Konfigurationsoberfläche von RFBridge eingetragen werden können. Leider funktioniert das aber wohl nicht mit jeder Fernbedienung. Ich hatte selber mal eine selbstlernende Funksteckdose von Aldi, die ich einlesen wollte. Leider zeigt der Sketch hier "TriState Code: not applicable". Damit gehts dann leider nicht. Eine IR-Steuerung hatte ich auch schonmal überlegt. Derzeit ist aber der Speicherplatz im EEPROM für die Konfigdaten ziemlich knapp geworden. Ich müsste erstmal überlegen, wie ich dieses Problem knacke, denn FLASH-Speicher gibts ja grundsätzlich zu hauf... |
|
Ok der Haken ist in der Fritzbox gesetzt. Wie funktioniert das mit dem seriellen Portmonitor welches Programm kannst du empfehlen? Muß ich die Portfreigaben unter Filter-Listen anlegen ? wenn ja Quellcode = Zielcode ? oder was muß ich da machen? Alexa findet einfach kein gerät. |
|
Nein, es sind keine Portfreigaben notwenig. Ganz im Gegenteil. Aus sicherheitstechnischen Aspekten rate ich dringend davon ab, den ESP8266 aus dem Internet erreichbar zu machen. Als Portmonitor empfehle ich den in der Arduino IDE eingebauten seriellen Monitor. Wenn sich der Alexa-Dot und der ESP8266 im selben Wlan befinden, habe ich keine Idee, woran das liegen könnte. Ich habe dieses Programm bereits auf mehreren verschiedenen Modulen installiert. Das Netzwerk war noch nie ein Problem. Welches ESP8266-Modul hast du denn im Einsatz? Und was genau ist die Antwort von Alexa auf das Sprachkommando "Alexa, erkenne meine Geräte"? |
|
ich habe ein nodemcu V3 im Einsatz. |
|
Über die App gestartet: |
|
Hier habe ich die suche mit der Sprache gestartet: |
|
Ok, es scheint tatsächlich daran zu liegen, das es sich um einen Echo-Plus handelt. Hast du die Gedult, mir dabei zu helfen, die Software ans laufen zu bekommen? |
|
Ja natürlich ich möchte ja gerne die Steckdosen schalten und selber bekomme ich das nicht hin |
|
Diese Bin-Datei gibt die empfangenen Datagramme beim Suchen auf dem Monitor aus. Diese Daten benötige ich. |
|
ok ich Flash sie auf das node und dann starte ich die suche oder wie ? |
|
Genau, ich brauche die Daten die Alex (192.168.178.35) bei der Suche von Geräten ins Netz geschickt werden. |
|
UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.35:50000 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:1900 UDP Packet Type: Multicast, From: 192.168.178.1:36574 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:36574 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:36574 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:36574 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:36574 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 UDP Packet Type: Multicast, From: 192.168.178.1:32976 |
|
Da scheint sich tatsächlich was geändert zu haben...Bitte versuche mal die Suche mit dieser Version: |
|
UDP Packet Type: Multicast, From: 192.168.178.1:36574 |
|
Ich hab mal ein bisschen recheriert. Wohlmöglich wurde die ursprüngliche Funktion, die sogn. WeMo-Switches zu schalten, in einen Skill ausgelagert. Siehe: "NOTE FOR EXISTING ALEXA USERS: If you previously have Wemo devices paired to Alexa and you cannot operate a product, then you’re required to update your Alexa devices with a new Wemo Skill. This will change the way Alexa interacts with your Wemo devices and ensure proper functionality." Ich schlage daher vor, das du deinen ESP8266 wieder auf die ursprüngliche Release-Version von RFBridge flashst und über die Alexa-App den im Artikel genannten WeMo-Skill installierst und aktivierst. |
|
Die WeMo App habe ich gekauft aber auch diese findet nichts UDP Packet Type: Multicast, From: 192.168.178.1:36574 |
|
WeMo "App"?! Meinst du damit, daß du dir im Google Play Store die Wemo App installiert hast? Gemeint ist eigentlich der Alex-Skill.... |
|
Bei der Aktivierung des WeMo Skills heißt es Wemo mit Alexa verbinden. Dann: Button Bereit zur überprüfung: Es ist ein Netzwerkproblem aufgetreten. Button"einreichen" Kurz warten: Hmm. Wir können keine Übereinstimmung finden. Button erneut versuchen: In der WeMo App auf dem Ipad kann man nach neuen Geräten such dort heißt es dann auch kein gerät gefunden. Eine einstellung für den Rmeotezugriff ist in der App nich möglich: |
|
Also zunächst mal Danke für deine Unterstützung bei der Entwicklung der Software. Wie ich bereits sagte, offensichtlich hat sich wohl was bei der eingebauten Unterstützung der WeMo-Switches, die von der RFBridge-software emuliert werden, bei dem Echo Plus etwas geändert. Da ich keinen Echo Plus habe, wird es für mich sehr schwierig, eine Unterstützung dafür anbieten zu können. Ich werde aber in den kommenden Tagen versuchen, die Software so anzupassen, das sie mit der WeMo-App funktioniert, in der Hoffnung, das sie dann auch mit dem Echo Plus funktionieren wird. Solange möchte ich dich um Gedult bitten und hoffe, das du dann weiter für mich testen kannst. |
|
Zur deiner Info: Fauxmo ist das Projekt, auf den dieses Projekt basiert. Dort hat man wohl jetzt ähnliche Probleme.. |
|
Ok Dann bin ich wohl nicht der einzige. Habe es gestern abend einmal bei bekannten mit Alexa aus der 1.Gen getestet dort funktioniert es einwandfrei. Also kann ich ausschließen das ich etwas falsch gemacht habe. Und ich muss sagen eine wirklich tolle Sache die Lampensteuerung von dir. |
|
Freut mich, das dir die Software gefällt. Könntest du mal bitte die Firmeware-Version deines Echo Plus raussuchen? Du findest sie unter "Einstellungen" in der Alex-app. Die Spalte heisst "Version der Gerätesoftware". |
|
Klar mach ich das für dich! |
|
Da scheint der Hund begraben zu sein. Zweite Generation Echos, womit es noch funktioniert, haben die Version 592452720. Aber ich habe gerade einen Hinweis bekommen, wie man das Problem löst. Könnte nur etwas dauern. |
|
das währe super! |
|
Ich bin noch nicht ganz fertig, aber eingerichtete Geräte müssten von Alexa jetzt erkannt werden können. |
|
Hallo hatte gestern keine Zeit aber habe es gleich heute morgen versucht und ja er findet die Geräte: HTTP/1.1 200 OK UDP Packet Type: Multicast, From: 192.168.178.34:50000 HTTP/1.1 200 OK ON CLIENT CALLED HTTP/1.1 200 OK UDP Packet Type: Multicast, From: 192.168.178.35:50000 HTTP/1.1 200 OK ON CLIENT CALLED HTTP/1.1 200 OK UDP Packet Type: Multicast, From: 192.168.178.35:50000 HTTP/1.1 200 OK ON CLIENT CALLED HTTP/1.1 200 OK UDP Packet Type: Multicast, From: 192.168.178.1:36574 PS: Super mach weiter so. |
|
Habe gerade deine Hue-Emu nochmal auf meinem Echo Dot Gen. 2 (SW.: 597465220) getestet. Er befindet sich bei mir in der Firma also in einem komplett anderen Netzwerk als der Echo (SW.: 595530420). Fauxmo hat auch hier nicht funktioniert. LAN-Verbindung* 1 LAN-Verbindung* 3 Drahtlosnetzwerkverbindung Bluetooth-Netzwerkverbindung Starting HueEmulation for IP 192.168.1.121:C48508363206 |
|
Echo Dot und der grosse Echo der ersten Generation (genannt Echo1) scheinen den selben softwarestand bezüglich SmartHome/Wemo/Hue zu haben. Deshalb funktioniert hier die SmartHome-Geschichte wie bisher. Nur bei Echo Plus und Echo der zweiten Generation (ich nenne ihn Echo2) hat sich was geändert:
Hiermit fragt der Echo2 nach einer Authtentifizierungs-API. Diese ist im HueEmu nicht eingebaut und antwortet deshalb mit einem 404/not found. Daraufhin bricht er den erkennungsvorgang ab. Der Echo1 macht das nicht, deshalb funktioniert hier die Emulation. Ich werde gleich schnell die Auth-Api in den Emulator einbauen. Dann können wir schauen, wie weit er kommt. |
|
ok ich muss nur immer hin und her fahren oder eines der beiden Geräte mit nehmen zum Test. |
|
Ich danke dir für deine Hilfe. Mir würde es reichen, wenn wir den HueEmu auf dem Echo2 zum laufen bekommen würden. Hier ist die Version mit Auth-API: |
Dieses Projekt hat vermutlich mit dem Echo2 das selbe Problem, wie alle anderen Projekte auch. Es funktioniert einfach nicht, weil im Echo das Protokoll zur Ansteuerung der Wemo-Geräte geändert worden ist. Wenn ich mit der HueEmulation auf dem ESP8266/NodeMcu fertig bin, werde ich mich um eine Ansteuerung per Infarot bemühen. Versprochen. |
|
die Ansteuerung per IR oder RF ist ja letztenendes egal solange man ein Sketch als Basis hat welches zumindest mal Alexa kompatibel ist. Deine aktuelle Hueemu wird vom Echo2 jetzt erkannt, beim Anschalten von test 1 kommt ein Windowsfehler: "org.huesken.fauxmonet.Console funktioniert nicht mehr" und Alexa sagt: "ich weis nicht was schief gelaufen ist" Das gleiche passiert bei allen anderen Sprachbefehelen bzgl. Test1&2 und auch bei dem Schalten per App LAN-Verbindung* 1 LAN-Verbindung* 3 Drahtlosnetzwerkverbindung Bluetooth-Netzwerkverbindung Starting HueEmulation for IP 192.168.178.94:C48508363206 |
Der HueEmu erwartet, das im Datenpaket vom Echo2 ein Leerzeichen zwischen ":" und "true" beinhaltet. Jedenfalls war das beim Echo1 so der Fall. |
|
Jetzt sollte das ding nicht mehr abschmieren. Aus diesem C# stumpf kann ich jetzt einen schöne HueEmulation für den NodeMCU basteln. |
|
ja jetzt hängt sich hueemu nicht mehr auf, Alexa sagt aber: "Das Gerät Test1/2 reagiert nicht, bitte überprüfe Netzwerkverbindung und Stromversorgung" Hier wieder der Consolenausdruck. LAN-Verbindung* 1 LAN-Verbindung* 3 Drahtlosnetzwerkverbindung Bluetooth-Netzwerkverbindung Starting HueEmulation for IP 192.168.178.94:C48508363206 |
Vermutlich sagt sie das, weil der HueEmu bei der Gerätestatusabfrage immer antwortet, das das Gerät ausgeschaltet sei, egal ob es eingeschaltet wurde oder nicht......es ist halt nur ein dummer Stumpf |
|
sie sagt es jedenfalls beim ein und ausschalten. Wenn es wirklich nurnoch das ist, wird es wohl kein Hexenwerk mehr sein ihr den aktuellen Status mitzuteilen. |
|
die aktuelle Version vom hueemu funktioniert übrigens auf dem Dot tadellos: LAN-Verbindung* 1 LAN-Verbindung* 3 Drahtlosnetzwerkverbindung Bluetooth-Netzwerkverbindung Starting HueEmulation for IP 192.168.1.121:C48508363206 |
|
Ich hab mal ne statusabfrage eingebaut. Ich kann hier allerdings gerade nichts testen....das ist so völlig ins Blaue reinprogrammiert. |
|
Die Wemo-Emulation hat die Unschönheit, das man für jedes Gerät (also für jeden Schalter), seine eigene SSDP-Nachricht über die unsichere UDP-Verbindung schicken muss. In gut ausgelasteten WLans kann das zu Problemen führen. Dieses Problem hat man mit der HueEmulation nicht mehr, da nur noch die Bridge per SSDP erkannt werden muss. Die einzelnen Lichter nicht. |
|
Hallo Monarch, echt genial dass du es hinbekommen hast! (habe mittels deiner rfbridge endlich ein gerät von alexa 2.0 erkennen lassen können) Allerdings bin ich etwas verwirrt...^^ Ich hatte bisher in meinem eigenen Sketch einen esp mit verschiedenen funktionalitäten programmiert, denen ich mittels fauxmo hardcoded unterschiedliche Alexa-Namen gegeben habe. Habe dann mit Hilfe des OnMessage-Events die entsprechenden Funktionalitäten ausgeführt, sobald der Alexa Command erkannt wurde. Ich dachte die ganze Zeit beim Lesen, dass du einen Sketch entwickelt hast, den ich in meinen Sketch einbinden kann um die Geräte wieder im Quellcode so zu definieren, dass Alexa sie auch findet und ansprechen kann. Aber dann war es eine .bin :D Ist das jetzt überhaupt möglich meinen eigenen Quellcode zu triggern? Wenn ja, wie kann ich die rfbride.ino.bin so umschreiben, wie ich es benötige ? Hatte bisher immer über die Arduino IDE geflasht... |
|
bei der aktuellsten Version hat sich nichts verändert. LAN-Verbindung* 1 LAN-Verbindung* 3 Drahtlosnetzwerkverbindung Bluetooth-Netzwerkverbindung Starting HueEmulation for IP 192.168.178.94:C48508363206 |
|
Echo Dot 2 und Echo 2 sind zwei unterschiedliche paar Schuhe! Meines Wissens funktioniert die RFBridge nur mit dem Echo Dot 2, aber nicht mit dem Echo 2 bzw Echo Plus. Du kannst in der RFBridge auch eigene funktionen einbauen. Dafür war es allerdings nie gedacht. Das Projekt richtet sich hauptsächlich an unerfahrene Benutzer. Um das Projekt kompilieren zu können benötigt man Visual Studio Community und weitere Tools. Beschrieben im Readme.md : https://github.com/Monarch73/RFBridge#setting-up-development-environment |
|
ich wäre aber auch sehr an einer offenen Version als Arduino Sketch also .ino oder an einer library mit einem Beispiel usw intressiert. Das selbe gilt natürlich für die spätere Hue Version. Nur um eine funktionierende komunikation zu Alexa zu haben, als Basis für eigene Projekte. |
|
Grundsätzlich lässt sich das RFBridge.ino auch im Arduino Studio kompilieren. Allerdings muss dafür ein aktuelleres esp8266-Arduino-SDK installiert werden (2.4.0 ist vorgestern released worden) Und die externen libraries, die vom "git clone --recursive" ebenfalls geladen werden, müssen in den entsprechende Ordner im Heimverzeichnis des aktuellen Benutzers verschoben werden. Ich nehme an, ein findiger Benutzer wird sich da mit ein paar Grundkenntnissen schon zurecht finden. Ich als Softwareentwickler ziehe Visual Studio aber definitiv vor. Dagegen ist das Arduino Studio regelrecht primitiv und bietet so gut wie keine Hilfen. Also eine offizielle Unterstützung für das Arduino Studio wirds von mir nicht geben. |
|
gibt es neuigkeiten? |
|
Gedult. Ich stelle das Projekt auf eine kompett neue Codebasis mit einem auf Angular5 basierendem Webfrontend und aktueller Version der Espressif-SDK. Soll ja schließlich gut werden :-) https://github.com/Monarch73/RFBridge2/commits/master |
|
jetzt hab ich nur Bahnhof verstanden XD ich hoffe ja ich bekomm es überhaupt hin es in eine ino zu konvertieren um es für meine Bedürfnisse zu erweitern oder anzupassen. |
|
Alternativ kannst du auch Visual Studio 2017 Community runterladen und dadrin da Visual Micro-Addon installieren. Das ist 1000 mal besser als dieses Arduino Studio. |
|
ich hab mit visual studio schon arbeiten müssen und war nur auf Kriegsfuß damit. Es ist einfach zu professionel und bietet zu viele Möglichkeiten alles zu verstellen |
|
So. Ich habe eine Version fertig, die mit meinem Amazon Echo der ersten Generation problemlos zu funktionieren scheint. https://github.com/Monarch73/RFBridge2/files/1628242/RFBridge2.zip Ich erwarte nicht, das die Software auf anhieb mit einem Echo der zweiten Generation zusammen spielt. Aber Probleme sind da, um sie zu lösen. |
|
👍 ...fehlen nur noch die zu steuernden Steckdosen für einen vollständigen Test... Wie lässt sich denn die RFBridge wieder komplett zurücksetzen, wenn z.B. das WLAN geändert werden muss? |
|
Das sind ja excellente Neuigkeiten! Wenn die RFBridge nach einem Reset ihr WLAN nicht findet, geht die Software automatisch wieder in dem Errichter-Modus, in dem der Access-Point "EasyAlexa" wieder sichtbar wird. Hier kann man dann wieder über http://192.168.4.1 eine neue ESSID und Passwort eingeben. Durch setzen eines Häckchens kann hier auf der Speicher (SPIFFS) einmal komplett formatiert werden. Da werden dann auch alle Lampen/Schalter gelöscht |
|
Mit Verweis auf RFBridge2 möchte ich dieses Projekt einstampfen. Obwohl die Entwicklung von RFBridge2 noch nicht abgeschlossen ist, hat RFBridge bereits jetzt viele Vorteile, die RFBridge (1) nicht bietet: Ein auf Angular5 basiertes Webfrontend, ein IRRemote interface (Infrarot Fernbedienung) und eine phillips hue emulation, die das Projekt deutlich kompatibler zu den Amazongeräte machen |
Hallo habe es soweit hinbekommen dass ich über den browser die Lampen ein und aus schalten kann.
Aber Alexa findet keine Geräte an was kann das liegen ??
The text was updated successfully, but these errors were encountered: