Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[padrino]

Schon sehr merkwürdig...
Gewartet, hat nix gebracht.
Also mal den Adapter neu gestartet, hat nix gebracht.
Nochmal gewartet, nix gebracht.
Adapter im Debug Modus gestartet, läuft. :man-shrugging:
Wie ein junger Gott, History wird schnell befüllt und kann drauf reagiert werden.

Ich frag mich ja, wie kann es, wenn es nicht läuft, zu dieser "queue" kommen, also dass History erst nicht und dann mit dem Wert davon befüllt wird?
Dass muss dann ja schon von Amazon zurück gehalten und dann versetzt gesendet werden, oder?

[reini84]

@padrino

ich habe im Moment dasselbe Problem.
Alexa aktualisiert sehr verzögert oder gar nicht.

[padrino]

@reini84
Nachdem der Adapter nun in Debug Modus problemlos lief, habe ich wieder auf normal umgestellt.
So läuft er nun seit einer Weile auch wieder.
Vermutlich/sichrt alles nur Zufall, aber versuch's doch auch mal. =)

[reini84]

@padrino

werde ich gleich mal probieren. Dank Dir

[reini84]

@padrino

scheint wieder alles zu funktioniert.

Unsicher ob es am Umschalten des Debug Modus lag. Aber läuft wieder vernünftig...

[padrino]

Hier wohl wieder hin...
Wie schaut's bei Euch aus?
Schon krass, in so Fällen merkt man erst, wieviel man "selbst gestrickt" hat... :relieved:

[Adenmara]

Bin eben heim gekommen, und habe das gleiche Problem.
Summary aktualisiert sich nicht automatisch, obwohl "push-connection established".

Ein manuelles triggern unter "alexa2.0.History.#trigger" funktioniert und gibt mir die letzten summarys aus.

[uwe72]

Habe leider das gleiche Problem. Im "alexa2.0.History.summary" Datenpunkt kommt kein Wert an. War die letzten Tage immer mal wieder so. War nun 4 Tage unterwegs, heute Abend/gerade funktioniert es konstant gar nicht.

Gibts hier einen Workarround/Erklärung?

Danke Euch und VG
Uwe

[Siragus]

Hallo, seit heute nachmittag nimmt der Alexa Adapter 2.23.2 keine Sprachbefehle mehr an. Es wird zwar der übliche Ton ausgegeben, aber das entsprechende Skript wird nicht getriggert.
Hatte jemand auch das Problem und konnte es beheben, oder weiß jemand woran es liegen könnte?
Unter Routines bleiben die jeweiligen Werte für die entsprechenden Sprachbefehle auch auf false und wechseln nicht auf true.
Dot und Alexa Adapter habe ich bereits neu gestartet.

[Digi-Bit]

Hallo,

Seit gestern Abend geht es hier auch nicht mehr, nur mit dem Trigger Botten ansonsten bleiben alle datenpunkte leer :(

mfg

Digi-Bit

[tomtaz]

Schließe mich dem an. Bei mir ist es genau das selbe.

[Gaspode]

Ich hab hier das gleiche Problem. Das Log nach einem Neustart sieht nach meinem Dafürhalten gut aus, es kommt aber anscheinend nix über die Push Verbindung rein.

[Dr. Bakterius]

Nach einem Neustart gestern, habe ich auch dieses Problem.

Entweder korrigiert das Amazon wieder oder vielleicht findet @apollon77 dafür eine Lösung. Sonst verliert der Adapter leider viel von seiner Expereance.

[padrino]

Tja, würde sagen, es sieht im Moment wohl schlecht aus... :(
Hier kann man zum Thema auch mitlesen:
https://github.com/Apollon77/ioBroker.alexa2/issues/1045

[Dr. Bakterius]

Man könnte das Problem mit einem kleinen Skript umgehen. Allerdings weiß ich nicht ob das empfehlenswert ist. Könnte sein, dass man zu viel Traffic verursacht und von Amazon gesperrt wird. Also bitte mit Vorsicht gebrauchen! Vielleicht kann auch @apollon77 was dazu sagen?

1. Den Datenpunkt alexa2.0.History.summary beschreibbar machen.

2. Folgendes Skript starten:
   

   Spoiler

   
   <block xmlns="https://developers.google.com/blockly/xml" type="on_ext" id="^rIr.5D_bV:8fdV7frvD" x="37.4" y="12.800000000000011">
   <mutation xmlns="http://www.w3.org/1999/xhtml" items="1"></mutation>
   <field name="CONDITION">any</field>
   <field name="ACK_CONDITION"></field>
   <value name="OID0">
   <shadow type="field_oid" id="`qlNghp0H;fE)lIJN{S">
   <field name="oid">default</field>
   </shadow>
   <block type="selector" id="CQ4bt~yUkDl/s9068VjK">
   <field name="TEXT">state[id=alexa2.0.Echo-Devices..Player.volume]</field>
   </block>
   </value>
   <statement name="STATEMENT">
   <block type="toggle" id="VHZIKyAEN6;{Ne^M}O#Q">
   <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="true"></mutation>
   <field name="OID">alexa2.0.History.#trigger</field>
   <field name="WITH_DELAY">TRUE</field>
   <field name="DELAY_MS">2000</field>
   <field name="UNIT">ms</field>
   <field name="CLEAR_RUNNING">FALSE</field>
   <next>
   <block type="control" id=",I5^Vg1)5R33iD%Nidb-">
   <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="true"></mutation>
   <field name="OID">alexa2.0.History.summary</field>
   <field name="WITH_DELAY">TRUE</field>
   <field name="DELAY_MS">2500</field>
   <field name="UNIT">ms</field>
   <field name="CLEAR_RUNNING">FALSE</field>
   <value name="VALUE">
   <block type="text" id="*O#xeS6JM7jEDMbF{HR@">
   <field name="TEXT"></field>
   </block>
   </value>
   </block>
   </next>
   </block>
   </statement>
   </block>
   

Edit: Skript geändert damit es nur nach einem Befehl aufgeführt wird. Das funktioniert (momentan noch).

[padrino]

@dr-bakterius
Auch, wenn es nicht wirklich viel spart, könnte man noch einfügen, dass die Befehle nur ausgeführt werden, wenn sich der Wert von Volume nicht geändert hat. :relieved:
(bei einem Volume change braucht man vermutlich nicht triggern ;))

[DJMarc75]

@dr-bakterius ich persönlich würde da eher auf den DP "muted" triggern, da, zumindest ich, diesen DP eigentlich nie nutze - dafür aber eigentlich den halben Tag Radio über Echo höre und dort dann auch hin und wieder das Volume ändere.

Habe für mich mal ein "Masterskript" erstellt und ohne den DP "summary" - funktioniert bestens wenn man den momentanen Umstand betrachtet ;)

[Dr. Bakterius]

@djmarc75 Ich setze den DP 'summary' deswegen zurück, weil er normalerweise ja von Alexa gelöscht wurde. Setzt man jetzt den gleichen Befehl hintereinander ab und triggert auf Änderung von 'summary', dann passiert nichts wenn der DP schon mit dem gleichen Inhalt gefüllt ist.

[DJMarc75]

@dr-bakterius sagte in Alexa2 wieder summary Probleme?:

Setzt man jetzt den gleichen Befehl hintereinander ab und triggert auf Änderung von 'summary', dann passiert nichts wenn der DP schon mit dem gleichen Inhalt gefüllt ist

Korrekt. Wenn man den DP als Trigger nutzt dann momentan eher auf aktualisieren.

So würde ich das übergangsweise lösen:

Damit braucht man den Summary nicht auf wtriteable stellen.

[DJMarc75]

Oder vll sogar noch besser:

Dieses Skript befüllt ja den Summary durch den oberen Trigger.
Danach wird der Wert vom Summary in einen eigenen DP geschrieben.

Somit kann man in anderen Skripten, in welchen man den Summary als Trigger verwendet, einfach diesen durch den eigenen DP ersetzen.

Nur so als Idee