OpenKNX-Sensormodul release

[LostWolf]

Mal wieder deine dumme Idee von mir 😅
Wäre es möglich zwei TOF Sensoren an einer Hardware zu betreiben und durch die (zwar minimale) zeitliche Differenz der Auslösung (bei Anforderung nebeneinander) auswerten zu können in welche Richtung eine Person sich bewegt.

Wäre an z.B. Treppen recht interessant

[mumpf]

Dumm nicht, aber mit der aktuellen Firmware nicht zu machen. Die Sensormodul-Firmware ist ca. 5 Jahre alt (wenn auch schon paar mal überarbeitet und erneuert), aber das Grundkonzept ist immer noch so, dass nur ein I²C-Bus abgefragt wird. Somit sind mehrere Sensoren nur möglich, wenn sie verschiedene I²C-Adressen haben. Soweit ich weiß, hat der TOF aber nur eine I²C-Adresse - somit muss man für Deinen Ansatz mehrere I²C-Busse nutzen.
Ich hab sogar Ideen, wie man das realisiert. Aber das bedeutet die Kernfunktion der Sensorabfrage (für alle Sensoren) neu zu schreiben. Und da hab ich mich noch nicht dran versucht...
Aber selbst wenn das ginge, ist es noch offen, wie man eine Richtung über Entfernungsmessung rausfinden will. Denn man kann auch so schräg zum Sensor gehen, dass als Delta zwischen den Sensoren der Abstand wächst und nicht sinkt, wie man es erwarten würde. Und dann erfolgen die Messungen nicht kontinuierlich, sondern diskret 4-5 mal pro Sekunde. Das reicht nicht, um beim schnellen vorbeigehen auch noch die Richtung festzustellen, zumindest nicht zuverlässig.
Und dann gibt es noch den Punkt, dass ich an solche Richtungsauswertungen nicht wirklich glaube, das geht schief, wenn mehr als eine Person im Haushalt lebt. Und da wir zu fünft sind, sehe ich keinen Anlass, so was zu versuchen .

Gruß, Waldemar

[willisurf]

Ich glaube auch, das man solche Richtungserkennung nicht wirklich braucht, bzw. es nicht robust/trennscharf genug ist.
Einzig der BWM55 mit seinen 2 Sensoren kann da etwas direkt liefern.

LostWolf wenn Du Lust zum experimentieren hast, kannst Du versuchen das Rohsignal Entfernung des Radarsensors (am besten über interne Verknüpfung) auszuwerten und über einen Logikkanal den Gradienten zu berechnen und ggf. zu filtern.

[SchAndy]

Moin, ich stell einfach mal dumm meine Frage hier, sollte das falsch sein, bitte verschieben o.ä.
Ich habe einen OpenKNX HF Sensor von ab-smarthouse hier und haben den auch geflasht und eingebunden zum testen usw.
Meine Frage ist, einfach nur aus Interesse, muss man ab und an mal gucken ob es neue Firmware gibt und das Gerät dann neu Flashen und alles neu einstellen oder ist das ehr die Ausnahme statt die Regel das man sowas macht.
Die gleich Frage gilt für die KNX ETS Datei. Aber ich nehme an, wenn man die in einer neuen Version importieren will, weil z.b. neue coole Funktionen eingefügt wurden, muss man auch die passende Firmware neu Flashen richtig?

VG!

[shortyle]

Also in der Regel werden FW und ETS Applikation immer zusammen aktualisiert, da voneinander abhängig. Das betrifft im Übrigen alle OpenKNX Hardware. Vereinzelt gibt es Minor FW Updates die keine neue Applikation verlangen. Das schreiben die Herausgeber aber immer mit dazu.

Eine komplette Neuparametrierung in der ETS ist, bei korrekter Aktualisierung (Button „Aktualisieren“ statt Auswahl aus Dropdown-Menü), im Normalfall nicht notwendig.

[SchAndy]

Ah okay, danke für die Info.

Eine komplette Neuparametrierung in der ETS ist, bei korrekter Aktualisierung (Button „Aktualisieren“ statt Auswahl aus Dropdown-Menü), im Normalfall nicht notwendig.

Das verstehe ich aber nicht so genau. In der OpenKNX Toolbox gibt es ja nur den Punkt "Firmware aufspielen" und nicht "aktualisieren". Das aktualisieren, aktualisiert ja nur die Liste in der Toolbox selber oder nicht? Und dann bekomme ich auch eine neue Applikation, die ich auch erst ein die ETS laden muss, damit ich die neue Version nutzen kann oder wie aktualisiert man die Applikation? Edit, gerade gefunden wie das in der ETS geht. Die andere Frage bleibt aber bestehen^^

[traxanos]

https://openknx.atlassian.net/wiki/s.../pages/9469953

[willisurf]

Die andere Frage bleibt aber bestehen^^

Ein Release besteht immer aus den beiden Komponenten Firmware und Applikation.
Die Firmware wird mit der Toolbox oder mit einem Windows PowerShell Script geflasht
Die Applkation wird von der Toolbox oder einem Shellscrpt erzeugt, danach importiert, ins Projekt kopiert und dann kann in der ETS die bestehende Applikation wie oben beschrieben aktualisiert werden. Dabei bleibt alles erhalten.

Die Shellscripte sind normalerweise auch Bestandteil des Release und die Anwendung ist einfach. Man muss nur vorher einmal ggf. die Powershell Settings anpassen. Siehe
https://openknx.atlassian.net/wiki/s...rShell-Scripte

[willisurf]

..Doppelpost

[Triox85]

Hier dein alter Post:
Moin moin und danke für die tolle Möglichkeit über KNX eigene Sensoren auf den Bus zu bekommen.

Ich habe mir alle 17 Seiten durchgelesen und komme gerade nicht weiter.

Zur Hardware: SEN-UP1-8xTH (V00.20a)
Firmware: 4.2.5 vom 10.03.2025 (OAM-SensorModule)
Applikationsprogramm: Sensor-Wire-PM-Logic-Button-BI V4.2

Die Firmware habe ich mit dem Tool OpenKNX Tollbox auf den RP2040 geflasht und mir auch die KnxProd darüber erstellen lassen und in die ETS 6.3.0 gezogen.
Das klappt alles.

Ich versuche die Werte Temperatur und Luftdruck für den BMP280 mit der i2c Adresse 0076 zu erhalten - leider ohne Erfolg.
Gleiches mit den Werten für den BME680 mit der i2C Adresse 0076 oder auch 0077 ( ohne den BMP280 installiert zu haben) - dazu noch die Werte Voc,Co2 und Feuchte. - auch hier kann ich keine Werte empfangen über den Busmonitor.
Auch der SCD30 gibt keine Werte aus.
Wenn ich jedoch den SHT3x installiere, oder den SCD40, oder den VEML7700 bekomme ich jedoch die Verfügbaren Werte.
Defekt sind die Sensoren BME680 und BMP280 nicht . Diese kann ich am ESP32 über Tasmota wunderbar auslesen.

Gefühlt habe ich alle Möglichkeiten vom Löschen und neu aufspielen der Firmware, neu einbinden der KnxProd, tauschen der Sensoren, Kaltstart, Warmstart usw. ausprobiert.

Hat noch einer eine Idee was fehlerhaft sein kann?

Hat hier keiner eine Antwort zu?

[mumpf]

Sorry, bin zur Zeit viel unterwegs und konnte das noch nicht ausprobieren. Eine Erklärung habe ich nicht, da I²C scheinbar funktioniert, sonst würden der VEML und der SCD40 nicht gehen. Beim SCD30 kann ich aber gleichsagen, dass der nie zufriedenstellend lief - verwende den eher nicht. Der hat immer wieder den I²C-Bus zum hängen gebracht und ich habe es nie geschafft, das zu bereinigen.

Also: Wer neu anfängt, sollte den SCD30 nicht verwenden. Die Option ist nur für Leute drin, die den Sensor schon haben und mit den gelegentlichen Hängern leben können.

Ich werde kommende Woche mehr Zeit für KNX haben, dann schaue ich mir das an, ebenso die aktuellen Meldungen zum PM.

Gruß, Waldemar

[Tokal]

Hallo zusammen,

ich würde auch gerne nochmal auf die Anfrage von Triox85 und Amenophis zurückkommen. Bei mir klappt die gleiche Konstellation auch nicht (V4.2.5, BME280 auf SEN-UP1-8xTH (V00.20a)). Irgendwelche Ideen woran das liegen könnte?

Ich bin gerade nochmal auf die 4.0.2 zurück, damit klappt das Auslesen eines BME280 ohne Probleme.

Gruß,
Matthias