Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
[OpenKNX-Ready] Präsenzmelder und Multisensor: Diverse Sensoren & Binäreingänge
Benni620 Da Du die Rohsignale des HF Sensors und des PIR als KO zur Verfügung hast, kannst Du mit dem ja ebenfalls integriertem Logikmodul (99 Kanäle) und dem VPM (40 Kanäle) alles beliebig zusammenbauen.
Diskutiert haben wir, in einer späteren Software die Signale auch bereits intern noch flexibler nutzbar zu machen.
Ob das man direkt einstellen kann, weiß ich nicht. Also ob Du direkt interne Sensoren einzeln selektieren kannst.
Du kannst aber sagen, dass Du externe und keine internen Sensoren nutzen möchtest und dann kannst Du bei den Eingängen direkt die bestehenden KO's der Rohdaten verbinden oder allgemein GA's, welche mit den Rohdaten verknüpft sind.
Funktionieren wird das also.
Wenn ihr wüsstest.. Was ich alles an DIY Projekten hier aus dem Forum schon in Kundenanlagen gefunden habe.. Sogar gewerblichen Projekten. Da blickt niemand durch was verbaut wird.
Dieser Beitrag enthält keine Spuren von Sarkasmus... ich bin einfach so?!
Was ich alles an DIY Projekten hier aus dem Forum schon in Kundenanlagen gefunden habe.
Aber die wird doch der Kunde installiert haben, oder? Das darf er ja ruhig, solange er der ETS kundig ist (wobei die Frage bleibt, ob es überhaupt jemanden gibt, der der ETS kundig ist ).
Oder es ist dann ein DIY vom Elektriker, und er wartet das dann entsprechend. Keine Ahnung. Wenn ich mit Systemintegratoren oder KNX-kundigen Elektrikern gesprochen habe, hieß es immer, dass es vollkommen egal ist, wie gut unsere Geräte funktionieren, im professionellen Umfeld kann man die soweiso nicht einsetzen. Und mir war das durchaus recht.
Benni620 Zu den Rohsignalen möchte ich noch ergänzen, dass es für die Tests am Anfang Sinn macht, das normal über GAs zu verbinden, um zu schauen, wie sich alles verhält. Aber ansonsten würde ich Rohsignale direkt über interne KO-Verknüpfungen machen, denn die Rohsignale müllen Dir ganz schön den Bus zu, wenn jemand im Raum ist .
Ihr habt es geschafft. Nun habe ich mir auch mal einen zum testen bestellt. Den PIR habe ich allerdings nicht mit bestellt.. Nach Euren Ausführungen denke ich, dass zumindest im kleinen Büro dieser nicht benötigt wird.
Beeinflusst eigentlich der VOC-Sensor gar nicht die Temperatur im Gehäuse? Die arbeiten doch eigentlich mittels verdampfen oder?
Beeinflusst eigentlich der VOC-Sensor gar nicht die Temperatur im Gehäuse? Die arbeiten doch eigentlich mittels verdampfen oder?
Stimmt, aber die Messung erfolgt nicht kontinuierlich und, ich vermute, es ist auch nur eine sehr kleine "Kammer", die da tatsächlich aufgeheizt wird.
Daher tragen die Teile kaum etwas zur Wärmeentwicklung bei, da fällt die MCU bzw. auch die BCU mehr in's Gewicht.
Da das Gehäuse insgesamt jedoch relativ groß und die einzelnen Komponenten (durch die Modularität/Steckbarkeit) stark voneinander getrennt sind, konnte ich bisher keine nennenswerten Auswirkungen auf die Temperaturmessung feststellen.
das hört sich schon einmal gut an. Geplanter Einsatz bei mir ist ersteinmal im Büro, vielleicht aber auch als temporärer Ersatz im Kinderzimmer für einen Steinel, der eingeschickt wird. Wenn ich dazu komme, kann ich ihn also in mehreren Räumen testen und vielleicht auch mal einen Vergleich mit dem Steinel anstellen (Erkennung und Sensoren).
Meine Hoffnung ist ja, dass der die Steinel ersetzen kann. Wer weiß, wie lange die noch funktionieren .
Ich bin auf jeden Fall schon einmal gespannt und freue mich.
Beeinflusst eigentlich der VOC-Sensor gar nicht die Temperatur im Gehäuse?
Nein, das funktioniert sehr gut. Hier mal ein Temperaturmitschrieb eines vollbestückten Multisensor (BME680, VEML, SCD41, PIR und LD2420) montiert unter der Decke auf 2,65m Höhe im Vergleich zu einem Glastaster Temperatursensor, der ca. 2m entfernt auf 1,5m Höhe hängt. Der Temperaturoffset des SCD41 ist nur auf 0,2K eingestellt.
Die Höhe der Sprünge sind 0,1K. Die etwas größere Abweichung zu Beginn kommt, weil quergelüftet wurde und der GT mehr vom Durchzug abbekommt und Nachts wirkt ein wenig die Temperaturschichtung.
Die 16 Kanäle repräsentieren um 70cm versetzte "Donuts" um den Sensor herum. Kanal 1 macht also 0-70cm, Kanal 2 70-140cm, Kanal 3 140-210cm, wobei die Trennung nicht absolut scharf ist und mit zunehmenden Abstand immer mehr verwischt.
Also wenn die Tür noch im Erfassungsbereich liegt,
z.B. 180cm Abstand, dann sollte man doch besser noch einen PIR am Eingang zusätzlich verwenden (vor allem bei offener Tür)?
Aktuell setze ich noch den TP im Gästebad ein, könnte mir aber vorstellen den gegen euren Melder zu ersetzen.
Viele Grüße
Korbinian
- Nobody is perfect!
- Fehler passieren, wichtig ist was man daraus lernt!
Also wenn die Tür noch im Erfassungsbereich liegt,
z.B. 180cm Abstand, dann sollte man doch besser noch einen PIR am Eingang zusätzlich verwenden (vor allem bei offener Tür)?
Muss man schauen, ggf. genügt auch die Abgrenzung über Entfernung, ist allerdings im 0,7m Raster und auch nicht beliebig trennscharf. Der PIR vom Multisensor lässt sich nicht gut in der Entfernung eingrenzen (wie bei allen PIR) und hilft dann nicht. Aber an der Tür passt das natürlich.
Wegen der Ansprechgeschwindigkeit benötigt man den PIR definitiv nicht, da ist der LD2420 superschnell.
Bzgl. PIR wäre z.B. ein Infrarot Temperatur Array Sensor für die Zukunft vielleicht eine Lösung. Panasonic hat da was im Angebot mit 8x8 Pixeln (AMG88).
Allerdings nur mit einem FOV von 60 Grad.
(Braucht dann wohl auch eine Optik dazu)
Prinzipiell wären aber dann eine feinere Zonierung durchaus möglich und mit HF kombiniert auch die dauerhafte Präsenzerkennung.
Viele Grüße
Korbinian
- Nobody is perfect!
- Fehler passieren, wichtig ist was man daraus lernt!
ich habe soeben das SensorModule-Big-3.2.10 Release freigegeben. Dieses Release bitte unbedingt verwenden, wenn ihr den Multisensor-PM verwendet. In der Firmware stecken alle Erkenntnisse drin, die abtools und ich in unseren Tests und mit Testern (hier besonderer Dank auch an willisurf) gesammelt haben.
Weil ich hier immer wieder lese "ich will damit den TP ersetzen": Das kann klappen, muss es aber nicht. Derzeit haben wir einen Stand, bei dem wir glauben, dass man mit den Standardeinstellungen für
Empfindlichkeit
Entfernung von/bis
Verzögerung
sehr weit kommt und das gewünschte Präsenzerlebnis erreicht. Aber wir haben kein Labor und testen die Funktionalität im privaten Umfeld in realen Situationen. Auch wenn ich fest glaube, dass das ein Vorteil ist, heißt es trotzdem nicht, dass ich in 20 Räumen diesen Melder habe. Ich teste mit einem Melder verschiedene Situationen nach und nach, und der bleibt auch mal 1-2 Wochen an einer Stelle. Das selbe läuft auch bei Testern so.
Wir können noch gar nicht alle Situationen erfasst haben und wünschen uns Feedback aus dem Feld. Es wird Probleme geben und es wird bei einigen nicht so funktionieren, wie sie sich das vorgestellt haben. Und dann müssen wir gemeinsam analysieren und schauen, was man verbessern kann.
Das ist der Stand der Dinge.
Ich wollte für interessierte noch ein paar Parameterwerte mitteilen, mit denen ich bisher recht gut gefahren bin. Heißt nicht, dass andere Werte nicht funktionieren, sondern dass sie in den aktuellen Testszenarien nicht benötigt wurden:
Empfindlichkeit: 80%-100%, meist bin ich mit 90% unterwegs und schaue mal, ob es in Grenzsituationen mit 80% oder mit 100% besser wird.
Entfernung von: 0.7m (Range 1). Fragt mich nicht warum, es war bisher nie nötig, auch 0m (Range 0) zu nutzen.
Entfernung bis: 2.8m (Range 4), 3.5m (Range 5) oder 4.2m (Range 6). Hab noch in keinem größeren Raum getestet
Verzögerung: >10 Sekunden. Ich teste viel, was hier möglich ist, und bin bis auf 1s runter, das funktioniert nicht. Das beste, was zuverlässig funktionierte, waren 3s, aber nach einer Umparametrisierung hab ich das nicht wieder zuverlässig hinbekommen, war also eher Glück. 10 Sekunden ist immer noch sehr gut!
In der PM-Applikation (in den Tagesphasen) sollte die Nachlaufzeit mindestens 3 Sekunden sein!! Manchmal "verschluckt" sich der HF-Sensor und schickt für 1-2 Sekunden ein AUS-Signal, wieder gefolgt von einem EIN. Mit 3 Sekunden kann man das stabil überbrücken, aber man kann natürlich auch viel längere Nachlaufzeiten machen.
Andreas hat in dieser Version viele Diagnosemöglichkeiten für diesen Sensor eingebaut, um verschiedene Umgebungen analysieren zu können. Deswegen solltet ihr unter "OpenKNX->Erweitert" das "Diagnoseobjekt anzeigen" aktivieren und eine GA mit KO 7 verbinden. Wir werden sicher - wenn hier rückfragen kommen - über diese GA ein paar Analysedaten sehen müssen.
Ebenso solltet ihr schon jetzt bei "Präsenzmelder->Allgemein" bei "Präsenz-Rohdaten auf den Bus senden" das JA aktivieren und eine GA mit KO 28 (Reset HF-Sensor) verbinden. Der Reset löst eine Neukalibrierung aus, und das sollte man machen, wenn der Raum leer ist. Es dauert ca. 30 Sekunden, manchmal braucht er 2 Versuche, dann sind es ca. 75 Sekunden. Über die Diagnose sieht man den Fortschritt der Kalibrierung, es werden
HLK cal start
HLK cal done
HLK cal send
HLK reb hard
ausgegeben. Wichtig ist: Man muss nicht dauernd rekalibrieren. Die oben beschriebenen Parameter Empfindlichkeit, Entfernung und Verzögerung können angepasst werden und erfordern keine neue Kalibrierung. Bei der Kalibrierung wir das Energieniveau des Raumes erfasst und bleibt üblicherweise so. Neu kalibrieren muss man eigentlich nur, wenn man was gravierend am Raum geändert hat und der Melder dann "dauer AN" oder "dauer AUS" macht.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar