Alternative Firmware für das Raum-Sensormodul von Masifi

[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 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

[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]

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

[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

[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 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

[doenke]

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

[Masifi]

Hallo Sönke,

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

[doenke]

Hallo mumpf,

ich habe eine Frage und eine Anregung:
Vorab: Ich habe ein V3 Board mit einem BME 680.

Gibt es noch irgendetwas zu beachten wenn ich die Luftqualitätsampel verwenden möchte?
Wenn ich von dem KO lese, so erhalte ich laut Busmonitor ein $00 zurück. Egal wann und wie ich das auslese, auf andere Schulnoten komme ich nicht. Das Modul läuft nun seit 14 Tagen... hatte gedacht, das müsste sich vielleicht erst kalibrieren, oder sowas. Hier mal ein Screenshot von den Messwerten:
Sensormodul.png
Die CO2 Werte steigen teilweise auch auf über 3000. Das finde ich irgendwie nicht glaubwürdig. Aber vielleicht kann man auf die VOC-CO² Abschätzung tatsächlich nicht allzuviel geben.

Zum Anderen hätte ich noch einen Wunsch:
Die Verrechnung der Messwerte mit externen Werten klappt super. Allerdings fände ich es toll, zusätzlich auch den eigenen Messwert mit auf dem Bus zu haben, um ihn in eine Datenbank wegschreiben zu können. Da ich aktuell doch halbwegs unterschiedliche Messwerte von meinen verschiedenen Temperatursensoren bekomme, muss ich das jetzt mal im Langzeit-Vergleich abbilden und dann kalibrieren.

Schönes Wochenende,
Sönke

Edit: Anrede korrigiert.

[mumpf]

noch nicht mal an den Undo-Button gedacht.

Freut mich, wenn ich was zurückgeben kann. Wenn es auch nur solche Tipps sind...

Hast du inzwischen eignentlich heraus gefunden wie man knxprods macht die für mehrere Medien gehen?

Jein... Mit

            <Hardware2Program Id="M-00FA_H-WPKNX103-1_HP-0001-01-0000" MediumTypes="MT-0 MT-5">

bekommst Du es hin, dass die ETS das Applikationsprogramm sowohl in der IP- wie auch in der TP-Linie akzeptiert. Allerdings muss dann beim Programmieren das Gerät auch zurückmelden, dass es diesen Medium-Type hat. Das hab ich bisher als "Hack" in meinem fork drin... in der Applikation steht:

        <ApplicationProgram Id="M-00FA_A-0001-01-0000" ... MaskVersion="MV-07B0" ... >

was ja eigentlich TP ist, ich hab aber in der bau57B0.h folgendes gemacht:

    uint8_t _descriptor[2] = {[COLOR=#e74c3c]0x07[/COLOR], 0xb0}; // hack! original was {0x57, 0xb0};

Damit funktioniert es. Ich konnte so die Linux-Instanz programmieren. Ist aber schon lange her - inzwischen kann ich auch den SAMD debuggen, so dass ich die Linux-Variante komplett vernachlässigt habe... Ich habe es somit schon lange nicht mehr probiert (ca. 1 Jahr).

Gruß, Waldemar

[thesing]

Na toll da hab ich vor lauter Ärger über die verlorenen Verknüpfung noch nicht mal an den Undo-Button gedacht. Ich glaube ich habe bei meiner smarthomeNG-knx Anbindung ca. 150 KOs etwa 4 mal verbunden... (Da hatte ich aber auch noch mit den Updates experimentiert.)

Hast du inzwischen eignentlich heraus gefunden wie man knxprods macht die für mehrere Medien gehen?

[mumpf]

Hi Thomas,

danke für die Unterstützung. Du hast Recht, ich muss es zumindest für mich machbar und überschaubar machen. Ansonsten habe ich das Verfahren zum Update in der Applikationsbeschreibung hoffentlich hinreichend beschrieben . Und noch eine Info (für Dich und alle anderen): Wenn beim update nichts schief geht (also kein Laufzeitfehler passiert), dann kann man mit "Undo" das Update noch rückgängig machen.

Gruß, Waldemar

[Sisamiwe]

Ich würde das ganz pragmatisch sehen: du machst das in deiner Freizeit komplett freiwillig. Also mach es so wie es für dich am Besten ist. Es wird schließlich niemand gezwungen auf die neue Version zu wechseln. So lange klar kommuniziert wird, dass man beim Upgrade einige KOs neu verbinden muss ist alles ok. (zumal sich bestimmt genug Leute die Konfiguration des Gerätes in ETS zerschießen, indem sie die neue Firmwareversion im Dropdown auswählen und nicht auf den Upgrade-Applikation-Button drücken.

[thesing]

Ich würde das ganz pragmatisch sehen: du machst das in deiner Freizeit komplett freiwillig. Also mach es so wie es für dich am Besten ist. Es wird schließlich niemand gezwungen auf die neue Version zu wechseln. So lange klar kommuniziert wird, dass man beim Upgrade einige KOs neu verbinden muss ist alles ok. (zumal sich bestimmt genug Leute die Konfiguration des Gerätes in ETS zerschießen, indem sie die neue Firmwareversion im Dropdown auswählen und nicht auf den Upgrade-Applikation-Button drücken.