Neue Version des Selfbus KNX-Moduls für Gira Dual Q Rauchmelder

[IPv6]

Servus jhmeier,
wenn man per Progger flasht, muss man entweder die Version ohne "flashstart_0x3000" flashen (dann hast du diese Version drauf, die sollte funktionieren, die kann aber nur wieder per Progger aktualisiert werden) oder man flasht den Bootloader "bootloader_release_(lpc11xx)_v1.11_libv2.02.hex" von https://github.com/selfbus/software-...ter/bootloader (damit hat man dann den ARM vorbereitet und kann den Bus anstecken und dann per Updater die eigentliche Firmware draufspielen). Weil der Bereich "vorne" für den Bootloader reserviert ist, beginnt die eigentliche Applikation dann bei 0x3000.

Mir leuchtet das noch nicht ganz ein.
Das bedeutet doch, dass ich meinen 10 Rauchmeldermodulen (liegen noch auf dem Schreibtisch) allen per KNX die Firmware aufspielen muss, wenn ich später die Möglichkeit zum Update haben will.

Gäbe es nicht die Möglichkeit, ein hex file bereitzustellen, dass am Anfang den Bootloader enthält und hintendran gleich die aktuelle Firmware?
Dann könnten die Rauchmeldermodule alle bequem und schnell auf dem Schreibtisch per Programmieradapter geflasht werden und man kann die Module später trotzdem updaten, ohne die Rauchmelder alle abzuhängen.
Das wäre doch genau das, was die allermeisten Nachbauer eines solchen Moduls benötigen.
Gerade für die initiale Inbetriebnahme erscheint es doch etwas umständlich, erst per Programmieradapter den Bootloader aufzuspielen und anschließend per KNX die eigentliche Firmware, was ja alles andere als schnell geht.

[Doumanix]

Hi IPv6,

ich gebe dir da völlig recht. Das Problem ist uns bewusst. Aktuell ist es so, dass wir aus unseren automatischen Builds die 0x3000er Version erzeugen und die Version, die nur die Firmware an sich enthält. Soweit ich im Kopf habe, ist es im Moment nicht möglich aus der IDE heraus diese kombinierte Version, die du ansprichst, zu erzeugen. Es gäbe da ein Skript im beta-Stadium, das diesen Merge vornehmen könnte...

Aber a) sind unsere Ressourcen begrenzt, da kümmert sich aktuell niemand drum (@all: hätte jemand Bock? Das ist sicher eher überschaubar.) Und b) wollten wir nicht noch mehr und noch mehr Build-Varianten erzeugen. Die Kombinatorik, welche Varianten aus einer Grund-Software bei uns erzeugt werden können, lässt einen dann ganz schnell den Überblick verlieren (nicht beim Rauchmeldermodul, aber z.B. bei den Binäreingängen: 2-, 4-, 8-, 16-fach. Pull-Up und Pull-Down. Flashbar. Busupdatebar. Release / Debug...).

Aber ich sehe deinen Punkt. Wie immer: ich bin echt dankbar für das Feedback. In dieser ganzen Zeit, als wir das alles umgekrempelt haben, waren es nur ein paar Leute, die froh und stolz waren (sind), dass die Dinge wieder besser laufen und an Struktur gewinnen. Da nimmt man die eine oder andere Hürde einfach hin, die nun euch als neue User vollkommen ins Auge stechen.

Wir reden da auf jeden Fall nochmal drüber ;-)

Grüße
Christian

[jcd]

Danke für deine ausführliche Rückmeldung. Ich kann jetzt leider erstmal nicht weiter testen, da mir RWM fehlen und ich das Modul wieder ausgebaut und durch das ursprüngliche Funkmodul ersetzt habe.

Einer meiner RWM war/ist einfach tot (keine Reaktion auf den Funktionstest). Nach nur gut einem Jahr und ohne Batterie-Warnung!! Ich bin jetzt etwas schockiert…ich hatte den Funktionstest bisher nur als pro-forma-Sache gesehen.

Der Ersatz-RWM ist eingetroffen und ich habe das Selfbus-Modul eingebaut. Da etwas anderes dazwischen kam, lief es eine Weile bevor ich erstmalig die GA abfragen konnte. Alle Werten waren dann aber sämtlich korrekt bzw. plausibel.

Einen Verbesserungsvorschlag hätte ich noch für die Platine: Wie wäre es möglich/sinnvoll die (insbesondere an der Seite der Steckverbindung) 2-3 Millimeter größer zu machen, sodass man eine bessere Anfassmöglichkeit hat um die wieder vom RWM abzuziehen? Derzeit kann man die Platine vollständig aufgesteckt nur schlecht greifen. Ich habe mit einem Hebel von unten drücken müssen.

[ReinhardW]

Nabend,

ich hab insgesamt 21 Rauchmelder Module mit Bootloader und dann der Firmware über KNX geflasht, ging einwandfrei und die Dauer war auch überschaubar.
Etwas schwierig sehe ich die Verwaltung der UID, bei vielen Geräten.

Ist der Sinn dahinter eigentlich das Gerät vor Fremdzugriffen zu schützen oder ist das etwas was der Hersteller schon vorgibt?
Also so nach den Motto, wenn du in Sektor X schreiben willst identifiziere dich erst.
Wäre praktisch wenn man das irgendwie in der ETS mit verwalten könnte, so in der Art wie die DCA App von MDT.
Und für den Selfbus-flasher wäre entweder eine GUI noch interessant oder zumindest ein PowerShell Script, das mit Abfragen und "übergebenen Werten" arbeiten kann.
Aber mir ist natürlich auch klar was an Arbeit in solchen Wünschen steckt, deshalb: Klasse Job, macht weiter so.

Gruß
Reinhard

[Doumanix]

Einen Verbesserungsvorschlag hätte ich noch für die Platine: Wie wäre es möglich/sinnvoll die (insbesondere an der Seite der Steckverbindung) 2-3 Millimeter größer zu machen, sodass man eine bessere Anfassmöglichkeit hat um die wieder vom RWM abzuziehen? Derzeit kann man die Platine vollständig aufgesteckt nur schlecht greifen. Ich habe mit einem Hebel von unten drücken müssen.

Hi jcd : dafür sind eigentlich die beiden Bohrungen in der v3.9 vorgesehen. Da kannst du einen kleinen Kabelbinder oder vielleicht auch Paketband durchziehen und mit verbauen. Wenn du das Modul dann doch mal herausziehen musst, kannst du da einfach senkrecht direkt am Steckverbinder dran ziehen und es sollte ohne Querkräfte sich herausziehen lassen.
Zu Not geht auch das von beschriebene Hebeln ganz gut. Vorne neben den Pins etwas drunterschieben (zum Beispiel das hintere, runde Ende einer Pinzette) leicht hebeln und mit der anderen Hand am anderen Ende beim Taster rauf und runter wackeln - dadurch bewegt sich das Modul recht schnell und mit wenig Kraft aus dem RWM).

[jcd]

Über die Löcher hatte ich mich schon gewundert…
Kabelbinder ist ein guter Tipp!

[jcd]

Meine Frage geht ein kleines bisschen OT - falls es ausufert mache ich auch gerne einen neuen Thread.

Welche Strategie empfiehlt sich zur Umsetzung eines Brandalarms?
Ich möchte gerne, dass bei einem Brandalarm alle Rollläden hochfahren, eine Nachricht versendet wird und ggf. weiteres. Da es sich ggf. um eine lebenswichtige Funktion handelt gelten besondere Ansprüche:
1) Es sollten möglich wenige Geräte in der "Alarmierungskette" beteiligt sein.
2) Es muss möglichst failsafe und übersichtlich sein.
3) Die Funktion muss testbar sein.

Das selfbus KNX-Modul unterscheidet (wie vermutlich auch die Variante von Gira) zwischen Testalarm (KO 33) und echtem Alarm (KO 34). In der derzeitigen Testphase habe ich eine Brandalarm-GA und eine separate Testalarm-GA für diese beiden KO.

Wegen 1) möchte ich keine zusätzliche Logik-Geräte benutzen. Im Fall des Falles könnte das Gerät ausgefallen sein, oder aufgrund irgendwelcher Probleme nicht wie gewünscht funktionierten (->2). Ich möchte daher gerne eine Brandalarm GA und diese direkt mit dem KO 34 des KNX-Moduls sowie den passenden Alarm-KO verschiedener Aktoren verbinden.

Mein Problem: Wie teste ich bei diesem Aufbau den Alarm inkl. aller Alarm-Aktionen?
a) via Vernetzungs-KO 1 über den BUS echten Alarm auslösen? -> Funktioniert nicht über den Testalarm-Knopf des RWM und ist ziemlich laut.
b) zu jedem Aktor KO nicht nur die Alarm-GA, sondern auch das Test-Alarm-GA verbinden? -> Riskant. Ich könnte die Alarm-GA vergessen. Dann funktioniert der Test, aber der Ernstfall nicht. Außerdem: Falls während eines echten Alarms dann eine 0 über die Test-Alarm GA empfangen würde, würden die Alarmaktionen beendet.
c) Das KO 33 für den Testalarm einfach mit der "echten" Brandalarm GA verbinden? -> Scheint einfach. Meine Bedenken: Falls während eines echten Alarms über die Test-Alarm-GA eine 0 gesendet würde, würden die Alarmaktionen beendet.
d ) Echten Alarm und Test-Alarm in einer Logik "ver-odern" und das Ergebnis für die Alarmierung nutzen. -> widerspricht meiner Anforderung 1)
e) ...?

Ich tendiere zu c). Das zyklischen Senden des Test-Alarm-Status muss dazu natürlich deaktiviert sein und sicherheitshalber würde ich das zyklische Senden des Alarms aktivieren. Das Risko, dass das KNX-Modul fälschlicherweise auf dem KO 34 dann eine 0 sendet halte ich für gering und dürfte ja nur passieren, wenn gerade wirklich ein Testalarm beendet würde.
Was meint ihr dazu?

[pawgac]

Ich habe mit selfbus Sensoren die originalen von Gira ersetzt (Funktionsumfang), klasse Arbeit. Support bei Problemen auch erstklassig.
Hätte er noch I2C Pins für einen SCD40 oder BME680, wäre es All-in-One Sensor, der dazu noch gut aussieht :-)

[uncelsam]

jcd: zum Testen: Gute Ohrenschützer und Testspray, so kannst Du dir sicher sein, dass allers im Ernstfall funktioniert...

[g0bi]

Hi Christian,

es hat zwar lange gedauert, wollte das aber testen um ausschließen zu können.
Der besagte Rauchmelder, der mit der Platine 3.9 angefangen hat zu piepen, tut es immer noch. Ich habe gewartet bis ich von IPv6 die EMV Schirmungsbleche erhalten habe, hab an diesem ein Schirmblech verbaut und siehe da... Er piept immer noch, ca. 30min. nach Einsetzen

Ich gehe jetzt tatsächlich von einem Defekt des RM aus. Ich habe jetzt den zweiten Rauchmelder genommen und hier die Platine eingebaut ohne Schirmungsblech und schau mal was hier passiert.

Willst du den einen Rauchmelder zum testen mal haben? Dann kann ich ihn dir gerne zuschicken, bei mir geht er jetzt sonst in die Tonne. Hoffen wir, dass der zweite nicht anfängt zu piepen

Grüße Stefan

[Doumanix]

Hi Christian,

Willst du den einen Rauchmelder zum testen mal haben? Dann kann ich ihn dir gerne zuschicken, bei mir geht er jetzt sonst in die Tonne. Hoffen wir, dass der zweite nicht anfängt zu piepen

Hi Stefan,

ich hoffe, darth hat sich bei dir gemeldet. Er würde sich den defekten RWM mal gerne ansehen.

Was sagt der zweite RWM? Ich hoffe, dem geht es gut und alles funzt?

Grüße
Christian

[g0bi]

Hallo Christian,

ja, darth hat sich gemeldet. Ich verschicke den Rauchmelder Anfang nächster Woche. Ich gab mir gedacht, wenn dann ganz oder garnicht und hab den Rauchmelder im Schlafzimmer als zweites Testexemplar ausgewählt. Mir war schon mulmig als ich schlafen gegangen bin, aber bis heute ist der zumindest ruhig.

Hier habe ich bisher auch leine Schirmplatine verbaut, mache das nur bei denen die wirklich piepen. Die Tage kommt die zweite Platine dran und dann gibts erste Tests.

mal sehen

Grüße Stefan

[jcd]

Ich habe eine Frage zur Funktionsweise des KO2 "Alarm zurücksetzen".
In der Beschreibung in der ETS steht dazu: "Setzt sekundären Alarm zurück. Es geben nur jene Rauchmelder weiter Alarm, die den Alarm ausgelöst haben."
Bei meinem Test eben wurde der Alarm aber nur zwischen KNX- und drahtvernetzten Meldern beendet, in der Funk-Gruppe lief er weiter, bis ich das auslösende Gerät erneut betätigt habe.

Ich hätte erwartet, dass auch die Funk-Gruppe bis auf den auslösenden Melder verstummt. Ist das richtig? Ich muss dazu sagen, dass ich nicht sonderlich lange abgewartet habe, weil ich es nicht so lange piepen lassen wollte.

Details zum Test:
In meinem Aufbau ist ein KNX-Melder mit einem Funk-Melder via Drahtverbindung verbunden und dann weitere Melder über die Funk-Gruppe.
Ich habe bei einem Funk-vernetzten Melder Testalarm ausgelöst (Taste gedrückt). Nach kurzer Zeit signalisieren alle Melder den Alarm und auch auf dem Bus kam die Meldung an. Dann habe ich via KO 2 den Alarm zurückgesetzt. Der KNX-Melder und der verbundene Funk-Melder gingen aus, die anderen Funk-Melder liefen weiter.
Erst als ich am auslösenden Melder erneut die Taste drückte, verstummen die anderen recht schnell.

[ur63]

Wie hoch ist denn der Busstrom je Modul?

[ur63]

Das Problem ist uns bewusst. Aktuell ist es so, dass wir aus unseren automatischen Builds die 0x3000er Version erzeugen und die Version, die nur die Firmware an sich enthält. Soweit ich im Kopf habe, ist es im Moment nicht möglich aus der IDE heraus diese kombinierte Version, die du ansprichst, zu erzeugen. Es gäbe da ein Skript im beta-Stadium, das diesen Merge vornehmen könnte...

Wir reden da auf jeden Fall nochmal drüber ;-)

Konntet ihr das schon drüber reden und insbesondere mit welchem Ergebnis?
Das wäre m.E. definitiv kein Nice-to-Have Feature, um Komplexität rauszunehmen UND die Akzeptanz zu erhöhen.