NEWS
IoBroker Alexa2 v2.0 ALPHA!!! Status GitHub Version!
-
Funktioniert bei mir mit Version 1.1.3 auch nicht mehr.
Bei mir verbindet er sich zwar sobald ich den Cookie aus dem Log lade und liest auch direkt alle Werte aus, aber sobald ich einen Wert setzen möchte kommt:
2019-06-16 17:26:56.333 debug Alexa-Remote: Response: {"message":"Forbidden","code":null} alexa2.0 2019-06-16 17:26:56.176 debug Alexa-Remote: Sending Request with {"host":"alexa.amazon.de","path":"/api/phoenix/state","method":"PUT","timeout":10000,"headers":{}}and data={"controlRequests":[{"entityId":"1bae7ba5-3970-405d-816b-alexa2.0 2019-06-16 17:26:56.176 debug Alexa-Remote: No authentication check needed (time elapsed 41438)
Folgendes hat nicht geholfen:
-
Adapter entfernt und neu Installiert, sowie den Cookie über den Link im Log geladen.
Ergebnis: {"message":"Forbidden","code":null} -
Frisches Debian, IoBroker,Alexa und Cloud Adapter installiert.
Cookie wieder über das Log eingelesen
Ergebnis:{"message":"Forbidden","code":null} -
Cookie gelöscht und Adapter neu gestartet um Cookie über das Log erneut zu laden.
Ergebnis: {"message":"Forbidden","code":null}
Getestet in einem Docker Container und VMware
-
-
Moin, mit V1.1.3 und manuellem Cookie Abruf, bekomme ich es zum laufen!
Ich habe vorher Cookie usw gelöscht. dann erst die V1.1.3 gestartet.
leider verschwinden dann einige neuere Funktionen, da der Adapter unbekanntes löscht.
Grußedit: nach dem die V1.1.3 erfolgreich aktiviert wurde hab ich wieder auf die Version 2.2.0 aktualisiert und der Fehler ist wieder da. So kann man auf das cookie handling in V2.2.0 das problem eingrenzen, denke ich.
Matten Matten
-
Ich hab was gefunden, wenn ich in der datei
\node_modules\iobroker.alexa2\main.js
zeile
2022
folgendes
cookie: adapter.config.cookieData, // cookie if there is already one
in
cookie: adapter.config.cookie, // cookie if there is already one
abändere, kann ich die V2.2.0 wieder erfolgreich starten.
dann funktioniert zumindest das manuelle Cookie laden wieder.
Cookie manuell holen: [https://forum.iobroker.net/topic/14454/iobroker-alexa2-v0-4/472]
-
Hab den Browser cache gelöscht und bekomme nun ebenfalls die Meldung
-
@Matten-Matten
Hast Du gut gemacht.
Als vorübergehender Workarround sicher gut zu gebrauchen.
Zumindest läuft so mein System erstmal wieder.
Dann wollen wir mal warten ob apollon77 und Kollegen eine Lösung finden. -
Ich hätte mal eine testbitte. Am besten mir unmodifiziertem Code.
Bitte in den instanz Objekt Einstellungen (system.adapter.alexa2.0) auf den Stift und dort unter raw sehr ihr die Cookie Daten. Ist da ein „leeres“ craft mit drin oder fehlt es? Egal wie mal bitte ein csrf=12345678 oder so reinschreiben. Geht es dann nach einem Neustart?
Alternativ mal mit dem modifizierten Code und dem Cookie mit csrf den Wert mal ändern. Geht es dann noch immer?
-
@apollon77
kein craft
{
"from": "system.host.iobroker.cli",
"ts": 1548520580799,
"common": {
"name": "Alexa Cookie",
"role": "text",
"type": "string",
"def": "",
"read": true,
"write": false
},
"native": {},
"acl": {
"object": 1636,
"owner": "system.user.admin",
"ownerGroup": "system.group.administrator",
"state": 1636
},
"_id": "alexa2.0.info.cookie",
"type": "state"
} -
@leuchttrm Du bist glaube im falschen RAW
@apollon77
So sieht das bei mir aus. CSRF ist gesetzt. Alles andere habe ich mal mit *** geschwärzt."cookieData": { "loginCookie": "***", "frc": "***", "map-md": "***", "deviceId": "***", "deviceSerial": "***", "refreshToken": "***", "tokenDate": 1560830823529, "amazonPage": "amazon.de", "localCookie": "session-id=123-4567890-1234567; session-id-time=2191550824l; ubid-acbde=123-4567890-1234567; x-acbde=\"***\"; at-acbde=\"Atza|***-***-**_0x-***-***-***"; sess-at-acbde=\"***", "csrf": "2094313357" }
Mit dem Workaround von @Matten-Matten hat es bei mir auch funktioniert.
Nur was soll ich mit dem csfr Wert dann machen? -
@Diginix
ich finde den Datenpunkt nicht. Unter System Adapter....und dann wo/welcher ? -
@dslraser Der Expertenmodus muss an sein.
Dann unter:
system.adapter.alexa2.0 -
-
@Diginix
@leuchttrmhabe ich so, und dann ?
-
Bei mir läuft es mit workaround auch nicht, den Cookie gelöscht, den neuen laut Beschreibung geholt und eingetragen und neugestartet. Dann blinkt der adapter kurz gelb und wird sofort wieder rot.
Der Log gibt dann immer wieder das hier aus:host.raspberrypi 2019-06-18 21:58:48.367 error instance system.adapter.alexa2.0 terminated with code 0 (OK)
host.raspberrypi 2019-06-18 21:58:48.367 error Caught by controller[0]: at AlexaRemote.init (/opt/iobroker/node_modules/iobroker.alexa2/node_modules/alexa-remote2/alexa-remote.js:133:9)
host.raspberrypi 2019-06-18 21:58:48.367 error Caught by controller[0]: at getCookie (/opt/iobroker/node_modules/iobroker.alexa2/node_modules/alexa-remote2/alexa-remote.js:127:21)
host.raspberrypi 2019-06-18 21:58:48.367 error Caught by controller[0]: at getCookie (/opt/iobroker/node_modules/iobroker.alexa2/node_modules/alexa-remote2/alexa-remote.js:140:18)
host.raspberrypi 2019-06-18 21:58:48.366 error Caught by controller[0]: at AlexaRemote.checkAuthentication (/opt/iobroker/node_modules/iobroker.alexa2/node_modules/alexa-remote2/alexa-remote.js:738:14)
host.raspberrypi 2019-06-18 21:58:48.366 error Caught by controller[0]: at AlexaRemote.httpsGetCall (/opt/iobroker/node_modules/iobroker.alexa2/node_modules/alexa-remote2/alexa-remote.js:697:25)
host.raspberrypi 2019-06-18 21:58:48.366 error Caught by controller[0]: at Object.request (https.js:239:15)
host.raspberrypi 2019-06-18 21:58:48.366 error Caught by controller[0]: at Object.request (http.js:38:10)
host.raspberrypi 2019-06-18 21:58:48.366 error Caught by controller[0]: at new ClientRequest (_http_client.js:173:14)
host.raspberrypi 2019-06-18 21:58:48.366 error Caught by controller[0]: at ClientRequest.setHeader (_http_outgoing.js:498:3)
host.raspberrypi 2019-06-18 21:58:48.366 error Caught by controller[0]: at validateHeader (_http_outgoing.js:494:11)
host.raspberrypi 2019-06-18 21:58:48.364 error Caught by controller[0]: TypeError: The header content contains invalid characters
alexa2.0 2019-06-18 21:58:47.442 debug Schedule restart: 15 3 * * *
alexa2.0 2019-06-18 21:58:47.441 info starting. Version 2.2.0 in /opt/iobroker/node_modules/iobroker.alexa2, node: v8.11.3
host.raspberrypi 2019-06-18 21:58:46.205 info instance system.adapter.javascript.0 started with pid 1245
rpi2.0 2019-06-18 21:58:45.644 error No Value found for cpu_frequency
host.raspberrypi 2019-06-18 21:58:45.562 info instance system.adapter.alexa2.0 started with pid 1227
host.raspberrypi 2019-06-18 21:58:44.515 info Restart adapter system.adapter.alexa2.0 because enabled
host.raspberrypi 2019-06-18 21:58:44.515 error instance system.adapter.alexa2.0 terminated with code 0 (OK)
host.raspberrypi 2019-06-18 21:58:44.515 error Caught by controller[0]: at AlexaRemote.init (/opt/iobroker/node_modules/iobroker.alexa2/node_modules/alexa-remote2/alexa-remote.js:133:9)jemand eine Ahnung?
-
@dslraser
Na das was apollon77 geschrieben hat. Bei mir war aber ein csrf Wert drin.
Ich habe dann den Workaround von Matten Matten angewendet und den Cookie manuell neu gesetzt. Nun läuft die Instanz wieder.
Interessanterweise ist die zweite Instanz noch nie gelb gewesen und läuft mit dem alten Cookie weiterhin. -
@dslraser Dann gibt es unter RAW
die config und unter
"cookieData": {
findest du dann die Einträge -
@leuchttrm
@Diginixalles klar, ich bin am Handy und habe im RAW nicht weit genug runter gescrollt.
-
@Diginix
meine Instanz (habe nur eine) läuft auch immer noch, wollte mich nur schon informieren. -
@Diginix setz mal das tokendate auf einen aktuelleren Unix timestamp in Millisekunden. Denke der ist alt und daher gilt er nen neuen.
Und ja er setzt keinen neuen wenn csrf fehlt. Also bringt das nix.
Außer mal das zweite in meinen post die Frage ob man in den manuell geladenen Cookie Daten den csrf änderten kann und es immer noch tut.
-
@apollon77 ich habe jetzt mal den csrf bei der geänderten Config in der Main.js auf 12345678 geändert und den Adapter neu gestartet. Funktioniert immer noch.
-
@apollon77 sagte in IoBroker Alexa2 v2.0 ALPHA!!! Status GitHub Version!:
@Diginix setz mal das tokendate auf einen aktuelleren Unix timestamp in Millisekunden. Denke der ist alt und daher gilt er nen neuen.
Ich habe ja jetzt einen neuen Cookie manuell hinterlegt mit dem die Instanz wieder läuft. Soll ich dennoch das tokendate anpassen?
Das oben gepostete ist von 2019-06-18 4:07am (UTC). Also von heute morgen.