UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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

[Dr. Bakterius]

@djmarc75 sagte in Alexa2 wieder summary Probleme?:

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

Das klappt sicher auch gut. Wenn man aber eine größere Anzahl an Skripten hat die auf 'summary' triggern, ist das nicht wenig Arbeit. :neutral_face:

[Meister Mopper]

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

größere Anzahl an Skripten hat die auf 'summary' triggern

Ja, aber der wird ja mit Verstand an einem Punkt der eindeutigen Deklaration liegen.

[padrino]

@djmarc75 sagte in Alexa2 wieder summary Probleme?:

Damit braucht man den Summary nicht auf wtriteable stellen.

Aber das ist doch nur für den Admin, oder?
Also, ich schreib hier per Script problemlos Sates die "nicht schreibbar" sind... :thinking_face:

[DJMarc75]

@padrino sagte in Alexa2 wieder summary Probleme?:

problemlos Sates die "nicht schreibbar" sind

na dann schau auch mal in Dein LOG rein wenn solch ein DP gesetzt wird.

[padrino]

@djmarc75
Also im Admin4 stand da nie was, bin ich mir recht sicher... :thinking_face:
Loglevel "info", nicht höher...
Daher hielt ich das immer für ok, hab da aber schon ewig nimmer (bei neuem Admin) nach geschaut...

[2hot4you]

@siragus sagte in Alexa Adapter nimmt keine Befehle an:

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.

Habe seit gestern das gleich Problem mit meinem Adapter 3.23.2. Es werden keine Sprachbefehle mehr unter History/summary angezeigt.
Ohne IO Broker funktioniert alles. Habe den IO Broker auch schon komplett neu gestartet, keine Besserung.

[haselchen]

@Homoran
@Negalein

Diesen Thread bitte dorthin verschieben:

https://forum.iobroker.net/topic/64495/alexa2-wieder-summary-probleme/27

THX

[Rushmed]

Es gibt schon ein Issue auf Github dazu.