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

[habreli]

Was mir auch auffällt:
In der ETS steht bei den Sensoren / Allgemein / VOC:
Der VOC-Sensor braucht bis zu 2 Tage für die Kalibrierung, das KO 24 gibt den Fortschritt in % aus
Ich habe das KO24 aber nicht für den Fortschritt, sondern das KO88.

[willisurf]

Ja, das kann sein, das im Text noch die alten KO Nummern auftauchen. Ist aber kein Problem.

[habreli]

Ich konnte es nachträglich nicht feststellen. Aber es war natürlich ! vermutlich die Hardware falsch. Ich habe die .knxprod neu erstellt und mit der Bestehenden verglichen. Da waren doch ein paar Bytes verdreht. Also auch neu geflasht und siehe da - VOC klappt wie erwartet.
Vielen lieben Dank an Alle welche sich nun Mühe gegeben haben,
Hans

[willisurf]

Prima!

Nur zur Einordnung, die knxprod ist hardwareunabhängig und bezieht sich immer genau auf einen Softwarestand.

Aber ja, bei der Firmware ist es wichtig, die passende Firmware für das jeweilige Gerät auszuwählen.

[mumpf]

habreli: Nur zur Einordnung für Dich (und andere, die hier mitlesen):

• Die knxprod, die Du lokal baust, nennen wir ETS-Applikation oder abgekürzt Applikation.
• Eine Applikation hat eine Version (z.B. RaumController 5.1) und besteht ihrerseits aus Modulen, von den jedes auch eine Version hat (bei Dir Sensormodul 4.10)
• Ein Release besteht aus einer Applikation und der zugehörigen Firmware, deren Versionen sind 3-Stellig (z.B. RaumController 5.1.5). Alle Firmwares passen zu der Applikation, die die gleichen ersten 2 Stellen hat. Die 3. Stelle gibt letztendlich die Korrekturversion an, wird ein Bug in der Firmware gefunden, wird dieser korrigiert und die letzte Stelle erhöht. Die Applikation muss nicht geändert werden.
• Ein Release kann auf einem oder vielen Geräten (Hardware) laufen. Die Geräte haben alle Namen und eigene Versionsnummern.
• In den meisten Fällen schaffen wir es, in der Firmware passend auf die verschiedenen Hardwareversionen zu reagieren.
• In den wenigen Fällen, in den das nicht klappt, führen wir beim Firmwarenamen auch die Version mit.
• Man muss unbedingt die korrekte Firmware (passender Name - und falls aufgeführt - auch die passende Version) auf das Gerät spielen.
• Welche Firmware aufgespielt ist, sieht man in der Konsole des Gerätes.
• Falls das Gerät nach dem Aufspielen der Firmware nicht reagiert, dann ist das ein guter Hinweis, dass es die falsche Firmware war.

Die Firmware wäre OAM-RaumController v5.1.5-Release

Das ist das Release, dass Firmware und Applikation enthält. Die Firmware für das abgebildete Gerät ist

firmware-AB-SmartHouse-PresenceMultiSensor.uf2

und steht im Verzeichnis

AB-SmartHouse-PresenceMultiSensor

Sensormodul ist V4.10

Das war ein Missverständnis, das wir derzeit leider häufig haben. Hintergrund:

• Es gibt das Sensormodul als Softwarekomponente, derzeit in der Version 4.10
• Es gibt eine Hardware "Sensormodul", die gibt es in den Versionen 4.0, 4.1, 4.2 und 4.3.

Bei gleichzeitiger Erwähnung von Präsenz Multi Sensor (Hardware) und Sensormodul dachten wir beim zweiten auch an Hardware. Und das hätte nicht zusammen gepasst. Im RaumController 5.1.5 ist das Sensormodul 4.10 enthalten, das ist vollkommen korrekt.

Gruß, Waldemar

[gkrit]

Hi everyone,

I’m wiring a new KNX house and I’m planning to use OpenKNX 24GHz presence sensors (HLK-LD2420 based) in almost every room.

Challenge: in (almost) every room there will be a ceiling fan mounted in the center of the ceiling.
I’m worried the fan (moving hub/motor reflections + periodic Doppler) could cause false presence or “stuck occupied” while the fan is running.

Fan model (0–10V version):
https://b2b.ventilator.de/en/ceiling...bn-nbki-0-10-v
Important detail: the blades are WOOD (non-metal). Only the motor/hub/canopy/screws are metal.

From the discussions here I understood:
- The detection range can be limited very well (70cm steps / rings).
- Sensitivity can be tuned via threshold/hold values (but needs testing).
- There is also an option to use PIR as a “trigger/arming” sensor and let the radar maintain presence.

My questions:
1) If I set “Distance from = 0.7m (Range 1)”, does it truly ignore the entire 0–70cm ring, so a center-mounted ceiling fan won’t trigger presence?
(Blade tips are roughly ~0.71–0.75m away from the ceiling center sensor depending on downrod, so it’s close to the 0.7m boundary.)
2) If Range 1 is borderline due to blurred ring edges, would “Distance from = 1.4m (Range 2)” be the recommended safe option for rooms with ceiling fans,
while still reliably detecting people on the floor?
3) For this “fan in the center” use case: is the best practice to increase trigger threshold (to avoid fan peaks) while keeping hold tuned for a stationary person?
Any recommended starting values/strategy?
4) PIR + radar concept: can I configure it so that PIR is required to switch from NO presence to presence (arming/trigger),
and radar is then used mainly to HOLD presence (so the fan cannot create the initial ON by itself)?
If yes, which device/app setting is this in (VPM / Multisensor PM), and does it work well in practice?

Calibration question:
Should calibration always be done with the room empty and the fan OFF (then rely on distance/thresholds), or is there any benefit calibrating with the fan ON?

Bathrooms:
Two bathrooms will have no ceiling fans, but limited ceiling height, so I’m considering UP1-PM-HF (wall-mount). Any placement tips are welcome.

Thanks a lot!

[mumpf]

1) If I set “Distance from = 0.7m (Range 1)”, does it truly ignore the entire 0–70cm ring, so a center-mounted ceiling fan won’t trigger presence?

The first ring ist 0-0.35m (70 cm diameter). And no, we are talking about HF signals, nothing is exact or even measureable - you have to test any situation you need.
And - for all length dependant values: The relevant value is NOT what you measure with you ruler. It is the value, which is measured by the sensor itself. And this is not predictable in special situations.
If I am in my shower (which is 3m from the sensor) with door closed, it measures a person in about 4.2m distance. Just as an example...

so it’s close to the 0.7m boundary.

Very important: There is no boundary - just reflected HF fields.

the recommended safe option

No, there is no safe option. To be very clear: We have no experience with rooms, where something moves constantly. You can try this in one room and tell us, how it behaves. But it is not a good idea, to plan anything before you tested everything.

I would not expect, that this PM can work with a moving fan as expected. I would expect a permanent presence signal from the sensor.

Regards, Waldemar

[gkrit]

Thanks a lot, Waldemar — that explanation helps a lot and makes it very clear what to expect.

Understood that there is no strict boundary/ring cutoff and that the “distance” is the sensor’s own measurement, which can differ significantly from real geometry.

I’ll proceed by buying a single unit first and testing it in one room with a ceiling fan (different speeds / scenarios). I’ll report back with the results.

Best regards

[habreli]

Ich muss nochmals auf mein Problem mit den nicht gesendeten VOC Werten zurückkommen.
Dies hat sich ja nach dem Flashen der korrekten Firmware behoben.
Zumindest bis vor 2 Tagen.
Seit diesem Zeitpunkt kommen keine Werte mehr auf der besagten GA.
Ich hätte zwischenzeitlich testweise auch schon auf zyklisches Senden (alle 10 Sek.) umgestellt - es kommt gar nichts.
Dann ist mir noch aufgefallen dass auch auf der GA des Luftdrucksensors (auch BME680) keine Daten mehr kommen.
Kann man irgendwie testen ob dieses Sensormodul noch "lebt" ?
Oder gibt es eine andere Vorgehensweise ?
Ich habe leider kein zweites derartiges Modul zum Tauschen hier.
Danke, Hans

[willisurf]

Hast Du auch einen SCD40/41 verbaut?

[habreli]

Ja, ein SCD41 ist vorhanden.
CO2 Werte z.b. werden auch geliefert.

[willisurf]

Es gibt noch ein Problem, wenn beim Multisensor mit der neuen Firmware 5.1.5 sowohl BME680, als auch SCD40/41, VEML und HLK verbaut sind.
Wir arbeiten daran, umgehen lässt es sich, wenn man einen Sensor entfernt (vorzugsweise den SCD) und auch in der Software deaktiviert.
habreli Könntest Du ja mal probeweise testen.

[LostWolf]

Danke dir die Info

Wie äußert sich das Problem?
Hätte hier vier Geräte im Aufbau mit genau dieser Sensorkombination.

Lieber hier mit dem aufspielen der Software warten? (verbaut werden die erst in ein/zwei Monaten)
Oder zum Funktionstest einen älteren Softwarestand laden? (wenn ja welchen?)

[willisurf]

Es müsste wahrscheinlich genügen, den SCD in der Software zu deaktivieren. Einen älteren SW Stand würde ich nicht nutzen.

Und bis zu Deiner Anwendung wird es ein neues Release geben (sage ich jetzt mal…)

[habreli]

Umgehen lässt es sich, wenn man einen Sensor entfernt (vorzugsweise den SCD) und auch in der Software deaktiviert.
habreli Könntest Du ja mal probeweise testen.

Zur Info:
Ich habe mal testweise den SCD nur softwaremäßig deaktiviert. Ab diesem Zeitpunkt lieferte der BME680 wieder Werte.
Somit warte ich "einfach" auf ein angepasstes Softwarerelease. Danke für deinen Einsatz dafür.