Alternative Firmware für das Raum-Sensormodul von Masifi

[ReinerDaniel]

Hallo Waldemar,

Du hattest schon am 19.04. geantwortet:
https://knx-user-forum.de/forum/öffe...72#post1496472

Aber doppelt Danke für Deine Unterstützung. Die Logikfunktionen sind beeindruckend.
Gruß, Matthias

[mumpf]

Hi,

Nun habe ich im knx-stack den Defaultwert der PA von 0 (0.0.0) auf 65535 (15.15.255) gesetzt.

kann es sein, dass der knxd bei Dir 0.0.0 selbst verwendet? Vielleicht als Tunnel-Adresse? Oder die eigene Adresse? Dann könnte ich mir das erklären...

thesing: Spricht was dagegen, standardmäßig die Initial-PA im Stack auf 0xFFFF, also 15.15.255 zu setzen? Falls das solche Probleme löst, wäre ich nicht abgeneigt. Und "normale" KNX-Geräte kommen ja auch immer initial mit 15.15.255.

Gruß, Waldemar

[thesing]

Spricht was dagegen, standardmäßig die Initial-PA im Stack auf 0xFFFF, also 15.15.255 zu setzen?

Ich hab damit kein Problem.

[mumpf]

Hi Thomas,

danke für die Antwort - ich meinte allerdings, ob vom Coding her etwas dagegen spricht (weil z.B. irgendwo die 0 als Initialwert vorausgesetzt wird). Ich hab mir mal alle Stellen angesehen und nichts relevantes gefunden, deswegen hab ich jetzt mal testweise

    uint16_t _ownAddress = 0xFFFF;

gesetzt. Wenn das ohne weiteres funktioniert, werde ich das im nächsten Release ausliefern.

Gruß, Waldemar

[thesing]

Genau das hab ich damit sagen wollen (dass eben nichts dagegen spricht vom Coding her). Das Linux Beispiel wäre dann nicht mehr automatisch im Programmiermodus, aber dass kann man leicht beheben.

[mumpf]

Hi,

an alle, die das Sensormodul mit Logiken verwenden: Ich bin jetzt dabei, auch 1-Wire im Sensormodul zu integrieren. Dabei hab ich gemerkt, dass ich mich bei den benötigten KO verrechnet habe. Ich würde gerne die Nummern aller KO vom Logikmodul um 20 verschieben. Das würde aber bedeuten, dass alle GA-Zuordnungen zu diesen KO verloren gehen, wenn man ein Update macht. Man müsste somit die KO neu zuordnen. Da wollte ich mal fragen, wie da die Meinung dazu ist.

Also nochmal explizit:

• Alle Parameter bleiben erhalten (Sensor- und Logikmodul)
• Alle KO vom Sensormodul (KO1 bis KO 39) bleiben erhalten
• Alle KO der Logikkanäle (KO50 - KO319) werden gelöscht

Wer hat denn (außer mir) schon so viele Logikkanäle belegt, dass das "wehtun" würde, es erneut zuzuordnen? Wie gesagt, mein Ziel ist, es kompatibel zu machen, aber es ist mein erstes größeres Projekt mit ETS-Applikationen und da passieren eben blöde Fehler.

Die andere Alternative wäre, eine Firmware-Version mit Sensor/Logik zu machen (so wie sie jetzt ist) und eine weitere mit Sensor/Logik/1Wire, die dann eine andere KO-Belegung hat. Das würde aber auch 2 verschiedene Applikationen bedeuten und mehr Stress bei der Erstellung von neuen Versionen und natürlich potentielle Verwirrung bei den Nutzern. Lieber wäre mir nur eine Version warten zu müssen.

Langer Rede kurzer Sinn: Wie ist eure Meinung dazu? Nochmal einmalig Arbeit beim Upgrade? Oder verschiedene Applikationen, bei denen man aber immer wissen muss, welche zu verwenden ist?

Gruß, Waldemar

[Sisamiwe]

Langer Rede kurzer Sinn: Wie ist eure Meinung dazu? Nochmal einmalig Arbeit beim Upgrade? Oder verschiedene Applikationen, bei denen man aber immer wissen muss, welche zu verwenden ist?

Ich bin ganz klar für EINE Applikation und damit Verknüpfungsarbeit beim Upgrade.

Beste Grüße
Michael

[ReinerDaniel]

Bin auch für eine Applikation.
Gruß Matthias

[mumpf]

Super, danke für das Feedback.

Nachdem ich jetzt eine Nacht drüber geschlafen habe, bin ich auch zu dem Schluss gekommen, dass mir der Aufwand für 2 Applikationen zu groß ist. Aber gut, dass ihr das auch so seht.

Ich hab auch das Update mal bei mir durchgespielt. Wenn man sich das alte Gerät vor dem Update in der ETS kopiert, dann nur für EIN Gerät ein update macht und dann einfach für beide Geräte die KO-Sicht aufmacht, kann man sehr schnell von einem Gerät per Drag&Drop die GA auf das andere Gerät ziehen. Ist gut zu verschmerzen.

Dann werde ich mal an der neuen KO-Struktur arbeiten - mit der Hoffnung, dass das jetzt endlich final ist.

Zur Roadmap - Ich hab folgende Versionen vor:

1. Derzeit 1.1.0 - Das was jetzt da ist, Sensoren und Logik, bekommt updates (meist nur Firmware), wenn ich oder sonst jemand Fehler drin findet.
2. Ich teste gerade die 2.0.0, da kommen in der Logik noch Zeitschaltuhren mit Feiertags- und Sonnenstandsberechnungen hinzu. Wenn die Version die nächsten Feiertage korrekt berechnet (Christi Himmelfahrt, Pfingsten, Fronleichnam), könnte ich mir vorstellen, dass ich das nach den Pfingstferien freigebe.
3. Die Version 3.0.0 ist das 1-Wire-Release und wird noch lange brauchen, ich will den ersten internen Alpha-Test bis Ende Mai hinbekommen. Hier ist der Zeithorizont als eher Ende des Jahres, zumindest Q4.

Da erst in 3.0.0 die KO-Verschiebung technisch nötig ist, aber bis dahin ja potentiell schon viele Logiken entstanden sind, neige ich dazu, die KO-Verschiebung schon in 2.0.0 zu machen. Das würde dann weniger Arbeit für euch bedeuten, da ja bis Pfingsten nicht soooo viele Logiken entstehen werden - zumindest weniger als bis zum Jahresende. Und für mich ist es auch einfacher bei der Wartung - wenn in 2.0.0 Fehler auftauchen, kann ich die Korrekturen bei gleicher KO-Struktur einfacher in 3.0.0 übernehmen.

Auch hier wieder langer Rede kurzer Sinn: Die KO-Verschiebung wird mit 2.0.0 kommen, obwohl sie da technisch nicht notwendig ist und bereitet dann das 1-Wire-Release sozusagen vor.

Gruß, Waldemar

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

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

[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

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

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

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