für mein neues Projekt (Schlüsselerkennung) wollte ich auch gleich mein VD364 Spracherkennungsmodul von Sensory mit in 1-Wire einbinden.
Leider bleiben die geschalteten Ausgänge des Moduls nur für ca. 0,5 - 1 Sek. aktiv (4V), zu kurz um mit einem DS2408 erfasst zu werden.
Kennt jemand eine einfache Möglichkeit, den Pegel für ca. 3 Sekunden auf HIGH zu halten, ohne hier extra Mikrokontroller oder andere IC’s einzusetzen? Evtl. Kondi/ Widerstandskombi? Nur wie am besten?
Jemand eine Idee?
Grüße,
Doc
Hier ist mal eine kleine Anleitung zu dem Modul. Leider kann man nicht erkennen, was das für Ausgänge sind, zumindest ich sehe es nicht. Die Ausgänge habe ich über 1k nach Masse gezogen und werden dann ca. 4V wenn aktiv.
habe ich mich noch nicht genauer mit befasst. Allerdings geht es mir hier nicht nur um den VD364, sondern auch um den Anschluss der Proximity Sensoren zur Schlüsselerkennung. Ich möchte vermeiden, das ein leicht pendelnder Schlüssel den Eingang des DS2408 immer umschaltet, oder habe ich das mit dem Latch jetzt falsch verstanden?
in IP-Symcon gibt es für jeden Port des DS2408 zwei verschiedene Variablen, die den Eingangszustand beschreiben.
- ohne Latch: die Variable liefert den Zustand des Ports zum Zeitpunkt der Abfrage: TRUE = Hi, FALSE = Lo - mit Latch: die Variable liefert die Information, ob sich der Zustand des Ports während des letzten Abfrageintervalls geändert hat: TRUE = Zustand hat sich geändert, FALSE = Zustand ist konstant geblieben
Mit der Latch-Variable lassen sich also auch Impulse erfassen, die kürzer sind als das Abfrageintervall.
danke für die ausführliche Erklärung, das war das, was mir zum „Latch“ gefehlt hatte.
Allerdings sehe ich darin noch nicht wirklich die Lösung meines Problem.
Hier Beispiel des Schlüssels:
Der Schlüssel wird angehängt, und pendelt noch eine Weile vor dem Sensor. Der Eingang am DS2408 schaltet demzufolge auch ständig um. Somit habe ich bei einem Abfrageintervall von 1-2Sek. sich ständig ändernde Zustände an der Variablen. Wird der Schlüssel entnommen, könnte durch die Bewegung evtl. auch ein High/Low erfolgen, was naturlich nicht gewünscht ist, weil damit dann wieder unbeabsichtigt andere Scripte ausgelöst werden.
Evtl. stehe ich auch gerade auf dem Schlau. Was ich eigentlich möchte ist, die Eingänge für ca. 3 Sek. entprellen, um ungewolltes Scripttriggern zu vermeiden.
Für den VD364 gebe ich dir recht ( und Steiner natürlich auch), das ist mit der Latchvariablen eine gute Idee, aber mit dem Schlüssel?
Du schreibst ein Skript, in dem zwei verschiedene Trigger-Quellen ($IPS_SENDER) unterschieden werden.
Aufruf durch die Triggervariable ($IPS_SENDER == „Variable“):
Der Schlüssel wurde gerade eben eingehängt (TRUE) oder entnommen (FALSE).
ScriptTimer starten (Wartezeit z.B. 5s)
Aufruf durch den ScriptTimer ($IPS_SENDER == „TimerEvent“):
Der Schlüssel hat sich eingependelt (TRUE) oder wurde dauerhaft entnommen (FALSE).
entsprechende Aktionen starten
Wenn der Schlüssel eingehängt wurde, wird Punkt 1 vermutlich mehrfach aufgerufen. Der Timer wird dabei immer wieder neu gestartet. Ist der Timer abgelaufen, kann man davon ausgehen, dass der Schlüssel zur Ruhe gekommen ist oder entfernt wurde.
Hi,
hab da noch ne Hardwarelösung.
Ich habe den Trick mit meinen DS2405érn angewandt, da die ja kein Latch haben.
gebe deinen Impuls an ein Transistor weiter und schalte damit ne direkte Ladung auf ein Elko. (Kapazität variable). Bei mir haben 22uF gereicht um mit einem Kurzen 5V Impuls genug Ladung zu haben um über einen weiteren Transistor den eigentlichen Impuls weiter zu geben. Der Entladestrom natürlich über einen Vorwiderstand zur Basis.
So, die HW-Anbindung des VD364, Schluesselerkennung und des DOG-Displays funktioniert nun problemlos.
Das VD364 habe ich so beschaltet, das ich mehrere Datensätze anlegen kann, die aus verschiedenen Entfernungen besprochen werden können, jeder Datensatz dann mit den gleichen Wörter. Bei mir hier z.B. JA, NEIN, OK.
Das hat den Vorteil, das beim Antworten aus versch. Entfernungen die Erkennung gleich gut funktioniert. Habe ich auch mal getestet, mehre Meter sind so kein Problem mehr.
Ein genauere Beschreibung liefere ich mal, wenn es komplett fertig ist.
Jetzt habe ich aber noch mal ne Frage zum Scripten.
Wie kann man am besten innerhalb eines Scriptes z.B. auf eine Antwort warten (Variablenänderung)?
Hatte mir erst überlegt, mit Sleep eine Weile zu warten, und dann die Variable abzufragen, scheint mir aber zu unflexiblel, was die Zeiten angeht.
Oder sollte man das besser in eine FOR/Next Schleife verpacken, um bei einer Änderung schneller reagieren zu können, oder gibt es da noch bessere Möglichkeiten.
Als Beispiel beim Verlassen des Hauses kommt die Sprachausgabe, das es schon dunkel ist und ob evtl. die Rolläden schon geschlossen werden sollen. Hier wäre dann die Antwort JA o. NEIN, nur wie im Script das abfangen?
Hallo Doc,
kennst Du die Events beim Script, z.B. onUpDate oder onChange nicht?
Die müßten dein Problem doch einfach lösen (nicht innerhalb !!).
Oder hab ichs falsch verstanden ?
Im Script kommt die Abfrage über Sprachausgabe, ob z.B. die Rolladen schon runter gefahren werden sollen. Nun muss das selbrige Script auf eine Antwort warten (Änderung einer Variablen durch das VD364), um weiter Aktionen ausüben zu können. Ich möchte das Script nicht beenden und wieder neu starten müssen. Somit suche ich eine gute Lösung das im Script mit verbauen zu können.
onUpDate oder onChange bringt mir da glaube ich nicht wirklich viel.
Ja ich glaube es auch.
Aber bei mir sperrt sich was, wenn ich ein Script beschäftige, um auf eine neue Aktion (Veränderung der Variable) warte.
So gut kenn ich mich aber auch nicht aus. Ich denke nur immer, das System nicht unnötig zu beschäftigen.
Eine Idee: nimm eine Semaphore.
Das Haupscript setzt eine Semaphore und wartet in einer Schleife mit sleep auf die Auflösung.
Ein OnChange-Script der gewünschten Variable setzt die diese Semaphore zurück und das Hauptprogramm läuft weiter.
ein Skript sollte grundsätzlich nicht auf etwas warten, sondern nur dann ablaufen, wenn es benötigt wird.
Moderne Ansätze zur Programmierung finden offenbar nur schwer Eingang bei IP-Symcon Nutzern. :o
Das Zauberwort heißt: Ereignisgesteuerte Programmierung
IP-Symcon ist so aufgebaut und es gibt eigentlich keinen Grund Skripte nicht nach dem selben Prinzip zu organisieren.
Die Switch - Case Anweisung ist dafür bestens geeignet. Man kann damit in einem Skript in Abhängigkeit von der Triggerquelle verzweigen.
switch ($IPS_SENDER)
{
case "Variable":
switch ($IPS_VARIABLE)
{
case "Schluesselbrett":
// Schlüssel wurde eingehängt oder entnommen
break;
case "Spracheingabe":
// es wurde ein Sprachbefehl erkannt
break;
}
break;
case "TimerEvent":
// Timer Event bearbeiten
break;
case "Designer":
// Eingaben im Designer bearbeiten
break;
}