Folgendes Problem:
- Alexa setzt meinen Weckzeit-Dummy sagen wir auf 06:15 => funktioniert bestens
- Per wie-auch-immer-aber-nicht-Alexa setze ich meine Weckzeit auf sagen wir 06:09
- Natürlich wird der geänderte Wert auch in den Weckzeit-Dummy geschrieben
- Anfrage per Alexa-Fhem liefert reproduzierbar den alten Wert, also 06:15 :( :(
Wieso wird das, und wo, gecacht ?
LG
pah
alexa-fhem hängt per longpoll an den events.
d.h. das wie auch immer muss ein event erzeugen. setreading ist geeignet. setstate nicht.
schau mal ob es für das setzen jeweils ein event im event monitor gibt und ob auf der alexa konsole eine ausgabe für dieses event erzeugt wird.
gruss
andre
Habe ich inzwischen auch schon gefunden, hatte readingsSingleUpdate ohne ausgelöstes Event genommen, um eine Schleife bei der FHEM2FHEM-Kommunikation zu vermeiden.
LG
pah
Hallo Andre,
Reeeeeeespekt und Danke für Deine Arbeit :-* :-* :-*
Hab nun smart home, als auch custom skills hinbekommen. Meine Erfahrungen und Verbesserungsvorschläge fürs Wiki poste ich später.
Ich hab das gleiche Problem wie pah bei einem einfachen schalter. Der Status wird mit Start des scripts gecached, aber nie geändert. Weder durch schalten über alexa, noch normales schalten.
Einzige Idee: Ich hatte Berechtigungsprobleme. Die sind größtenteils gelöst. Allerdings kann ich alexa-fhem aus FHEM nur starten, wenn ich bereits ein alexa-log mit Berechtigung 664(dialout/fhem) vorher anlege. Sagt Dir das was ? Ist da ein Zusammenhang ?
Konfiguriert habe ich 1:1 wie im Wiki beschrieben.
Danke&Grüße Markus
wie oben geschrieben: schau ob es events im event monitor gibt und dann schau ob sie auf der alexa-fhem konsole zu sehen sind.
wenn nein -> du musst events erzeugen.
wenn ja -> genaues beispiel posten.
zu den berechtigungen: ich vermute alexa-fhem darf in deinem log dir nicht schreiben. dort die berechtigungen anpassen.
klar erzeugt der schalter events, aber weder im Log, noch bei Start von alexa-fhem in der Konsole tut sich was bei einem event. :-\
response :{"version":"1.0","sessionAttributes":{},"response":{"outputSpeech":{"type":"PlainText","text":"Ich habe kaminlicht ausgeschaltet."},"shouldEndSession":true}}
**** Received Directive: {"version":"1.0","session":{"new":true,"sessionId":"amzn1.echo-api.session.xyz","application":{"applicationId":"amzn1.ask.skill.xyz"},"user":{"userId":"amzn1.ask.account.xyz"}},"context":{"AudioPlayer":{"playerActivity":"IDLE"},"System":{"application":{"applicationId":"amzn1.ask.skill.xyz"},"user":{"userId":"amzn1.ask.account.xyz"},"device":{"supportedInterfaces":{"AudioPlayer":{}}}}},"request":{"type":"IntentRequest","requestId":"amzn1.echo-api.request.xyz","timestamp":"2017-02-19T21:05:50Z","locale":"de-DE","intent":{"name":"StatusIntent","slots":{"preposition":{"name":"preposition"},"Room":{"name":"Room"},"Device":{"name":"Device","value":"kaminlicht"}}}}}
[2/19/2017, 10:05:51 PM] IntentRequest
[2/19/2017, 10:05:51 PM] StatusIntent
[2/19/2017, 10:05:51 PM] [FHEM] executing: http://192.168.178.50:8083/fhem?cmd=%7B$defs%7BAlexa%7D-%3E%7B%22active%22%7D%20=%201%7D&XHR=1
[2/19/2017, 10:05:51 PM] [FHEM] executing: http://192.168.178.50:8083/fhem?cmd=setreading%20Alexa%20intent%20IntentRequest%20StatusIntent&XHR=1
[2/19/2017, 10:05:51 PM] [FHEM] executing: http://192.168.178.50:8083/fhem?cmd=%7B$defs%7BAlexa%7D-%3E%7B%22active%22%7D%20=%200%7D&XHR=1
[2/19/2017, 10:05:51 PM] 0
[2/19/2017, 10:05:51 PM] [FHEM] caching: On: 1 (as number; from 'on')
response :{"version":"1.0","sessionAttributes":{},"response":{"outputSpeech":{"type":"PlainText","text":"kaminlicht ist an"},"shouldEndSession":true}Zitatzu den berechtigungen: ich vermute alexa-fhem darf in deinem log dir nicht schreiben. dort die berechtigungen anpassen.
Jo, hab nun auf 664 geändert und schon kann der user pi auch ein neues file anlegen. Hätte das vorher schon auf 664 sein müssen ?
und die events sind auch im event monitor zu sehen?
was ist das für ein device? wie wird der status gesetzt?
ganz simpler IT m. V1 Protokoll. events über FB, alexa, FHEM mit set Kaminlicht on :-\ Alles im event monitor sichtbar. Weitere Schalter(deren events) ändern auch nicht den Status.
Und dann fiel mir ein, dass die TRX-Module nicht "richtig" programmiert sind. Test mit FS20 und... voila. Heißt also, dass wir mit den TRX-Modulen Probleme haben :'( Und Willy ist vom Erdboden verschluckt :'( :'( :'(
Das es Probleme mit den THX Modulen gibt ist schon länger bekannt. Es gab einige Versuche der Anpassung. Wie weit das gediegen ist vermag ich aber nicht zu sagen. Gehört aber auch nicht hier her.
@KölnSolar ich habe gerade nochmal geprüft sowohl IT V3 als auch V1 wird bei mir mit korrektem Status erkannt und über Alexa/Echo ausgegeben und auch geschaltet.
Hast du irgendwas spezielles als Typ für die Zwischenstecker hinterlegt (zeig doch mal ein list)?
das problem mit den fehlenden events ist im IT modul seit einiger zeit behoben. im TRX modul noch nicht.
d.h. wenn die device über einen CUL/miniCul/... laufen geht es. wenn sie über ein RFXtrx laufen geht es nicht.
ach ja: noch etwas: man kann im homebridgeMapping nocache=1 setzen. dann werden die werte immer per ReadingsVal von fhem geholt. das ist aber nicht besonders effizient und nur eine notlösung.
edit: kommando zurück. das geht aktuell nur bei homebridge-fhem. kommt für alexa-fhem auch noch.
@Master_Nick: wie Andre schon schrieb: CUL mit IT funktioniert, RFXTRX nicht, wenn das Schalten mit einem set-Befehl(Web, notify, alexa...) erfolgt :'(
Danke Andre
;) War das nicht zeitlich gesehen nach meiner Aussage :-) ?
Naja schade jedenfalls, aber so einen Cul 433 hast du dir doch schnell gebaut..... 12 € in die Hand genommen 3 Wochen Lieferzeit und fertig?