[OpenKNX-Ready] Präsenzmelder und Multisensor: Diverse Sensoren & Binäreingänge

[LostWolf]

Was ist eigentlich die beste Art nach dem löten einen Funktionstest durchzuführen?

Habe bei dem einen Exemplar das ich heute testweise mal gelötet habe recht schwer damit getan das das Lötzinn auf der Platine haften blieb.
Das kannte ich so von anderen Platinen/Lötprojekten nicht so.
Mache ich da was falsch oder ging das anderen hier auch so?

[abtools]

Hallo Michael,

Was ist eigentlich die beste Art nach dem löten einen Funktionstest durchzuführen?

Gibt eine Diagnose-Befehl "sen test mode":
Dann werden alle Sensoren getestet und entsprechende Ausgaben gemacht.

Geht vermutlich auch über Diagnose-KO, aber am besten direkt per Konsole ausführen.

Habe bei dem einen Exemplar das ich heute testweise mal gelötet habe recht schwer damit getan das das Lötzinn auf der Platine haften blieb.
Das kannte ich so von anderen Platinen/Lötprojekten nicht so.
Mache ich da was falsch oder ging das anderen hier auch so?

Wenn das Lötzinn nicht auf dem Lötpad haftet, ist es vermutlich einfach nicht heiß genug:
Also entweder du bist zu ungeduldig oder du brauchst mal einen neuen Lötkolben. ;-)

Viele Grüße
Andreas

[LostWolf]

Danke Andreas für die schnelle Rückmeldung.

Gibt eine Diagnose-Befehl "sen test mode":
Dann werden alle Sensoren getestet und entsprechende Ausgaben gemacht.

Dann werde ich mich mal mit der Konsole dafür beschäftigen.

Wenn das Lötzinn nicht auf dem Lötpad haftet, ist es vermutlich einfach nicht heiß genug:
Also entweder du bist zu ungeduldig oder du brauchst mal einen neuen Lötkolben. ;-)

Habe zuerst mit 350°C gearbeitet und dann hoch auf 370°C.
Komischerweise war das anlöten an die BCU deutlich einfacher.
(ist Lötzinn mit Blei und Flussmittel)

[willisurf]

ist Lötzinn mit Blei und Flussmittel

Da sollten eigentlich 350° genügen, wenn der Lötkolben ausreichend leistungsfähig und mit guter Temperaturregelung ist.

[LostWolf]

Müsste eigentlich, ist eine (recht selten genutzte) RDS80 (80W) von Elsner.

[LostWolf]

mhm, ich habe da scheinbar ein Problem
Die aktuelle RaumController Firmware installiert und die Applikation per ETS geladen.
Im Busmonitor sehe ich die Werte:
image.png
Aber PuTTY liefert keine erkannten Sensoren (außer dem HLK):
image.png

An was kann das liegen?
Muss für einen erfolgreichen Test der knx Bus verbunden sein?
Habe diesen getrennt als ich eine Serielle Verbindung per Konsole hergestellt habe

UPDATE:
Ja muss wohl knx-Bus und eine serielle Verbindung zum PC bestehen:
(achtet darauf das ihr einen USB Isolator benutzt!)
image.png
Ich lasse das trotzdem mal online, falls wer Anders auch das Problem mal hat.

[willisurf]

Ja muss wohl knx-Bus und eine serielle Verbindung zum PC bestehen:
(achtet darauf das ihr einen USB Isolator benutzt!)

Kurz noch ergänzt:
Die allgemeine Empfehlung ist entweder KNX oder USB, hier für den Test wird ja aber scheinbar beides benötigt.

Es gibt dann zwei Sachverhalte (für alle OpenKNX oder OpenKNX-Ready Geräte), die zu beachten sind:

• Der USB Isolator verhindert, das es Masseeinkopplungen/Verbindung zum KNX System gibt (ist also gut), genügt aber nicht um ganz sicher zu sein
• Intern gibt es dann zwei Spannungsversorgungen, diese sind zwar über Dioden entkoppelt, ich empfehle nach Untersuchungen zur Spannungsversorgung trotzdem immer zuerst die KNX Verbindung und erst danach die USB Verbindung herzustellen. Beim Trennen dann umgekehrt, d.h. zuerst USB trennen (obwohl das nicht mehr so essentiell ist).

Für interessierte noch der Hintergrund: Der NCN kann (selten) in instabile Zustände kommen, wenn er gegen eine Spannung aufstartet. Dies wäre ja der Fall, wenn zuerst USB und dann erst KNX verbunden wird. Daher vermeide ich das. Ich weiß es gibt viele Entwickler, die dies regelmäßig machen und es gibt kein Problem. Aber sicher ist sicher...

T.L.D.R: Im Normalfall nur entweder USB oder KNX verbinden
Wenn funktional beide Verbindungen notwendig sind, einen USB Isolator benutzen (oder ein Laptop mit Akkubetrieb)
und erst KNX und dann USB anschließen.

[abtools]

Hallo zusammen,

auch nur zur Ergänzung:
Den "sen test mode" habe ich bisher nie nur mit KNX (ohne Serial/Progger) ausgeführt. Eigentlich würde ich erwarten, dass das auch geht, aber bisher nicht getestet.
Kann ich aber sicherlich mit Waldemar mal ausprobieren und ggf. fixen, wenn das mit "nur KNX" aktuell nicht geht.

Aber er geht 100 % mit nur Serial/Progger, solange beim Progger "Vcc2" auf "3V3" steht - so mache ich das nämlich immer, wenn ich etwas testen.

Also um diesen Testmodus auszuführen, ist grundsätzlich keine KNX-Verbindung erforderlich und das Gerät muss auch noch nicht einmal mit der ETS parametrisiert worden sein. Es genügt den Progger anzustecken, Firmware aufzuspielen und dann direkt den Testmodus über "sen test mode" in der Konsole zu starten.

Viele Grüße
Andreas

[LostWolf]

Aber er geht 100 % mit nur Serial/Progger, solange beim Progger "Vcc2" auf "3V3" steht - so mache ich das nämlich immer, wenn ich etwas testen.

Danke für die Info, dass habe ich natürlich nicht getestet gehabt 😅

Kann ich den mit "nur KNX" überhaupt eine Konsolenverbindung herstellen?
Braucht das nicht eben die serielle Verbindung über den Progger?

[mumpf]

sen test mode ist nur für unconfigured Geräte gedacht. Wenn das im laufenden Betrieb ausgeführt wird, kann zumindest ein Enduser nicht beurteilen, inwiefern das Ergebnis aussagekräftig ist - selbst ich muss den jeweiligen Fall immer analysieren.
Außerdem ist der Befehl neu und möglicherweise funktioniert noch nicht alles.
Gedacht ist er vor allem für HW-Test nach dem löten, damit man ohne proggen möglichst schnell schauen kann, ob alle Sensoren antworten. Das ist ein erster Indikator, dass korrekt gelötet wurde und das die Sensoren was tun.

Gruß, Waldemar

[Techi]

Ich wollte heute meinen ersten UP1-PM-HF in Betrieb nehmen. (OAM Sensor Module 4.2.5-Big)
Bezüglich Sensoren, bestückt ist nur der HF Sensor (HLK-LD2420).

Das Gerät ersetzt einen MDT SCN-BWM55.01 welcher im Keller auf ca. 2m Höhe an der Wand montiert ist und längs die Kellertreppe hoch schaut.
Hier konnte der MDT PIR Melder nie gut performen weil man ja auf den Melder zu- bzw. weg-gelaufen ist.
Ich erhoffe mir hier die Vorteile eines HF Melders nutzen zu können welche hier wesentlich besser funktionierten sollten.

Leider komme ich mit den HF Parametern einfach nicht wirklich zurecht.
Ich bräuchte eigentlich einen MIN. Funktion der Ruhephase um einen wirklich guten Haltewert finden zu können.
Gibt es einen Grund warum das nicht vorgesehen ist ?
Für den Trigger Wert ist MAX. ja wirklich super aber für Halten wäre halt MIN eine wirklich brauchbare Funktion.
"Standard Abweichung" und "Durchschnitt" hilft um die Offsetz zum Einschalten besser abschätzen zu können aber für "Halten" nicht wirklich.

Wie geht Ihr vor wenn Ihr den "Halten" Wert finden wollt ?

Noch was, ich muss auch immer die Applikation hochladen das mit dem "Einstellungen ausprobieren" funktioniert nicht.

LG, W.

[mumpf]

Gibt es einen Grund warum das nicht vorgesehen ist ?

Ja, es würde Dir nicht helfen, weil der Wert nicht das repräsentiert, was Du erwartest .
Es ist eine Stichpobe von einem Rauschen - das Minimum geht über beliebige Werte bis zur 0 - war nicht aussagekräftig.
Es geht um Halten. Der Durchschnittswert ist ein guter Anhaltspunkt. Wenn es zur Dauerpräsenz führt, kannst Du mit niedrigeren Werten probieren. Ich gehe immer in 100er-Schritten, für Detailanpassung dann 50er. Wenn Du ein Minimum (als Richtwert) schätzen willst, nimmst Du

Durchschnitt - (Standardabweichung - Durchschnitt)

Das ist die Standardabweichung "nach unten".

Noch was, ich muss auch immer die Applikation hochladen das mit dem "Einstellungen ausprobieren" funktioniert nicht.

Dann hast Du eine Schnittstelle oder LK, der eine zu kurze APDU hat. Dann musst Du es über die Applikation machen.

Gruß, Waldemar

[Techi]

Ja, es würde Dir nicht helfen, weil der Wert nicht das repräsentiert, was Du erwartest .
Es ist eine Stichpobe von einem Rauschen - das Minimum geht über beliebige Werte bis zur 0 - war nicht aussagekräftig.
Es geht um Halten. Der Durchschnittswert ist ein guter Anhaltspunkt. Wenn es zur Dauerpräsenz führt, kannst Du mit niedrigeren Werten probieren. Ich gehe immer in 100er-Schritten, für Detailanpassung dann 50er. Wenn Du ein Minimum (als Richtwert) schätzen willst, nimmst Du

Das ist die Standardabweichung "nach unten".

Ok, dann probier ich weiter

Dann hast Du eine Schnittstelle oder LK, der eine zu kurze APDU hat. Dann musst Du es über die Applikation machen.
...

Der Vorgang "Parameterscript..." wird erfolgreich ausgeführt, aber die Änderungen zeigen keinerlei Effekt, erst wenn ich die Applikation komplett neu lade ändert sich was.

[mumpf]

Der Vorgang "Parameterscript..." wird erfolgreich ausgeführt, aber die Änderungen zeigen keinerlei Effekt, erst wenn ich die Applikation komplett neu lade ändert sich was.

In dem Online-Progress (rechts in der ETS) sollten die Meldungen:
"PM: Schreibe Halten und Trigger ..."
"PM: Halten geschrieben"
"PM: Trigger geschrieben"
"PM: HF-Sensor wird neu gestartet ..."
stehen, die ersten 3 womöglich so schnell hintereinander, dass man das nicht lesen kann, der letzte sollte aber knapp 30s da stehen.
Das Diagnoseobjekt sollte beim Neustart des HF-Sensors auch ein "HLK reb hard" ausgeben.
Ich hab geschaut, ich schreibe nur 16*2+4+2 = 38 Bytes, das ist für alle aktuellen Schnittstellen kein Problem (mit APDU >=55), nur für die alten, die APDU < 30 hatten, ist es problematisch. Was für Schnittstellen bzw. LK liegen denn zwischen ETS und dem Gerät?
Trotzdem: Programmieren der Applikation ist immer ein gut funktionierender Fallback.

Ok, dann probier ich weiter

Was ist denn das Problem? Vielleicht kann ich ja helfen?
Halten ist normalerweise recht einfach einzustellen. In vielen Fällen geht einfach der Durchschnitt. Führt das schon zur Dauerpräsenz, versucht man es mit der Standardabweichung. Das ist "fürs Grobe". Zum Feintuning:

• Die vom Sensor gemessene Entfernung über den Bus ausgeben lassen.
• An der kritischen Stelle schauen, welche Entfernung der Sensor misst.
• In dem entsprechenden Range den Haltewert höher stellen bei Dauerpräsenz...
• ...oder entsprechend niedriger stellen bei zu frühem Präsenzabfall
• Die beiden benachbarten Ranges auch etwas modifizieren, damit die Werte möglichst eine Kurve und keine Treppe ergeben, da die Ranges nicht scharf abgegrenzt sind.

Da Du eine Treppe überwachen willst, somit keine echte Präsenz brauchst, sollte das Halten gar nicht so relevant bei Dir sein, deswegen verstehe ich das Problem nicht wirklich...

Gruß, Waldemar