Keine Status Mitteilung an Alexa
-
Nabend werte Community...
ist hier jemand der sich mit der Pallette "node-red-contrib-alexa-smart-home" auskennt und mir da helfen kann?
Ich versuche mich gerade mit der genannten Palette, in Verbindung mit meinen Amazon Echo Geräten.
Es geht darum das ich die Statusmeldungen nicht an die Alexa App übermittelt bekomme.
Ich geht jetzt erst einmal davon aus, das ich in "meiner" Logik Fehler begehe.
Dazu angemerkt... Das Beispiel als solches funktioniert an sich.
Ich kann per Spracheingabe das Licht steuern, was aber nicht korrekt funktioniert ist die Übermittlung
des korrekten Status des Lichts.Sprich wenn in der Alexa App steht, das Licht ist aus kann es real auch eingeschaltet sein.
Wenn ich dann in der App auf den Button drücke zeigt die App "Licht an", aber es wurde gerade durch die App
abgeschaltet.Muss der Aufbau anders sein?
Gruß Jörg
-
@jörg-winterstein sagte in Keine Status Mitteilung an Alexa:
node-red-contrib-alexa-smart-home
Ich habe keine Alexa - aber ich hab mal bissi gegoogelt und hier sieht man wie die Nachrichtenobjekte auszusehen haben:
https://docs.cb-net.co.uk/en/development/state-reporting.html -
@mickym sagte in Keine Status Mitteilung an Alexa:
https://docs.cb-net.co.uk/en/development/state-reporting.html
Moin...
Auch wenn ich mit einigem experimentieren die eine andere Sache zu laufen kriege,
ich bin nicht fit genug um selber meine Fehler zu analysieren. Ich habe mir schon versucht bei GOOGLE Rat zu holen und
da das eine oder andere gesehen. Allerdings verstehe ich echt nur Bahnhof wenn man es um den logischen Aufbau bei so etwas geht.Nehmen wir mal das hier:
msg : {
"acknowledge":true,
"payload" : {
"state" : {
"power": "ON"
}
}
}Der Inhalt ist für mich auch ersichtlich und selbst wenn nicht könnte ich herausfinden was z.b. "acknowledge" und wofür es ist . Ich versuche es einmal anders zu formulieren...
Für mich stellen sich Fragen wie:
Wie erkläre ich Alexa das etwas schon an ist, ohne das ich ihr eine Spracheingabe erteilt habe?
Also wenn ich per Taster, App oder grafischer Oberfläche den Status eines Aktors verändert habe.
Besser oder überhaupt MQTT?
Wenn ja wie baue ich es richtig ein?
Wie geht es mit der verwendeten Palette?
Wenn mit dieser Palette, wo baue ich was ein?
Baut man die Nodes immer in einem Stück zusammen, oder muss man das wann wie anders machen?Ich hoffe es ist einiger Maßen verständlich wo mein Problem liegt.
Ich selber habe noch keinen Plan wie ich alles zusammenfügen kann, ob alles nur mit NODERED, vielleicht Blockly, oder beides zusammen. JS ist für mich totales Neuland... wie oder wann muss ich JS Codes wo einpflegen?Also kurz um... alles was ich auf der Seite von https://docs.cb-net.co.uk/ oder auch teils woanders gesehen habe
kann ich nur teilweise für mich als Hilfe nutzen, da mir das Grundwissen fehlt. Ich suche immer nach Hinweisen,
damit ich etwas rekonstruieren kann um es dann für mich zu zerlegen und daraus zu lernen. -
@jörg-winterstein Also mqtt spielt hier wenn überhaupt nur eine untergeordnete Rolle. Wenn Du NodeRed benutzt, dann brauchst Du in der Regel auch kein JS - ausser Du schreibst Code in function Nodes und Blockly brauchst Du in diesem Zusammenhang schon mal überhaupt nicht.
Was grundsätzlich generell stimmen sollte sind ein paar Grundsatzentscheidungen. Wenn Du Deine Homematic Kompunenten über einen Adapter im iob ansprichst, dann solltest Du keine Homematic Nodes in NodeRed verwenden - umgekehrt wenn Du mit den Homematic Nodes in NodeRed hantierst, dann würde ich keinesfalls den Homematic Adapter im iob verwenden.
2 Herren gleichzeitig dienen, das ist schon immer schief gegangen.So und nun kurz zu mir:
Ich habe keine Alexa und kenne diese Nodes auch nicht im Detail: https://flows.nodered.org/node/node-red-contrib-alexa-smart-home
Die 1. Node da machst Du Deine Alexa Konfiguration - das müsste ja schon funktionieren, sonst könntest Du mir Alexa nicht schalten.
Die 2. Node intiiert einen Flow - sie ist eine Eingangsnode, da sie ja nur einen Ausgang auf der rechten Seite hat und die Flows gehen immer von links nach rechts. Diese Nodes nimmst Du also um die Befehle der Alexa auf Deine Hardware umzusetzen.
Die 3. Node ist die, die Du brauchst (state). Dies ist eine Ausgangsnode, da sie nur einen Eingang auf der linken Seite hat. Mit dieser Node informierst Du Alexa über den Zustand bzw. Zustandsänderungen Deines Geräts.
Die 4. Node ist eine response Node - da habe ich aber keine Ahnung, dass bedeutet wohl, dass Du hier Alexa bestimmte Antworten schicken kannst/sollst.So ob oder um Alexa nun den Status Deiner Geräte mit zuteilen, schaust Du am Besten in Deiner Debug Node nicht nur die payload Deines Nachrichtenobjektes, sondern das gesamte Nachrichtenobjekt an.
Wie du richtig vermutest muss in die State Node die Nachricht in einem bestimmten Format vorliegen.
Am Besten nimmst Du also eine Change Node und modifizierst Deine Nachricht und nutzt gleich JSONATA.
Damit Du die Nachricht auch so rausbekommst - würde ich auch wieder eine Debug Node dran machen, bevor Du etwas an die state Node schickst - und erst wenn die Nachricht so rauskommt, wie es auf der Abbildung gezeigt ist, dann schickst Du die Nachricht in die Alexa state node.
@jörg-winterstein sagte in Keine Status Mitteilung an Alexa:
Nehmen wir mal das hier:
msg : {
"acknowledge":true,
"payload" : {
"state" : {
"power": "ON"
}
}
}
Der Inhalt ist für mich auch ersichtlich und selbst wenn nicht könnte ich herausfinden was z.b. "acknowledge" und wofür es ist . Ich versuche es einmal anders zu formulieren...Nun ja wenn Du den Screenshot auch liest, dann steht da mit anderen Worten
If you disable “Auto Acknowledge” you must set msg.acknowledge to true later in the flow, otherwise any command and state update will be dropped.
Das heißt in der Node gibts irgendeine Option AutoAcknowledge, die Du anhaken musst oder ansonsten setzt Du ahlt die Nachrichteneigenschaft acknowledge auf true.
Für die payload kopierst Du Dir aus der Beschreibung das gesamte Objekt erst mal raus und stellst bei payload von einem String auf JSONATA - das ist das große J:
Sobald du das gemacht hast, siehst Du die 3 Punkte und damit öffnest Du den JSONATA Editor.
Dort hinein kopierst Du aus dem Screenshot das payload Objekt:
{ "state" : { "power": "ON" } }
Wenn Du jetzt einfach mit einer Inject node diesen Miniflow mit der ChangeNode triggerst, dann kommt genau das Nachrichtenobjekt raus, was Du in der Abbildung siehst.
Nun steht da ja immer power: ON und Du willst ja dass die payload aus Deinem aktueller Status da drin steht. Nun wirst Du gleich sehen, wie genial so eine Change node mit JSONATA ist.
Nehmen wir also an, Deine payload mit der Du den state füttern willst, enthält bereits eine payload "ON" oder "OFF" - die ich wieder mit Inject Nodes simuliere:
Wenn Du die beiden drückst, ändert sich natürlich noch nichts und Du bekommst das Objekt wie am Anfang zurück.
Du kannst aber in JSONATA Editor einfach das "ON" durch die vorherige, eingespeiste Payload ersetzen.
Dieses Mal ohne "Gänsefüsschen", da wir uns auf die variable Nachrichteneigenschaft payload beziehen, die wir mit den Inject Nodes einspeisen.
Nun bekommst Du schon je nachdem welche payload Du einspeist, die korrekten Objekte für Deine Alexa state Node geliefert:
Wenn wiederum für den Zustand Deines Gerätes true und false als Booleans rauskommen, kannst Du das direkt in JSONATA konvertieren.
In diesem Fall - fügst Du in Deiner ChangeNode im JSONATA noch gleich die Konvertierung hinzu;
Nun wird auch bei true und false als payload - das Objekt richtig mit "power":"ON" bzw. "power":"OFF" ausgegeben,
So wie es nun in der Referenz steht, siehst Du alle möglichen Eigenschaften deiner Eigenschaft state Deiner payload.
payload { state { "brightness": 0-100, "colorBrightness": 0-1, "colorHue": 0-360, "colorSaturation": 0-1, "colorTemperature": 0-10000, "contact" : "DETECTED" || "NOT_DETECTED", "input": string, "lock": "LOCKED" || "UNLOCKED", "mode" : string, "motion" : "DETECTED" || "NOT_DETECTED", "mute" : "ON" || "OFF", "percentage": number, "percentageDelta": number, "playback": playback, "power": "ON" || "OFF", "rangeValue" : number, "rangeValueDelta" : number, "temperature": number, "thermostatMode": "HEAT" || "COOL", "thermostatSetPoint" : number, "targetSetpointDelta": number, "volume": number, "volumeDelta": number } }Nehmen wir an - ich keine Deine Objekte aus Deinen Nodes oder aus dem iob nicht. Es wird bei power = true auch noch die Helligkeit mitgegeben. Entweder in einer eigenen Eigenschaft brightness oder als Eigenschaft Deine payload.
Also so:
dann kann man natürlich auch beides auf einmal schicken:
In diesem Fall änderst Du also Dein JSONATA:
Normalerweise sollten Nachrichteneigenschaften ausserhalb von state ignoriert werden. Du kannst sie aber auch bei Bedarf in der letzten Regel löschen:
Wenn die Nachricht keine Eigenschaft enthält, dann ist JSONATA so intelligent, das es keinen Fehler auswirft, dass die Eigenschaft nicht definiert ist, sondern lässt die Eigenschaft einfach weg.
Die erste Nachricht erzeugt also ein Objekt mit brightness und power, die zweite Nachricht - lässt die Eigenschaft einfach weg, wenn sie nicht vorhanden ist.
Somit kannst Du Dir also ein Referenzobjekt mit allen möglichen Parameter in Deine ChangeNode packen:
Die payload enthält nur die states für das auch entsprechende Nachrichteneigenschaften existieren:
Hier kannst du die Beispiele ausprobieren:
-
@mickym Moin... also vorweg mal WOOOW Danke für diese mega ausführliche Antwort.
Mir sind beim durchlesen direkt ein paar Dinge aufgefallen die ich falsch gemacht oder falsch interpretiert habe.Zu NodeRed und Blockly:
Ich nutze zwar aktuell beide parallel, aber nie das beide die selbe Funktion nutzen.
Hmmmm denke ich jedenfalls... ich versuche das mal zu zerlegen.NodeRed nutze ich zur Visualisierung von virtuellen Lichtschaltern auf einem Tab. Die Smart Home Control Eingangsnode nutze ich zur um die Geräte für Alexa zu finden, die Routinen dazu sind nur Dummys die aber nicht die Eingangsnodes ansprechen, das übernimmt dann Blockly. Alexa nutz nur in Verbindung mit den Dimmern und Rollläden die Eingangsnodes, weil ich es bis jetzt nicht hinbekommen habe diese über Blockly zu steuern.
Das nur einmal so nebenbei.
Ja Du hast Recht man sollte sich natürlich für eines von beiden entscheiden, es war wie gesagt aus meiner Unfähigkeit heraus eine Entscheidung beides zu nutzen um vorübergehend etwas funktionsfähiges zusammen zustellen.
So nun zu einem weiteren Punkt der natürlich gleich aufgefallen ist und der mir selber ja bewusst ist, deshalb habe ich hier ja auch geschrieben. PAYLOAD habe ich einfach immer nur als payload, ohne weitere Definitionen genutzt weil ich eben nicht weiß wie man die Möglichkeiten der vorhanden DATEN wie z.B. in JSONATA verwendet. Oder auch das und wie man ACKNOWLEDGE verwenden kann... kein Plan dazu.
Ich habe bis jetzt über wirklich einfachste Mittel etwas zu bewegen, was natürlich nicht das Ergebnis bringt was man erreichen könnte. Wie das dann so ist man sucht im WWW nach Ansätze, man findet auch einiges... aber wie setzt man das richtig ein und um?
Mal eine Frage zu einer Sache die mir auch aufgefallen ist.
REGEL löschen: Wozu würde man eine Regel wie in dem Beispiel "brigthness" löschen?Darf ich auch mal kurz fragen ob oder welchen Sprachassi Du verwendest?
Bis dahin erst einmal wirklich vielen Dank und nun werde ich mich mal damit beschäftigen.
-
@jörg-winterstein Hallo Jörg, ein paar Missverständnisse muss ich ausräumen:
- Du kannst Blockly und NodeRed durchaus parallel nutzen. Beides sind Logikmaschinen und die tun sich erst mal nicht weh.
- Ich habe aber davon gesprochen, dass Du EINE HARDWARE nur von EINER Seite ansprechen sollst. Sprich wennn Du die Homematic Nodes in NodeRed installierst, dann konkurieren die mit dem Homematic Adapter im iob. Da Du mit NodeRed auch über die iobroker Nodes auf alle Adapter zugreifen kannst, ist das der richtige Weg, wenn Du sowohl Blockly als auch NOdeRed nutzen willst. - Als Logikmaschinen kannst Du beide nutzen und die tun sich auch nicht weh. Du musst halt nur aufpassen, wenn Du mit beiden Systemen die gleichen Datenpunkte modifzierst, dass Du in beiden Systemen nachschaust und dann nicht an unerklörlich Phänomene zwischen Himmel und Erde denkst.
Also in Summe geht es darum, dass man die Hardware nicht von verschiedenen Systemen steuern soll, sonst verliert man den Überblick und ggf. bekommt es auch der Hardware nicht, wenn ein System sagt, mache was und das andere System sagt, halte still.
Ja und ich nuze keinen Sprachassistenten - ich habe mal über den YAHKA Adapter Siri zum Schalten genutzt - habe aber schnell gemerkt, dass das nicht meins ist.
-
@jörg-winterstein sagte in Keine Status Mitteilung an Alexa:
Mal eine Frage zu einer Sache die mir auch aufgefallen ist.
REGEL löschen: Wozu würde man eine Regel wie in dem Beispiel "brigthness" löschen?Musst Du nicht - wie gesagt ich habe das nut gemacht, wenn zum Beispiel diese Eigenschaft deiner Nachricht stören könnte oder Du plötzlich Seiteneffekte hast. In diesem Zusammenhang wollte ich einfach, dass die Ausgabe so aussieht, wie auf dem Referenzbildchen, sonst wäre es halt noch von der Inject Node mit drin gewesen.
-
@mickym mal eine Frage zu dem Bild
{ "state": { "power": payload ? "ON" : "OFF" }}Wenn ich das in die Change Node unter JSONATA so eintrage, wird eine Fehlermeldung ausgespuckt.
Ich hatte mal geschaut ob da ein ";" oder "()" fehlt... kann das sein?Aber erst einmal grundsätzlich wird da abgefragt ob PAYLOAD "ON" oder "OFF", richtig?
Wenn das Richtig ist müsste PAYLOAD im nächsten Step auf "true" oder "false" geändert wird,
damit für die CCU Node das State VALUE entsprechend des gewünschten Schaltzustandes angepasst wird.
Die CCU Value NODE kann mit "acknowledge" nichts anfangen, oder wie müsste ich das betrachten? -
@jörg-winterstein Nein die Alexa state Node siehst Du doch in der Referenz braucht "ON" oder "OFF". Entweder liefert Dir das Deine Hardware (Homematic Node) oder sie liefert true/false und DU wandelst es in true oder false um.
Hast Du denn meinen Flow nicht importiert? Da siehst Du doch alles und kannst diese NOdes verwenden? Ansonsten musst halt einen Screenshot machen.
-
@mickym sagte in Keine Status Mitteilung an Alexa:
YAHKA Adapter Siri
Ok das ist soweit klar...
Natürlich muss darauf geachtet werden das beide Systeme sich nicht gegenseitig im Wege stehen.
Für mich war es in der Tat ein Gedanke ob das eine gute Idee ist NodeRed und Blockly zusammen zu nutzen.
Ich würde gerne nur NodeRed nehmen das es im Grunde alles wichtige bietet, allerdings ist ein für mich großes
die Spracheingabe an der Sache.Ich möchte eine große Bandbreite an Satzvarianten und Fremdsprachen verwenden und das fand ich unter NodeRed für meine Kenntnisse doch too much. Also versuche ich jetzt mein Kenntnisstand zu erweitern und hoffe das ich dann mich auf eine der beiden Logiksysteme zu beschränken.
-
@jörg-winterstein Ja kannst Du Dir überlegen. Ich mache alles mit NodeRed unter dem iobroker. Bis auf ein paar Kleinigkeiten, wenn Du Funktionen oder Räume benutzt ist NodeRed gegenüber Blockly im Nachteil, aber ansonsten bist Du mit NodeRed wesentlich flexibler - gerade was die Objektbearbeitung betrifft und Du kannst ZUSÄTZLICH auch mal Nodes nehmen, wenn der Iobroker Adapter nicht so tut, wie er soll. Ich habe deshalb meine Harmony Ansteuerung lieber in NodeRed gemacht, weil der Harmony Adapter viel zu langsam war (ändern der Lautstärke zum Beispiel). Andererseits gibts zum Beispiel für die Autoadapter im iobroker keinen adäquaten Ersatz in NodeRed, aber duch die iobroker Nodes kann ich diese Adapter im iob nutzen und die Logik trotzdem in NodeRed abbilden.
Lange Rede kurzer Sinn - ich persönlich habe kein einziges Blockly produktiv laufen, sondern steuere auch alles im iobroker mit NodeRed. Wenn Du Hilfe bei der Umstellung einzelnen Blocklys nach NodeRed brauchst, kann ich versuchen zu helfen, du solltest aber einen eigenen Thread aufmachen - sonst verwirrt die Alexa.
-
@mickym Ich habe Deinen Flow importiert...
ich versuche gerade herauszubekommen wie ich der "Change" Node erkläre das beim PAYLOAD "ON" > "true" an das Value weiter zugeben ist und bei "OFF" eben false.Ich habe für Homematic den Auszug:
{"topic":"192.XXX.XXX.XX/HmIP-RF/XXXX:2/STATE",
"payload":false,
"ccu":"192.XXX.XXX.XX",
"iface":"HmIP-RF",
"device":"XXXXX",
"deviceName":"K 0.05",
"deviceType":"HmIPW-DRS8",
"channel":"XXXXX:2",
"channelName":"Arbeitszimmer - Licht",
"channelType":"SWITCH_VIRTUAL_RECEIVER",
"channelIndex":2,
"datapoint":"STATE",
"datapointName":"HmIP-RF.XXXXX:2.STATE",
"datapointType":"BOOL",
"datapointMin":false,
"datapointMax":true,
"datapointDefault":false,
"datapointControl":"SWITCH.STATE",
"value":false,
"valuePrevious":false,
"valueStable":false,
"rooms":["Arbeitszimmer"],
"room":"Arbeitszimmer",
"functions":["Licht"],"function":"Licht","ts":1734612619797,"tsPrevious":1734612340000,"lc":1734612619797,"change":true,"cache":false,"uncertain":false,"working":false,"stable":true,"_msgid":"468dfe252095487c"}Der Wert "true" oder "false" muss für diesen Fall "datapoint" STATE geliefert werden.
Wenn ich Dein Beispiel richtig verstanden habe kann man zwar zwei "INJECTS" nutzen, benötigt aber nur eine "Change" Node um den Schaltzustand an oder aus zu realisieren.
-
@jörg-winterstein Es ist sinnvoll - dass Du so was in Codetags packst.
Du brauchst gar nichts machen - sondern kannst mit diesem Output direkt die ChangeNode füttern.
Aus dem ganzen Nachrichtenobjekt, nimmt sich deine ChangeNode
nur Deine payload raus und wenn Du diese Variante der Change Node nutzt (kannst ja kopieren) konvertiert die das automatisch in "ON" und "OFF" in das richtige Objekt.
-
@mickym Nein tut es leider nicht... die CCU Value Node braucht true oder false, alles andere geht nicht.
Das habe ich jetzt in mehreren Varianten probiert... NULL Reaktion auf ON oder OFF -
@mickym Müsste man eine IF Abfrage dafür zum ändern des Payload nehmen?
-
@jörg-winterstein Ja die brauch true oder false - aber in den State von Alexa muss ON oder OFF. Du hast mir doch gepostet, was aus der Homematic Node rauskommt. Du kannst doch einfach mal meine Change Node, die in den importieren Beispielen ist, HINTER Deine homematic Node schalten und dann über eine Debug NOde schauen, was rauskommt. Wenn das richtig ist, dann speist Du es in die Alexa state node ein.
Da hängst Du meine Change Node dran und machst dann noch eine Debug Node dran und schaust, was rauskommt, wenn Du die Lampe ein und ausschaltest:
-
@jörg-winterstein sagte in Keine Status Mitteilung an Alexa:
@mickym Müsste man eine IF Abfrage dafür zum ändern des Payload nehmen?
Nimm diese Change Node. Mit dem ? : - wird eine if else Abfrage direkt in JSONATA gemacht!!!!
-
@mickym sorry hatte vergessen zu erwähnen das ich diese FLOW deaktiviert habe und nach dem Deinem Beispiel es kurz neu angelegt habe... also zur Demoansicht für mich. Ich habe dabei die "Alexa" Nodes komplett herausgenommen und dabei reagiert die CCU Node nicht drauf.
-
@jörg-winterstein Na gut, dann solltest Du folgendes machen.
Lade mit einer InjectNode aus deinem Homematic Adapter das Objekt in einen neuen Flow - häng nach der iobroker IN Node noch eine JSON Node und ein Debug Node hinten dran und poste was rauskommt als Screenshot.
-
Wenn Du soweit bist, dass Du den Status deiner Lampe in einem Flow hast dann mach doch mal einen Screenshot - damit ich mich etwas orientieren kann.
