Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054
Ja, das ist genau das was ich meinte, nämlich einer dieser Skills, bei dem du dich bei einem Cloud Service registrieren musst. Gleiches gibt es auch für Openhab.
Was ich noch nicht verstanden habe: Was genau ist der Vorteil?
Der einmalige Konfigurationsaufwand bei dem EDOMI Skill stehen der Komplexität der Verbindung von Node-Red mit Edomi gegenüber und der Tatsache, dass noch ein weiterer Cloudservice zwischengeschaltet ist.
Das wird so vermutlich nicht funktionieren. Das geht nur, wenn man einen echten Alexa Skill mit Cloud-Service im Backend entwickelt, d.h. eine zentrale Plattform, welche den Skill bildet und wo man sich registriert und womit sich EDOMI dann verbindet. Damit würde es dann einen EDOMI Alexa Skill geben, der von allen genutzt werden könnte, so dass man keinen Developer Skill mehr je User benötigt. Das ist aber definitiv nicht mein Ziel einen solchen Service aufzubauen.
Ich weiss nicht, wie es bei Google funktioniert, aber bei Alexa, muss die Lambda Funktion immer die entsprechende Antwort des SKills zurückliefern, ansonsten gibt Alexa einen Fehler zurück. Selbst wenn die Lambda Funktionion das Command per MQTT sendet, könnte es zwar bei EDOMI verarbeitet werden, aber die Lambda Funktion muss die korrekte Antwort an den Alexa Service zurückliefern, ansonsten bekommt du eine Fehleransage.
Geht es dir nur um Steuerbefehle oder auch um Statusabfragen? Geht das bei Google auch?
Ich bin hier einen Schritt weiter. Habe den Node-Red-Skill von Alexa genutzt und über einen Node-Red auf einem vserver außerhalb meiner internen Netzwerkumgebung am Laufen. Auf dem vserver läuft dann einfach ein Broker auf dem edomi dann subscribed. Ich kann mittlerweile alles schalten/dimmen/etc. Einzig an den Rückmeldungen arbeite ich noch, was aber geht.
Bei Alexa bekommt man aber mit den Routinen notfalls erstklassige Rückmeldung...
Werde den Weg die Woche über mal dokumentieren.
Ich hänge an Alexa und würde das ganze, was ich mit Google realisiert habe, gerne auch mit Alexa haben, da die Sonos-Integration bei Amazon deutlich besser ist.
Das wird so vermutlich nicht funktionieren. Das geht nur, wenn man einen echten Alexa Skill mit Cloud-Service im Backend entwickelt, d.h. eine zentrale Plattform, welche den Skill bildet und wo man sich registriert und womit sich EDOMI dann verbindet. Damit würde es dann einen EDOMI Alexa Skill geben, der von allen genutzt werden könnte, so dass man keinen Developer Skill mehr je User benötigt. Das ist aber definitiv nicht mein Ziel einen solchen Service aufzubauen.
Ich weiss nicht, wie es bei Google funktioniert, aber bei Alexa, muss die Lambda Funktion immer die entsprechende Antwort des SKills zurückliefern, ansonsten gibt Alexa einen Fehler zurück. Selbst wenn die Lambda Funktionion das Command per MQTT sendet, könnte es zwar bei EDOMI verarbeitet werden, aber die Lambda Funktion muss die korrekte Antwort an den Alexa Service zurückliefern, ansonsten bekommt du eine Fehleransage.
Geht es dir nur um Steuerbefehle oder auch um Statusabfragen? Geht das bei Google auch?
Ich hänge an Alexa und würde das ganze, was ich mit Google realisiert habe, gerne auch mit Alexa haben, da die Sonos-Integration bei Amazon deutlich besser ist.
Brick Ein Baustein kann eine Menge kosten, nämlich Aufwand.
Im iobroker habe ich sicher 500 Objekte, welche an Edomi gehen. Wenn jeder 10te ein true/false ist, dann macht das schnell keinen Spaß mehr und das Konzept auf der Edomi Seite eine IO Anlegen und auf der Gegenseite nur ein set/edomi/internal/ko geht ist schon nicht mehr so smart.
Da muss ich mich der Meinung von Brick anschließen, denn das hat so gar nichts mit dem MQTT-LBS zu tun und ist so speziell, dass es vermutlich niemand sonst verwenden würde. Genau für solchen Anforderungen ist ja das modulare LBS Konzept gedacht.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: