[OpenKNX-Ready] SoundModule SOM-UP: Tür-Klingel/Gong mit 4 Binäreingängen

[HansMeiser]

Hallo,

SOM-UP läuft seit heute aktiv als Klingel. Erstmal danke für das tolle Projekt

In der Doku steht zu Prioritäten:
"Hierbei gilt, dass die gleiche Priorität wie eine höhere Priorität gewertet wird. Hierdurch kann eine Hausklingel mehrfach gedrückt werden kann, selbst wenn der Sound aufgrund eines Nachklingen noch läuft".

Bei meinem Klingelsound klingt es bescheiden, wenn durch einen zweiten Druck mittendrin neugestartet wird. Lässt sich dieses Verhalten irgendwie ändern (ohne das ich an der Software rumpfuschen muss).
Vielleicht wäre pro Auslöser eine Auswahl "Gleiche Priorität wird als höher gewertet: ja/nein" eine Möglichkeit, oder sogar als Allgemeine Einstellung wenn es auch für externe Logiken gelten soll.

P.S. im Satz in der Doku ist ein "kann" zuviel und am Nachklingen fehlt ein "s".

P.P.S. Könnte man das Ergebnis mit einer internen Logik erreichen? Trigger auf den Taster und dann quasi EIN und NICHT Status

[traxanos]

Also wenn müsste man das auch global Konfigurierbar machen, da die Auswertung nicht auf dem Channel sondern auch Global passiert.

Man kann ganz sicher das Problem mit dem großartigen Logikmodul lösen Ich bin da jetzt kein Experte, aber denke da Grob an eine Tor-Logik. Solange der Triggerstatus der Klingel "aktiv" ist, sende kein weiteres EIN.


mumpf willisurf Was sagen die beiden Experten

[willisurf]

Ja genau richtig, mit einem TOR lässt sich bei aktiver Klingel ein weiteres Signal sperren.

[mumpf]

Genau, wobei in dem Fall auch ein einfaches UND ausreichen würde. Du hast also 2 Möglichkeiten:

1. UND, ein Einang ist die Klingelknopf GA, zweiter Eingang ist der negierte Player-Status. Hier muss aber der Klingelknopf 1 beim Drücken und 0 beim Loslassen senden.
2. TOR, der Klingelknopf geht an den Dateneingang (Eingang 1), der Player-Status negiert auf den TOR-Eingang (Eingang 2). TOR sendet weder beim öffnen noch beim Schließen. Hier würde es reichen, wenn der Klingelknopf auch nur 1 bei jedem drücken sendet.

Im 1. Fall würde es auch noch so sein, dass wenn jemand dauernd den Klingelknopf drückt, der Gong sofort nochmal klingelt, wenn der vorherige Sound abgespielt worden ist. Im 2. Fall muss man dann nochmal drücken.

Gruß, Waldemar

[HansMeiser]

mumpf ich scheitere gerade noch an der Umsetzen von Variante zwei:

Auf GA 0/4/0 habe ich Eingang 1 der Logik und den Schalt-Eingang des Klingeltasters
Auf GA 0/4/1 den Ausgang der Logik und Auslöser 1
Wenn ich die Logik-Operation auf UND stelle und Eingang 1 auf normal aktiv funktioniert die Klingel -> GA-Kommunikation scheint also zu stimmen.

Stelle ich die Logik-Operation auf TOR und Eingang 2 auf invertiert aktiv und Eingang 2 auf bestehendes KO 51 (Auslöser 1, Status) mit DPT 1.xxx passiert nach einem Start auf 0/4/0 nichts.

Auch wenn ich den Status von Auslöser 1 und Eingang 2 in eine eigene GA packe funktioniert es nicht.

Hast du eine Idee was ich hier falsch mache?

[willisurf]

Screenshots helfen…

[mumpf]

HansMeiser Das ist klar, das Tor ist ja auch noch zu! Du musst schon sagen, dass es bei einem Neustart aufgehen soll. Also musst Du Eingang 2 passend initialisieren, am besten, indem Du den aktuellen Wert vom Bus liest. Dann wird der Eingang vom Player eine 0 bekommen, da der Eingang invertiert ist, wird das Tor geöffnet und dann geht das Klingelsignal auch durch.

Gruß, Waldemar

[traxanos]

Den Fehler mach selbst ich immer noch...

[HansMeiser]

Das klingt logisch. Ich war davon ausgegangen, dass die Logik sich Eingang 2 liest wenn ein Signal auf Eingang 1 kommt.

Kann ich der Logik beibringen sich den Wert vom Bus beim Start zu lesen? Das hab ich bisher nicht gefunden.
"Eingangswert vorbelegen" mit AUS und/oder zyklisch lesen ginge.

[mumpf]

Ok, Du nutzt die interne Verknüpfung (Bestehendes KO nutzen), nicht wahr? Da kann man nicht lesen. Dass "Zyklisch lesen" immer noch sichtbar ist, ist ein Fehler, der mir bisher leider gar nicht aufgefallen ist. Interne Verknüpfungen sind keine "echte" Buskommunikation, sondern nur eine möglichst gute Simulation. Ein ReadRequest funktioniert da leider nicht.
Mach ein normales KO für den Eingang, verbinde es über GA mit dem Ausgang, dann kannst Du auch "vom Bus lesen" zur Initialisierung.

Und danke für den Fehlerhinweis, das werde ich in der nächsten Logikmodul-Version korrigieren.

Gruß, Waldemar

P.S.: Alternativ (falls das beim SOM geht): Initial den Status des Playerkanals senden lassen.

[HansMeiser]

OK, mit externem KO kann ich vom Bus lesen. Jetzt hab ich direkt noch zwei Logik-Modul-Fragen:

1. Kann ich bei einer Zeitschaltuhr einen Zeitraum (im Sinne von Tagen eines definierten Monats angeben), also z.B. 01.12. bis 26.12. (für den Weihnachts-Klingelton). Ich habe bei der Jahresschaltuhr nur Wochentage und einzelne Tage gefunden.

2. Ich würde gerne für bestimmten Tage des Jahres, oder Zeiträume bestimmte Klingeltöne abspielen, also, z.B.
31.10. -> Grusel-Irgendwas
1.12. bis 26.12. -> Weihnachtsgebimmel
Meine Idee war jetzt für jeden Tag/Zeitraum eine Zeitschaltuhr zu erstellen.
Eine UND-Logik jeweils mit dem Klingel-Trigger und dem Ausgang der Zeitschaltuhr anzulegen, deren Ausgang, dann die entsprechende Datei über "Externe Logik - Datei" abspielt.
Das sollte soweit funktionieren, wozu ich noch keine Idee habe ist der default case: "Wenn keine Zeitschaltuhr 1 war, spiele den Standard-Ton"

Hierzu irgendeine Idee, oder ist mein Ansatz falsch und das geht alles viel einfacher?

[mumpf]

Also... zu 1.
Klar, es geht bei Zeitschaltuhren immer um Zeiträume. Du hast Schaltzeiten, z.B. 17.12 um 06:50, da schaltest Du EIN. Und am 23.12 um 14:37 schaltest Du AUS. Dazwischen liegt ein Zeitraum, in dem das Signal EIN ist, davor und danach ist es AUS (sind auch Zeiträume).

Zu 2.
Deine Idee ist gut, würde ich auch so machen.
Und zu dem default case: Man kann

"Wenn keine Zeitschaltuhr 1 war, spiele den Standard-Ton"

auch so formulieren:
Wenn alle Zetschaltuhren 0 sind, spiele Standard-Ton.

Das ist dann ein großes ODER (aus mehreren Kanälen), dass bei AUS den Standard-Ton spielt.

Gruß, Waldemar

[HansMeiser]

Zu 1. Danke, jetzt hab ichs verstanden. Ich hatte irgendwie in cron-Syntax gedacht (immer wenn die Bedingung zutrifft ist der Ausgang ein).
Zu 2. hatte vermutet, dass das auf ein großes (mehrstufiges) OR rausläuft

traxanos wäre möglich, dass du trotzdem eine globale Konfiguration für gleiche Priorität wird/wird nicht als höhere Priorität gewertet einbaust?
Wenn ich jetzt Idee/Problem 1: Klingel drücken unterbricht aktuell gespieltes Sample nicht, mit Idee/Problem 2: verschiedene Töne nach Zeitraum kombiniere wirds wild: 3 Logiken pro Ton: 1 TOR, 1 Zeitschaltuhr, 1 UND und noch ein paar OR für den Default-Case

mumpf wäre eine switch-case Logik nicht was für ein nächstes release

[mumpf]

Die TOR-Logik brauchst Du nur einmal, wenn ich mich recht erinnere, gibt der Player global aus, ob er gerade was spielt. Aber das weiß traxanos besser.

Für das große OR kannst Du auch die internen Eingänge 3 und 4 nutzen (das ist eine weitere Möglichkeit, intern zu verknüpfen, nicht über KO, siehe Applikationsbeschreibung), dann brauchst Du bei 10 Zeitschaltuhren nur 3 Logikkanäle für das OR.

Nach meiner Rechnung bräuchtest Du für 11 verschiedene Töne (1 default und 10 special):

• 10 Zeitschaltuhren
• 10 UND
• 1 TOR
• 3 OR

traxanos Vielleicht doch mit 99 Logikkanälen compilieren .

wäre eine switch-case Logik nicht was für ein nächstes release

Ist schon geplant, nur anders als Du denkst, wesentlich mächtiger als switch-case und frühstens Ende 2024 fertig. Es lohnt also noch, es klassisch zu lösen

Gruß, Waldemar

[HansMeiser]

Eine globale TOR-Logik ist nicht ganz äquivalent, da dann alle Klingeltöne quasi die niedrigste Priorität haben. Sobald der Player irgend etwas spielt kann man nicht mehr klingeln.

Statt switch-case würde ich auch eine Textbox nehmen, in die ich irgendeinen Code paste, der dann zur Laufzeit interpretiert wird