LBS19000809 - Alexa Control

[tger977]

Hallo zusammen,

kurze Zwischenfrage, da mich die neuen Weckerfeatures auch interessieren: Geht der LBS in aktueller Version trotz der Umstellung auf PHP7 auch mit der alten CentOS6 und PHP5 Installation?

Auf CentOS7 + PHP7 kann ich derzeit noch nicht umstellen da der DMX 19000940 Baustein leider mit PHP7 nicht kompatibel ist und der Autor wohl auch nicht mehr hier im Forum unterwegs ist...

[trollmar]

Läuft bei mir auch noch unter Cent OS 6.5 und 1.64

[ThorstenGehrig]

Hi Jonofe
ich möchte nochmal auf das (manuelle/gezielte) Löschen von Weckern zurückkommen.
Ich könnte entweder gebrauchen das man alle deaktivierten Wecker löscht (eine art Wecker-clean-up) - oder das man Wecker einzeln gezielt löschen kann.
Generell geht das wohl so

[B]curl 'https://alexa.amazon.de/api/notifications/A4ZP7ZC4PI6TO-G0913L05939104QK-34fd473e-7259-36a2-80f8-5215add60796' -X DELETE ... (der rest wie üblich)[/B]

Wobei der A4ZP.... teil die ID des Weckers ist die man über die JSON Abfrage ja leicht exportieren kann.
Gibts da ne chance das du das irgendwann mit Einbaust?

Gruß
Thorsten

[jonofe]

Generell geht das wohl so

Das ist klar, ist ja schon Teil des LBS, nur nicht selektiv ausführbar für eine ID.

Im nächsten Update wird es möglich sein selektiv (IDs) Wecker zu löschen/aktivieren/deaktivieren.
Außerdem wird man dies auch für alle Wecker machen können.
Je nach Wert an E40 werden bezieht sich dass dann auf den aktuellen Echo (E40=2, E10=Echoname) oder auf den gesamten Amazon Account (E40=1).

[trollmar]

Kannst auch mal drüber nachdenken ob du anbieten kannst wann der nächste Wecker ist? Das geht in Code sicherlich viel einfacher als im Logikeditor

[Brick]

Sagt mal, geht bei euch der Status update (manuell)... ich hab bei mir ein Update Intervall von 10 Sekunden eingestellt.. das reicht normal.
Nur wenn man auf Play/Pause drückt soll der Status sich schneller ändern, damit man in der Visu gleich mitbekommt, das der Befehl umgesetzt
wurde. (da will man ja nicht bis zu 10 sec warten)
Jetzt hab ich das Updateintervall auf 0 gesetzt (wie in der Beschreibung) leider ändert sich nichts. Update findet immer noch zyklisch statt.

Stell ich mich blöd an ?

[trollmar]

Stell doch mal auf 2 Sek.

[jonofe]

Das geht in Code sicherlich viel einfacher als im Logikeditor

Das ist mir ehrlich gesagt etwas "too much", denn das ist nicht wirklich trivial.
Wenn mir jemand den Code beistellen will, dann kann ich ihn natürlich gerne einbauen.
Annahme dafür ist, dass in der Variable $notifications ein array aller notifications des Amazon Accounts stehen.
Dann muss die Funktion "nur noch" das array durchlaufen und ein Regelwerk bauen, wie der nächste Alarm bestimmt wird.

[Brick]

Stell doch mal auf 2 Sek.

Dauert trotzdem recht lang.. denk die Abfrage dauert hier einfach insgesamt zu lang. (ca. 5-7 sec)
Deswegen bringt mir das manuelle Update und das runterstellen auf 2 sec. hiern nichts.

[windy75]

Hallo, Alexa-Control geht leider immer noch nicht.
jonofe : hatte Dich so verstanden, dass der LBS prüft, ob ein Cookie-File vorhanden ist, falls nein, loggt er sich ein und generiert eines.
Ich hab' das File gelöscht und im Log findet sich folgendes:

 [TABLE="class: log, border: 0, cellpadding: 0, cellspacing: 0, width: 0, height: 12"]
 	 		[TR]
 			[TD]2020-01-14 18:04:35[/TD]
 			[TD]470576[/TD]
 			[TD]11652[/TD]
 			[TD]debug[/TD]
 			[TD]EXE19000809 [v1.12]: Importing session id from cookie file...[/TD]
 		[/TR]
 		[TR]
 			[TD]2020-01-14 18:04:35[/TD]
 			[TD]473298[/TD]
 			[TD]11652[/TD]
 			[TD]debug[/TD]
 			[TD]EXE19000809 [v1.12]: File: /usr/local/edomi/www/data/liveproject/lbs/EXE19000809.php | Error: 8 | Line: 1250 | Undefined variable: session_id[/TD]
 		[/TR]
 	 [/TABLE]

Log soweit nachvollziehbar, da zwar eine Cookie-Datei erzeugt worden ist, die ist aber leer. Loggt sich wohl nicht ein ...
LBS läuft im Auto-Mode - ein Login auf alexa.amazon.de funktioniert einwandfrei.

An anderer Stelle hattest Du mal die Frage gestellt, ob mit dem gleichen Account auf unterschiedlichen Edomi-Servern gearbeitet wird.
Ich hatte den Zusammenhang bisher nicht gesehen - hatte aber sowas ähnliches am Laufen: aus früheren Zeiten quasi eine Art "Alexa-Control" über OpenHab und dem Alexa-Echo-Control-Binding abgebildet. Mit denselben Amazon-Account-Daten. Der lief jetzt die ganze Zeit quasi leer noch mit (ist aber nicht mehr angetriggert worden. Jetzt habe ich das OpenHab-Binding deaktiviert und gelöscht - seither tut der davor einwandfrei gelaufenen LBS im Edomi nicht mehr mit den oben beschriebenen Symptomen.

Was kann ich denn noch tun, um quasi einen Reset des LBS samt Amazon-Login hinzubekommen?

[trollmar]

Das ist mir ehrlich gesagt etwas "too much", denn das ist nicht wirklich trivial.
Wenn mir jemand den Code beistellen will, dann kann ich ihn natürlich gerne einbauen.
Annahme dafür ist, dass in der Variable $notifications ein array aller notifications des Amazon Accounts stehen.
Dann muss die Funktion "nur noch" das array durchlaufen und ein Regelwerk bauen, wie der nächste Alarm bestimmt wird.

Versteh ich!

Wäre es aber nicht möglich das ganze auch "einfacher" zu machen?

Hier mal ein Screenshot der bisherigen Logik.

beispiel.jpg

Wenn man den nächsten Alarm möchte wäre es folgendes:


Annahme es gibt max 10 Wecker für alle Devices.
Gefiltert mit deinem JSON Filter mit "status:ON"

Jetzt müsste man einen kleinen LBS haben der prüft ob es ein recurringPattern gibt.
Davon gibt es ja wohl 10 stück. Gibt es keinen recurringPattern geht der JSON wieder 1:1 aus dem LBS raus.

Gibt es einen müsste man Anhand des recurringPattern und dem Value "alarmDate" und dem aktuellen Datum das value "alarmDate" modifizieren.
Anschließend würde der modifizierte JSON ausgegeben.

In meiner Logik wird dann aus dem JSON das alarmDate extrahiert und in Epoch gewandelt.
Anschließend werden alle EPOCH zeiten verglichen und das kleinste EPOCH genommen um den nächsten Alarm zu haben.


Das lässt mir halt keine Ruhe

LG

[ThorstenGehrig]

Was passiert denn wenn in deiner Logik ein Wecker auf OFF gestellt wird? Wenn der Filter NICHTS ausgibt bleibt der alte Wert ja vorhanden und die (nicht mehr gültige) Zeit auch...?

@Jonofe: SUUUPER. Ich warte dann mal gespannt und geduldig auf die nächste Version :-)

[ThorstenGehrig]

Hi
@Trollmar: ich hab mir mal was gebastelt das dich vielleicht Interessieren könnte.
"skalierbare" Logik die die erste Weckzeit heraussucht.
Eingang: iKO1...5 für die verschiedenen (aktiven) Weckzeiten.
Vorgehensweiße: Baustein 15000000 (Logikberechnung).
Formel an E1: date("H:i:s Y-m-d ", ((($a<$b)*strtotime($a))+(($a>=$b)*strtotime($b))) ) ;
Diese Formel gibt an A1 die frühere Zeit aus. Eingänge sind E4 ($a) und E5 ($b)
Im ersten Baustein gibt man iKO Weckzeit 1 und iKO Weckzeit 2.
Im zweiten Baustein an E4 das Ergebniss vom Vorherigen Baustein, E5 mit Weckzeit 3
Im dritten Baustein an E4 das Ergebniss vom Vorherigen Baustein, E5 mit Weckzeit 4 usw.

Hört sich komlizierter an als es ist... - aber ein Bild sagt mehr als tausend Worte.
Diese Logik liefert als Ergebniss die früheste Weckzeit aus 5 Weckern:
weckzeit.png

Ich hoffe es hilft jemanden :-)

Gruß
Thorsten

[trollmar]

...

Hört sich komlizierter an als es ist... - aber ein Bild sagt mehr als tausend Worte.
Diese Logik liefert als Ergebniss die früheste Weckzeit aus 5 Weckern:

ThorstenGehrig
Danke fürs teilen!

Bau ich mal nach

[ThorstenGehrig]

Full-quotes sind nicht schön...
PS: du musst natürlich zusehen das "leere felder" auf einen hohen Wert sind. Beim mir setzt ein "status=OFF" den Stamp auf "23:59:59 2030-01-01"