IoBroker Alexa2 v2.0 ALPHA!!! Status GitHub Version!
-
Starte mal den Adapter neu `
Habe ich natürlich bereits gemacht. Sogar beide Raspis neu rebootet.
Ich habe den Fehler gefunden:
Die Version 2.1.0 kommt mit Mutihost-Umgebungen nicht klar.
Wenn ich Webserver und Alexa-Adapter beide auf den Master ziehe, erscheinen tatsächlich die Nodes.
Die 2.0.0 hat mit Multihost keine Probleme. Ich vermute also hier einen Bug?
und kaum verschiebe ich die beiden Adapter wieder auf den Slave, kommt folgende Log-Zeile:
alexa2.0 2019-01-14 16:59:38.621 info Deleting the following states: ["Echo-Devices.G090U60884230800.Commands.ssml","Echo-Devices.G090U60884230800.Commands.announcement","Echo-Devices.G090U60884230800.Commands.notification","Echo-Devices.........wieder zurück zu Master:
alexa2.0 2019-01-14 17:02:24.675 info {"applianceId":"AAA_SonarCloudService_76673dd5-7fa5-3c3e-b100-4bb37a505388","endpointTypeId":"","driverIdentity":{"namespace":"AAA","identifier":"SonarCloudService"},"manufacturerName":"Amazon","frien alexa2.0 2019-01-14 17:02:24.675 info Smarthome-Device Capability Alexa.AcousticEventSensor unknown. Report to developer this and next log line from logfile on disk! alexa2.0 2019-01-14 17:02:24.675 info {"applianceId":"AAA_SonarCloudService_ee0be2fd-75d4-3a67-a138-24748be31f62","endpointTypeId":"","driverIdentity":{"namespace":"AAA","identifier":"SonarCloudService"},"manufacturerName":"Amazon","frien alexa2.0 2019-01-14 17:02:24.675 info Smarthome-Device Capability Alexa.AcousticEventSensor unknown. Report to developer this and next log line from logfile on disk! alexa2.0 2019-01-14 17:02:24.675 info {"applianceId":"AAA_SonarCloudService_a21261e2-b7c3-3a93-8610-6de0c81dac97","endpointTypeId":"","driverIdentity":{"namespace":"AAA","identifier":"SonarCloudService"},"manufacturerName":"Amazon","frien alexa2.0 2019-01-14 17:02:24.675 info Smarthome-Device Capability Alexa.AcousticEventSensor unknown. Report to developer this and next log line from logfile on disk! alexa2.0 2019-01-14 17:02:24.674 info {"applianceId":"AAA_SonarCloudService_7eaf0123-edc8-30d6-8e6b-501232d8036c","endpointTypeId":"","driverIdentity":{"namespace":"AAA","identifier":"SonarCloudService"},"manufacturerName":"Amazon","frien alexa2.0 2019-01-14 17:02:24.673 info Smarthome-Device Capability Alexa.AcousticEventSensor unknown. Report to developer this and next log line from logfile on disk! ```` `Dann habe ich einen einfachen Tipp: Hast du beim Update des Adapters den korrekten Host gewählt? Ich in der Meinung das auf Master die neue Version ist und auf dem Slave die alte. Stell sicher das beim Update per Admin oben auch der korrekte Host gewählt ist!!!
Gesendet vom Handy …
-
Also noch was zum JSON-Objekt:
Wenn ich eine kurze Pause zwischen "Alexa" und "Licht an" lasse, kommen zwei Trigger.
"alexa" und "aicht an"
Spreche ich das aber flüssig nacheinander, kommt "alexa licht an"
Mache ich die Pause zu groß, dann erhalte ich:
"alexa" und "Unknown" `
Fix für korrektes aussortieren der wake words kommt in nächster Version
Gesendet vom Handy …
-
Hallo, brauche Hilfe, komme ich einfach nicht weiter. Kriege ich die Alexa einfach nicht zum laufen, die bleibt einfach stumm und keine Commands funktionieren. Habe ich schon mehrere Versionen von dem Adapter ausprobiert, auch die alte 0.4, 1.1.3, 2.0 und zum letzten die 2.1, leider kein erfolgt. Das System ist VirtuelBox Debian 9 (schon mit Debian 8 probiert), ioBroker 3.5.10, node v8.15.0 nodejs 8.15.0 npm 6.4.1. Bei der Konstellation bei dem Version Alexa 2.1 bekomme ich nicht mal alle Objekte, nur info, dann muss ich zu erst die 1.1.3 instalieren, dann 2.1 rüber installieren, dann sind die Objekte, aber kein Funktion von Commands. Habe ich schon aus Verzweiflung das ganze auf RasPi mit fertigen Image von ioBroker (ioBroker_Image_RPi_2-3_20190104_stretch und ioBroker_Image_RPi_2-3_20180401_stretch) versucht, die gleiche Problematik, was mache ich falsch? `
Starte mal ohne debug und schau mal ob im log Meldungen für den Entwickler sind. Was hast du denn für Geräte? Sag mal die deviceType davon aus den Info Adaptern. Ob Kommandos existieren ist User Feedback und steht im Adapter drin pro deviceTyp. Also bitte deviceTypen und die info was das ist.Und um zu prüfen ob Kommandos überhaupt gehen kannst du die Alexa App nehmen und versuchen eine Routine anzulegen die auf dem Gerät etwas ausgibt. Wenn du das Gerät dort wählen kannst dann ist ggf Die Typ Info im Adapter falsch. Oder die Geräte können das einfach nicht.
Check das bitte mal.
Gesendet vom Handy …
-
Dann habe ich einen einfachen Tipp: Hast du beim Update des Adapters den korrekten Host gewählt? Ich in der Meinung das auf Master die neue Version ist und auf dem Slave die alte. Stell sicher das beim Update per Admin oben auch der korrekte Host gewählt ist!!!
Gesendet vom Handy … `
hmm… dann muss ich doof fragen. Wie kann man das denn von Katze explizit machen? Ich dachte, er nimmt dann den, der vorher im Admin eingestellt ist
-
Sollte er. Aber es zählt der Host der ganz oben im Admin im der Auswahl ist nicht der wo die Instanz läuft.
Gesendet vom Handy …
-
Sollte er. Aber es zählt der Host der ganz oben im Admin im der Auswahl ist nicht der wo die Instanz läuft.
Gesendet vom Handy … `
soeben hast du den Heldenstatus für mich erreicht.
Das war es. Ich wusste garnicht, dass man da umschalten konnte.
Muss ich viel mehr darauf achten
-
Schon selbst öfters reingefallen … -
in Alexa App die Routinen gehen, und werden auch ausgegeben (ausgesprochen), nur nicht aus Adapter. Sind zwei Geräte, jeweils Echo Dot 2. In Log sind auch keine Meldungen für Entwickler,
16727_alexa.jpg -
device.typen?
-
sind beide Echos: A3S5BH2HU6VAYF
-
Kurze Rückmeldung von mir bzgl. Cookie Refresh nach 24h und Instanz/ioB/System Restart: Funktioniert! Ich habe neue Cookies für beide Instanzen erhalten.
-
Danke. Die langzeit werte ich 14-21 Tagen werden interessant
Gesendet vom Handy …
-
sind beide Echos: A3S5BH2HU6VAYF `
Und du hast die 2.1 vom GitHub? Dann sollte das inkl command support drin sein.Gesendet vom Handy …
-
Moin,
ich habe ein Problem mit der neuen Version und dem Proxy.
ioBroker läuft als ein Docker Image. D.h. der Container hat eine interne IP von z.b. 172.17.0.7 auf dem Host mit der IP 192.168.1.1
Die interne IP kann von außen nicht erreicht werden dafür werden Portumleitungen definiert, z.b. 172.17.0.7:8881 <->192.168.1.1:8881
Damit kann ich aus dem normalen Netz meine Dockerinstanz ganz normal aufrufen mit192.168.1.1:8881
Das funktioniert mit allen ioBroker Services und in Summe 11 anderen Docker Containern.
Nun zum Problem:
Alexa2 meldet mir als Proxy 172.17.0.7:8887 (der Port ist fest eingestellt und wird auch von dem Host entsprechend weitergeleitet)
Also muss ich vom Browser die 192.168.1.1:8887 aufrufen…...nun liefert mir der Proxy aber zurück:
http://172.17.0.7:8887/www.amazon.com/a ... 2F%2Falexa.........
Hier müsste er aber den vorderen Teil von der Anfrage übernehmen und nicht verändern (So machen es alle anderen WebServices auch)
Ändere ich die URL nun Manuel in
http://192.168.1.1:8887/www.amazon.com/ ... 2F%2Falexa.........
komme ich leider auch nicht weiter......
Gruss
Sky
-
Ja ist bekannt und gibt ein GitHub Issue dazu. Kam noch nicht dazu. vllt in der 2.2
-
2.2.0 Auf GitHub released.
Änderungen:
-
Neue Kommandos calendarToday, calendearTomorrow, calendarNext zur Ausgabe von Kalenderevents von mit Alexa verbundenen kalendern. Ist das was die Routinen auch machen
-
History-Summary sollte jetzt wieder korrekt vom "Wakeword" befreit werden, also Routinen sollten jetzt auch bei schnellem sprechen wieder sauber getriggert werden.
-
-
Habe jetzt die Alexa mal gestresst und versucht, das Triggerwort zui provozieren.
ist mir nur beim ersten Mal gelungen und da war der Adapter zwar geupdated aber nicht restartet.
Nach einem Restart habe ich es nicht mehr gesehen.
ABER:
ich habe extra schnell gesprochen.
"Alexa, wie viel Uhr ist es"
Meist kam das auch so im Summary-Objekt an.
Einige wenige Male ist der Knoten aber leer geblieben und im Status stand: DISCARDED_NON_DEVICE_DIRECTED_INTENT
Alexa selbst hat mit die Uhrzeit brav angesagt.
Im JSON-Knoten stand:
{"name":"Echo Plus Schlafzimmer (2nd Gen)","serialNumber":"G090LA09xxxx601DS","summary":"","creationTime":1547594314787,"status":"DISCARDED_NON_DEVICE_DIRECTED_INTENT","domainApplicationId":"","domainApplicationName":"","cardContent":"","card":""}
Und ich habe es nicht im Schlafzimmer gesagt.
Korrekt wäre es gewesen:
{"name":"Echo Spot Arbeitszimmer","serialNumber":"G070RQxxxxxx11H2","summary":"wie viel uhr ist es","creationTime":1547594617722,"status":"SUCCESS","domainApplicationId":"","domainApplicationName":"","cardContent":"","card":""}
-
Das müsste man dann im Debug Log im Detail auseinandernehmen. Tippe auf zu schnelle updates im Objekt.
Mach mal ein Skript und lass es dir loggen.
DISCARDED_NON_DEVICE_DIRECTED_INTENT heisst an sich "Ich habe was gehört es aber verworfen weil doch nicht an mich gerichtet". Das kommt oft wenn man Alexa sagt und dann nichts mehr oder wenn Sie"von selbst" an geht
-
Das müsste man dann im Debug Log im Detail auseinandernehmen. Tippe auf zu schnelle updates im Objekt.
Mach mal ein Skript und lass es dir loggen.
DISCARDED_NON_DEVICE_DIRECTED_INTENT heisst an sich "Ich habe was gehört es aber verworfen weil doch nicht an mich gerichtet". Das kommt oft wenn man Alexa sagt und dann nichts mehr oder wenn Sie"von selbst" an geht `
Ja, das habe ich auch vermutet.
Was halt dann ausgeblieben ist, dass der endgültige Zustand nicht eingetragen wurde.
Bin gerade nicht zu Hause. Daher kann ich auf die Schnelle kein Log liefern.
Und da ich bisher mit node red gearbeitet habe, reicht wahrscheinlich auch ein debug im node red ?
-
Ich tippe ja das der Stand eingetragen wurde aber direkt mit dem anderen überschrieben wurde.
Am besten ein log auf den json History State. Wie du es loggst ist egal. Geht um die Reihenfolge.
Gesendet vom Handy …
