NEWS
Trigger in Adapterkonfiguration: hm-rega
-
Hi,
ich schlage mich heute bereits eine Weile mit folgendem Problem herum. Recherche hat bisher leider nicht geholfen, denn so wie ich die Suchergebnisse deute, müsste mein Vorhaben klappen - tut es aber leider nicht.
In der Adapterkonfiguration: hm-rega habe ich BidCoS-RF.50.PRESS_SHORT als Trigger eingetragen.
Damit möchte ich erreichen, dass folgendes Blockly eine Ausgabe der Systemvariabele Alexa-TTS auf den Alexa2-Adapter spricht:
Nun ist es so, dass diese Systemvariable auf der Raspberrymatic testhalber alle 10 Sekunden mit dem Wert der aktuellen Zeit in Minuten und Sekdunden beschrieben wird.
Im Anschluss erfolgt ein Auslösen von BidCoS-RF.50.PRESS_SHORT zeitverzögert um 3 Sekunden. Testhalber seht Ihr auch eine Auslösen von BidCoS-RF.50.PRESS_LONG zeitverzögert nach 4 Sekunden:
Man kann im Status der Rasperrymatic sehen, dass der Tastendruck alle 10 Sekunden erfolgt (so wie der Wert der Systemvariable gesetzt wird, siehe Bild oben). Das Auslösen des virtuellen Tasters sehr ihr hier:
Alexa spuckt allerdings nur ~ alle 30 Sekunden eine neue Sprachausgabe mit dem dann geltenden Wert der Variable aus. Das entspricht dem Pollingintervall und nicht etwa den getriggerten 10 Sekunden. Und es ist wohl egal, ob ich BidCoS-RF.50.PRESS_LONG oder BidCoS-RF.50.PRESS_SHORT verwende (natürlich mit entsprechender Anpassung in der Adapterkonfiguration: hm-rega).
Was läuft da falsch? Ich hätte natürlich gerne den aktuellen Wert aus der Systemvariable. Anwendungsfall für die Produktion ist anstelle des Testszenarios die Sprachausgabe beliebeiger Meldungen, die die Raspberrymatic generiert.
Auch die in den Suchergebnissen teils inskonsistente Verwendung des Doppelpunkts anstelle einfachem Punkt im Trigger führt zu keiner Änderung.
Eingesetzte Versionen:
Raspberrymatic 3.47.10.20190713
Alexa2 (Amazon Echo) 2.6.4
HomeMatic ReGaHSS 2.4.2
HomeMatic RPC 1.9.16
Script Engine 4.1.12Mit der Bitte um Unterstützung. Danke!
Gruß,
Oli -
Wofür du den Trigger im Homematic angelegt hast mit einem Virtuellen Datenpunkt BidCoS-RF.50. ist mir schleierhaft . Was willst du damit Schalten bzw. auslösen.
Teste mal:
Geh in den Datenpunkt bei iobroker " Alexa-TTS" und verändere da händisch den Text , hast du dort auch dort die Verzögerung !?
-
@Glasfaser sagte in Trigger in Adapterkonfiguration: hm-rega:
Wofür du den Trigger im Homematic angelegt hast
Wie er schreibr werden hm-rega Datenpunkte üblicherweise alle 30 sekunden geloggt.
Mit dem :50 press short wird der wert sofort abgeholt.
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
Was läuft da falsch?
Wie oft wird der wert denn in iobroker unter hm-rega.0 aktualisiert.
-
Also nach meinem Empfinden hast du alles richtig gemacht.
Den press long trigger brauchst du ja eigentlich garnicht.
Ich vermute den Fehler am ehesten im Homematic Programm.
Hier mal ein Foto wie dieses bei mir aussieht:
Das funktioniert zuverlässig.
Hast du es sonst schonmal mit einer weiteren / neuen Systemvariable getestet?
Oder mal mit einem einfachen true/false Wert?
Ich Habe die CCU2, keine Raspberrymatic, jedoch denke ich nicht dass da der Unterschied liegt. -
@Glasfaser Natürlich habe ich da ebenfalls die Verzögerung, die dem default polling intervall entspricht.
Ich will dass getriggert wird und damit die Aktualisierung auslösen um den Delay auf ein Minimum zu reduzieren. Und genau dafür ist BidCoS-RF.50.PRESS_SHORT gedacht.Gruß,
Oli -
@Homoran said in Trigger in Adapterkonfiguration: hm-rega:
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
Was läuft da falsch?
Wie oft wird der wert denn in iobroker unter hm-rega.0 aktualisiert.
Auch nur alle 30 Sekunden.
Sollte ein simuliertes HM-RCV-50 BidCoS-RF:50.PRESS_SHORT in den Objekten einen Refresh auslösen? Wenn ich den Tastendruck simuliere, tut sich da auch nichts.
Noch eine Verständnisfrage: Der Datenpunkt heisst "HM-RCV-50 BidCoS-RF:50.PRESS_SHORT". Der Trigger ist per Default aber wie oben eingestellt auf "BidCoS-RF.50.PRESS_SHORT" (mit Punkt, ohne "HM-RCV-50 ") gelegentlich liest man auch von "BidCoS-RF:50.PRESS_SHORT" (mit Doppelpunkt, ohne "HM-RCV-50 ") - was stimmt denn nun?
Gruß,
Oli -
@smile said in Trigger in Adapterkonfiguration: hm-rega:
Also nach meinem Empfinden hast du alles richtig gemacht.
Den press long trigger brauchst du ja eigentlich garnicht.Schon klar, den hatte ich testweise drin.
Ich vermute den Fehler am ehesten im Homematic Programm.
Glaube ich nicht. Ich kann inder Homematic sehen, wie getriggert wird (siehe Screenshot oben zum letzten Tastendruck) und ich kann ebenfalls sehen, wie der Wert der Systemvariablen geändert wird.
Hier mal ein Foto wie dieses bei mir aussieht:
Das funktioniert zuverlässig.
Hast du es sonst schonmal mit einer weiteren / neuen Systemvariable getestet?Die Systemvariable ist neu.
Oder mal mit einem einfachen true/false Wert?
Nein. Ich will ja Strings sprechen lassen.
Ich Habe die CCU2, keine Raspberrymatic, jedoch denke ich nicht dass da der Unterschied liegt.
Das wäre die Hoffnung.
Gruß,
Oli -
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
@Glasfaser Natürlich habe ich da ebenfalls die Verzögerung,...…..
Sehr komisch das hat dann nichts mehr mit der CCU zu tun , zwecks Verzögerung ………..
Welchen Adapter hast du Installiert für die Sprachausgabe Alexa Adapter oder ….Schreib mal bitte in den Datenpunkt "speak " etwas rein ob auch dort auch die Verzögerung kommt.
Wenn ja vermute ich es liegt am Adapter !?
Nachtrag : OK … sehe gerade du hast es angegeben : Alexa2 (Amazon Echo) 2.6.4
-
@Glasfaser said in Trigger in Adapterkonfiguration: hm-rega:
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
@Glasfaser Natürlich habe ich da ebenfalls die Verzögerung,...…..
Sehr komisch das hat dann nichts mehr mit der CCU zu tun , zwecks Verzögerung ………..
Welchen Adapter hast du Installiert für die Sprachausgabe Alexa Adapter oder ….Schreib mal bitte in den Datenpunkt "speak " etwas rein ob auch dort auch die Verzögerung kommt.
Wenn ja vermute ich es liegt am Adapter !?
Nachtrag : OK … sehe gerade du hast es angegeben : Alexa2 (Amazon Echo) 2.6.4
Ich fürchte Du hast noch nicht so recht verstanden, um was es geht.
Systemvariablen der Homematic CCU werden nicht sofort bei Änderung in der CCU sondern per Polling (Intervall Standard 30 Sekunden) an den ioBroker übertragen. Um der damit verbundenen Verzögerung nach Änderung der Variable entgegenzuwirken, kann in der CCU getriggert werden. Dann holt sich ioBroker die aktuellen Werte.
Und dieses Triggering funktioniert bei mir nicht.Dieses Verhalten äußert sich als Konsequenz natürlich auch im Alexa2 Adapter, da der nach Änderung der entsprechenden Variable nur alle 30 Sekunden aufgerufen werden kann. Und wie ich @Homoran bereits erklärte, kann man am Datenpunkt der Variable Alexa-TTS sehen, dass auch der nur alle 30 Sekunden aktualisiert wird.
Aufgabe in diesem Szenario lautet also herauszufinden, warum das Triggering nicht funktioniert, das im hm-rega-Adapter konfiguriert werden kann.
Gruß,
Oli -
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
jedoch denke ich nicht dass da der Unterschied liegt.
Das wäre die Hoffnung.
Vielleicht doch!
Ich bin mit den Firewall Einstellungen der RaspberryMatic nicht vertraut.
Aber ggf. Sind die anders. -
@Homoran said in Trigger in Adapterkonfiguration: hm-rega:
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
jedoch denke ich nicht dass da der Unterschied liegt.
Das wäre die Hoffnung.
Vielleicht doch!
Ich bin mit den Firewall Einstellungen der RaspberryMatic nicht vertraut.
Aber ggf. Sind die anders.Alles offen.
@osu said in Trigger in Adapterkonfiguration: hm-rega:
@Homoran said in Trigger in Adapterkonfiguration: hm-rega:
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
Was läuft da falsch?
Wie oft wird der wert denn in iobroker unter hm-rega.0 aktualisiert.
Auch nur alle 30 Sekunden.
Sollte ein simuliertes HM-RCV-50 BidCoS-RF:50.PRESS_SHORT in den Objekten einen Refresh auslösen? Wenn ich den Tastendruck simuliere, tut sich da auch nichts.
Noch eine Verständnisfrage: Der Datenpunkt heisst "HM-RCV-50 BidCoS-RF:50.PRESS_SHORT". Der Trigger ist per Default aber wie oben eingestellt auf "BidCoS-RF.50.PRESS_SHORT" (mit Punkt, ohne "HM-RCV-50 ") gelegentlich liest man auch von "BidCoS-RF:50.PRESS_SHORT" (mit Doppelpunkt, ohne "HM-RCV-50 ") - was stimmt denn nun?
Kannst Du auf diese Frage noch eingehen, @Homoran ?
Danke!
Gruß,
Oli -
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
Ich fürchte Du hast noch nicht so recht verstanden, um was es geht.
Doch habe verstanden …wollte nicht auf das Thema Trigger in der CCU eingehen ..
@glasfaser sagte in Trigger in Adapterkonfiguration: hm-rega:
Schreib mal bitte in den Datenpunkt "speak " etwas rein ob auch dort auch die Verzögerung kommt.>
Wenn du die gleiche Verzögerung hast , wenn du es händisch in den Datenpunkt in iobroker einträgst "speak " oder Alexa-TTS" dann hat das nichts mit der CCU zu tun , das eine Zeitverzögerung kommt.
Hast du es mal versucht
-
@Glasfaser said in Trigger in Adapterkonfiguration: hm-rega:
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
Ich fürchte Du hast noch nicht so recht verstanden, um was es geht.
Doch habe verstanden …wollte nicht auf das Thema Trigger in der CCU eingehen ..
@glasfaser sagte in Trigger in Adapterkonfiguration: hm-rega:
Schreib mal bitte in den Datenpunkt "speak " etwas rein ob auch dort auch die Verzögerung kommt.>
Wenn du die gleiche Verzögerung hast , wenn du es händisch in den Datenpunkt in iobroker einträgst "speak " oder Alexa-TTS" dann hat das nichts mit der CCU zu tun , das eine Zeitverzögerung kommt.
Hast du es mal versucht
Wieso sollte ich das tun, wenn ich sehe, dass die Ausgabe im gleichen Takt geschieht wie die Aktualisierung des ioBroker-Datenpunkts von "Alexa-TTS". Dieser Versuch geht am Problem vorbei.
Das Problem ist der Trigger, der nicht funktioniert.
-
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
Kannst Du auf diese Frage noch eingehen, @Homoran ?
Nö!
Einfach weil ich nicht weiß wie dieser Datenpunkt bei RaspberryMatic heißtIch habe jetzt nochmal bei mir nachgesehen. Der Datenpunkt heißt in ioBroker:
HM-RCV-50 BidCoS-RF:50.PRESS_SHORT
- HM-RCV-50 ist das Gerät mit den 50 virtuellen Kanälen
- BidCoS-RF:50.PRESS_SHORT ist der Datenpunkt (Kanal 50; kurzer Tastendruck)
-
@Homoran said in Trigger in Adapterkonfiguration: hm-rega:
@osu sagte in Trigger in Adapterkonfiguration: hm-rega:
Kannst Du auf diese Frage noch eingehen, @Homoran ?
Nö!
Einfach weil ich nicht weiß wie dieser Datenpunkt bei RaspberryMatic heißtIch habe jetzt nochmal bei mir nachgesehen. Der Datenpunkt heißt in ioBroker:
HM-RCV-50 BidCoS-RF:50.PRESS_SHORT
- HM-RCV-50 ist das Gerät mit den 50 virtuellen Kanälen
- BidCoS-RF:50.PRESS_SHORT ist der Datenpunkt (Kanal 50; kurzer Tastendruck)
Heißt genau wie bei Dir.
Also so:
Tut leider nicht.
Gruß,
Oli -
Falsche Schreibweise bei der Bezeichnung des Datenpunktes. IMO auch von Homoran (Doppelpunkt?!).
So bekommst du die richtige Schreibweise (copy&paste):
-
@hmanfred sagte in Trigger in Adapterkonfiguration: hm-rega:
So bekommst du die richtige Schreibweise (copy&paste):
und genau so habe ich sie ausgelesen
-
Hmm... seltsam.
Bei mir kommt da: hm-rpc.2.BidCoS-RF.50.PRESS_SHORT
Erste Spalte in den Objekten. Spalte "ID" und nicht Spalte "Namen".
Ohne Doppelpunkt zwischen RF und 50. Komisch, dass der Adapter in unterschiedlichen Installationen die Objekte verschieden anlegt.
-
@hmanfred sagte in Trigger in Adapterkonfiguration: hm-rega:
Spalte "ID" und nicht Spalte "Namen"
Möglich, dass ich unter Namen geraten war und/oder eine andere meiner Testinstallationen offen hatte.
Unter der produktiven Umgebung gemäß stable ist da tatsächlich kein Doppelpunkt.Und in meiner rega-Konfiguration steht nur BidCoS-RF.50.PRESS_SHORT.
Habe aber nie nachgesehen ob das funktioniert@osu
Ändere das bitte mal in der rega konfigEDIT: nur BidCoS-RF.50.PRESS_SHORT ergibt für mich Sinn, da es ggf. mehrere hm-rpc.x gibt
-
@Homoran sagte in Trigger in Adapterkonfiguration: hm-rega:
Und in meiner rega-Konfiguration steht nur BidCoS-RF.50.PRESS_SHORT.
Genau das steht auch bei mir drin - und funktioniert.
Ich vermute, dass @osu im Zuge seiner Tests mal daran rumgefummelt hat.