selfbus.org

Die RM soft würde für den 922er von StefanT geschrieben. Die ARM-lib in weiten Teilen auch von Ihm. Wer den RM auf ARM portiert hat, kann ich nicht sagen. Von der 922er soft her habe ich mitbekommen und hoffe es noch korrekt zu wissen:
Die Status Werte werden im 2 Sekunden Takt vom RM angefordert. In jedem Takt ein anderer. So sind sämtliche Stati in knapp einer Minute ausgelesen. Das passt dann mit der minimalen zyklisch Senden Zeit zusammen.
Die Betriebsstunden werden vom Melder selber summiert, wir nutzen hier ja schließlich die Auslesbarkeit des Melders aus.
Im Falle eines Alarms korrespondiert der Melder mit dem Modul von sich aus.
Die Spannung misst der neuere Melder (10 Jahres Batterie) eher sehr selten. Eine Anfrage veranlasst den Melder nicht zum Messen, eine Antwort mit nicht stimmigen Werten bekommt man bis dahin. Beim Vorgänger Modell mit 9V Alkaline war das noch anderst.

Hi Christian,
das wird hoffentlich die Entwicklung der Firmware voran bringen! Ich werde die VirtualBox gern verwenden.
Gruß
Hans

Vielen Dank oldcoolman, aber da hätte ich noch ein paar Anmerkungen aus meinen bisherigen Erfahrungen:

Die Status Werte werden im 2 Sekunden Takt vom RM angefordert. In jedem Takt ein anderer. So sind sämtliche Stati in knapp einer Minute ausgelesen. Das passt dann mit der minimalen zyklisch Senden Zeit zusammen.

Leider weiss man dann nicht ab wann die Daten ok sind, da sollte der RM einfach vorher nicht antworten, oder?

Die Betriebsstunden werden vom Melder selber summiert, wir nutzen hier ja schließlich die Auslesbarkeit des Melders aus.

Stimmt leider auch nicht, wenn ich den KNX Bus abziehe und wieder aufstecke sind ALLE Werte wieder auf Null ! Nachvollziehbar bei 25 Boards !

Im Falle eines Alarms korrespondiert der Melder mit dem Modul von sich aus.
Die Spannung misst der neuere Melder (10 Jahres Batterie) eher sehr selten. Eine Anfrage veranlasst den Melder nicht zum Messen, eine Antwort mit nicht stimmigen Werten bekommt man bis dahin. Beim Vorgänger Modell mit 9V Alkaline war das noch anderst.

Leider weiss man auch hier nicht welche Werte echt sind oder nicht, habe einige Boards die zeigen 18,36mV an, ein Board zeigt die korrekte Spannung nach einem Tag an, die anderen zwei überhaupt nicht.

Gruß
Michael

Hi zusammen,

nachdem einige Themen von Michael adressiert wurden, von denen wir aktuell nicht wissen, woher sie kommen
- ARM SW macht Probleme, LPC war ok?
- war auch beim LPC so?
- Hardware von Michael?
- ...
habe ich nochmal einen Vorstoß gemacht und ein Projekt in Git angelegt: https://github.com/selfbus/software-arm ... n/projects . Unter SW ARM incubation und für den Rauchmelder. Darin habe ich wiederum einen Issue aufgemacht mit dem Fokus den Fehler mit der Spannung tiefer zu analysieren. Das ist für mich der richtige Weg. So kann man ein Thema in einem Ticket verfolgen. Hier im Forum sind das zu viele Themen in einem Thread. Und ich zumindest weiß nicht, ob zum Beispiel das retten der Summenfunktion beim Modul-Abziehen als Bug oder als Featurerequest einzustufen ist.

@Michael: wäre cool, wenn diese konkreten Fehler / Features dort ausdiskutiert werden könnten.
Hoffe, die Sache funzt, wie ich mir das vorstelle.

Grüße
Christian

Hallo Christian,

vielen Dank für Deine Unterstützung, wenn Du Dein Image für die Virtual Box fertig hast werde ich mir das auch gerne mal runter ziehen, kann zwar kein C programmieren, dafür andere Sprachen, mal schauen ob ich mich damit auch in C rein schaffen kann. Bin aber ab Mitte nächster Woche auch erst mal für ein paar Wochen weg. Muss auch erst mal das mit dem Github lernen.

Freue mich schon auf eine gemeinsame Zusammenarbeit.

Gruß
Michael

Ich habe es leider nicht geschafft auf dem mir neuen Kommunikationskanal über GITHUB zu antworten. Drum eben doch hier.
Der Prozessor des Q Rauchmelders hängt stetig an 3,3V. Seine Aktivität wird durch ein Öffner Kontakt, der an einem weiteren PIN angeschlossen und vom Gehäuseboden betätigt wird, freigesetzt.
Wenn man dem ARM Prozessor die Energiezufuhr abdreht, verliert er nun mal sein Gedächtnis. Er muß die Stati erst wieder vom RM einholen. Meine Ausführungen betrafen den LPC922! Ich kann also nur vermutend sagen, wie es auch zum ARM portiert sein könnte.

Ja das habe ich verstanden, aber warum sind alle Statistikwerte wie die Bertiebsstunden und Alarme etc. nach Busspannungswiederkehr wieder zurück auf null, normalerweise sollten diese Werte doch im Dual Q gespeichert sein und werden durch das RM Modul nur gelesen? Nur die Seriennummer die kann er immer auslesen. Da muss irgendwo ein Reset der Statistikwerte im Dual Q passieren oder er schafft es nicht diese Werte auszulesen und addiert diese nur auf dem RM Modul auf!?!?

Gruß
Michael

Also laut dieser Doku müssten wirklich die Werte aus dem Rauchmelder kommen: https://github.com/selfbus/software/blo ... bjekte.txt

Ich fürchte, da hilft erst mal weiteres Zusammentragen alter Erkenntnisse nichts, da muss jemand mal wieder einen Logic Analyzer und das ARM debugging anwerfen und prüfen, was genau der Dual Q liefert und was der ARM macht.

Rein theoretisch könnte der ARM ja in seinem SRAM ja auch die Werte speichern. Was aber acuh wieder gefährlich ist, da beim Umstecken eines Moduls diese Werte ja auch mit wandern würden. Konsequent und richtig ist nur, wenn die Werte aus dem RM selber kommen.
Vielleicht löst das Modul ja bei Spannungswiederkehr soetwas wie einen Reset der Werte aus? Kann das sein?
Aber wie gesagt: da muss meiner Meinung nach nochmal analysiert werden.
Ich selber komme dazu aber frühestens ab Mittwoch. Und da will ich ja erst mal das Image mit der Dev-Umgebung hochladen...

LG
Christian

Ja, finde ich auch besser, wenn die Werte vom Dual Q ausgelesen werden, nur das scheint nicht richtig zu funktionieren. Hat jemand die Dinger mit allen Funktionen am laufen?

Es sieht fast so aus, das die ARM Portierung doch nicht so richtig geklappt hat? Oder ich habe bei allen 25 Modulen den gleichen Fehler gemacht

Gruß
Michael

Servus Michael,

nach etwas intensiverem meditieren und beobachten, bin ich der Meinung, dass der RM ARM wunderbar funktioniert.

Du hast recht, dass die Werte zurückgesetzt erscheinen, wenn die Bus-Spannung weg war. Da verliert der ARM sein Gedächtnis und muss die Werte erst wieder beim RM erfragen. Bzw. muss man wohl korrekter Weise sagen: er muss warten, bis der RM von sich aus die aktuellen Werte schickt!

Bis zu diesem Zeitpunkt liefert das Modul falsche Werte (0 für die Anzahl XY Werte oder falsche Spannungswerte etc.). Das war wohl auch schon beim LPC Modul so (siehe geraete-f2/platine-erste-versuche-fehler-t549-10.html ) und ich vermute, dass das beim kauf-Original nicht viel anders sein dürfte. Wenn doch, wäre es interessant, da mal ne genauere Beschreibung zu bekommen.

Da der RM grundsätzlich ja länger läuft, ist eine Stabilisierungsphase von ein paar Stunden (Spannung) oder Minuten (andere Werte) tolerierbar würde ich sagen. Das Nicht-Vergessen der SUmmenwerte wie Betriebszeit etc.. würde ich aktuell als neues Feature einstufen, was meiner Meinung aber durchaus realisierbar wäre.

Grüße
Christian

[Edit] Ergänzung: ich habe mir mal angesehen, was das offiziele Modul kann. Dort sind die ganzen Kommunikationsobjekte wie Betriebsdauer, Anzahl Alarme, etc. gar nicht auswählbar! Das offizielle Modul stellt also diese Infos gar nicht auf dem Bus zur Verfügung, womit sich auch die Frage erledigt hätte, wie die das denn machen mit dem Spannungsverelust, dem aus dem Sockel nehmen usw.