Hallo, ich möchte euch mein Heimautomatisierungsprojekt vorstellen. Es geht darum, per Alexa (bzw Google Home) Sprachbefehle kostengünstige Funksteckdosen, wie man sie im Baumarkt erhält, zu schalten. Das man mit dem Amazon Echo machen kann, ist ja weiss Gott nichts Neues. Solche Projekte gibt es im Web wie Sand am Meer. Bei meinem Projekt war die oberste Priorität, das es so kostengünstig wie möglich sein sollte. Ausserdem sollte auch ein Elektronik- bzw Computelaie es einsetzen können und ich glaube, das ist mir ganz gut geglückt. Alle Projekte, die man im Web so finden kann, setzen vorraus, das man ein Entwicklungsumgebung einrichtet und Quellcode selbst kompiliert. Das ist bei meinem Projekt nicht der Fall. Aussemdem sollen die Betriebskosten (Stromverbrauch) so gering wie möglich sein; deshalb kommt kein PC, kein RaspberryPI sondern ein ESP8266 zum Einsatz. Benötigt werden also: - Ein Esp8266-development board. Ich empfehle ein D1 Mini R2. Denkbar ist aber auch ein Nodemcu oder ein ESP-01. Letzteres ist zwar das günstigste Board, benötigt aber wieder einen externen flasher... - Ein 433Mhz Transmitter. Beim Chinamann kosten diese Module wenige cent pro stück. Bei Amazon Deutschland etwa 2-3 Euro. - 433Mhz Funksteckdosen. Diese bekommt man im Baumark im 3erpack für relativ kleines Geld. Optimal sind Funksteckdosen mit sog. Dip-Switches (Mäuseklavier). Bei Funksteckdosen mit Drehwählern wird die Einrichtung etwas schwieriger. (Hier muss man erst die sog. TriState-Codes mit einem 433mhz Empfängermodul einlesen. Aber das Thema möchte ich an dieser Stelle aussen vor lassen.) Tja, jetzt kommt vermutlich das komplizierteste: Diese beiden Module müssen miteinander mit einfachen Drahtbrücken verbunden werden. VCC an +5V, GND an GND (-) und Datenpin geht an GPIO2. Beim D1 Mini R2 ist das D4. Bei anderen Boards müsste ihr das im PinOut-Plan kurz nachschauen. Jetzt muss der Programmcode auf das Modul geflashed werden. Dazu lädt man sich aus dem github-Repository den neuesten Release herrunter und das Flash-Tool: https://github.com/nodemcu/nodemcu-flasher/archive/master.zip https://github.com/Monarch73/RFBridge/releases Die heruntergeladenen Archive werden entpackt und man startet die flasher.exe und brennt damit die entsprechende bin-datei auf sein ESP-Board ab adresse (0x0000). Fertig. Ab jetzt brauchen wir den PC nur noch zum Einrichten. Wenn alles geklappt hat,sieht man nun ein WLAN-Hotspot der sich "EasyAlexa" nennt. Damit verbindet man sich und öffnet im Browser "http://192.168.4.1";. Hier wird man gebeten, die ESSID und das Passwort seines AP anzugeben, auf speichern zu klicken und das ESP8266-Modul neu zu starten. Name und Passwort sowie die folgende Konfiguration wirden im nicht-flüchtigen Speicher des ESP8266-Moduls gespeichert und ist somit auch nach Versorgungsspannungverlust noch vorhanden. Wenn das auch geklappt hat, müsste der WLAN-Hotspot nun verschwunden sein. Stattdessen müsste sich das Modul mit dem WLAN verbunden haben. Um die Software zu konfigurieren brauchen wir die IP-Adresse. Diese kann man sich entweder mit meinem Network-Scanner raussuchen (z.B. Android: Net Scan) oder man kann sie mit einem seriellen Terminal sich anzeigen lassen. Diese IP-Adresse öffnet man im Browser z.B: http://192.168.0.19 (Achtung: Das ESP-Modul hat keine eigene Firewall und keine Authetifizierung. Es ist eine ganz furchtbar schlechte Idee, diese IP aus dem Internet zugänglich zu machen!) Man bekommt eine Eingabe-Maske angezeigt mit zwei Zeilen mit eingabe-boxen. Wir konzentrieren auf die untere. Zuerst geben wir einen Namen in das Namensfeld ein. Dieser Name sollte von Alexa per Sprachbefehl leicht zu erkennen sein. Ein schlechtes Beispiel wäre z.B. Namen wie "b1" oder "abc" usw. Man wählt lieber ein Wort aus dem Wörterbuch wie "Lampe". Es finden sich in der Funksteckdose üblicherweise ein DipSwitch-Block mit 10 Schaltern. Jede dieser Schalter kann entweder in "on"- oder "off" Position sein. Diese Positionen müssen wir nun übersetzen, wobei "on" als "1" und "off" als "0" zu representieren ist. Die ersten 5 Schalter sind der sog. "Hauscode". Diese müssen in der entsprechenden Textbox übertragen werden. z.B. "00110". Die letzten 5 Code sind der Gerätecode und werden in der entsprechenden Texbox eingetragen. Die anderen Tristate-Textfelder müssen leer bleiben. Ein Raum-Name kann eingetragen werden, wird aber zur Zeit noch nicht verwendet. Auf Speichern klicken. Der Gerätename sollte nun nebst Ein/Aus-Button im Browser erscheinen. Wenn das der Fall ist, sollte der Echo-Dot nun in der Lage sein, das Gerät zu erkennen. Die Geräteerkennung startet man per Alexa-app im Smart-Home-Reiter oder per Sprachbefehl: "Alexa, erkenne meine Geräte". Alexa sollte nach einer Weile melden, das mindestens 1 Gerät erkannt worden ist. Dieses kann man nun mit dem vergebenen Namen schalten. z.B: "Alexa, schalte Lampe ein", "Alexa, schalte Lampe aus"
Hallo Niels, Dein Beitrag war für mich der Anlaß, mir endlich auch so ein paar ESP-Boards zu bestellen. Die Verbindung mit Alexa ist das, was ich immer gesucht habe. Gruß, Rene
Interessantes Projekt, wer sich allerdings erst diese simplen Funksteckdosen anschaffen muss, ist besser bedient gleich eine WLAN-Dose zu erwerden. (Sonoff et al). Das 433MHz-Protokoll verschlüsselt in keinster Weise.
Hi, sehr schön! Hatte schon lange mal vor meine Implementierung zu verschönern...das kann ich mir jetzt sparen. Danke dafür! PS: Ich hab meinen code mal mit angeängt...evtl kann man ja ein paar Code-Fetzen davon gebrauchen... LG Johann
@Olli, die WLAN Steckdosen kosten aber viel mehr und der Stromverbrauch liegt auch ein paar mW über den RF Dosen. Zuhause habe ich die Intertechno Dosen, weil die von JBMedias LightManager unterstützt werden. So hab ich in der PRE-Alexa Ära meine TV IR-Steuerung auf Funk Bridge realisiert. LG Johann
Oliver S. schrieb: > Interessantes Projekt, wer sich allerdings erst diese simplen > Funksteckdosen anschaffen muss, ist besser bedient gleich eine WLAN-Dose > zu erwerden. (Sonoff et al). Wie ich bereits sagte, das Projekt ist auf Low-Cost optimiert. Eine Wemo WLAN-Steckdose kostet pro Stück 50€. Für den selben Preis bekommt man Funksteckdosen im 10-Pack.
Johann H. schrieb: > PS: Ich hab meinen code mal mit angeängt...evtl kann man ja ein paar > Code-Fetzen davon gebrauchen... Ich sehe, du hast 6 Geräte in deim Code eingetragen. Mit sovielen Geräten habe ich meine Software noch nicht getestet; obwohl es eigentlich keine Rolle spielen sollte. Sag mal bitte auf jeden Fall bescheid, ob es Probleme gibt oder auf anhieb problemlos funzt.
Niels H. schrieb: > Wie ich bereits sagte, das Projekt ist auf Low-Cost optimiert. Eine Wemo > WLAN-Steckdose kostet pro Stück 50€. Für den selben Preis bekommt man > Funksteckdosen im 10-Pack. Die weit verbreiteten Sonoff WLAN Steckdosen mit ESP8266 (freie Firmware verfügbar) gibt es einzeln und inkl. Versand ab z.Zt. 4,36EUR (https://de.aliexpress.com/item/Itead-Sonoff-Smart-Wifi-Switch-DIY-Smart-Wireless-Remote-Switch-Domotica-Wifi-Light-Switch-Smart-Home/32831445550.html). Das unterbietet Deinen 10er-Pack Funksteckdosen deutlich.
Son of Esp schrieb: > Die weit verbreiteten Sonoff WLAN Steckdosen mit ESP8266 (freie Firmware > verfügbar) gibt es einzeln und inkl. Versand ab z.Zt. 4,36EUR Das ist aber keine Steckdose sondern ein Gerät, das erst noch angeschlossen/ verbaut werden muss. Die SONOFF WLan-Steckdosen kosten auch dort, bei Aliexpress, 10€. Wenn du es dir importieren lässt, dauert deine Bestellung 6-8 Wochen und wenn du über 20€ kommst, könnte es passieren, das dein Paket im Zoll hängen bleibt. Man hat dann eine Woche Zeit, um es beim Zollamt abzuhohlen und Rechnung und Überweisung nachzuweisen. Zu Uhrzeiten, wo jeder normale Mensch arbeiten ist, versteht sich. Eine einzelne Sonoff-WLAN-Steckdose kostet hier zu lande etwa 20€
:
Bearbeitet durch User
Mehrere Geräte gingen bei mir auch erst, nachdem ich ein kleines [hässliches] delay in den UPNP Responder gepackt habe. 8 Geräte ohne Probleme. Ich sag Dir auf jeden Fall Bescheid, ob deine Version auch klappt... Sonoff ist cool, wusste nicht, dass die SOOO billig sind. Hab mir mal eins bestellt, zum ausproBIERen, A propos Bier...schönen Feierabend. LG Johann
Niels H. schrieb: > Die SONOFF WLan-Steckdosen kosten > auch dort, bei Aliexpress, 10€. Wenn du es dir importieren lässt, dauert > deine Bestellung 6-8 Wochen und wenn du über 20€ kommst, Kommt drauf an, wann Du bestellst. Ich habe die für ca. 6,50 € / Stück bekommen. Und ob Du die 23 € überschreitest ist Dir ja überlassen. Man kann auch z. B. 10 mal 1 Stück (versandkostenfrei) bestellen - oder? Ich habe die Teile i.d.R. nach 3 - 5 Wochen. Aber wie lautet Der Thread nochmal?
Den Feuerlöscher Bitte nicht vergessen mit zu Bestellen. Nunja bei MQTT gibt es ein Problem man benötigt einen Broker. Der kann im AWS -> Amazon Web Services sein oder lokal. Lokal muss dieser aber per HTTP ansprechbar sein, um die Alexa request zu parsen und zu MQTT zu Verwandeln. Das lustige dabei ist das man Alexa auch reden lassen kann wenn man in der response entsprechenden Code übergibt. Das Teil hat schon seinen reiz, allerdings aus Sicht vom Datenschutz sehr bedenklich.
:
Bearbeitet durch User
Son of Esp schrieb: > Das unterbietet Deinen 10er-Pack Funksteckdosen deutlich. Nun, Funksteckdosen habe ich im Dreierpack in D schon für 10 EUR gekauft. Ob es solche Angebote heutzutage auch noch gibt, weiss ich nicht.
Alles was du in die Büchse hineinspricht wandert nach draußen. Sie wartet ja auf das Stichwort "Alexa" zeichnet als alles im Raum auf. Da fallen extrem viele Daten an. Aus dem dein Verhalten, Gewohnheiten und Stimmung ableiten lässt. Das nutzt Amazon aus um dein Kaufverhalten zu animieren und zu analysieren. Damit verdient Amazon viel Geld. Zumal sich Menschen damit geziehlt manipulieren lassen. Viel besser als z.Bsp über Smartphone, sie ist Teil deines Lebens das du mit denjenigen teils die Zugriff auf die Daten haben.
:
Bearbeitet durch User
Marco H. schrieb: > Alles was du in die Büchse hineinspricht wandert nach draußen. Sie > wartet ja auf das Stichwort "Alexa" zeichnet als alles im Raum auf. Das Stichwort wird aber ausgewertet und erst ab Erkennung dann wird das Kommando aufgezeichnet und übermittelt.
Marco H. schrieb: > Nunja bei MQTT gibt es ein Problem man benötigt einen Broker. Der kann > im AWS -> Amazon Web Services sein oder lokal. Sogar den könnte man minimalistisch auf einem ESP laufen lassen: https://github.com/martin-ger/esp_mqtt 433MHz-Steckdosen sind ausserdem nicht irgendwie verschlüsselt oder sonstwie gesichert. Wieso gibt es eigentlich noch nicht so ein Spaßgerät was ständig alle Codes rauf- und runterzählt und damit Steckdosen in der Nachbarschaft klappern lässt?
:
Bearbeitet durch User
Oliver S. schrieb: > Wieso gibt es eigentlich noch nicht so ein Spaßgerät was ständig alle > Codes rauf- und runterzählt und damit Steckdosen in der Nachbarschaft > klappern lässt? Ich bin mir sicher, die gibt es bestimmt. Man müsste aber dann vermutlich eine größere Sendeleistung haben, denn das Problem wird vermutlich die Reichweite sein. Wenn ich mich draußen auf der Straße mit einem kleinen, normalen Handsender hinstelle, reagiert drinnen keine Steckdose.
Oliver S. schrieb: > Wieso gibt es eigentlich noch nicht so ein Spaßgerät was ständig alle > Codes rauf- und runterzählt und damit Steckdosen in der Nachbarschaft > klappern lässt? Wer sagt, dass es das nicht gibt? Natürlich nur, um den Hauscode der eigenen Steckdosen zu ermitteln ;-) Für Fernseher mit IR-Fernbedienung gibt es sowas auch schon lange - TV-gone oder so ähnlich
Hast du dir mal HABridge angeschaut ? finde das in Verbindung mit den ESPs recht ok, Nutze das für meine selbstgebauten Lichtschalter, Übertragung der Befehle mache ich per HTTP GET befehl, aber man kann auch Programme darüberstarten und ne menge mehr, das einzige blöde ist das es in Java geschrieben ist, und etwas Ressourcen hungrig aber hält sich noch in grenzen.
Nunja, wie ich bereits sagte: Lösungen dafür gibt es so viele wie Sandkörner im Meer. Habridge benötigt mindestens einen Raspi. Für meine Lösung brauchts halt maximal einen ESP01 und ein kleines Funkmodul.
Ich habe mich jetzt eine ganze Weile mit Alexa und Heimautomatisierung beschäftigt. Was mit aktuell stört ist das man einen eigenen Skill schreiben muss und alles recht umständlich ist, weil der Homaeautomationskill nur grundbegriffe wie ein, aus, auf, zu unterstützt. Kennt einer von euch einen einfach möglichkeit auch kompliziertere Geräte anzusprechen. Beispiel: Ich habe meiner Jura Kaffeemaschine einen Nodemcu verpasst und eine kleine Software dazu geschrieben. Leider muss man dafür umständlicher weise einen Skill schreiben. Gibts da bequemere varianten?
Oliver S. schrieb: > 433MHz-Steckdosen sind ausserdem nicht irgendwie verschlüsselt oder > sonstwie gesichert. > Wieso gibt es eigentlich noch nicht so ein Spaßgerät was ständig alle > Codes rauf- und runterzählt und damit Steckdosen in der Nachbarschaft > klappern lässt? Gibt es doch, nennt sich fhem! Ich musste bei mir autocreate ausgeschalten nachdem sich bei mir 30! verschiedenen Steckdosen angemeldet haben. Ich habe dann an der Arbeit eine Demonstration mit fhem und einem miniCUL-433 gemacht. Jetzt will keiner meiner Kollegen mehr solche Steckdosen haben. Ich denke mal für den Einsatz als Ein/Aus der Weihnachtsbaumbeleuchtung sind die ganz in Ordnung. Wer damit aber die Kaffeemaschine schaltet, sollte sich nicht wundern, wenn Morgens um 3 die Küche brennt. Es reicht ein einziger Schaltbefehl in der Nähe (300m) eines miniCUL und fhem hat die Steckdose mittels autocreate im room IT eingerichtet. Das Sicherheitsproblem ist nicht fhem, es ist die vorgespielte Sicherheit von 10 DIP-Schaltern.
qwertz schrieb: > Ich habe meiner Jura Kaffeemaschine einen Nodemcu verpasst und eine > kleine Software dazu geschrieben. Leider muss man dafür umständlicher > weise einen Skill schreiben. Gibts da bequemere varianten? fauxmo! https://github.com/n8henrie/fauxmo Da umgehst du den eigenen Skill und gaukelst alexa ein Belkin WeMo Device vor. Der Vortel ist ein eigener Server und damit keine chinesischen Zaungäste in der Cloud. Den Server musst du aber trotzdem irgendwo aufsetzen. Ein Raspy reicht dicke.
> Beispiel: > Ich habe meiner Jura Kaffeemaschine einen Nodemcu verpasst und eine > kleine Software dazu geschrieben. Leider muss man dafür umständlicher > weise einen Skill schreiben. Gibts da bequemere varianten? Mein Projekt ist eine Weiterentwicklung von Fauxmo. Es verwendet eine eigene Codebase. Es wird auch bei mir kein Skill benötigt. Daüber hinaus braucht es keine umständliche konfiguration über den Quellcode. Einfach binary aufs esp8266-board brennen und fertig. Konfiguriert wird über Webinterface. https://github.com/Monarch73/RFBridge
Hi. 433 MHz Transceiver habe ich mir mal bestellt aus CN. Habt ihr mal Links/Typen für günstige, geeignete Funksteckdosen für den Innenbereich? Wollte das Projekt mal ausprobieren... Peter
:
Bearbeitet durch User
Alle mit DIP-Switches funktioniert am leichtesten. Mit Drehwahlschalter müssen vorher eingelesen werden und selbst-lernende funktionieren leider garnicht. Mein persönlicher Favorit sind die von Brennenstuhl z.B. https://www.amazon.de/dp/B001AX8QUM/ PS: Es scheint probleme mit Echo Plus und Echos der zweiten Generation zu geben, weil sie keine Wemo-Smartsteckdosen mehr zu unterstützen scheinen.
Mist. Aktuell kann man doch nur echo v2 kaufen... Peter
Mit dem 2nd gen Echo Dot sollte es noch gehen. Aber ohne Gewähr....
Ich sehe gerade, es gibt die 1st gen Echos noch: https://www.amazon.de/dp/B01GAGVWYU/ Damit gehts definitiv.
Hi. Habe es heute mal trocken mit einem esp-01 probiert (ohne 433MHz
sendmodul dran). EasyAlexa Webpage + Eingebe ssid + passwd + save =ok.
Aber: Verbindet sich nicht mit dem Router (WPA2)..?
Seriell 115200 kommt:
rld��|�l�|�$�c|����{�c�c��o'�lno���bx��l;l{lp�n��d��co�|l��c��'o�d��$`�n
o$`'{���oc�ls��'c�l�$`�o�75
Initialized 4040 bytes of EEPRom memory!
No ssid defined
AP IP address: 192.168.4.1
??
Ich habe SAVE gedrückt und es kam auch die Rückmeldung 'Conf, ok
..please reset..
(Das Modul ist ein blaues mit 1MB Flash)
EDIT: Auch mit einem schwarzen Modul neueren Datums getestet-identisches
Resultat.. scheint die SSID+PASSWD nicht zu speichern und kommt danach
wieder als Hotspot hoch..
Peter
:
Bearbeitet durch User
Also ich würde vermuten beim formatieren vom SPIFFS läuft was schief. Bitte lade dir mal von der espressif-Homepage das Download-Tool runter. Da gibt es einen Button zum "Erase" des flash-speichers. Auf diesem Wege kannst du auch gleich mal sicherstellen, das du auch die letzte Version von RFBridge geflashed hast: Ganz wichtig: In den 20-30 sekunden nach dem ersten Start wird der Flashspeicher (SPIFFS) formatiert. In dieser Zeit sieht es so aus, also ob der esp8266 abgestürzt ist, weil er auf nichts reagiert. Bitte in dieser Zeit den esp8266 nicht unterbrechen..... http://espressif.com/en/support/download https://github.com/Monarch73/RFBridge/files/1503470/RFBridge.zip (letzte Version Stand 27.12.2017)
Hmm.. wenn die Wepage kommt.. Conf. saved bitte reset.. muss man davon ausgehen, das man das dann auch machen darf (Reset) und nicht noch 20-30s warten.. Nun habe das auch mal auf einem wemos Board geflasht. Hier ging es bis zu alles gut: Der Gerätename sollte nun nebst Ein/Aus-Button im Browser erscheinen. Protokoll auf seriell: ---------------------- V1.0 192.168.0.26 Ready NOT_FOUND: GET http://192.168.0.26/favicon.ico _HEADER[Host]: 192.168.0.26 _HEADER[User-Agent]: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0 _HEADER[Accept]: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 _HEADER[Accept-Language]: de,en-US;q=0.7,en;q=0.3 _HEADER[Accept-Encoding]: gzip, deflate _HEADER[Connection]: keep-alive Starting Server on Port 81 0 0 Setting state 1 0 0 Setting state 0 UDP Packet Type: Multicast, From: 192.168.0.21:50000 UDP Packet Type: Multicast, From: 192.168.0.21:50000 UDP Packet Type: Multicast, From: 192.168.0.10:58765 UDP Packet Type: Multicast, From: 192.168.0.10:37103 ---------------------- Holt sich also ip adresse vom router (komisch wird das Gerät nicht über Lan Verb. gelistet?). 0.10 scheint das Android Handy mit der Alexa App zu sein (beim Gerät suchen?) 0.21 ist wohl der Amazon Echo bei Gerät suchen? Aber: Alexa (echo) findet kein Gerät (Ist Version 2!). Die Firmware ist die Release Version von heute morgen.. Peter
So. Nochmals die Firmware aus dem obigem Link geladen und generic auf ein esp-01 geflasht. Nun ging alles wie beschrieben - bis: Alexa findet das Gerät nicht..? Das Android App scheint aber zu versuchen Verbindung auf zu nehmen: ... UDP Packet Type: Multicast, From: 192.168.0.10:46563 UDP Packet Type: Multicast, From: 192.168.0.10:46563 ... In der App steht noch was von Skills im Shop auswählen..?? Muss ich dazu noch etwas machen..? Peter
:
Bearbeitet durch User
Peter S. schrieb: > Muss ich dazu noch etwas machen..? Wer billig kauft, kauft mehrfach! (Nur so,als Anregung :-) ) (Ist böse - ich weiss - aber leider ab und an wahr.)
Noch habe ich quasi nichts gekauft.. die esp-01 + wemos hatte ich hier bereits liegen. Nur so mal als Antwort. Und die 433MHz Transceiver kosten mich 2x1€. Peter
Peter S. schrieb: > Noch habe ich quasi nichts gekauft.. die esp-01 + wemos hatte ich hier > bereits liegen. Nur so mal als Antwort. > Und die 433MHz Transceiver kosten mich 2x1€. Und jetzt - erwartest Du ein Rezept?
Dieter F. schrieb: > Und jetzt - erwartest Du ein Rezept? Nein, das war vermutlich die Antwort auf "wer billig kauft, kauft zwei mal". Bei 2 Euro kann man es wohl auf einen Versuch ankommen lassen, schätze ich.
Peter S. schrieb: > Aber: Alexa (echo) findet kein Gerät (Ist Version 2!). Leider, leider... Echo Plus und der Echo der 2 Generation (wichtig: Echo DOT 2nd Gen ist nicht betroffen!) unterstützen wohl die Belkin Wemo schalter nicht mehr. Daher gibt es hier wohl auch Probleme mit den Sonoff Geräten. Ich arbeite gerade an einer Version, die statt der Wemo-Switches eine Alex-Kompatible Phillips Hue Bridge emuliert. Bis ich damit soweit bin, wird es wohl aber noch was dauern.
Moin, also bei mir geht die Kombination Echo Dot V2, D1 mini und Brennenstuhl RCS 1000N Comfort, sonoff geht auch. Gruss Peter
Peter Z. schrieb: > also bei mir geht die Kombination Echo Dot V2, D1 mini und > Brennenstuhl RCS 1000N Comfort, sonoff geht auch. Wie ich bereits schrieb: > *wichtig: Echo DOT 2nd Gen ist nicht betroffen!* Aber wie gesagt, wenn ich mit der Phillips Hue Emulation durch bin, sollte es auch auf dem großen Echo Plus und Echo 2nd Gen keine Probleme mehr geben. Und ein ansehnlicheres Webinterface gibts dann auch.
:
Bearbeitet durch User
Geht das auch ohne Google? Und auch ohne alexa?
Natürlich. Das Ganze lässt auch nur mit dem Browser steuern.
Hi Niels. Wunderbar! Gut Ding will Weile haben. Danke für deine Entwicklung. Trotzdem schade, das Amazon hier anscheinend nach gutdünken Sachen entfernt.. Was machen denn dann Besitzer entsprechender Geräte..? Peter
Peter S. schrieb: > entfernt.. Was machen denn dann Besitzer entsprechender Geräte..? Vermutlich die heillos überteuerte Phillips-Hue-*&%$&/"§$ kaufen... "billig" ist nicht immer günstig, aber teuer ist auch nicht immer gut. Das neueste IPhone ist wohl der beste Beweis dafür.
:
Bearbeitet durch User
Das ist ja generell das Problem solcher Big Player. Nicht nur Inhalte können verschwinden sondern auch Hardware die plötzlich nicht mehr läuft. Das schreiben sie auch mittlerweile ganz unverblümt auf die Packung. Man stelle sich vor ein Autohersteller würde per Update eine Achse demontieren. Der Aufschrei wäre groß, hier stört sich keiner daran.
:
Bearbeitet durch User
Hallo Peter, es wäre schön, wenn du mal etwas für mich ausprobieren könntest. Siehe https://github.com/Monarch73/RFBridge/issues/1#issuecomment-354430079
Hi. Habe leider nur Linux Mint hier.. Kein Windows mehr. Peter
Nur mal so zum Verständnis. Das Projekt funktioniert so das per UPnP die Geräte als Gerät eines Herstellers gefunden werden. Alexa aktiviert darauf den Skill womit sich die Geräte steuern lassen als wären sie von der Firma. Das Prinzip der Geräte Steuerung habe ich bis her so verstanden das Geräte per AwS angebunden werden und Amazon dafür Geld verlangt. Das AWS läßt sich über den Skill verknüpfen. Irrend jemand muß zahlen für die Ressourcen? Jeder Skill benötigt auch einen Aws Account über den die Rechenleistung abgerechnet wird. Jeder der extern was für die Büchse anbieten will wird also zur Kasse gebeten? Es gibt keine Ressource die Amazon per Kundenkonto zur Verfügung stellt? Es wird immer im AwS des Anbieters verarbeitet?
Marco H. schrieb: > Das Projekt funktioniert so das per UPnP die Geräte als Gerät eines > Herstellers gefunden werden. Alexa aktiviert darauf den Skill womit sich > die Geräte steuern lassen als wären sie von der Firma. Nein, ein Skill wird nicht benötigt. Die Echos haben die Funktion für Wemo-Switches und die Funktion zum Ansteuern von Phillips-Hue-Bridges fest eingebaut. Bei neueren Echos ist sogar eine Phillips-Hue-Bridge eingebaut. > Das Prinzip der Geräte Steuerung habe ich bis her so verstanden das > Geräte per AwS angebunden werden und Amazon dafür Geld verlangt. Das ist etwas ab von diesem Projekt, aber ja, es gibt Lösungen, die ein AWS-Konto benötigen und wo man sogenannte Nodejs-Lambda funktionen auf diesem AWS-Konto einrichten muss. Hinzu kommt ein Developer-Account bei Amazon, um die Sprachsteuerung der Lambda-Funktionen einzurichten. Zu guter letzt wird bei solchen Lösungen meist noch ein Portforwarding ins eigene Netz benötigt, damit diese AWS-Lambdas die Geräte oder eine Bridge steuern. > Jeder Skill benötigt auch einen Aws Account über den die Rechenleistung > abgerechnet wird. Bei einem Entwickler-konto muss man zwar eine Konto-Verbindung angeben, aber die Nutzung der Lambdas und das Einrichten der Sprachsteuerung der Lambdas ist für privatpersonen weitestgehend kostenlos. Es fallen auch keine monatlichen Gebühren an. Aber wie gesagt, all das hat nichts mit diesem Projekt zu tun. Das erkennen von UPNP-Geräten (Belkin-wemo und Phillips Hue) ist in den Echos fest eingebaut und braucht keinen Skill, kein Entwicklerkonto und keine Lambdas. Es funktioniert einfach so.
Marco H. schrieb: > Ok gesteuert werden diese dann auch per UPNP. Um es ganz ohne mögliche Missverständnisse auszudrücken: Belkin Wemo und Phillips Hue werden im lokalen Netz von Alexa via einer per UPNP angepriesener Web-API (XML, Restful Json) gesteuert.
Ist das irgendwo öffentlich, also was bei senden muß ?
Nun ich habe mich mit dem Thema etwas befaßt und das Fazit der Sache ist -> man sollte die Finger davon lassen von dem Alexa Kram. Dein Projekt ist doch von einen Skill abhängig. Dieser Smart Home Skill wird per Standard geladen wenn sich beim Discovery unterstützte Geräte zeigen. Um das Problem auf den Punkt zu bringen, für alles was man mit der Büchse machst ist man zu 100% abhängig von Amazon und dessen Geschäftsgebaren. Entwickler die sich die Mühe und Zeit nehmen hierfür etwas zu programmieren werden gnadenlos ausgenutzt. Das Prinzip ist in der Sache genial das Amazon jedenfalls immer der Gewinner ist und das Geld kassiert. Gespielt wird nach eigenen Regel, EU oder deutsches Recht für Amazon ein Fremdwort. Diese Regeln ändern sich täglich so wie man es eben braucht.
Marco H. schrieb: > Dein Projekt ist doch von einen Skill abhängig. Wie ich bereits sagte, es wird für mein Projekt kein Skill benötigt. Alle funktionen, die benötigt werden, sind in Alexa bereits fest eingebaut. > Um das Problem auf den Punkt zu bringen, für alles was man mit der > Büchse machst ist man zu 100% abhängig von Amazon und dessen > Geschäftsgebaren. Sei mir bitte nicht böse, aber auf diesen "Ich bin ein kleiner Rebell"-Niveau diskutiere ich nicht. Dieses Alter habe ich lange hinter mir und auch sehr froh drum.
Das funktioniert mit dem Standard Home Still und auch nur wenn sich Geräte melden die vom diesem unterstützt werden, bzw. es muss sich eine Regel finden zu dem Gerät. Diese Geräte lassen sich dann auch über die App im Reiter "Smart Home" steuern. Vielleicht hat sich an der Regel etwas geändert um Trittbrettfahrer auszubremsen? Der herkömmliche Weg ist einen eigenen Still mit der Home Skill API zu basteln. Hierzu benötigt man die kostenpflichtigen AWS Funktionen in der Regel nicht. Wenn man das per UPNP löst und sich die Ausführung des Lambada Codes in grenzen hält. Für Open Source ist die Büchse wenig interessant, da alles in irgend etwas unteilbares und Geld kostendes verläuft. Geräte sind ans AWS mit TLS und eigenen Zertifikat inkl. Regel gebunden. Jedes Gerät ist somit eindeutig erkennbar und dessen Daten laufen durch Amazons Hände. Selbst kommerziell habe ich so meinen Zweifel ob Hersteller von IoT Geräten überhaupt in der Lage sind Datenschutz Bestimmungen die hier gelten einzuhalten. Zumal sie immer Gefahr laufen ihrer Geschäftsgrundlage beraubt zu werden.
Hallo, Niels H. schrieb: > Echo Plus und der Echo der 2 Generation (wichtig: Echo DOT 2nd Gen ist > nicht betroffen!) unterstützen wohl die Belkin Wemo schalter nicht mehr. > Daher gibt es hier wohl auch Probleme mit den Sonoff Geräten. wurde hier wohl bereits korrigiert: m-seach index issue fixed https://github.com/kakopappa/arduino-esp8266-alexa-multiple-wemo-switch Gruß aus Berlin Michael
Michael U. schrieb: > wurde hier wohl bereits korrigiert: m-seach index issue fixed > https://github.com/kakopappa/arduino-esp8266-alexa-multiple-wemo-switch Entsprechendes Ticket wurde noch nicht geschlossen: https://github.com/kakopappa/arduino-esp8266-alexa-multiple-wemo-switch/issues/23 Ich habe begonnen in meinem Projekt die HueBridge zu emulieren. Diese API ist von Phillips dokumentiert und scheint mir auch systemisch sauberer zu sein. Allerdings ist die Änderung etwas zeitaufwendiger.
Marco H. schrieb: > Vielleicht hat sich an der Regel etwas geändert um Trittbrettfahrer > auszubremsen? Das mag sein, aber das glaube ich nicht, da Amazon selbst keine Wemo-switches herstellt. Die hätten also nichts davon. > Für Open Source ist die Büchse wenig interessant, da alles in irgend > etwas unteilbares und Geld kostendes verläuft. Das entspricht schon nicht dem Status-Quo. Mein Projekt sowie 100 weitere Projekte, die sich irgendwie mit dem Echo beschäftigen, sind bereits OpenSource. Phillips Hue hat seine API-Schnittstelle dokumentiert. Diese Doku ist öffentlich zugänglich. > Zumal sie immer Gefahr laufen ihrer > Geschäftsgrundlage beraubt zu werden. Für soetwas gibt es Kooperationsverträge. Ich schätze, davon hat Amazon bereits eine Menge geschlossen. Wer sich von Amazon abhängig gemacht hat, ohne einen solchen Vertrag geschlossen zu haben, ist quasi selbst schuld.
Niels H. schrieb: > Ich habe begonnen in meinem Projekt die HueBridge zu emulieren. Hi. Wenn ich was auf esp8266/esp-01 testen kann, meld dich einfach dann.. Gruß Peter
Also bisher habe ich es so verstanden. Das der Standard HomeSkill das Discovery auslöst und dann das entsprechende Lambda Script startet. Bei dir werden die Geräte erkannt durch den HomeSkill aber es findet kein Script was diese Event verarbeitet. Die Antwort auf das Discovery hat Fehler oder Abweichungen so das der Standard HomeSkill nicht das passende Script startet und auch keins findet was diese Unterstützen würde. Deswegen läuft das ganze ins leere. Was man machen könnte sich die Original Steckdosen und dessen Datenaustausch nochmal anschauen. Ich denke das dies weniger mit den Dosen und dessen Hersteller zusammenhängt. Sondern mit dem Standard HomeSkill, des wegen will ich ja auch verstehen was da abläuft ;). Ich bin mittlerweile so weit das mein MQTT Projekt mit dem AWS und dessen Schatten funktioniert. Die Anbindung über den AVS und dem IOT Gateway ist aufgrund nicht sehr guter Kenntnisse von nodejs und der verwendeten API etwas zeitintensiv. Zumal man vom AWS formal von dessen Möglichkeiten erschlagen wird. Das ist in 10min nicht machbar.
Marco H. schrieb: > Das ist in 10min nicht machbar. Eben drum hat man mit Fauxmo einen Wemo-Device Emulator gebaut, damit man diesen Konfigurationsmarathon nicht durch exerzieren muss. Wenn du es dennoch gerne mal versuchen möchtest, einen eigenen SmartHome Skill im AWS anzulegen, würde ich dir empfehlen, FHEM mit Alexa zu verbinden. FHEM benötigt allerdings einen Server. Ich habe bereits selber nach dieser Anleitung erfolgreich einen eigenen Homeskill im AWS anlegen können. Als Server habe ich einen Raspberry Pi verwendet. https://wiki.fhem.de/wiki/Alexa-Fhem
Hmm Danke, so langsam verstehe ich das immer mehr ;)...
https://wiki.fhem.de/wiki/Datei:2gpXyLN.jpg nur mal für den unbeteiligten was da alles zusammen wirkt.. Also meine Tätigkeiten sind momentan nicht von Erfolg, das Problem mit den zahllosen Anleitung ist eben das sie von einer abstammen und wenig erklärt wird weshalb dies so konfiguriert werden muß.
Ich gebe das erst mal auf. Der Kram ist viel zu kompliziert aufgebaut. Zumindest wenn man sein eigenes Projekt dort mit einbinden möchte. Den komischen Button bekommt man in 5min zur Funktion. Komisch mit seinen eigenen Kram geht es dann doch einfacher. Die zahlreichen Beispiele sind zumindest 1:1 nicht mehr anwendbar, da sie die Playload 2 verwenden. Ohne extrem viel Zeit in die Einarbeitung zu verlieren kostet das nur nerven und dann ändert Amazon wieder sein Konzept oder sie wollen Geld. Wie schon vermutet zu Gefährlich und unbeständig am sich damit herumzuplagen. Man sollt seine Zeit lieber in Offene und beständige Dinge stecken. Jetzt versteht man auch warum die meisten Skills nur Müll sind. Wie schauts mit google aus ?
:
Bearbeitet durch User
Marco H. schrieb: > Ich gebe das erst mal auf. Der Kram ist viel zu kompliziert aufgebaut. Verständlich. Ich habe auch mehrere Stunde gebraucht um das per selbst programmierten Homeskill etwas ans laufen zu bekommen. Aber warum ignorierst du so beharrlich fauxmo? Damit muss man den ganze komplizierten quatsch nicht machen.
:
Bearbeitet durch User
Nun da ich mein MQTT Projekt damit verbinden wollte. Aber schnell feststellen musste dass dieses mit AWS schwer teilbar ist. Auch wenn ich gestern aus Frust aufgegeben habe reizt es mich schon meine Kenntnisse dort zu vertiefen. Ich bekomme das schon hin, die Frage ist bloß wie lange es dauert ☺️.
So mich etwas mit node.js befaßt und begriffen wie das funktioniert. Anhand der Test Funktionen konnte ich herausfinden wie diese Daten übergeben werden und ich konnte sie filtern. Auf die Schatten von things zuzugreifen ist auch ganz einfach. Das geht per HTTP über den Endpoint des things. Das Problem ist eben das so umfangreich ist das man erst mal erschlagen wird und nicht weiß wo man ansetzen muß. Um auf dein Projekt zurückzukommen. Es gibt 3 Möglichkeiten wie ein Skill interagieren kann. Die einfachste ist per HTTP Request, das setzt allerdings voraus das der Webserver von außen erreichbar ist. Mit dem AWS, nicht wirklich öffentlich teilbar da sehr speziell konfiguriert. Das Problem mit dem Standard SmartHomeSkill besteht drin das dieses ein lambda Script anschiebt das für das Gerät geeignet zu sein scheint. Irrend wer wird für das Script schon zahlen bzw. sehen wieviele falsche Anfragen dort hineinkommen. Die sehen also wenn Trittbrettfahrer mit aufspringen. Man könnte ein eigenen Skill bauen aber das Script muß im AWS gehostet werden. Überschreitet dies ein gewisses Kontingent fallen kosten an. Ich glaube das will keiner, wenn irrend ein Depp per DOS die kosten in die Höhe treibt. Als Fazit bleiben bloß die HTTP Request übrig. Die im CC2 gezeigten Steckdosen funktionieren offenbar so. Das blöde war allerdings das sie zum Hersteller Broker unverschlüsselt arbeiteten. Die Anfragen wurden per HTTP Request über den Skill versendet und wer die ID kannte konnte auch andere Dosen im Broker steuern.
:
Bearbeitet durch User
Marco H. schrieb: > Die einfachste ist per HTTP Request, das setzt allerdings voraus das der > Webserver von außen erreichbar ist. Und da ist der Punkt, wo das Pferd vor die Apotheke kotzt. Ich, als halbwegs professnioneller Softwareentwicker, will niemanden eine Software zumunten, für die man noch großartig das Netzwerk umkonfigurieren muss; geschweige denn ein Portforwarding einrichten muss. Ich will auch nicht, das der Endnutzer meine Quellcodes selber kompilieren muss. Aus diesem Grund liefere ich nur Binaries aus, die du als Nutzer nur flashen musst. > Mit dem AWS, nicht wirklich öffentlich teilbar da sehr speziell > konfiguriert. Das bekommt man mit sicherheit auch teilbar hin. Aber wie ich bereits sagte, das möchte ich den Nutzern meiner Software nicht zumuten, ein Loch in ihr Netzwerk zu konfigurieren. __Ein IOT-Device, daß aus dem Internet direkt erreichbar ist, ist Sicherheitstechnisch ein absolutes no-go__. Wie gesagt, in zukünfigen Versionen meiner RFBridge orientiere ich mich lieber an die gut dokumentierte Phillips Hue-API.
Ich habe eine Version der RFBridge fertig, die eine Phillips Hue Bridge emuliert. Mit meinem Echo der ersten Generation funktioniert sie schon ganz gut. Es wäre ganz Nett, wenn jemand das mal mit einem großen Echo der 2. Generation ausprobieren könnte. https://github.com/Monarch73/RFBridge2/files/1628242/RFBridge2.zip Danke!
Habe die V2 auf einem esp-01 geflasht.
Ging alles wie beschrieben - bis auf: alexa erkennt keine neuen Geräte.
Es kam die Nachricht.. wenn sie Philips Hue.. nutzen, betätigen sie eine
Taste..
--- Log ---
headerValue: 22
args:
Plain: {"devicetype": "Echo"}
Request: /api
Arguments:
New client
method: POST url: /api search:
headerName: Content-Type
headerValue: application/json
headerName: User-Agent
headerValue: Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORD Build/LVY48F)
headerName: Host
headerValue: 192.168.0.19
headerName: Connection
headerValue: Keep-Alive
headerName: Accept-Encoding
headerValue: gzip
headerName: Content-Length
headerValue: 22
args:
Plain: {"devicetype": "Echo"}
Request: /api
Arguments:
---
Peter
Peter S. schrieb: > Habe die V2 auf einem esp-01 geflasht. > Ging alles wie beschrieben - bis auf: alexa erkennt keine neuen Geräte. Ich habe am Wochenende nochmal etwas Arbeit in das Projekt investiert und ein paar Fehler behoben. Von mehreren Stellen wurde mir berichtet, das die Software nun funktioniert. Auch mit Echos der zweiten Generation. Zusätzlich unterstützt werden in diesem Softwarestand auch eine Infrarot-Steuerung. Auch wenn ich in diesem Projekt beschrieben habe, wie man das Projekt selbst compiliert, empfehle ich dies nicht zu tun. Ich kann euch bei Problemen mit selbst-kompilierte Softwarestände nicht unterstützen, weil ich nicht weiss, welche Versionen ihr von welchen Libraries und ESP8266-arduino SDK eingebunden habt. Besser wäre es, ein aktuelles release-binary zu flashen. https://github.com/Monarch73/RFBridge2
Hi. Ich finde da kein rfbridge2.bin zum flashen..? Peter
Peter S. schrieb: > Hi. Ich finde da kein rfbridge2.bin zum flashen..? Ist im Zip-Archive im Menue "releases" https://github.com/Monarch73/RFBridge2/releases
Hi. Neueste Version aus esp-01 (generic) geflashed. EasyAlexa conf. ok Aber http://192-168.0.19 zeigt nur einen schwarzen Bildschirm.. Schwarzer Bildschirm = keine Eingabefelder, kein Text.. wirklich alles nur schwarz-grau. Hatte dann auch mal Cache des Browsers geleert.. gleiches Bild. (ESP-01 hat 1MB Größe). Keine Ahnung, warum das bei anderen geht und bei mir nicht? Log: Request: /polyfills.5b59249e2a37b3779465.bundle.js Arguments: New client method: GET url: /main.e8c6b586049960613364.bundle.js search: headerName: Host headerValue: 192.168.0.19 headerName: User-Agent headerValue: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 headerName: Accept headerValue: */* headerName: Accept-Language headerValue: de,en-US;q=0.7,en;q=0.3 headerName: Accept-Encoding headerValue: gzip, deflate headerName: Referer headerValue: http://192.168.0.19/ headerName: Connection headerValue: keep-alive args: Request: /main.e8c6b586049960613364.bundle.js Arguments: request handler not found Peter
:
Bearbeitet durch User
Nach hard reset des esp-01 bekam ich dann den bekannten Bildschirm unter
192.168.0.19 zur Konf. eines Gerätes. (Habe als Name: lampe genommen).
Aber alexa findet immer noch keine Geräte:
Log:
Reply by whole config
New client
method: POST url: /api search:
headerName: Content-Type
headerValue: application/json
headerName: User-Agent
headerValue: Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORD Build/LVY48F)
headerName: Host
headerValue: 192.168.0.19
headerName: Connection
headerValue: Keep-Alive
headerName: Accept-Encoding
headerValue: gzip
headerName: Content-Length
headerValue: 22
args:
Plain: {"devicetype": "Echo"}
Request: /api
Arguments:
Reply by whole config
??
Ich habe wie bereits gesagt, noch nichts am esp-01 angeschlossen!
Peter
Peter S. schrieb: > Schwarzer Bildschirm = keine Eingabefelder, kein Text.. wirklich alles > nur schwarz-grau. Sorry, mein Fehler. Ich vergas zu erwähnen, das RFBridge2 ein aggressives Caching nutzt um die Seite schneller laden zu lassen. Wenn die ausgelieferten Seiten sich ändern, passt der Cache natürlich nicht mehr zur Logik im Code und dann passiert sowas. Ich hätte erwähnen sollen, das der Cache vom Webbrowser zu leeren ist. Anyways, ich hab etwas gefunden, was die Probleme bei dir beheben könnte. Aus deinem Logs ist ersichtlich, das ein POST-Request /api mit "WholeConfig" beantwortet wurde. Das ist nicht richtig. Hier hätte eigentlich "Reply by success" stehen müssen. Bitte versuche es einmal hiermit: https://www.dropbox.com/s/72q3771zis8zr5p/RFBridge2.ino.bin.zip?dl=0
:
Bearbeitet durch User
Hi.
Version aus dropbox geflasht (vorher erase_flash).
Alles ok - bis auf leider immer noch das Alexa kein neues Gerät findet.
Log:
New client
method: POST url: /api search:
headerName: Content-Type
headerValue: application/json
headerName: User-Agent
headerValue: Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORD Build/LVY48F)
headerName: Host
headerValue: 192.168.0.19
headerName: Connection
headerValue: Keep-Alive
headerName: Accept-Encoding
headerValue: gzip
headerName: Content-Length
headerValue: 22
args:
Plain: {"devicetype": "Echo"}
Request: /api
Arguments:
Reply by success POST
Peter
Danke für die Info. Ich glaub, ich weiß jetzt wie ich das Problem in den Griff bekomme
Schau in die Alexa App ob das Gerät dort schon vorhanden ist! Gerät entfernen und erneut suchen. Ich bin soweit das beide Skill Arten funktionieren. Ich muss die Infos erstmal sammeln und dann schreibe ich ewt. etwas dazu.
Ist bisher noch kein Gerät gefunden in der App. Soll ich erneut aus obiger Dropbox laden? Ohne Änderung wird sicher wieder das gleiche Ergebnis heraus kommen wie das letzte Mal.. Peter
Hmm hätte ja sein können, dann wird es auch nicht mehr gefunden wenn die vorhandene endpoint_ID zurückgeliefert wird. Was echt zum kotzen ist das sie die API ändern und dies nicht wirklich fundiert dokumentieren. Das ist doch das erste was man macht, wer soll den Kram denn benutzen wenn keiner weiß wie. Im Zusammenhang mit meinen SmarteHomeSkill weis ich momentan nicht welche Version ich als Response zurückliefen muss. Da an vielen stellen der Doku unterschiedliche aussagen hierzu auftauchen. Genial ...
So ich habe die Sache jetzt im Griff :). Noch ein Hinweis du mußt unbedingt den Status Report mit einbauen. Sobald man die Alexa App aufmacht versucht der Skill per polling den aktuellen Status abzufragen. Wenn dies fehlschlägt steht in der App "Serververbindung fehlgeschlagen", wenn das Gerät auf eine Directive nicht Antwortet "Gerät reagiert nicht". Per Status Report werde ich dann per GET den Schatten nach seinen Status abfragen. Da man im IOT Teil keine Themen Abonnieren kann. Ich werde mich mit der API weiter beschäftigen ;). Wie gesagt blöd ist wenn Beispiele nicht funktionieren da die API geändert wurde. Wenn im allgemeinen hierzu Interesse besteht kann man auch einen neuen Thread aufmachen.
:
Bearbeitet durch User
Im übrigen habe ich einen Lücke gefunden wie man die Begrenzung vom IOT von 12 Monaten aushebeln kann. Man bindet die IOT einfach bei google ein :) da sind 250MB pro Monat Trafic frei. Abgerechnet wird in 1024 Byte Einheiten und Protokoll Trafic wird nicht mitgezählt. Lambda bleibt bei bis zu 1000000 Anforderungen kostenlos, das Script leitet per HTTPs die Anfragen zum google IOT weiter :). Ob und wie lange sich das google oder Amazon gefallen lassen steht in den Sternen. Noch gibt es keine öffentlichen HTTPs Brücken.
Hallo, bin Neueinsteiger und versuche nach der Beschreibung meinen ESP8266 einzurichten. Leider sehe ich keinen Hotspot Kann mir jemand helfen? MfG
Hi! Habe heute nachmittag meine Bridge aufgesetzt und muss sagen, ich bin begeistert! 1000 Dank an Niels für das tolle und schnell umsetzbare Projekt!!!! @Olaf: Du musst -falls noch nicht geschehen - zunächst die Firmware auf den ESP brennen. Bei meinem Modell habe ich danach die Programmierplatine von der ESP Platine getrennt und den ESP neu gestartet. Nach kurzem warten wurde mir dann auf meinem Notebook unter Wlans der EasyAlexa Accesspoint angezeigt. Damit dann verbunden und die 192.168.4.1 IP in den Browser eingetragen. Dann die Grundeinrichtung durchgeführt. Danach nochmals neustarten und die Switche einrichten. Bei mir gabs da nochmal ne Herausforderung, da die Schalter von der Firma Pollin bei der Codierung invertiert sind. Hat ne Weile gedauert, bis ich das herausgefunden hatte. Ab da gings dann wunderbar! Eine Frage hätte ich noch: ich hab auch noch einen Google Home rumfliegen. Dort funktioniert die Einrichtung von Hue wohl etwas anders, denn nach Auswahl des Moduls und der Anmeldung bei Philips fordert der Einrichtungsdialog mich auf, bei der Hue Bridge eine Taste zur Erkennung zu drücken. Die hab ich natürlich nicht. Deshalb ist dort eine Einrichtung der Bridge - glaub ich - nicht möglich. Hat jemand eine Idee, ob die Bridge auch an Google Home genutzt werden könnte? Viele Grüße, Stephan
Geht das bei dir mit Alexa 2te/neueste Generation? Peter
Ich habe einen Echo Dot. Kurz vor Weihnachten in der Aktion gekauft. Müsste zweite Generation sein. Viele Grüße, Stephan
Hmm. Ich habe ein Alexa auch aus Weihnachtsaktion. Bei mir findet Alexa aber partout kein Gerät?? Muss ich dazu auf der Alexa App noch irgendwas machen? Bisher mache ich nach dem Setup wie beschrieben nur "Alexa, erkenne meine Geräte" - dann sieht man auch im Logging über seriell, das da 3 Anfragen kommen, die auch beantwortet werden (siehe weiter oben im Thread..) - aber immer mit dem Resultat - "keine neuen Geräte gefunden" :-( Peter
Peter, kannst du mal ein Link zur der Amazon-Seite posten zu dem Gerät, das du gekauft hast? Ich möchte einfach nur auf Nummer sicher gehen. Die RFBridge2 funktioniert derzeit auch nicht mit der Phillips-Hue-Android App. Ich schätze, wenn ich dieses Rätsel gelöst habe, dürften sich auch deine Probleme erledigt habe. Leider ist von Berufswegen meine Freizeit sehr knapp bemessen....
Ich hab die Suche der Geräte für meinen Dot mit der Alexa Android App gemacht. Da ist das Ganze problemlos durchgelaufen, die Geräte wurden gefunden. Und, gerade ausprobiert, ich kann sie auch über die Alexa App ein- und ausschalten. Wenn ich das richtig verstanden habe, gibt es anscheinend zwei verschiedene Möglichkeit, sich mit einer Hue Bridge zu verbinden: einmal über den "Meethue" Service und einmal im Hue-Bridge-Mode. Will sich vielleicht der neue "große" Echo nur noch per Bridge-Mode mit Hue verbinden, während die alten und der Dot auch im Meethue Mode funktionieren? Viele Grüße, Stephan
Hi. Hier der Link zu Amazon: https://www.amazon.de/dp/B06ZXQV6P8/ref=asc_df_B06ZXQV6P849720609/?tag=googshopde-21&creative=22398&creativeASIN=B06ZXQV6P8&linkCode=df0&hvadid=229559756060&hvpos=1o1&hvnetw=g&hvrand=15108507197652710922&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9044241&hvtargid=pla-377037846199 Peter
Weihnachtsaktion hin oder her. Stephan hat einen 2nd Gen Echo Dot. Du, Peter, hast einen 2nd Gen Echo. Das ist ein Unterschied. Ich bin nicht mehr weit entfernt von einer Lösung (hoffentlich)....nur Geduld..
Bin doch geduldig ;-) Gut Ding will Weile haben.. Dachte der Unterschied ist nur der eingebaute Lautsprecher..? Peter
Peter S. schrieb: > Dachte der Unterschied ist nur der eingebaute Lautsprecher..? Nein, offensichtlich unterscheiden die sich auch durch ne andere Firmware.
Du sitzt auf einen Ast der abgesägt wird. "But what happens in the third step when the consumer makes a device discovery request? Does it actually seek for devices emitting some signal within the home? Is it querying everything it can within the local WIFI area? The answer to both questions is no. Although there are a couple of exceptions to enable early support of popular products such as Philips Hue and Belkin WeMo, the process described next is what is supported today and moving forward." Die Aktuelle Methode ist das über den SmarteHomeSkill der User mit der Geräte Cloud verbunden wird. Deine Lösung ist obsolet und es ist nur eine Frage der Zeit bis dies nicht mehr funktioniert. Ich wollte diese Discovery Daten abgreifen.... Die Methode ist aber obsolet, die suche nach Geräten erfolgt immer mit dem verknüpften Account in der Hersteller Cloud.
:
Bearbeitet durch User
So wie es ausschaut ist diese schon seit 2016 obsolet und stammt aus der Version1, in den nachfolgenden Versionen V2 und aktuell V3 wird diese nicht mehr unterstützt. Somit ergibt sich ein hohes Risiko das so noch zu nutzen. Für die Hersteller ist dies kein Problem, allerdings ist davon auszugehen das sie aus ihrer Cloud Trittbrettfahrer raushalten.
Marco H. schrieb: > Für die Hersteller ist dies kein Problem, allerdings ist davon > auszugehen das sie aus ihrer Cloud Trittbrettfahrer raushalten. Du hast vermutlich recht. WeMo ist vermutlich tatsächlich schon aufgegeben worden. In den neueren Versionen der Echo-Modelle wird unter den unterstützen SmartHome-Produkten "Wemo" nicht mehr erwähnt. So z.B. bei der neuen Echo Show und Echo 2nd Gen. Phillips Hue hingegen wird weiterhin ausdrücklich unterstützt und ich kann mir auch nicht vorstellen, das bei dem breiten Markt Phillips Hue so schnell aufgegeben wird. Das ist einer der Hauptgründe, warum ich in meinem Projekt von der Wemo-Emulation zur Hue-Emulation gewechselt bin. Weiteres wird vermutlich die Zeit zeigen. Bis dahin bleibt meine Lösung eine extrem preisgünstige Alternative, die sehr leich Einzurichten und bedienbar ist. Selbst wenn Amazon die Unterstützung für Phillips Hue aufgibt, was ich mir wirklich nur schwer vorstellen kann, kann niemand behaupten, dadurch viel Geld verloren zu haben.
:
Bearbeitet durch User
Peter S. schrieb: > Bin doch geduldig ;-) Gut Ding will Weile haben.. Danke. Um einen kleinen Einblick in meine Arbeit daran wiederzugeben: das Ding kostet mich mitlerweile schlaflose Nächte. Meine Situation ist, das ich einen funktionierenden "Proof of Concept" in C#/.NET habe; ein port auf den ESP8266 aus mir unerfindlichen Gründen einfach nicht funktionieren will. Auf gut deutsch: Ich werd' irre...
Nun Philips stellt einfach einen Skill zu verfügung bzw. verweist auf den Echo plus der hat ja einen HUB drin. Es führt bei der Büchse kein weg an einer Cloud vorbei. Es gibt keine Möglichkeit das die Büchse mit irgend was direkt Verbindung aufnimmt. Im cc2tv wurde ja eine Videokamera vorgestellt. Die API hierzu lässt keinen direkten connects zu! Es geht nicht anderes als die Bilder bzw. den Stream aus der Cloud zu laden. Macht man dies im AWS fallen hohe kosten an. Wie gesagt, ich blicke da jetzt durch ;). Die Autorisierung und verknüpfen der Accounts mit Amazon hat auch seine Tücken. Geld hat keiner verloren, nur Zeit... Wenn ich mit Amazon durch bin werde ich mich mal mit google beschäftigen. Vielleicht ist das ja besser aufgebaut...
:
Bearbeitet durch User
Also als Info die neue Prozedur geht so... Im Skill ist ein link hinterlegt in dem per OAuth sich in der Hersteller cloud Anmeldet. Als Response erhält Amazon einen Token mit dem der Skill auf die Hersteller Cloud zugreifen kann. Der Skill übergibt diesen Token und nun muß der Hersteller schauen zu welchen Account der gehört und welche Geräte zu diesem angemeldet sind. Das ist mal richtig besch... Denn der Hersteller muß selber wie auch immer nach den Geräten suchen und sie in die Cloud integrieren. Danach muß sich der User über die Alexa App anmelden und sein Account mit der Hersteller Cloud verlinken. Dann erfolgt das Discovery über die Hersteller Cloud, die wie erwähnt schaut welche Geräte zu den token gehören. Das Verfahren heißt Gewinnmaximierung um jeden Preis und das ausschließen sämtliche Projekte die nicht bereit sind zu zahlen. Das Verfahren hat seine Tücken, wenn man mal das Feedback der Skills so ließt. Entfernt der Anwender den Skill ist der Token weg, ob sich die Geräte dann beim Wiederanmelden zuordnen lassen hängt vom Geschick des Herstellers ab.
:
Bearbeitet durch User
Also es gibt noch eine Möglichkeit mit Greengrass. Dort lassen sich sogar lokale Ressourcen nutzen. Die Geräte werden an einen RPI auf dem Greengrass läuft angebunden und dieser ist dann an die Cloud gebunden. Da auch der Code local läuft funktioniert das auch offline. Mit Alexa dann natürlich nicht mehr ;). Aber die Hausautomation läuft weiter. Ich habe versucht das zu testen bin aber am IAM gescheitert. Beim testen der Rule hätte sie funktionieren müssen aber der Code ließ sich nicht bereitstellen ->"GreenGrass is not authorized to assume the Service Role associated with this account". Die Rule wurde der Core Gruppe hinzugefügt aber es klappte nur ein einziges mal dann nie wieder. Meine Vermutung ist das im RPI klemmt,da wurde irgend wo was eingespielt und nun läßt sich der Code nicht mehr hochladen. l.m am A.. es ist nicht heraus zubekommen warum das Breitstellen nicht funktioniert.... Hilfe ist kaum zu erwarten wieder mal ein Thema das die Verfahren ihrer eignen Doku nicht funktionieren.
:
Bearbeitet durch User
Der Nagel hängt beim Kernel und dessen virtuellen Memory zwar mit Hand aktiviert aber es funktioniert offenbar nicht so wie es soll. Das Ding ist eine blackbox man kann nicht mal schauen ab sich das greengrass Code überhaupt im AWS angemeldet hat. An den rechten kann es nicht liegen aber habe auch mal zum Test alles freigegeben. Selbe Ergebnis, scheint wohl nicht mehr zu laufen mit dem RPI und den aktuellen Kernel.
Hallo zusammen, ich interessiere mich brennend für dieses Projekt. Leider habe ich Probleme nach der Eingabe der WLAN Zugangsdaten, daß der ESP mein WLAN nicht findet und im AP Modus bleibt. Kann es sein, dass es nicht funktioniert, wenn die SSID Leerzeichen enthält, oder die SSID zu lang ist (in meinem Fall 22 Zeichen)? Mit meinem Gastzugang (kurz und ohne Leerzeichen) scheint er sich zu verbinden. Jetzt möchte ich natürlich nicht meine SSID und alle meine WLAN Geräte umkonfigurieren. Weiß jemand Rat? Viele Grüße Moscito
:
Bearbeitet durch User
Leider geht es mit den Backslashs auch nicht. Mir ist aufgefallen, dass er sich beschwert, dass die SSID nicht gefunden wurde und in der angezeigten SSID sind die letzten zwei Zeichen meiner SSID abgeschnitten. Die Konfiguration ist also erfolgreich durchgelaufen, nur mit der zur kurzen SSID. Also doch zu lang? Nach meinen Recherchen soll die SSID aber bis 32 Zeichen lang sein dürfen, oder zählt bei der Länge das Passwort mit? Dann sind es über 32. Merkwürdig.
:
Bearbeitet durch User
Eine ESSID darf laut Spezifikation maximal 32 Zeichen lang sein. Mein Code begrenz die Anzahl der verfügbaren Zeichen auf 19. Das kann natürlich ein Problem sein. Ich werde das bei Gelegenheit mal anpassen.
Hallo Niels, danke für das Feedback. Falls Du das ändern könntest, wäre ich Dir äußerst dankbar. Damit erspare ich mir die stundenlage Neueinrichtung des WLANs und der dutzenden Klienten. Viele Grüße Moscito
Welche Zielplattform brauchst du? ESP-01, NodeMCU oder Wemos d1 mini?
Hab ein AZDelivery D1 Mini NodeMcu Lua ESP8266 ESP-12E WLAN WIFI Internet Module
Mos K. schrieb: > Hab ein AZDelivery D1 Mini NodeMcu Lua ESP8266 ESP-12E WLAN WIFI > Internet Module Das sind alles Schlagwörter, um die Suchergebnisse einer maschinellen Suche zu optimieren. Du hast vermutlich einen "D1 R2 Mini" oder etwas dazu kompatibles. Ich hab die Größe der ESSID angepasst. Bitte stelle sicher, das die Checkbox "formatieren" angetickt ist, damit die Konfigurationsdatei im Speicher des ESP8266 entsprechend neu angelegt wird. Das formatieren des Speichers dauert etwa 30sek. In dieser Zeit reagiert der ESP8266 auf nichts....
Hallo Niels, funzt! Du bist der Beste. Tausend Dank für Deine Unterstützung. Viele Grüße Moscito
Also: Habe 8 Steckdosen einkonfiguriert. Alle lassen sich über die Weboberfläche bedienen. Mein Echo Dot g2 erkennt jedoch nur zwei Geräte. Die beiden reagieren auch brav auf Sprachkommandos. Hat das womöglich etwas damit zu tun? Johann H. schrieb: > Mehrere Geräte gingen bei mir auch erst, nachdem ich ein kleines > [hässliches] delay in den UPNP Responder gepackt habe. 8 Geräte ohne > Probleme.
Mos K. schrieb: > Hat das womöglich etwas damit zu tun? Nein, es passierte das, was passieren musste. Ich habe dir eine Version geschickt, mit der ich gerade versuche, die RFBridge2 mit der Android Hue-Bridge App zum funktionieren zu bewegen. Die Schalter, die dargestellt werden, sind Testcode.... Anbei die (hoffentlich) richtige Version.
Jetzt passt alles - Thumbs up. Danke nochmals. Btw: Wirklich gute Arbeit Dein Projekt. Binary flashen, drei Kabel dran und fertig. Einfacher geht's nicht. Wäre bei dem ESP8266 IoT Contest bestimmt gut angekommen. https://www.hackster.io/contests/ESP8266
Hallo Niels! Ich würde deine Version auch gerne testen, leider finde ich nirgend wo einen Anschlussplan, wie ich den 433mhz sender anschließen muss. Aktuell habe ich das über ein NodeMcu V3 Board ohne Webinterface als Wemo simulation umgesetzt. Das ganze funtioniert gut, aber wenn ich was neues hinzufügen muss benötige ich immer den Rechner. Angeschlossen habe ich den Sender aktuell an "GPI01" und den Empfänger um Frequenzen anlernen zu können an "GPI02". Kannst du mir sagen wie ich was bei deiner Version anschließen muss damit es läuft? Danke auf jedenfall schon mal für deine Arbeit. Mfg Blue-Whirlwind
Blue-Whirlwind schrieb: > Ich würde deine Version auch gerne testen, leider finde ich nirgend wo > einen Anschlussplan, https://github.com/Monarch73/RFBridge2 In der Readme.md ist eigentlich alles notwendige beschrieben. Wenn etwas unklar beschrieben sein sollte, einfach fragen....
Hallo Mos Kito, hallo Niels, erst einmal vielen dank für euere Antwort. Ich habe da ganze jetzt getestet und es läuft alles gut. Super Arbeit , danke dir Niels. Aber Leider habe ich ein paar Probleme: In der Alexa App werden mir alle Steckdosen als Lampen mit Dimmerfunktion angezeigt. Ist das so gewollt? Die blaue LED lauchtet ständig was den Stromverbrauch erhöht, was für micht zwar nicht das Schlimmste ist, aber das Licht stört mich. Mir wäre es Lieber wenn die LED nur leuchtet wenn ein Signal gesendet wird. Kann mann das Ändern? Vielleicht kann mir da jemand einen Tip geben, wie man das ändern kann. Ansonsten läuft das ganze sehr gut. Danke noch einmal für die echt tolle Arbeit. Nachtrag noch zur Wemo diskussion weiter oben: Ich glaube nicht dass die Unterstützung dazu demnächst eingestellt wird, da es ja immer noch die Wemo Steckdosen mit Alexa unterstützung zu kaufen gibt. Aber trotzdem ist es super eine Alternative zu haben. Mfg Blue-Whirlwind
Macht ja nix. Dann gibt es eine APP was dass Disovery macht und die Geräte in eine Cloud einbindet. Über dein Cloud Account meldest du dich bei Amazon an. Der Skill wird verknüpft und über den Token kann der Hersteller die Geräte zuordnen. Deswegen sagte ich ja, für den Hersteller kein Problem, nur für Trittbrettfahrer. Hmm vielleicht hat er die Geräte ein falsches Profil gegeben im HUE. Das mit Greengrass funktioniert jetzt auch... Das Projekt ist ja erst ca 6 Monate alt. Da kann man schon mal grün sehen ;). Im Prinzip eine gute Sache und die Kosten sind gering. Man kann auch auf lokale Ressource des RPI zugreifen. Allerdings ist fies das die Core Zertifikate Standard 7 Tage maximal 30 Tagen ablaufen. Danach baut der baut der Core eine Verbindung zur Cloud auf und erneuert es. Schlägt die Verbindung fehl fliegen alle Devices raus. Damit wird verhindert das der Core offline ewig läuft und Amazon keine Gebühren entgehen. Wenn sie mal bei Steuern zahlen auch so gründlich wären.
:
Bearbeitet durch User
Hallo Blue-Whirlwind, hatte gestern schon mal mein USB Power Meter drangehängt. Der ESP zieht 50ma. Das ist mal echt wenig. Ich gehe mal davon aus, dass davon 10-20ma auf die LED zurückgehen. Bin gerade dabei ein 3D druckbares Gehäuse für die beiden Platinen zu entwerfen. Die LED bekommt dann entweder einen höheren Vorwiderstand, oder fliegt ganz raus. Das mit der Dimmerfunktion stört mich so wenig, wie Alexa :-) Gruß Moscito
Für die geplagten User von Funksteckdosen, bei denen kein House-Code oder Tri-State auslesbar ist, würde ich gerne anregen, den Binärcode mit in die Konfiguration der RF-Bridge aufzunehmen. Der ist das Einzige, was ich bei meinen Uni-Tec Funksteckdosen auslesen kann. Wäre das noch ohne zu großen Aufwand möglich ?
Blue-Whirlwind schrieb: > In der Alexa App werden mir alle Steckdosen als Lampen mit > Dimmerfunktion angezeigt. Ist das so gewollt? Phillips Hue Produkte scheinen allesamt eine Dimmerfunktion zu haben. Ich habe auf anhieb kein "Device-Type" gefunden, der keine Dimmerfunktion hat. Zukünfitg könnte man ja sowas verwenden, um irgendetwas per PWM oder I2C zu steuern.... > Die blaue LED lauchtet ständig was den Stromverbrauch erhöht, was für > micht zwar nicht das Schlimmste ist, aber das Licht stört mich. Was die LED betrifft; Ich hatte sie bisher nicht explizit auf dem Schirm. Beim D1 mini und nodemcu hängt die BUILTIN_LED am D4/GPIO2. Also am Port, an dem auch der 433Mhz-Transmitter angeschlossen ist. Diesen Pin umzuprogrammieren würde die Funktion des Transmitters stören. Notfalls auslöten. Wenn ich das richtig sehe, hat sie eine reine Signal-Funktion und wird für den Betrieb des ESP8266 nicht gebraucht.
hamstidamsti schrieb: > oder Tri-State auslesbar ist, würde ich gerne anregen, den Binärcode mit > in die Konfiguration der RF-Bridge aufzunehmen. Hat das jemand schonmal getestet? Funktioniert das? Wenn ich versuche, meine Fernsteuerung für die selbst-lernenden Steckdosen auszulesen, bekomme ich garnichts.
Marco H. schrieb: > Doch das Profil nennt sich "On/Off light"... Ich hatte das hier schonmal ausprobiert. Hat aber nicht funktioniert. Die emulierte Hue Lampe bzw Steckdose wurde nicht erkannt von Alexa. https://developers.meethue.com/content/whats-json-value-light-type-onoff-light
Ich habe in der Arduino IDE den Beispiel Sketch von RC-Switch "AdvancedReceiveDemo-example" auf den Wemos D1 Mini geladen. Datenleitung des Empfängers an zB Pin D1 und im Sketch anpassen: "mySwitch.enableReceive(5)". Dann kommen im seriellen Monitor der IDE bei Tastendruck auf der Fernbedienung so etwas wie hier: Decimal: 2137484 (24Bit) Binary: 001000001001110110001100 Tri-State: not applicable PulseLength: 528 microseconds Protocol: 5 Raw data: 7400,421,1143,422,1141,946,633,413,1145,419,1142,428,1149,412,1141,423,1 140,946,632,415,1149,413,1142,945,632,938,635,933,630,415,1147,941,636,9 31,627,419,1146,941,626,419,1153,935,631,939,621,422,1145,423,1153,
Vermutlich weil Philips selber keine Steckdosen anbietet....
Also das mit dem Greengrass funktioniert nur bedingt. Bei lokalen Topics wird der Client sofort getrennt. Das ärgliche ist das man auf fragen keine Antwort erhält und hinterher wollen sie noch Geld von einen. Für den Sch.. den sie zusammen gefummelt haben. Danke auch...
So ich habe mich etwas mit google beschäftigt. Noch schlimmer die ganze Sache ... das viel mir negativ auf... - jwt max 24h gültig wenn abgelaufen disconnect - disconnect bei inaktivität > 20min, folge keepalive <20min (was soll dieser Mist bitte schön ?) - clientID setzt sich umständlich zusammen - als password muss ein JWT (Java webtoken)generiert werden dieser hat eine begrenzte Lebensdauer. - die Verknüpfung zu anderen google Diensten ist bescheiden positiv 250MB frei Pakete für die trafic werden nicht mitgezählt. Fazit: wer Langeweile hat oder Geldgeber die einen die Zeit bezahlen soll sich darauf einlassen. Den restlichen Interessenten würde ich sagen laßt die Finger davon. Man ist so etwas von denen abhängig und hinterher kommt die Hand raus zum abkassieren. Ich werde meine Kraft jetzt in MQTT 5.0 stecken :)
Hallo Leute, da ich nun alles Geräte über das Webinterface eingetragen habe, habe ich jetzt eine weitere Frage. Gibt es jetzt eine möglichkeit das ganze zu sichern? Also das Ganze jetzt z.B.als .bin datei vom Nodemcu runter zu laden und zu speichen um es ggf. wieder aufspielen zu können? Ich habe da schon gegoogelt, bekomme aber da keine Infos dazu. Mfg
Blue-Whirlwind schrieb: > Gibt es jetzt eine möglichkeit das ganze zu sichern? Theoretisch, weil noch nicht ausprobiert: Es gibt ein Projekt mit dem Namen Esp8266FTPServer. Wenn du dir das Beispiel kompilierst und hochlädst, müsste es eine Datei im Speicher des ESP8266 exponieren, die "EEPROM.TXT" heisst. Dadrin sind alle Konfigurationsdaten enthalten. https://github.com/nailbuster/esp8266FTPServer
Du kannst auch mit dem esptool die .bin sichern und auch wieder drauf laden !
sry dür doppelpost ! esptool.py --port /dev/ttyUSB0 write_flash -fm dio 0x00000 sonoff.ino.bin esptool.py --port /dev/ttyUSB0 read_flash 0x00000 0x100000 image1M.bin
Hallo! Jetzt habe ich ein erneutes Problem. Anscheinend ist das Programm auf 16 Geräte begrenzt. Kann mann diese begrenzung aufheben. Ich brauche 10 Geräte mehr. Kann mir da jemand helfen?
Blue-Whirlwind schrieb: > Kann mir da jemand helfen? Ja, ich :-) Ich habe die Software auf 50 Geräte erweitert. Ich habe allerdings keine Ahnung, wie das Webinterface aussehen wird, wenn die 50 Geräte angelegt sind. Ich empfehle dir bei der Einrichtung den SPIFFS-Speicher neu zu formatieren und die Geräte neu anzulegen.
Hallo Niels, danke für deine Arbeit. Ich werde das ganze am Donnerstag gleich testen, aktuell bin ich och auf Dienstreise.
Hallo Niels, leider funktioniert das ganze nicht. Ich kann zwar alle geräte jetzt einspeichern, aber leider bringt Alexa eine fehlermeldung. Alexa: Ich weis nicht was los ist. Und schaltet dann auch nicht. Die Alexa app: Das gerät reagiert nicht. Wäre es auch möglich die Erweiterung der Geräte auf der ersten version (WeMo) zu machen? Ich hatte die ohne Probleme am laufen. Die wäre mir lieber. Danke dir schon mal für deine Hilfe.
Blue-Whirlwind schrieb: > Wäre es auch möglich die Erweiterung der Geräte auf der ersten version > (WeMo) zu machen? Jedes Emulierte Wemo-Gerät braucht seine eigne TCP- und UDP-Multicast-Verbindung. Das braucht Arbeitsspeicher (RAM) und der ist beim ESP8266 ohnehin sehr knapp bemessen. Ausserdem möchte ich eigentlich keine Zeit mehr in eine Gerät stecken, das langfristig vermutlich nicht mehr von Amazon unterstüzt wird. Ich habe eine Vermutung woher die Probleme kommen. Der Antwortspeicher für die Geräteauflistungsanfrage durch Alexa wird statisch alloziert. Ich nehme an, das 1KByte wohl an dieser Stelle nicht mehr ausreichend ist und das Programm den klassischen Bufferoverflow-Tot stirbt. Ich müsste an dieser Stelle wohl etwas mehr Zeit investieren...mal schauen, wann ich dazu komme.
Hi Niels, das Projekt hört sich sehr interessant an. Vielen Dank für deine Mühen. Ich habe versucht das Projekt zu flashen, alles streng nach Anleitung. Leider schafft es das fake WeMos D1 mini nicht in mein WLAN. Ich habe die Vermutung es lieg am Key, denn dieser hat 62 Zeichen. Kommt dein Programm damit klar? Ich habe zum Test einen Gastzugang bei meiner FritzBox eingerichtet und konnte darauf connecten. Gibt es eine Möglichkeit danach wieder zum "EasyAlexa"-WiFi zu wechseln? Selbst nach wiederholtem flashen wählt sich das Modul in mein Gast-WiFi ein, statt sich neu konfigurieren zu lassen. Zur Hülf! edit: Habe gerade im weiten Web gelesen, daß der ESP8266 nur mit 32 Zeichen SSID bzw. Key klarkommt. Damit ist das Gerät praktisch Nutzlos für mich :(
:
Bearbeitet durch User
Hallo M Herberts, Momentan ist die Länge der SSID auf 36 Zeichen begrenzt (was dem Standard entspricht) und die Länge für das WLAN-Passwort auf 80. Um die Einstellungen zurück zusetzen, gibt es zwei möglichkeiten: - Aus Reichweite des WLAN gehen. Der ESP8266 geht dann automatisch in den "Errichtermodus". - Mit dem Flash-Tool von Expressif den Flash-Speicher löschen und das Programm neu flashen.
Na sowas, trotzdem funktioniert mein Key nicht. Die SSID hat nur 8 Zeichen, der Key hat 62. Mein Gastzugang hat eine SSID mit 20 Zeichen und ein PW mit 16 Zeichen. Vielen Dank für die Infos mit der WLAN-Reichweite :) Werde noch ein wenig tüfteln ;)
Sooo... ich mal wieder: Es funktioniert alles soweit ich das beurteilen kann. Ich habe auch schon ein kleines Gehäuse für das Gerät gebastelt und es an zentraler Stelle in der Wohnung platziert. Ein kleiner Wermutstropfen ist leider noch da: Jedesmal wenn ich Alexa etwas ein- oder ausschalten lassen quittiert sie es mit "Ich weiß nicht was schiefgelaufen ist.". Sie führt es aber dennoch aus. Hat jemand eine Idee woran das liegen könnte?
M. H. schrieb: > Ein kleiner Wermutstropfen ist leider noch da: Jedesmal wenn ich Alexa > etwas ein- oder ausschalten lassen quittiert sie es mit "Ich weiß nicht > was schiefgelaufen ist.". Sie führt es aber dennoch aus. Hat jemand eine > Idee woran das liegen könnte? Du hast vermutlich eine 2nd Gen Alexa. Also die hier: http://i.otto.de/i/otto/21594991 Diese Reagiert leider ein bisschen anders als die anderen Alexas. Warum sie allerdings so reagiert wie sie es tut kann ich leider nicht sagen. Und ich hab leider auch keine Möglichkeit das nachzuvollziehen, weil ich keine habe.
Ich habe keine 2nd Gen Alexa, ich besitze "nur" zwei Dots. Ich habe die beiden Dots am CyberMonday letzten Jahres gekauft. Schon interessant...
Hallo zusammen! Ich habe das ganze jetzt auf 35 Geräte erweitert. Ich möchte aber ausdrücklich darauf hinweisen, dass ich nur eine Änderung vorgenommen habe und nicht der geistige Eigentümer dieses Codes bin. Der eigentliche Code ist von Niels Huesken und ich möchte mich bei ihm auch für seine Arbeit herzlich bedanken. Es funktioniert alles ohne Probleme. Wichtig ist das im Arduino unter Boardverwaltung --> esp8266 by ESP8266 Commmunity die Version 2.3.0 instaliert ist. Bei allen höheren oder niedrigeren Versionen kommt es zu Fehlfunktionen. Ich habe mich für die RF-Bridge2 version 0.91b entschieden, da ich keine IF funktion benötige. @Niels ich hoffe es ist für dich ok dass ich dein etwas Programm abgeändert habe und hier neu einstelle. Sollte dies nicht OK für dich sein melde dich und ich entferne natürlich sofort den Download. Jetzt hätte ich aber evtl. noch eine verbesserung zum Webinterface. Wäre es möglich hier den aktuellen Status anzeigen zu lassen? z.B. das Gerät ist aus dann könnte der "off" Button orange gefüllt bleiben, ist ein Gerät eingeschaltet dann könnte der "on" Button grün gefüllt bleiben Dadurch könnte mann diese Webinterface an einem alten Tablet anzeigen lassen und dieses an einer Zentralen stelle im Haus platzieren und hat immer einen Überblick über die eingeschalteten Geräte. Leider bin ich noch Anfänger in dieser Programierung. Gruß Whirlwind
Blue-Whirlwind schrieb: > @Niels ich hoffe es ist für dich ok dass ich dein etwas Programm > abgeändert habe und hier neu einstelle. Sollte dies nicht OK für dich > sein melde dich und ich entferne natürlich sofort den Download. Nein, alles gut. Die Software steht unter MIT Lizenz, die dir quasi erlaubt alles mit der Software zu machen, was du möchtest, solange mein Name irgendwo auftaucht. Wobei selbst das wäre nichts, worauf ich unbedingt pochen würde... Wenn du möchtest: ich habe auf Github einen Branch aufgemacht, wo du deine änderungen reinpacken könntest, wenn du möchtest. Dafür bräuchte ich nur dein github namen. > Jetzt hätte ich aber evtl. noch eine verbesserung zum Webinterface. > Wäre es möglich hier den aktuellen Status anzeigen zu lassen? > z.B. das Gerät ist aus dann könnte der "off" Button orange gefüllt > bleiben, ist ein Gerät eingeschaltet dann könnte der "on" Button grün > gefüllt bleiben Sorry, ich habe bei einem neuen Arbeitgeber angefangen und komme derzeit zu nichts. Das webinterface ist eine Angular2-App, die du ebenfalls deinen ansprüchen anpassen kannst, wenn du dich etwas mit Angular auskennst: https://github.com/Monarch73/rfbridge-angular Entwickelt wird in Visual Studio Code und kann leicht angepasst werden. Dafür startest du mit "npm start" die App und wenn dir browser sich öffnet hängst du der Url ein #-Tag und dann die IP deines ESP8266. z.B. http://localhost:4200/#192.168.1.1
Hallo Niels danke für deine Freigabe. Mein Gidhub Name ist Blue-Whirlwind. Leider kenn ich mich mit der Angular2-App nicht so aus, werde mich aber mal einarbeiten. Kann aber etwas dauern, da ich beruflich einfach viel unterwegs bin. Ich bedanke mich aber sehr herzlich bei dir für deine bisherige Hilfe. mfg Blue-Whirlwind
Moin Moin, also gibt es im Moment keine Lösung für den Echo der 2nd? Habe schon unzählige Programme probiert damit ich meine Funksteckdosen schalten kann aber nichts funktioniert richtig. mfg Marcel
Das beste ist man besorgt sich HUE Geräte und verwendet einen echo+ oder simuliert den HUE Hub.. Für alles andere sieht es so aus das dessen Unterstützung er fraglich ist. Man kann sich natürlich auch als Entwickler im AWS anmelden und dann seine Geräte einbinden.. So habe ich das gemacht, Vorraussetzungen sind aber TLS,MQTT oder REST und Json.. Wenn man die Grenzen nicht sprengt besteht di Aussicht das man auch nach 1 Jahr kostenfrei davon kommt.
ich habe jetzt eine Lösung für das kompatibilitätsproblem. Also eine, die mit allen Alexa Versionen kompatibel sein sollte. Benötigt wird allerdings der "Homebridge"-skill, der aktiviert und registriert werden muss. Danach kann der esp8266 mit eines der Bin-Dateien geflashed werden: https://www.monarch.de/index.php/apps/files?dir=//microhomebridge Teil des Softwarepakets ist ein FTP-Server. Wenn der ESP mit der Software starte, muss man man die übrigen .json und .gz-dateien in das SPIFFS des esp8266 per hochladen (windows-firewall abschalten!, PASV nicht unterstützt also nur PORT, nur 1 verbindung gleichzeitig, username/passwort egal). Ansonsten ist das Programm einzurichten, wie beschrieben. Das Programm ist noch nicht fertig. Über Beta-tester würde ich mich freuen...
:
Bearbeitet durch User
Ich habe mich auch mit dem ESP8266 und Alexa beschäftig. Als Basis habe ich das Beispiel von Heise developer genommen: https://www.heise.de/developer/artikel/Gutes-Echo-mit-ESP8266-oder-ESP32-3991889.html Es funktionierte natürlich nicht out-of-the-box. Durch viel probieren und Lesen der Issues auf der Bitbucket-Seite der FauxmoESP-Bibliothek habe ich es aber ans laufen bekommen. Ich verwende als Hardware das LoLin "new NodeMcu V3" und den Echo Dot Gen2. Die Software-Versionen sind: - Arduino IDE 1.8.7 - esp8266 Board-Unterstützung 2.4.2 - Eingestelltes Board: Node MCU 1.0 - FauxmoESP 3.0.2 Der fauxmo Funktionsaufruf muss im Beispiel angepasst werden:
1 | fauxmo.onSetState([](unsigned char device_id, const char * device_name, bool state, unsigned char value) |
Bei den Board-Einstellungen in der IDE muss die "lwIP" Variante umgestellt werden: IwIP „v1.4 Higher Bandwidth“ An der Stelle "fauxmo.enable(true);" im Sketch muss diese Sequenz eingefügt werden:
1 | fauxmo.enable(true); |
2 | fauxmo.enable(false); |
3 | fauxmo.enable(true); |
Nach dem Übersetzen und Hochladen des so erstellen Codes wurden bei mir die Fake-Lampen gefunden und sie konnten geschaltet werden. Auch Kommandos zum Dimmen funktionieren. Andere Kombinationen von Echo-Gerät und Software-Version funktionieren mit "meiner" Lösung eventuell nicht. Infos und Diskussionen zur Kompatibilität ist auf der Seite unter "Issues" zu finden: https://bitbucket.org/xoseperez/fauxmoesp
Mit fauxmoesp werden spätestens die Spots und Show nicht mehr funktionieren, weil diese Wemo nur hier nicht mehr eingebaut ist. Mir war der WEMO-Weg zu hügelig. Der Homebridge-Skill, den ich in meiner letzten Version eingebaut habe, funktioniert über alle Alexa-Versionen. https://github.com/Monarch73/MicroHomebridgeAlexaEsp8266
Niels H. schrieb: > Mit fauxmoesp werden spätestens die Spots und Show nicht mehr > funktionieren, weil diese Wemo nur hier nicht mehr eingebaut ist. > > Mir war der WEMO-Weg zu hügelig. Der Homebridge-Skill, den ich in meiner > letzten Version eingebaut habe, funktioniert über alle Alexa-Versionen. > > https://github.com/Monarch73/MicroHomebridgeAlexaEsp8266 Die FauxmotESP Bibliothek emuliert ab V3 nicht mehr WeMo, sondern Philips Hue Lampen. Damit ist dann auch Dimmen möglich. Also bei "Alexa, schalte die Lampe auf 50 %" bekommt man einen Wert von 127 zurück.
Sebastian E. schrieb: > Die FauxmotESP Bibliothek emuliert ab V3 nicht mehr WeMo, sondern > Philips Hue Lampen. Das scheint aber aucht nicht ohne Probleme zu laufen. Selbige Probleme hatte ich bereits mit meinem RFBridge2 und hab schlussendlich aufgegeben, die Hue Bridge emulieren zu wollen. https://bitbucket.org/xoseperez/fauxmoesp/issues/58/v30-not-discovered-by-alexa
Niels H. schrieb: > Sebastian E. schrieb: > >> Die FauxmotESP Bibliothek emuliert ab V3 nicht mehr WeMo, sondern >> Philips Hue Lampen. > > Das scheint aber aucht nicht ohne Probleme zu laufen. Selbige Probleme > hatte ich bereits mit meinem RFBridge2 und hab schlussendlich > aufgegeben, die Hue Bridge emulieren zu wollen. > > https://bitbucket.org/xoseperez/fauxmoesp/issues/58/v30-not-discovered-by-alexa Und so schließt sich der Kreis und wir sind wieder bei meinem ursprünglichen Post angekommen ;-) Dort habe ich ein Kondensat aller interessanten Diskussionen aus den Issues zusammengeschrieben für diejenigen die bei der Suche nach FauxmotESP diesen Thread finden. Ist ja nur eine Alternative, will das nicht aktiv promoten. Deine aktuelle Lösung mit dem Hombridge ist durchaus interessant, da sie viel mehr Möglichkeiten bietet. Mich persönlich schreckt die Registrierung und der Apple-Dunstkreis wieder ab.
> Mich persönlich schreckt die Registrierung und der Apple-Dunstkreis > wieder ab. Auf längerer Sicht wirst du um eine Registrierung nicht mehr herum kommen. Die neueren Alexa-Geräte (Spot und Show) sind keine Smarthome-Mechanismen mehr eingebaut sondern nur noch per Skill erreichbar. Den Homebridge-Skill, den ich verwende, hat nichts mit Apple zu tun. Er wird maintained von einem Canadier und ist explizit für die Alexa-Anbindung entwickelt worden. Zudem ist der quellcode des Services auf Github einsehbar, also völlig open-source.
Den Skill kann man sich aber selber basteln. Auch nach einen Jahr fliegt dieser nicht heraus. Man könnte diesen auch veröffentlichen. Das Problem dabei ist das du dann für die Trafic zahlst ;). Das ist ja das Prinzip von Amazon und dessen Geräte. Die Kunst ist es den Skill so zu gestalten das im AWS geringe kosten anfallen. Im Januar läuft mein kostenlos Account aus, ich werde mein Kram mal einen Monat laufen lassen und über die Kosten berichten :). Bei 5€ im Monat lasse ich die Kirche im dorf... Den Code für den skill könnte man ja teilen, ohne Account Daten ;). Lässt sich der HUE Hub nicht über den Philips Skill ansprechen ? Dann zahlt Philips...
:
Bearbeitet durch User
Marco H. schrieb: > Den Skill kann man sich aber selber basteln. Das brauchst du gar nicht selber basteln. Das Rad haben schon tausend andere vor dir erfunden. Aber ja, du kannst ihn auch selbst betreiben, wenn man das möchte. Der Skill, den ich nutze, liegt im quellcode auf github. Aber er wird bereits vom Author auf AWS bereits betrieben..... Also warum sollte man noch einen Skill selbst entwickeln und betreiben?
Passend den verschiedenen Alexas hat Amazon auch das Buch "ZERO" von Marc Elsberg: https://www.amazon.de/ZERO-Sie-wissen-tust-Roman/dp/3764504927 Ich kann das Buch sehr empfehlen, es gibt mal einen Einblick, was man alles so in Zukunft mit der Technologie machen kann.
Da der Anbieter des Skills auch für dessen Ressourcen zahlt. Das ist das Prinzip des AWS.. Amazon hat die Daten und kassiert von den Anbietern. Wenn du wieder als Trittbrettfahrer mit fährst passiert genau das gleiche erneut.
Ich habe ja versprochen euch über die kosten zu informieren.. Da mein kostenlos Kontingent im AWS ja verbraucht war. Also ganze 7cent haben meine 10 Geräte verbraucht ! In Anbetracht dieser Tatsache lohnt sich es wirklich nicht irgend welche Lösungen zu basteln und als Trittbrettfahrer mit zu fahren.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.