Vorstellung: HM-Bell - Sensor/Aktor für Haustürklingel

[t0mk]

Hi,

im github liegt ja eine zip-Datei, da drin sind neben den Eagle-Dateien und Gerber-Daten auch noch eine pdf-Datei mit der Schaltung. Dort gibt es das Problem der verpixelten Darstellung nicht.

[paso]

Ich habe den aktuellen Schaltplan nochmal als hochauflösendes png unter Images/ hinzugefügt. Ich denke die 400 kb kann der Server verkraften.

[tobias.faust]

Hi,
muss eigentlich R9 gesetzt oder kann dieser auch weggelassen werden?
Dieser liegt direkt unter dem plan aufliegendem CC1101.
Wenn ich diesen nun setze liegt der CC1101 nicht mehr plan auf und macht ein auflöten ohne stiftleiste sehr schwierig.

[paso]

R5-R10 sind für den Spannungsteiler, damit der CC1101 nicht mit der 5V Betriebsspannung des Arduino betrieben wird. (War eine Anfrage aus dem Forum)
Ich habe es selbst seit beginn des Projektes mit 5V im Einsatz und es läuft zerstörungsfrei und ohne Probleme. Die Stiftleisten für das Funkmodul habe ich spendiert, damit ich im Labor auch schnell mal etwas tauschen kann. Da habe ich dann bei der Positionierung der Widerstände nicht weiter drüber nachgedacht.
Ist aber ein guter Punkt für eine etwaige Revision.
Viele Grüße

[homtic]

Ich habe mir schon vor einiger Zeit die Platine und die Bauteile besorgt und vor ein paar Tagen auch endlich zusammengebaut. Bevor ich mich an die Klingel mache, wollte ich damit erstmal ein wenig rumspielen.

Der Testaufbau ist so:
- an VIN hängt ein 12 V DC Netzteil (AC habe ich nicht zum Testen, aber die Spannung wird ja eh gleichgerichtet, oder?)
- an BTN hängt ein Taster
- an BELL und LED messe ich einfach die Spannung

LED verhält sich so, wie ich es erwarten würde: ist Kanal 1 aus, liegen dort 12V an und ansonsten 0V (invertierte Belegung)
BELL verhält sich auch so, wie ich es erwarten würde: ist Kanal 1 aus und wird der Taster an BTN betätigt, liegen dort 12V an, ansonsten 0V
Aaber: wird der Taster einmal betätigt, geht der 2. Kanal auf AN, beim 2. Betätigen geht der 2. Kanal auf AUS u.s.w. Was mich dabei wundert:
1. Ich hatte die Doku so verstanden, das der 2. Kanal solange auf AN stehen bleibt, bis man ihn manuell in der UI oder per Programm wieder ausschaltet, um den Taster zu entprellen bzw. beim Sturmklingeln nur 1x zu signalisieren. Mein Modul würde stumpf bei jedem ungeraden Tastendruck signalisieren? Ist das so gewollt, habe ich was falsch verstanden oder mache ich irgendwas falsch?
2. Nach der ersten Taster-Betätigung blinkt das Lämpchen für die serielle Kommunikation auf dem Nano im Sekundentakt (ca.). Ich war neugierig und habe mir die serielle Konsole angeschaut, dort kommt dann mit schöner Regelmäßigkeit "long pressed". Es wird zwar nichts gesendet, bzw. wirklich erst dann, wenn der Taster betätigt wird, aber ist das auch so gewollt, habe ich was falsch verstanden oder mache ich irgendwas falsch?

Ich würde das gerne klären, bevor ich das Modul einbaue, denn dann ist es nicht mehr so einfach mit dem Testen. Kann das jemand bestätigen oder auch nicht? Zumindest das blinken der RX-/TX-LED sollte sich recht einfach ausmachen lassen.

[paso]

Hallo homtic,

das Testen mit DC ist kein Problem, wie du selber gesagt und auch festgestellt hast.

Zum Thema Schalten des 2. Kanals hast du recht. Die Software nutzt den 2 Kanal Switch welcher regulär bei jedem Tastendruck umschaltet. Wenn wir hier ein besser geeignetes SW Modul finden, wäre dies auch Wert mit dokumentiert zu werden.

Grundsätzlich muss daher der 2. Kanal immer zurück gesetzt werden. Damit die Klingel wieder einsatzbereit ist. Ein zweites klingeln kurz danach setzt den Kanal wieder zurück und ein drittes klingeln müsste somit wieder möglich sein, ja.

Welcher Befehl im seriellen Interface ausgegeben wird ist auch abhängig von der SW. Ich habe es mir im Detail nicht angeschaut, aber es kann sein, dass der Switch hier für die Funktion nicht unterscheidet ob kurz oder lang gedrückt wurde, da es sich softwareseitig um einen einfachen Switch (in/off) handelt.

Bisher habe ich, seit Beginn dieses Themas, keine Probleme mit dem Aufbau in der Praxis feststellen können, welche mit deinen Punkten korrespondieren. Allerdings weiß ich jetzt auch, warum ich doch manchmal ein mehrfaches Klingeln in meinen Pushnachrichten sehe.

[homtic]

Danke für die Info, das macht einiges klarer.

Ich habe die Platine jetzt an meinem Gong hängen, die funktioniert und die kleinen Unschönheiten fallen kaum ins Gewicht. Aber sollte sich jemand mit ausreichenden AskSin-Kenntnissen finden, könnte man diese Punkte also für diese Platine fixen:

1. Alternative / HM-LC-Sw2-FM:

• Ausgabe "long press" auf der seriellen Konsole unterbinden oder zumindest sinnvoll mit der Dauer der Klingelbetätigung verbinden. Im Moment nur störend / sinnlos.
• Kanal 2 wirklich nur für die Dauer der Klingelbetätigung auf AN setzen oder bei der 1. Klingelbetätigung für eine im Sketch definierbare Zeit auf AN, danach wieder auf AUS. In der Zeit sämtliche Klingelbetätigungen ignorieren. In jedem Fall sollte diese alternierende Kanalumschaltung bei jeder Klingelbetätigung entfernt werden.
• Die invertierte Kanalbelegung im 1. Kanal in der SW umdrehen, damit der Benutzer in der CCU nicht umdenken muss.

2. Alternative / HB-Modell, Integration in JP-HB-Device-Addon :
wie oben, jedoch zus. bei dem 2. Punkt in der Web-UI einen Parameter vorsehen für die Dauer der "Entprellung" oder auch für die Umschaltung der Betriebsart.

Leider kann ich das mit meinen Programmier-Kenntnissen nicht nicht stemmen, und @papa brauchen wir nach seiner Absage ein einem anderen Thread nicht zu fragen, aber vielleicht könnte Jérôme (@jp112sdl) hier unterstützen?

[jp112sdl]

Ausgabe "long press" auf der seriellen Konsole unterbinden oder zumindest sinnvoll mit der Dauer der Klingelbetätigung verbinden. Im Moment nur störend / sinnlos.

Wer guckt sich den seriellen Output an? Ist doch nur zum Debug oder?

Kanal 2 wirklich nur für die Dauer der Klingelbetätigung auf AN setzen oder bei der 1. Klingelbetätigung für eine im Sketch definierbare Zeit auf AN, danach wieder auf AUS. In der Zeit sämtliche Klingelbetätigungen ignorieren. In jedem Fall sollte diese alternierende Kanalumschaltung bei jeder Klingelbetätigung entfernt werden.

Kann man doch über die interne Tastenverknüpfung über die WebUI konfigurieren?

Die invertierte Kanalbelegung im 1. Kanal in der SW umdrehen, damit der Benutzer in der CCU nicht umdenken muss.

Brauchst es doch nur dort zu ändern?
https://github.com/paso42/HM-Bell/blob/ ... FM.ino#L25

[paso]

Hinsichtlich der Schaltzustände „active high/low“ hatte ich mir Gedanken über die mittlere Stromaufnahme und den Fallback State gemacht.

• Wenn die Stromversorgung der Relais ausfällt, soll die Funktion der Klingel weiterhin gegeben sein. So muss man nicht sofort die Platine ausbauen und reparieren. (z.B. durch Überspannung am Arduino)

• Unter der Annahme, dass der überwiegende Zustand der Klingel „an“ ist, sollte das Relais nicht kontinuierlich angezogen sein um Stromverbrauch zu senken und ggf. die Lebensdauer der Komponenten zu verlängern. Ob das was bringt mal dahin gestellt.

[jp112sdl]

Unter der Annahme, dass der überwiegende Zustand der Klingel „an“ ist, sollte das Relais nicht kontinuierlich angezogen sein

Ja und das kann man doch genau damit erreichen.

Deinem Sketch nach, zieht das Relais an, wenn der Pegel am Arduino HIGH (Schaltzustand "EIN") ist.

Wenn man LOW_ACTIVE auf "1" oder "true" setzt, zieht das Relais an, wenn der Pegel am Arduino LOW (Schaltzustand "AUS") ist.
Bei Verwendung dieser Option, ist das Relais nicht angezogen, wenn in der WebUI der Schaltzustand auf "EIN" steht.

Das ist doch das, was erreicht werden soll, oder nicht?
- Platine hat keinen Strom: Klingel-Stromkreis ist geschlossen
- Platine läuft und steht auf "EIN": Klingel-Stromkreis ist geschlossen

Über die Einstellung "Verhalten bei Spannungsrückkehr" (oder so ähnlich) lässt sich auch einstellen, dass der Kanal nach Stromzufuhr gleich "EIN" geschaltet wird.