Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[osu]

@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

[Glasfaser]

@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

[osu]

@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

[Homoran]

@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.

[osu]

@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

[Glasfaser]

@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 ..:wink:

@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 :question:

[osu]

@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 ..:wink:

@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 :question:

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.

[Homoran]

@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ßt

Ich 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)

[osu]

@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ßt

Ich 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

[hmanfred]

Falsche Schreibweise bei der Bezeichnung des Datenpunktes. IMO auch von Homoran (Doppelpunkt?!).

So bekommst du die richtige Schreibweise (copy&paste):

[Homoran]

@hmanfred sagte in Trigger in Adapterkonfiguration: hm-rega:

So bekommst du die richtige Schreibweise (copy&paste):

und genau so habe ich sie ausgelesen ;-)

[hmanfred]

@Homoran

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. 🤔

[Homoran]

@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 konfig

EDIT: nur BidCoS-RF.50.PRESS_SHORT ergibt für mich Sinn, da es ggf. mehrere hm-rpc.x gibt

[hmanfred]

@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.

[osu]

@hmanfred said in Trigger in Adapterkonfiguration: hm-rega:

@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.

GEFUMMELT? Niemals. ;-)

War per Copy & Paste unterwegs aus den Datenpunkten, allerdings nicht per Copy-Icon. Muss den Tipp oben nochmals checken.

Gruß,
Oli

[hmanfred]

@osu
Vermutlich hast du den Datenpunkt auch aus der Spalte "Namen" kopiert. Hier kannst du kopieren:

BidCoS-RF.50.PRESS_SHORT

😉

[osu]

Danke vorerst für die ganzen Antworten.

Noch habe ich's nicht geschafft. Hoffe bis spätestens am WE Feedback geben zu können.

Gruß,
Oli

[osu]

Hi @Homoran und @hmanfred

Zwischenfrage einsweilen:
Hatte ich oben schonmal gestellt, ist aber wohl untergegangen.
Wenn Ihr den Tastendruck simuliert - bekommt Ihr dann ein Update Eurer Systemvariablen getriggert?

In meinem Log erscheint folgendes:

Aktualisiert wird dann aber nichts.

Der Copy&Paste-Wert des Triggers lautet "hm-rpc.0.BidCoS-RF.50.PRESS_SHORT".

Eingestellt in der Adapterkonfiguration ist wie oben vorgeschlagen:

Damit funktioniert das Triggern nicht.
Auch vollqualifiziert "hm-rpc.0.BidCoS-RF.50.PRESS_SHORT" funktioniert nicht.

Das simulierte Drücken funktioniert allerdings auch nicht zur Aktualisierung.

Und der Eintrag im Log (siehe oben) verunsichert mich, denn wenn ich die :49 anstelle der :50 drücke erfolgt keine Warning im Log.

Gestern Abend hatte ich noch einen Funkhandsender testweise in ioBroker und Raspberrymatic als Trigger konfiguriert. Hat auch nicht funktioniert.

Neue Ideen? Vielen Dank vorab!

Gruß,
Oli

[hmanfred]

@osu
Auch bei mir sieht das so aus:

Mit hm-rpc.x davor geht es nicht. Dabei habe ich natürlich auch gleich getestet, ob eine Änderung dieses Eintrags und Rückkehr auf den Defaultwert vielleicht auf Grund eines Bugs diese Funktion zerschießt: nein, nach Rückkehr auf den obigen Wert, funktioniert es wieder.

Einziger Logeintrag (Stufe Info) jedesmal:

hm-rega.1	2019-08-01 09:22:27.551	info	pollingTrigger

Mein Versuchsaufbau:
Testvariable Typ Zahl 0-100.
3 offene Browserfenster neben-/übereinander:

• ioBroker Objekte mit Anzeige der Testvariable
• HM WebUi mit "Status und Bedienung / Geräte / HM-RCV-50 BidCoS-RF:50
• WebMatic zum Ändern der SV

Ablauf:
SV mehrfach geändert und Aktualisierung im Pollingintervall abgewartet.
Dann SV geändert und HM-RCV-50 BidCoS-RF:50 kurzer Tastendruck -> sofortige Änderung der SV im ioBroker.

Was mir jetzt noch einfällt ist einzig eine Neuinstallation des Rega-Adapters. Problem ist dabei natürlich, dass alle Programmierungen (VIS Objekte, Scripte etc.) ihre Referenzen verlieren. Ob sie nach Löschen der alten Instanz und Installation einer neuen mit gleicher Instanznummer wieder funktionieren, musst du testen.

[osu]

@hmanfred said in Trigger in Adapterkonfiguration: hm-rega:

Was mir jetzt noch einfällt ist einzig eine Neuinstallation des Rega-Adapters. Problem ist dabei natürlich, dass alle Programmierungen (VIS Objekte, Scripte etc.) ihre Referenzen verlieren. Ob sie nach Löschen der alten Instanz und Installation einer neuen mit gleicher Instanznummer wieder funktionieren, musst du testen.

Ja, daran hatte ich auch schon gedacht, da ja scheinbar NICHTS triggert. Derartige Logeinträge wie die Deinen kenne ich nicht aus meinem Log.

Schaffe ich aber definitiv frühestens am WE.

Bis dann.

Gruß,
Oli