[37_echodevice] Amazon Echo Modul (nicht Alexa)

Begonnen von michael.winkler, 12 Januar 2018, 18:20:12

Vorheriges Thema - Nächstes Thema

michael.winkler

Zitat von: Stippy19 am 20 Februar 2018, 19:38:55
Könnte mal einer Versuchen, ob ihr mit falschem Browser-Agent den Wecker seht? (kann das zusammenhängen?) Musik funktioniert, nur Wecker Reading wird nicht aktualisiert.
Auf Seite 1 gibt es die Version 0.0.24.


# 2018-02-22, v0.0.24
#
# v0.0.24
# - BUGFIX:  Timer Readings
#

ThoTo

KNX | MQTT | Docker | Sonos | FHEMapp

"Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher." (Albert Einstein)

michael.winkler

Zitat von: ThoTo am 22 Februar 2018, 13:29:33
v0.23

LG Thomas
ok, eigentlich sollte das Modul den FHEM Server nicht mehr blockieren. Bitte beim nächsten mal das Amazon Device auf Verbose 5 stellen. Wenn dann das LOG dauerhaft gefüllt wird, wäre es interessant welche Meldungen dort erscheinen. Bitte dann das Log Mal zusenden.

Stippy19

Zitat von: michael.winkler am 22 Februar 2018, 13:27:20
Auf Seite 1 gibt es die Version 0.0.24.


# 2018-02-22, v0.0.24
#
# v0.0.24
# - BUGFIX:  Timer Readings
#


Hey Michael! Super, vielen Dank dir.
Kann bestätigen: Wecker Reading funktioniert wieder wie gewünscht!

Immer wieder fasziniert von eurer "black magic" die ihr hier erfolgreich betreibt =)

Steffen

Guten Morgen!

Kann man den Intervall von "voice" irgendwie einstellen, ich bin dabei das mit einem Spracherkennungsmodul zu nutzen aber
die Abfragen kommen wohl in einem ca. 30sek Takt?!

Mfg Steffen

MadMax-FHEM

Für Sprachauswertung ist das (eher) nicht geeignet.

Es dauert ja schon bis das in der App (Historie) und im Webinterface ankommt.
Erst danach kann es dann überhaupt vom Modul abgefragt und angezeigt werden...

D.h. zuerst mal müsste es auf Amazon-Seite schneller werden...

Aber selbst dann.
Mit welchem Intervall willst du pollen (lassen)!?
Selbst eine Sekunde (drunter wird wohl nicht wirklich gehen) ist bei Sprachsteuerung "ewig"...

Geht eigentlich nur (vernünftig) mit alexa-fhem oder ha-bridge...
Oder per IFTTT...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Steffen

Guten Morgen,

Ich kann mich erinnern das in einer sehr frühen Version das reading super schnell in Fhem auf tauchte, da gab es auch noch das "attr interval". Ich nutze ja auch alexa-fhem aber zu frieden bin ich damit nicht so recht.

3-5 Sekunden würden ausreichen!

Das Sprachmodul ist ebend flexibler und habe damit mehr möglichkeiten.

Deswegen frage ich ja ob es noch die möglichkeit gibt das wieder so ein zustellen?!

Mfg Steffen

michael.winkler

Zitat von: Steffen am 23 Februar 2018, 07:51:54
Guten Morgen,

Ich kann mich erinnern das in einer sehr frühen Version das reading super schnell in Fhem auf tauchte, da gab es auch noch das "attr interval". Ich nutze ja auch alexa-fhem aber zu frieden bin ich damit nicht so recht.

3-5 Sekunden würden ausreichen!

Das Sprachmodul ist ebend flexibler und habe damit mehr möglichkeiten.

Deswegen frage ich ja ob es noch die möglichkeit gibt das wieder so ein zustellen?!

Mfg Steffen
https://mwinkler.jimdo.com/smarthome/eigene-module/echodevice/#Attribute

awel

Account-device, Login-Versuche bei Fehler reduzieren

Hallo,
bei einem Login-Fehler des Account-Devices versucht das Modul (nach meinem Protokoll) ca. alle 60 Sekunden einen neuen Login-Versuch.
Die Attribute "disable" und "intervalsettings" ändern -zumindest im laufenden Betrieb- daran nichts.

Gibt es eine andere Möglichkeit, die Versuche im Fehlerfall zu reduzieren?

Hintergrund:
Da die Verbindung bei mir nicht absolut stabil/connected ist und bei Abbruch i.d.R. erst nach längerer Zeit wieder funktioniert, würde ich gerne das account-device überwachen und z.B. über ein notify oder doif den Zeitraum zwischen den nächsten Anmeldeversuchen nach x Fehlversuchen auf einen -nach Möglichkeit einstellbaren- größeren Wert setzen, um Traffic und Log-File zu entlasten; ich habe auch den Eindruck, dass Wartezeiten eine Neuanmeldung erleichtern und ständige Versuche im Minutentakt nicht förderlich sind. Andererseits sollten die ersten Login-Versuche nach einem Scheitern zügig erfolgen (in der Web-App habe ich mit aktuellem Firefox hin und wieder auch 2 Versuche gebraucht).
Optimal wäre aus meiner Sicht ein Attribut ähnlich "intervalsettings" mit dem man die Verzögerung zwischen den nächsten Login-Versuchen einstellen kann.

Ist das sinnvoll und machbar?

Danke und vG
Achim

jojo61

Hallo

das was awel sagt ist mir auch aufgefallen.  Evtl wäre es sinnvoll das intervall bei einem erfolglosen login Versuch immer zu verdoppeln bevor man es wieder versucht (bis zu einen evtl. maximum von ein paar Stunden) . Ich hatte gestern auch das Problem das mein Cookie "kaputt" gegangen ist. Dann habe ich das Echo Device gelöscht und nach 3 Stunden wieder angelegt. Dann ging es auf anhieb.  Amazon scheint zu viele erfolglose Anmeldeversuche nicht zu mögen.

mfg
Jojo61

miche

Ich bin seit heute auch wieder disconnected und beim amazon login kam wieder die captcha Abfrage.
Ich denke auch es liegt an den vielen Anmeldeversuchen. Kann das sein?

TomLee

Mal so zu Info:

Hatte auch heute wieder ein diconnect (nutze noch v0.0.20), das oft Sonntags so, nicht nur bei mir auch bei anderen Usern, hab ich so über die Monate festgestellt. Das war auch schon bei Markus so.
Zufällig hatte ich auch gerade, weil mein TV-Modul einen Fehler zeigt, einen restart gemacht und war auch direkt wieder connected. Sonst kümmere ich mich gar nicht mehr um die disconnects, hatte auch schon gleich hier gepostet, war aber kurze Zeit später immer wieder eingeloggt.

Übrigens läuft auf einer entfernten Instanz die ich 'verwalte' noch v0.0.13 seit Michael sie veröffentlicht hatte ohne Probleme. Hier zeigt das Log 3-4 disconnects im Februar und 2-3 im Januar (aber nicht Sonntags) und das Modul ist immer paar Minuten später ohne zutun wieder verbunden.

Gruß

Thomas

MadMax-FHEM

#372
Hallo Michael,

leider ist dieser oder ein ähnlich lautender Fehler heute Nacht wieder aufgetreten:

https://forum.fhem.de/index.php/topic,82631.msg769020.html#msg769020


2018.02.25 01:18:21 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:21 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:21 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:21 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:22 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:22 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:22 2: RaspBee: http request failed: read from http://192.168.1.90:80 timed out
2018.02.25 01:18:22 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:22 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:22 1: Timeout for SYSMON_blockingCall reached, terminated process 27715
2018.02.25 01:18:22 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:22 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
2018.02.25 01:18:22 2: [echodevice_ParseAuth] echoIODev: connection error write to https://layla.amazon.de:443 timed out
Unmatched ) in regex; marked by <-- HERE in m/lpl:hv87h6@`46) <-- HERE gb:/ at ./FHEM/37_echodevice.pm line 2571.


Es gab wohl tatsächlich Unterbrechung ins Internet (evtl. Router Neuverbindung / analysiere ich nachher)...

Version des Moduls (laut version-Ausgabe von fhem):

37_echodevice.pm             15724 2017-12-29 22:59:44Z michael.winkler

Wobei sich das wohl die letzten Male nicht mehr geändert hat...

Version laut Datei-Header: 0.0.23


##############################################
#
# 2018-02-19, v0.0.23
#
# v0.0.23
# - BUGFIX:  Nested quantifiers in regex
# - CHANGE:  Reading version
#
# v0.0.22
# - FEATURE: Attribut browser_useragent https://mwinkler.jimdo.com/smarthome/eigene-module/echodevice/#Attribute
#
# v0.0.21
# - CHANGE:  Header
#
# v0.0.20
# - CHANGE:  Cookie erstellen auf nonBlocking
#            Cookie erstellen Timeout 10 sekunden


Aber nach Neustart gleich wieder connected... :)

EDIT: so dann auch gleich auf die 0.0.24 hochgerüstet.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

Nach dem Hochrüsten immer noch gleich wieder connected und scheint auch soweit zu laufen.

Allerdings bekomme ich beim Starten (shutdown restart / aber auch reload) folgendes im Log:


2018.02.25 17:11:12 1: echoIODev: json evaluation error malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "Invalid authenticati...") at ./FHEM/37_echodevice.pm line 1494.

$VAR1 = 'Invalid authentication token!';


Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

ToKa

Hallo zusammen,

jetzt hat es mich auch erwischt, seit heute Mittag wird mein Log zugemüllt.

2018.02.25 21:58:35.588 1: ZS_zs_AC_echodevice: json evaluation error
$VAR1 = '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Bad request.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: xxxxxxxx
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>';


Ich muss dazu erwähnen, dass ich heute auch Probleme mit VoIP hatte und hier alles einmal neustarten musste.

Leider lässt sich das Account device nicht mit dem disable attribut Sarah hindern immer weiter ein Connect zu probieren.

Beste Grüße
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight