Amazon Echo (Alexa) mit IP-Symcon verbinden

Ich habe alle neuen Einladungen versendet.

[i]Für die, die sich immer wieder neu in der Liste anmelden: Ich kann euch nur genau ein mal hinzufügen. Wenn dies passiert ist, könnt ihr den Invite Link im ersten Beitrag nutzen. Ein erneutes Anmelden in der Liste versendet keinen neuen Invite.

[/i]​paresy

Die Szenen in aktueller Form sind noch nicht deaktivierbar. Hier kommen aber noch deaktivierbare Szenen bei denen dann zwei Skripte angegeben werden. Es kann auch zweimal das gleiche Skript angegeben werden, und mit $_IPS[‚VALUE‘] ausgewertet werden, ob die Szene aktiviert oder deaktiviert wird.

Das ist bisher aber noch nicht drin. Da setze ich mich aber zeitnah mal ran.

Hallo,

Ich habe in der Gruppe Wohnzimmer ein Thermostat (Homematic, SET_TEMPERATURE) und ein Thermometer (Homematic, TEMPERATURE). Diese werden auch in Alexa als unterschiedliche Komponenten erkannt (Thermostat by IP-Symcon, Temperature Sensor by IP-Symcon).
Beide Komponenten einzeln lassen sich auch ansteuern/abfragen (sie haben unterschiedliche Namen).

Frage ich aber die Gruppe „Wohnzimmer“ nach der Temperatur, antwortet Alexa „Es gibt mehr als ein Thermostat im Wohnzimmer…“
Sage ich „Setze Wohnzimmer auf 21 Grad“, dann funktioniert das.
Frage ich auf Wieviel grad Wohnzimmer eingestellt ist, antwortet Alexa wieder „Es gibt mehr als ein Thermostat im Wohnzimmer…“
Es gibt aber definitiv nur 1 Thermostat in der Gruppe, das andere ist der Sensor.

Scheint mir als ob Alexa oder der Skill das nicht sauber unterscheiden kann?!? Oder sitzt das Problem vor dem Bildschirm? :smiley:

Danke Euch!

Gruß, Lutz

Hallo Lutz,

du hast nichts falsch gemacht, hier liegt ein Fehler bei Alexa vor. Den habe ich auch schon bei Amazon gemeldet, aber bisher wurde der wohl nicht gefixt: Groups with thermostat and temperature sensor do not enable proper checking for temperature - Forums

Wenn du dich im Wohnzimmer befindest und direkt nach der Temperatur fragst, dann funktioniert es allerdings. Das Problem tritt nur dann auf, wenn du gezielt nach der Wohnzimmer-Gruppe fragst.

Ich habe gerade eine neue Version gepusht. Jetzt gibt es deaktivierbare Szenen und in der Dokumentation werden die dazugehörigen Systemvariablen erörtert.

Doofe Frage: woher weiß Alexa denn dass ich im Wohnzimmer bin?

Und wie frage ich sie nach der Innentemperatur ohne Angabe des Raumes?

Gruß, Lutz

Du kannst deinen Echo einer Gruppe zuweisen. Wenn jetzt der Echo, den du der Wohnzimmer-Gruppe zugewiesen hast abgefragt wird, dann prüft er automatisch die Wohnzimmer-Gruppe, wenn du nach der Temperatur fragst. Und dann funktioniert halt auch die Abfrage so wie sie sollte.

Genau so kannst du dann auch im aktuellen Raum das Licht anschalten und dergleichen ohne die Gruppe oder die Geräte zu benennen.

Hallo Symcon,

Ich glaube meine Frage von letztens ist hier untergegangen.
Ist geplant, dass man mit den Modul auch direkt Skripte ausführen kann(und nein ich meine jetzt keine Szenen) die bei Ausführung des Skriptes ihre, die Werte übergeben. Also z.B. bei einer Lampe mit Farbe die Werte = Farbe, Helligkeit, Anschalten, Ausschalten und Farbtemperatur?

Kann derzeit das Alexa Module nicht verwenden, ich möchte nicht mehrere Variablen erstellen die z.B. Heißen Licht Wohnzimmer Status, Licht Wohnzimmer Farbe, Licht Wohnzimmer Temperatur und Licht Wohnzimmer Helligkeit.
Das aus meinen Sicht wenig Sinn, weil in der Bedienung über Alexa und in der Erstellung einfach zu Kompliziert ist.

Ich Poste hier nochmal ein Beispiel Skript vom alten Alexa Modul wie ich mir das Vorstelle:


<? 
    $light_id = 29725; 
    $temp_id = 29729; 
    $level_id = 26168; 
     
    if($_IPS['SENDER'] != "AlexaSmartHome") { 
        exit; 
    } 
     
    switch($_IPS['REQUEST']){ 
        case "TurnOnRequest": 
            OSR_SetValue($light_id, "STATE", true); 
            break; 
        case "TurnOffRequest": 
            OSR_SetValue($light_id, "STATE", false); 
            break; 
        case "SetPercentageRequest": 
            OSR_SetValue($light_id, "LEVEL", $_IPS['VALUE']); 
            break; 
        case "IncrementPercentageRequest": 
            $new_level = GetValueInteger($level_id) + 25; 
            $val = round($new_level *2.55); 
            if($val < 0) $val = 0; 
            if($val > 255) $val = 255; 
             
            OSR_SetValue($light_id, "LEVEL", $new_level); 
            break; 
        case "DecrementPercentageRequest": 
            $new_level = GetValueInteger($level_id) - 25; 
            $val = round($new_level *2.55); 
            if($val < 0) $val = 0; 
            if($val > 255) $val = 255; 
             
            OSR_SetValue($light_id, "LEVEL", $new_level); 
            break; 
        case "SetColorTemperatureRequest": 
            OSR_SetValue($light_id, "COLOR_TEMPERATURE", $_IPS['VALUE']); 
            break; 
        case "IncrementTargetTemperatureRequest": 
            $new_temp = GetValueInteger($temp_id) - 1000; 
            OSR_SetValue($light_id, "COLOR_TEMPERATURE", $new_temp); 
            break; 
        case "DecrementTargetTemperatureRequest": 
            $new_temp = GetValueInteger($temp_id) + 1000; 
            OSR_SetValue($light_id, "COLOR_TEMPERATURE", $_IPS['VALUE']); 
            break; 
        case "SetColorRequest": 
            list($r, $g, $b) = sscanf($_IPS['VALUE'], "#%02x%02x%02x"); 
            $rgb = $r*256*256 + $g*256 + $b; 

            OSR_SetValue($light_id, "COLOR", $rgb); 
            break; 
         
    } 

?> 

Wäre euch für eine Antwort sehr dankbar.

Swen

Genau das wünsche ich mir auch

ich ebenfalls.
Wieso ist das eigentlich so. Ist das im Payload 3 begründet?

Eine Antwort gab es ja bereits, an sich ist das nicht notwendig und es verkompliziert bei normalen Instanzen nur das einbinden. Dennoch wäre es wünschenswert wenn die Werte mit RunscriptEx auch separat übergeben werden, dann kann man diese auch in einem Aktionskript sauber verwenden wenn es sich um eine benutzerdefinierte Variable handelt. Dein Szenario das man drei Variablen braucht kann eigentlich nur auftreten wenn es sich um ein selbstgebautes Gerät mit eigenen Variablen handelt.

In deinem Bespiel ist das ganze Skript überflüssig, es handelt sich um eine PHP Modul, da Du eine farbige Lampe steuern willst, legst Du auf Lampe (Color) die Variable mit der Farbe in der Alexa Instanz an, gibst dieser einen Namen und fertig. Das ist ein einziges Gerät und damit schaltest Du das Gerät ein/aus, dimmst und verstellst die Farbe. Es gibt also auch nur eine Variable die eingebunden wird und daher auch nur einen Namen für das Gerät.

Was aus meiner Hinsicht unlogisch ist, und das bricht mit dem Konzept von IP-Symcon, das überhaupt Bezug auf eine Variable genommen wird, das verwirrt meiner Meinung nach nur und ist absolut nicht konsistent zum Bedienungsprinzip von IP-Symcon. Bei IP-Symcon wird eigentlich nie einer Varibale direkt eine Anweisung gegeben, dies ist nur der Fall wenn es sich um eine Benutzter definierte Variable mit Aktion Skript handelt.

Ansonsten wird immer Bezug auf die Instanz genommen und ein Methode für das Gerät aufgerufen und nicht die Variable direkt verstellt. Genau hier ist die Alexa Instanz aber unlogisch, weil sie sich von der restlichen grundsätzlichen Handhabung in IP-Symcon unterschiedet. Aus diesem Sinn macht es meiner ganz persönlichen Meinung auch nur Sinn im Konfigform nicht auf eine Variable zu verweisen sondern auf eine Instanz. IP-Symcon muss dann schon selber wissen wenn ich eine Lampen Instanz auswähle welche Variable zu schalten ist bzw. welche Methode aufgerufen werden muss um diese Instanz zu schalten. Oder man arbeitet mit List in List und wählt zunächst eine Instanz als Zuordnung aus und dann in einer weiteren Liste die passenden Variablen die die Funktion im Webfront abbilden um das Gerät zu schaltet. Alles andere mit Bezug auf Variablen kann aus meiner Sicht nur ein Workarround sein, da Amazon hier auch klar Geräteeigenschaften pro Typ vorsieht und man nur mit dem Variablen Konzept so oder so nicht bei allen Gerätetypen ans Ziel kommen wird. Ein List in List in der Alexa Instanz Konfiguration wird denke ich also bei komplexeren Gerätetypen wie einem Entertainment Device so oder so unumgänglich werden.

Danke Fonzo für die Antwort.

Mir ist bewusst, dass ich eine Lampe ausschalten wenn die Farbe Schwarz ist und ich auch über die Farbe die die Helligkeit steuern kann, aber mehr halt nicht bei der Alten Version konnte zusätzlich noch die Farbtemperatur ändern.
Und da kommen wir jetzt zu meinen Problem. Die Lampen sind in der Regel RGBW Lampen. Jetzt erzählt mir mal jemand wie ich damit die Farbe weiß steuern kann, ohne das ich dafür einen 2 Namen in Alexa anlegen kann.

Und genau da gebe ich dir recht Fonzo. Aus meiner Sicht widerspricht das derzeitige Modul sich mit den Möglichkeiten, die mir IP-Symcon eigentlich liefert. Da ich keine Möglichkeit mehr habe direkt auf befehle eingehen zu können und immer nur einen Wert ändern kann. Es beschränkt als den Benutzer auf nur eine Möglichkeit.(z.B. Nur Farbe, oder nur Weiß!)

Ich würde mich trotzdem gerne auf eine Stellungname seitens Symcon freuen.:smiley:

Swen

Ein Farblicht kann alles, was auch ein Dimmer kann. Du kannst also eine beliebige Farbe einstellen und diese dann dimmen. Im Falle von Weiß verhält sich das dann also wie ein regulärer Dimmer.

Zugegebenerweise fehlt RGBW an dieser Stelle noch, das Dimmen funktioniert über Grautöne. Hier können aber weitere Gerätetypen hinzugefügt werden, die das dann auch exakt wiedergeben.

Moin,

Es wäre schön wenn der Fehler aus diesem etwas älteren Beitrag mal behoben wird :smiley:

Amazon Echo (Alexa) mit IP-Symcon verbinden (V3, Beta) - Seite 17

LG
Sven

Hast du den Niels eine Antwort auf seine Frage gegeben?
Michael

Also wird es bei einer Variable pro Name bleiben und es wird nicht möglich sein über ein Skript mehrere Variablen zu ändern. (Anhand des Befehls).
Nun noch eine Frage wäre es nicht möglich eine Liste zu erstellen wo Man Skripte auswählen kann und dieses bekommen bei Aufruf des Names alle Information gesendet.
Sollte das nicht gehen. Wird das alte Alexa Modul von IPS 5 noch unterstützt?

Gruß: Swen

Alexa liest es so vor wie es in der Datenbank steht, und nicht wie das Profil eingestellt ist.

Wenn also 14,33000537 in der Datenbank steht liest sie es auch so vor :confused:
Lg

@Acer90: Wir wollen vorerst das Modul für Benutzer einfach halten, daher ist momentan keine „Skriptschicht“ dazwischen vorgesehen. Das mag für Experten charmant sein, aber der Laie kann da schnell überfordert werden. Was du tun könntest, ist deinen eigenen Fork vom Alexa-Modul zu machen, in dem du die Eingaben direkt an Skripte weiterleitest.
Alternativ kannst du das alte Modul auch weiter benutzen. Dafür müsstest du aber vorerst auf den nicht-Beta-Skill zurückwechseln. Bedenke auch, dass du hier dann nur Zugriff auf die Alexa v2 API hast.

@shiashalive: Alles klar, das ist ein leichtes anzupassen, das mache ich gleich.

@Dr. Niels: Wenn Du grad dabei bist, könntest Du doch bestimmt auch einbauen, dass man bei nem Dimmer mitbekommt ob es ein Dimm- oder an-aus Befehl war… :wink:

Das würde mir weiterhelfen…

Habt ihr eigentlich schon was gehört, wann Rolläden durch Alexa vernünftig unterstützt werden?

Das ist ja verständlich, das es einfach sein soll, aber was spricht denn dagegen die Parameter über RunSkriptEx einfach durchzureichen? Wer so oder so nur IP-Symcon Instanzen benutzt bzw. PHP Module benötigt auch kein Aktionsskript bei einer eigenen Variable. Und diejenigen, die das unbedingt nutzten wollen, können die Parameter dann zumindest in einem eigenen Aktionsskript abgreifen. Die „Skriptschicht“ existiert damit doch auch jetzt schon, nämlich bei einer eigenen Variable mit einem Aktionsskript. Dazu jetzt extra einen eigenen Fork zu erstellen halte ich persönlich etwas für übertrieben. Es ändert sich ja nichts, es wird immer noch auf eine Variable verwiesen nur das Aktionskript, das dahinterliegt, bekommt mehr Daten übermittelt, mit denen man bei Bedarf dann auch arbeiten kann.