Binäreingang 4x 8x 16x / Tasterinterface mit LED 2x 4x 6x für TS-ARM

[Doumanix]

Hi Uwe,

ich habe eben nochmal die SW ausprobiert ... irgendwas stimmt da meiner Meinung nach nicht.

Ich habe, wie in geraete-f2/bewegungsmeldermodul-t451-10.html diskutiert, so einen kleinen Sensor angeschlossen. Wenn ich nun die in16-bim112 Firmware drauf spiele und Kanal 1 bei steigender Flanke schalten lasse, dauert das immer 3-4 Sekunden, bis wirklich geschaltet wird - obwohl ich keinerlei Verzögerungen eingestellt habe.

Ich habe noch keine verschiedenen Versionen durchexerziert. Habe das beobachtet bei

• ARM Einbaumodul v3.07 mit LPC 1115/303
• #define MANUFACTURER 0x83 // MDT
• #define DEVICETYPE 0x0030 // Binäreingang
• #define APPVERSION 0x20 // Version 2.0
• INVERT ist gesetzt
• in der ETS5 entsprechend den MDT Binäreingang 16fach BE-16000.01 verwendet und auf Kanal 1 den Eingang benutzt

Wie gesagt: er schaltet / sendet ein Gruppensignal - aber Zeitverzögert.
Mit der BCU1 Firmware zum Jung Binäreingang 8fach 2118REG funkt alles wie gewünscht ...

Grüße
Christian

[Hendrik]

INVERT aktiviert den pull-up und ein Übergang von 0->1 ist eine "fallende Flanke" (siehe Kommentar in config.h). Ich finde diese Definition nicht intuitiv, aber probier's mal ohne INVERT.

[Doumanix]

Oh Mann, klar. Hast recht! Manchmal sieht man den Wald vor lauter Bäumen nicht. Ich dachte mir schon, dass das Ding doch schon mal besser, sprich ohne Verzögerung, funktioniert hatte.

Klar: durch das INVERT hat das Eingangsmodul immer dann geschaltet, wenn der Sensor wieder in den Ausgangszustand ging. Und immer wenn die Bewegung erkannt wurde, ist erst mal nichts passiert.

--> funktioniert also eigentlich wie es soll, wenn man es auch richtig benutzt

[Doumanix]

Hi Uwe,

jodamm hat einen Fehler festgestellt: das Überschreiben der phys. Adresse geht nicht ...
Ggf. kannst ja mal einen Blick drauf werfen, wo der Fehler liegt.
Gerne darf das natürlich auch jemand anderer als Uwe...

LG
Christian

[Doumanix]

Hallo zusammen,

auch den Thread grabe ich nochmal aus, da ich denke, dass es einen kleinen Bug in der FW gibt.

Kann jemand bestätigen, dass bei der Nutzung als (16x) Binäreingang das erste mal nach einem Neustart der des Moduls, wenn ein IO genutzt wird, kein Paket auf den Bus, sprich eine Nachricht an die Gruppe, gesendet wird? Ich nutze das Modul als 15x Binäreingang hinter Lichtschaltern.
Und jedes mal, wenn ein Modul neu gestartet wurde (neu programmiert, Busausfall, manueller Neustart), muss ich ein zweites mal auf den Schalter drücken, damit sich was tut. Das ist so für jeden der IOs! Ab dann läuft alles gut und wie erwartet. Aber wie gesagt das erste Mal ...

Grüße
Christian

[Darthyson]

Hallo Christian,

Ich nutze das Modul als 15x Binäreingang hinter Lichtschaltern.

Ich würde versuchen das nachzustellen. Kannst du dazu bitte noch schreiben wie genau du die Kanäle konfiguriert hast?

• Kanäle: einzeln oder gruppiert

• Funktion: Schalten, Schalten kurz/lang, Ein-Taster Dimmen...

• eventuelle Unterfunktionen

Viele Grüße
Denis

[Doumanix]

Hi Denis,

also Firmware ist es die 16-fach Binäreingang, ohne die INVERT Option: https://github.com/selfbus/software-rel ... ARM/inputs
Da fällt mir übrigens auf, dass diese .hex-Version noch die falsche Appversion enthält. Aber das sollte nicht Auslöser des Problems sein.

In der ETS: Jeder Kanal einzeln, Schalter, ohne Zusatzschnickschnack / Unterfunktionen, kein Sperrobjekt. Jeder Kanal ist auf "ein" senden bei steigender Flanke konfiguriert. Ist aber genauso nachvollziehbar bei "ein" senden bei fallender Flanke, dann eben, wenn man den Taster loslässt. Mehr Varianten hab ich jetzt nicht getestet, denn ich vermute, dass das Problem genereller Natur ist und in der FW zu suchen ist.

Grüße
Christian

[Darthyson]

Hallo Christian,

mit der Version ohne INVERT BI16-BIM112_1.0_NO-INVERT.hex konnte ich das Problem reproduzieren.

Falls du kannst, teste mal mit der INVERT-Option BI16-BIM112_1.0_INVERT.hex.
Mit der Version tritt das Problem bei mir nicht auf.

Viele Grüße
Denis

[Darthyson]

Hallo nochmal,

ich vermute den Bug in der input.cpp (Input::begin), wo die Initialisierung (bisher ohne Betrachtung ob INVERT oder NICHT) der Eingänge erfolgt. Hier mein Diff um den Bug zu fixen:

void Input::begin(int noOfChannels, int baseAddress)

Code: Alles auswählen

diff --git "a/sensors/binary-inputs/in16-bim112/src/input.cpp" "b/sensors/binary-inputs/in16-bim112/src/input.cpp"
index 9325211..d0dfa2e 100644
--- "a/sensors/binary-inputs/in16-bim112/src/input.cpp"
+++ "b/sensors/binary-inputs/in16-bim112/src/input.cpp"
@@ -20,14 +20,19 @@ void Input::begin(int noOfChannels, int baseAddress)
     inputState = 0;
     scan();
     int mode;
+    unsigned int mask = 0;
+
 #ifdef INVERT
     	mode = INPUT | HYSTERESIS | PULL_UP;
 #else
     	mode = INPUT | HYSTERESIS | PULL_DOWN;
 #endif
+
     for (int i = 0; i < noOfChannels; i++)
     {
-        unsigned int mask = 1 << i;
+#ifdef INVERT
+        mask  = 1 << i;
+#endif
         pinMode(inputPins[i], mode);
         inputDebouncer[i].init(inputState & mask);
     }

Fix ist im Repository in16-bim112

Viele Grüße
Denis