NEWS
Alexa2 Adapter 3.18.x (BETA)
-
@djmarc75 Darum geht es ja nicht. Aber du stellst meine Antworten in Frage und willst Belege wie Datum und wer das editiert hat. Wozu? Bin ich unglaubwürdig? Traust du nur dem Entwickler?
Egal, bin nun raus bei dem Thema. -
@diginix sagte in Alexa2 Adapter 3.18.x (BETA):
Wozu? Bin ich unglaubwürdig? Traust du nur dem Entwickler?
ich habe @apollon77 geschrieben und nicht Dir... ich freue mich über jede Antwort aber trotzdem war meine Frage an den Entwickler gerichtet ! Bist Du der Entwickler oder schreibst Du in seinem Auftrag? Wenn ja dann super, wenn nein dann warte ich gerne auf die Antwort vom Entwickler ! Das macht glaub Sinn.
Lass uns da nicht streiten bitte. -
@djmarc75 sagte in Alexa2 Adapter 3.18.x (BETA):
Aber das lassen wir bitte @apollon77 entscheiden
Also, wenn es um den Datenpunkt für Do Not Disturb geht, der kann nicht Boolean sein, weil er auch Sekunden oder eine Uhrzeit enthalten kann.
Das ist entschieden und kommt vom Entwickler.kannst :
- true/false (bool oder string) senden für an/aus
- Zahl für dauer in sekunden
- String "hh:mm:ss" für enduhrzeit
-
@padrino ne, geht nicht nur um DND... geh mal alle DPs in dem Ordner durch...
sind alle so.
EDIT: ein paaaar sind so
EditEdit: eigentlich nur wenige, aber trotzdem ist das Verhalten von XXX nicht grad toll -
@djmarc75 Jetzt nal locker alle beide
@Diginix hat aber recht. Dieser Datenpunkt ist "mixed" weil er erlaubt verschiedene Dinge zu steuern:
- Boolean true/false (oder "true", "false") für an/aus
- Zahl in Sekunden kleiner als 12h oder so für "Einschalten so lange" (wenns mal tut bei Amazon)
- String "HH:mm:ss" für "Einschalten bis Uhrzeit" (wenns mal tut bei Amazon)
Damit ist das in Admin nicht so schön zu nutzen ... aber am Ende macht das doch eh keiner via Admin ausser zum testen. Skripte können aber alles tun.
Im Expertenmodus im Admin kann man auch den Datentyp wählen
-
@djmarc75 Also es sollte ausschliesslich doNotDisturb so sein (wenn ich recht erinnere), sonst sollte der Datentyp überall so sein wie er soll. Wenn haste noch gefunden?
-
@apollon77 Ja, und hiermit möchte ich mich bei @Diginix entschuldigen.
-
Servus, da man ja in der APP das "Aktivierungswort" ändern kann erschliesst sich mir die Frage ob das evtl auch im Adapter realisiert werden kann ?
Greets -
@djmarc75 Ja könnte man ... aber warum? Was ist der Usecase?In meinen AUgen ist das so ein "Setzt man einmal und ändert man nie wieder" Thema
-
@apollon77 sagte in Alexa2 Adapter 3.18.x (BETA):
Was ist der Usecase?
Na "mein" Usecase wäre da dass ich zumindest in der VIS mir anzeigen kann auf welches Wort das jeweilige Device reagiert.
Habe z.B. im Büro und im Wohnzimmer je 2 Echos mit unterschiedlichem Aktivierungswort - frag nicht warum - ich weiss es auch nicht -
@djmarc75 Naja das wäre ja nur die Anzeige ... Mach doch mal nen Feature Request ... wenn ich mal wieder Zeit habe schaue ich mal
-
@apollon77 sagte in Alexa2 Adapter 3.18.x (BETA):
Naja das wäre ja nur die Anzeige
Wäre mir ausreichend und
@apollon77 sagte in Alexa2 Adapter 3.18.x (BETA):
Mach doch mal nen Feature Request
wird gemacht
-
@apollon77
Inzwischen sieht man unter "Aktivitäten" in der App ja auch von wem das Kommando gesprochen wurde.
Wäre es evtl. möglich auch die Info in einen History Datenpunkt zu packen?
Oder kommt die nicht an die App zurück? -
@padrino Hatten wir schon zwei mal diskuiert ... die Info steht erst mit einem Verzug von 5-10s zur Verfügung. Ergebnis war das niemand so lange mit nem "History"-Trigger warten will Und nachträglich macht auch keinen Sinn.
-
@padrino sagte in Alexa2 Adapter 3.18.x (BETA):
@apollon77
Inzwischen sieht man unter "Aktivitäten" in der App ja auch von wem das Kommando gesprochen wurde.
Wäre es evtl. möglich auch die Info in einen History Datenpunkt zu packen?
Oder kommt die nicht an die App zurück?@apollon77 Fände es auch gut den menschlichen Befehlsgeber in einem neuen DP mit zu bekommen.
Selbst wenn es 5-10s dauert bis dieser bekannt wäre. Bei Kindern im Haushalt kann es schon hilfreich sein Dinge darüber dann nicht auszuführen. Normale Aktoren will man wahrs. in Echtzeit schalten. Aber bei sicherheitskritischen Befehle für Schlösser oder TV an/aus könnte ich damit leben diese verzögert auszuführen wenn ich dafür aber wüsste dass es von einer Person kam, die es darf. -
@diginix naja bringt mich zurück zur Frage Wie man das transportieren will das man es auch nutzen kann. Mit mehreren Geräten könnten auch Dinge parallel passieren. Haben nur ein set an History States. Mal von der quasi verdoppelung der requests abgesehen. Nicht so easy umzusetzen
-
@apollon77 Ok, wenn man es nicht eindeutig mit dem Befehl in Verbindung bringen kann, ist es tatsächlich wertlos.
-
@diginix naja sagen wir so: Ich hatte bisher noch keine zündende Idee wie das sinnvoll gehen sollte, die auch für nich so erfahrene User irgendwie passt
-
@apollon77 Ggf ein History DP pro user. K.a. ob du eine ID oder den Username bekommst.
Entw. man triggert dann über alle user History DP oder man nutzt den generischen und prüft dann nur ob der Befehl zB nicht bei dem user drin steht, der ihn nicht darf oder umgekehrt.
Oder ein JSON mit user + befehl in einem DP. Wer das in Skripten verarbeiten will, muss eh bissel Ahnung haben. Wer es nicht braucht ignoriert die DPs. -
@apollon77 sagte in Alexa2 Adapter 3.18.x (BETA):
@padrino Hatten wir schon zwei mal diskuiert ... die Info steht erst mit einem Verzug von 5-10s zur Verfügung.
Davon weiß ich nix.
@apollon77 sagte in Alexa2 Adapter 3.18.x (BETA):
... Mal von der quasi verdoppelung der requests abgesehen. Nicht so easy umzusetzen
Ok, wenn das mehr traffic/overhead macht und schwierig zu nutzen ist, dann ist natürlich doof.
Sonst hätte ich gesagt, rein packen und wer es nutzen möchte, muss seinen Weg eben selbst finden.Könnte denn der iobroker (custom) skill diese Info nicht (schneller) zur Verfügung stellen?
Skills soll man doch, wenn ich das richtig in Erinnerung hab', inzwischen darauf reagieren lassen können?