Alternative Firmware für das Raum-Sensormodul von Masifi

[Masifi]

Hallo Sönke,

Ich stelle nur die HW.
daher müsste es heißen Hallo Mumpf
:-)

[doenke]

Ups. Sorry. Ich bin mal so frei und änder das einfach oben.
Ich bitte Euch beide um Entschuldigung.

[mumpf]

Hallo Sönke,

Tja, wie Matthias schon angemerkt hat, ich heiße nicht masifi...

Das mit der Luftqualitätsampel muss ich mal schauen. Mag sein, dass sich da ein Bug eingeschlichen hat, ich hab das jetzt schon länger nicht getestet, sorry. Als kurzfristigen Workaround kannst Du Dir in der Logik einfach Schwellwert-Logikkanäle bauen und passend Werte von 1-6 ausgeben lassen, das wird klappen. Kalibrieren muss sich da nichts, es kommen immer Werte passend zum VOC-Wert (beim BME680) oder CO2-Wert (beim SCD30). Wenn der Sensor sich noch nicht kalibriert hat, sendet er schlechte Werte, dann ist auch auf die Luftqualitätsampel kein Verlass. Ich hab aber gerade geschaut, mein Testsensor liefert auch eine 0 - ist somit ein Bug, danke für die Rückmeldung. Die Korrektur würde ich ins nächste Release aufnehmen.

Auf die Kalibrierung des BME680 hab ich keinen Einfluß, das macht die Software von Bosch, die ich eingebunden habe. Wie gut das ist, musst Du beurteilen, ich persönlich verzichte auf VOC, wenn ich nicht explizit Gestank (Gäste-WC, Bäder) messen möchte. Und dann werte ich nicht den Absoluten Wert aus, sondern die Zunahme in kurzer Zeit aus. Deswegen hab ich Matthias dazu überredet, auch einen echten CO2-Sensor zu integrieren.

Zu den Originalwerten der Sensoren: Ja... kann ich machen, aber frühestens mit v2.0 (Zeitschaltuhr-Release). Passt ganz gut in mein Vorhaben, nochmal alle KO anzupassen. Allerdings würde ich das anders machen als Du denkst...

Ich möchte sowieso ein Rechenmodul in der Logik unterstützen, dann würde ich einfach diese Werte in der Logik verrechnen lassen und das Sensormodul würde seine Originalwerte ausgeben. Der Vorteil hier wäre, dass man dann auch das Verrechnen mit externen Werten mit den 1-Wire-Sensoren nutzen kann. Ich muss mir das durch den Kopf gehen lassen...

Gruß, Waldemar

[Sisamiwe]

Hallo mumpf

Ich melde mich heute mal mit ein paar Beobachtungen.

A) Ich habe eine V1 mit einem BME280 in Betrieb. Hier habe ich beobachtet, dass das zyklische Senden (der Luftfeuchtigkeit) sporadisch hängen bleibt, sprich keine Werte mehr gesendet werden. Wenn ich alle Werte anfordere, kommt ein neuer Wert und das zyklische Senden funktioniert wieder.

B) Als Luftdruck wird aktuell der "reale" Luftdruck gesendet, nicht der auf NN normierte. Bei kommerziellen Produkten kann man die Höhe über Null des Meßortes einstellen, so dass dann der auf NN normierte Luftdruck gemeldet wird.
Wie siehst Du das?

C) Ich habe es noch nicht geschafft, denn Buzzer in Betrieb zu nehmen. Ich habe einen Logikkanal so konfiguriert, dass der Eingang auf eine GA mit dpt1 hört und dieser dann an Ausgang "Buzzer" ohne Änderung weitergeben wird. Meine Erwartung wäre, dass so lange die "1" am Eingang anliegt, der Buzzer ertönt. Ist das so korrekt?

Danke für die Rückmeldung
Michael

[mumpf]

Hallo Michael,

danke für das Feedback. Es benutzt also doch jemand .

Zu A) Sollte natürlich so nicht sein. Ein guter Hinweis ist, dass ein "Alle Werte anfordern" es wieder richtet. Welches Zeitintervall hast Du eingestellt? Und wie oft passiert es denn, dass es ausfällt? Alle paar Stunden? Tage? Wochen? Ich will nur wissen, was ich bei mir im Test einstellen muss und wie lange ich warten muss, bis es auftreten sollte. Könntest Du beim nächsten Vorkommen ein Lesetelegramm an die GA senden und schauen, ob der Wert anders ist als der zuletzt gesendete? Würde mir helfen herauszufinden, ob das Problem beim Messen oder beim Senden liegt. Wie lange die Korrektur dauert, kann ich nicht sagen, ich muss das erstmal irgendwie nachvollziehen können.

Als Workaround kannst Du Dir mit der Logik einen Watchdog bauen (nehmen wir mal an, Dein Sendeintervall ist 5 Minuten):

• Logik ODER, triggert bei jedem Eingangstelegramm
• Ein Eingang, DPT9, Wertintervall 0-100 (also immer true)
• Ausgang Treppenlicht, 15 Minuten, kann verlängert werden, kann nicht ausgeschaltet werden
• Ausgang sendet bei EIN: nichts
• Ausgang sendet bei AUS: Ein EIN-Signal
• An den Eingang legst Du die GA von der Luftfeuchte
• Der Ausgang bekommt die GA von "Alle Werte anfordern".

Wenn 15 Minuten lang keine Luftfeuchte gesendet wurde, fällt das Treppenlicht auf AUS und sendet ein "Alle Werte anfordern". Danach sollte es ja wieder gehen...

Zu B) Das ist richtig, ich sende hier einfach die Werte, die der Sensor liefert. Wenn ich Dich recht verstehe, ist die Normierung auf NN kein einfacher Offset (den könnte man ja eingeben), oder? Ich müsste mich da noch einlesen, bevor ich sagen kann, ob ich normieren kann. Falls die Normierung noch von anderen Faktoren abhängt, kann ich sie eventuell nicht berechnen. Da schaue ich aber nochmal.

Zu C) Deine Erwartung hier ist vollkommen richtig. Der Buzzer sollte so lange piepen, wie eine 1 am Eingang anliegt. Deswegen gleich die Frage an Masifi: Haben wir hier vielleicht noch ein Pin-Problem? In der Hardware.h steht für V1

#define BUZZER_PIN 9

Ist der bei V1 vielleicht anders? Ich konnte wie gesagt mit V1 nicht testen.

Gruß, Waldemar

[mumpf]

Hallo Michael,

hab nochmal im Hardware-Thread von Masifi geschaut... wenn man sich hier https://knx-user-forum.de/forum/%C3%...01#post1479201 die Tabelle anschaut, dann ist da für V1 der Buzzer auch durchgestrichen. Und in dem Pin-Layout-Bild drüber ist D9 auf V1 nicht verfügbar.

Masifi: Wenn man einen anderen Pin noch nutzen könnte (z.B. den D2, indem man eine Brücke auf der Aufsteckplatine lötet und das eine Beinchen zum GND abschneidet), dann könnte man natürlich einfach D2 in der Hardware.h eintragen und dann würde es auch gehen. Aber das müsst ihr untereinander klären...

Gruß, Waldemar

[Sisamiwe]

Zu B) Das ist richtig, ich sende hier einfach die Werte, die der Sensor liefert. Wenn ich Dich recht verstehe, ist die Normierung auf NN kein einfacher Offset (den könnte man ja eingeben), oder? Ich müsste mich da noch einlesen, bevor ich sagen kann, ob ich normieren kann. Falls die Normierung noch von anderen Faktoren abhängt, kann ich sie eventuell nicht berechnen. Da schaue ich aber nochmal.

Lass mich hier mal kurz antworten:
Hier wird die Barometrische Höhenformel benötigt. Siehe hier
Einen Beispielrechner mit einer vereinfachten Formel gibt es hier

• Temperaturschätzung: Temperatur auf Meereshöhe = Temperatur + Temperaturgradient * Höhe
• Barometrische Höhenformel: Luftdruck auf Meereshöhe = Barometeranzeige / (1-Temperaturgradient*Höhe/Temperatur auf Meereshöhe in Kelvin)^(0,03416/Temperaturgradient)

Zu C) Deine Erwartung hier ist vollkommen richtig. Der Buzzer sollte so lange piepen, wie eine 1 am Eingang anliegt. Deswegen gleich die Frage an Masifi: Haben wir hier vielleicht noch ein Pin-Problem? In der Hardware.h steht für V1

Der Buzzer ist an einer V3. Hatte ich vergessen zu schreiben.

[mumpf]

Hi Michael,

erstmal Danke für die Links und die Formel. Kann ich gerne einbauen... Da Du aber scheinbar Ahnung hast, gleich ein paar Fragen:

1. So wie ich die Temperaturschätzung verstehe, bräuchte ich die Außentemperatur und nicht die Innentemperatur, oder?
2. Die Höhe, auf der ich gerade messe, fließt die positiv oder negativ in die Formel mit ein? Ich hätte positiv erwartet, aber bei dem einen Rechner (vereinfachte Form) erschien mir der Wert plausibler, als ich den negativen Höhenwert genommen habe...

Ich sehe mal zu, dass ich das am Wochenende einbaue, ist ja nicht so schwer. Allerdings dann nur mit Innentemperatur. Und im ersten "Wurf" wird die Höhe nur im Coding einzugeben sein (schreib ich dann in die Anleitung), erst die v2.0.0 (Zeitschaltuhr-Version) hat in der ETS eine Parameter-Seite, wo solche Eingaben reinpassen.

Der Buzzer ist an einer V3.

Hmmm, da bin ich ratlos. Ich schreib jetzt mal alle ETS-Schritte, die ich brauche, um ein Piep zu entlocken. Ich gehe von einem Logikkanal mit Standardeinstellungen aus:

• Logik
  • Beschreibung des Kanals: Test Piep
  • Logik-Operation: ODER
  • Eingang 1: normal aktiv
  • Logik sendet ihren Wert weiter: Bei jedem Eingangstelegramm
• Eingang
  • einfach so lassen
• Ausgang
  • Wert für EIN senden: Tonwiedergabe (Buzzer)
  • Wert für EIN senden als: Ton laut einschalten
  • Wert für AUS senden: Tonwiedergabe (Buzzer)
  • Wert für AUS senden als: Ton ausschalten
• Eingangs-KO bekommt dann noch eine GA zugewiesen

Wenn ich jetzt auf dieser GA eine 1 sende, kommt bei mir ein Piep bis ich wieder eine 0 sende. Das hier nur, damit wir über das gleiche reden.

Und wieder mal eine Frage an Masifi: Gibt es noch eine einfache Möglichkeit, den Buzzer auf Funktion zu testen, z.B. indem man kurz 2 Pins überbrückt oder so?

Gruß, Waldemar

[Masifi]

Und wieder mal eine Frage an Masifi: Gibt es noch eine einfache Möglichkeit, den Buzzer auf Funktion zu testen, z.B. indem man kurz 2 Pins überbrückt oder so?

mit diesem Code ist es ganz schnell zu testen:

const int buzzer = 9; //buzzer to arduino pin 9

void setup(){
pinMode(buzzer, OUTPUT); // Set buzzer - pin 9 as an output
}

void loop(){
tone(buzzer, 2400); // Send 1KHz sound signal...
delay(1000); // ...for 1 sec
noTone(buzzer); // Stop sound...
delay(1000); // ...for 1sec
}

[mumpf]

Hi,

Masifi: Da ich natürlich davon ausgehe, dass meine Software funktioniert, dachte ich eher an eine Hardware-Überprüfung

Sisamiwe: Du kannst ja mal den kleinen Sketch von Masifi ausprobieren. Wenn es da nicht piept, bin ich raus...

Aber der Vollständigkeit halber: Du hast schon einen Buzzer auf der Zwischenplatine, oder? Sieht so aus wie auf dem Bild https://knx-user-forum.de/forum/%C3%...04#post1479204 in der Mitte, das runde schwarze Ding...

Sorry, falls Du die Frage zu blöd findest, aber ich bin durch meinen Job starkt Support geschädigt und hab da sehr viel erlebt... Ich will nur helfen.

Gruß, Waldemar

[Sisamiwe]

Hallo mumpf, Masifi

Hmmm, da bin ich ratlos. Ich schreib jetzt mal alle ETS-Schritte, die ich brauche, um ein Piep zu entlocken. Ich gehe von einem Logikkanal mit Standardeinstellungen aus:

• Logik
  • Beschreibung des Kanals: Test Piep
  • Logik-Operation: ODER
  • Eingang 1: normal aktiv
  • Logik sendet ihren Wert weiter: Bei jedem Eingangstelegramm
• Eingang
  • einfach so lassen
• Ausgang
  • Wert für EIN senden: Tonwiedergabe (Buzzer)
  • Wert für EIN senden als: Ton laut einschalten
  • Wert für AUS senden: Tonwiedergabe (Buzzer)
  • Wert für AUS senden als: Ton ausschalten
• Eingangs-KO bekommt dann noch eine GA zugewiesen

Ich habe meine Einstellung nochmal geprüft und festgestellt, dass ich die Logikoperation so nicht gesetzt habe.
Wenn man es genau so macht, wie hier von Dir beschrieben, geht es.
DANKE. Alles gut.

[Sisamiwe]

Hallo Waldemar mumpf,

Zu A) Sollte natürlich so nicht sein. Ein guter Hinweis ist, dass ein "Alle Werte anfordern" es wieder richtet. Welches Zeitintervall hast Du eingestellt? Und wie oft passiert es denn, dass es ausfällt? Alle paar Stunden? Tage? Wochen? Ich will nur wissen, was ich bei mir im Test einstellen muss und wie lange ich warten muss, bis es auftreten sollte. Könntest Du beim nächsten Vorkommen ein Lesetelegramm an die GA senden und schauen, ob der Wert anders ist als der zuletzt gesendete? Würde mir helfen herauszufinden, ob das Problem beim Messen oder beim Senden liegt. Wie lange die Korrektur dauert, kann ich nicht sagen, ich muss das erstmal irgendwie nachvollziehen können.

Als Workaround kannst Du Dir mit der Logik einen Watchdog bauen (nehmen wir mal an, Dein Sendeintervall ist 5 Minuten):

• Logik ODER, triggert bei jedem Eingangstelegramm
• Ein Eingang, DPT9, Wertintervall 0-100 (also immer true)
• Ausgang Treppenlicht, 15 Minuten, kann verlängert werden, kann nicht ausgeschaltet werden
• Ausgang sendet bei EIN: nichts
• Ausgang sendet bei AUS: Ein EIN-Signal
• An den Eingang legst Du die GA von der Luftfeuchte
• Der Ausgang bekommt die GA von "Alle Werte anfordern".

Wenn 15 Minuten lang keine Luftfeuchte gesendet wurde, fällt das Treppenlicht auf AUS und sendet ein "Alle Werte anfordern". Danach sollte es ja wieder gehen...

Ich habe diese Logik mal angelegt und werde das Verhalten beobachten. Dazu melde ich mich wieder, wenn ich etwas herausgefunden habe.

Danke Dir.

[Sisamiwe]

Hallo Waldemar mumpf,

nun noch meine Rückmeldung zum Thema "Luftdruck auf Meereshöhe".

So wie ich die Temperaturschätzung verstehe, bräuchte ich die Außentemperatur und nicht die Innentemperatur, oder?

Um korrekt zu sein, sollte man die Außentemperatur nutzen. Ich habe noch etwas recherchiert und als Näherung wird oft die Jahresdurchschnittstemp von 15°C verwendet. Du könntest das auch so machen.
Im SmellyOne von dreamy1 mit der SW-Unterstützung von WagoKlemme sollte die Umrechnung des lokal gemessenen Luftdruck auf den entsprechenden Luftdruck auf Meereshöhe auch inkludiert sein. Ggf. können die beiden auch einen Hinweis geben.

Die Höhe, auf der ich gerade messe, fließt die positiv oder negativ in die Formel mit ein? Ich hätte positiv erwartet, aber bei dem einen Rechner (vereinfachte Form) erschien mir der Wert plausibler, als ich den negativen Höhenwert genommen habe...

Die Seehöhe, auf der sich der Sensor befindet, fliesst positiv in die Rechnung ein. Warum? Mit zunehmender Höhe fällt der Luftdruck, also muss, wenn man den lokalen Luftdruck an einem Ort über Seehöhe auf Seehöhe umrechnet, höher sein. Ein Beispiel: Mein Wohn- bzw Messort liegt auf 435m. Ich messe einen lokalen Luftdruck von 960mBar. Umgerechnet auf Seehöhe mit 0m Höhe ergibt sich ein entsprechender Luftdruck (auf Meereshöhe) von 1010,55 mbar.

Ich sehe mal zu, dass ich das am Wochenende einbaue, ist ja nicht so schwer. Allerdings dann nur mit Innentemperatur. Und im ersten "Wurf" wird die Höhe nur im Coding einzugeben sein (schreib ich dann in die Anleitung), erst die v2.0.0 (Zeitschaltuhr-Version) hat in der ETS eine Parameter-Seite, wo solche Eingaben reinpassen.

Ich freue mich schon, dass Du das mit einbauen willst. Es würde aber für V2.0 reichen. Meinst Du es macht Sinn, beide Werte (also lokal und auf NN umgerechnet) zur Verfügung zu stellen?

Beste Grüße
Michael

[mumpf]

Die Möglichkeit, die Logik-Operation auf "keine" zu stellen, ist dazu gedacht, einen Logik Kanal zu deaktivieren, ohne dass alle Parameter verloren gehen. Ist praktisch bei der Fehlersuche, wenn man komplizierte Logiken macht.

Das werde ich aber in der Firmware 2.0 besser machen. Dann gibt es eine Checkbox zum deaktivieren des Kanals.

Freut mich, das es jetzt klappt.

Gruß, Waldemar

[mumpf]

Hi,

Es würde aber für V2.0 reichen.

das ist gut, dann kann ich das in Ruhe machen. Wenn die Tests über Pfingsten und in den Pfingstferien gut gehen, dann werde ich das danach auch freigeben.

Meinst Du es macht Sinn, beide Werte (also lokal und auf NN umgerechnet) zur Verfügung zu stellen?

Jein... Ich habe bei solchen Ausgaben immer ein Problem: Welcher Wert wird für die Sendebedingungen herangezogen (also für Senden bei absoluter oder relativer Abweichung). Um die Bedingungen für beide anzugeben, habe ich keinen Platz mehr (im Speicher) bzw. dann wäre das ein Riesenumbau, den ich derzeit nicht machen will.

Das gleiche Problem stellt sich bei https://knx-user-forum.de/forum/%C3%...26#post1507026 (Originalwerte der Sensoren senden bei Verrechnung mit externen Werten). Hier fällt allerdings eine Lösung über Formelfunktionen im Logikmodul aus.

Ich muss mir dazu noch was überlegen, eventuell wird zu 2.0 (was ja eigentlich schon fertig ist und nur noch getestet wird) nur ein "entweder-oder" möglich sein.

Gruß, Waldemar