Rauchmelder V2.4 auf ARM portiert
Re: Rauchmelder V2.4 auf ARM portiert
Hallo zusammen,
ich bin gerade aktiv in der Rauchmelder Programmierung, da stellen sich mir ein paar Fragen zu den Kommunikationsobjekten.
Auf dieser Wiki Seite Rauchmelder Kommunikations Objekte werden die Objekte "Alarm Vernetzung" und "Testalarm Vernetzun" beschrieben.
So wie es bisher war und ich auch so umgesetzt hatte, war es so, dass im Alarmfall auf diesen KOs geschrieben wurde (bsp. Alarm EIN).
Somit wurden alle anderen Rauchmelder aktiviert, die die gleiche Gruppenadresse auf dem KO haben.
Nun gibt es ja aber nochd en Fall, dass ich evtl. die Verzögerung des Alarms haben möchte.
Dann kann das ja so nicht gehen?!
Eigentlich müsste nur der Alarm Status bei einem aktiven Alarm gesendet werden. Und der verzögerte Alarm (nach Ablauf der Verzögerungszeit)
Dann würd esich die Möglichkeit ergeben, die GA der Vernetzung entweder dem Alarm Status KO oder der Verzögertem Alarm KO zuzuordnen.
Dann hätte man die Möglichkeit den Alarm nach Ablauf einer gewissen Zeit erst an alle anderen Rauchmelder zu geben.
Das würde im Falle eines Fehlalarms gut sein (man müsste schnell den Alarm deaktivieren).
Im echten Alarmfall wäre es natürlich nicht so optimal.
In der Wiki Seite ist der verzögerte Alarm auch gar nicht aufgeführrt, aber in der Software und in der Gerätedatei ist diese Funktion implementiert (KO Nr. 4)
Wie seht ihr das? Da das ja ein sicherheitsrelevantes Thema ist, wollte ich das nicht einfach so alleine entscheiden...
Grüße,
Olli
ich bin gerade aktiv in der Rauchmelder Programmierung, da stellen sich mir ein paar Fragen zu den Kommunikationsobjekten.
Auf dieser Wiki Seite Rauchmelder Kommunikations Objekte werden die Objekte "Alarm Vernetzung" und "Testalarm Vernetzun" beschrieben.
So wie es bisher war und ich auch so umgesetzt hatte, war es so, dass im Alarmfall auf diesen KOs geschrieben wurde (bsp. Alarm EIN).
Somit wurden alle anderen Rauchmelder aktiviert, die die gleiche Gruppenadresse auf dem KO haben.
Nun gibt es ja aber nochd en Fall, dass ich evtl. die Verzögerung des Alarms haben möchte.
Dann kann das ja so nicht gehen?!
Eigentlich müsste nur der Alarm Status bei einem aktiven Alarm gesendet werden. Und der verzögerte Alarm (nach Ablauf der Verzögerungszeit)
Dann würd esich die Möglichkeit ergeben, die GA der Vernetzung entweder dem Alarm Status KO oder der Verzögertem Alarm KO zuzuordnen.
Dann hätte man die Möglichkeit den Alarm nach Ablauf einer gewissen Zeit erst an alle anderen Rauchmelder zu geben.
Das würde im Falle eines Fehlalarms gut sein (man müsste schnell den Alarm deaktivieren).
Im echten Alarmfall wäre es natürlich nicht so optimal.
In der Wiki Seite ist der verzögerte Alarm auch gar nicht aufgeführrt, aber in der Software und in der Gerätedatei ist diese Funktion implementiert (KO Nr. 4)
Wie seht ihr das? Da das ja ein sicherheitsrelevantes Thema ist, wollte ich das nicht einfach so alleine entscheiden...
Grüße,
Olli
Tags:
Re: Rauchmelder V2.4 auf ARM portiert
Hallo,
vorerst mal super und auch ein fettes Danke, dass du dich der Software hier annimmst...
Bezüglich deiner Frage/Feststellung. Ich weiß jetzt nicht ganz, ob ich das richtig verstanden habe.
Dein Vorschlag wäre also, die KO 0 Vernetzung nur als "externen Aktivierungskontakt" zu verwenden, und dieser soll zb über die KO 3 Status bzw der nicht ausgeführten KO 4 Verzögern getriggert/aktiviert werden?
Wenn das so gemeint ist, dann würde ich das als gut befinden bzw für mein Verständnis besser umgesetzt empfinden als es jetzt ist. Zumindest meine aktuelle Umsetzung sieht so ähnlich aus. Vernetze mit OpenHAB und da benutze ich die KO 0 als externe Alarmaktivierung und über den Status KO 3 wird dieser in OpenHAB getriggert. Die direkte Vernetzung mit KO 0 und alle auf die gleiche GA hab ich noch nicht probiert.
Falls ich das jetzt komplett missverstanden habe dann sry. Jedenfalls danke fürs Engagement
Grüße
vorerst mal super und auch ein fettes Danke, dass du dich der Software hier annimmst...
Bezüglich deiner Frage/Feststellung. Ich weiß jetzt nicht ganz, ob ich das richtig verstanden habe.
Dein Vorschlag wäre also, die KO 0 Vernetzung nur als "externen Aktivierungskontakt" zu verwenden, und dieser soll zb über die KO 3 Status bzw der nicht ausgeführten KO 4 Verzögern getriggert/aktiviert werden?
Wenn das so gemeint ist, dann würde ich das als gut befinden bzw für mein Verständnis besser umgesetzt empfinden als es jetzt ist. Zumindest meine aktuelle Umsetzung sieht so ähnlich aus. Vernetze mit OpenHAB und da benutze ich die KO 0 als externe Alarmaktivierung und über den Status KO 3 wird dieser in OpenHAB getriggert. Die direkte Vernetzung mit KO 0 und alle auf die gleiche GA hab ich noch nicht probiert.
Falls ich das jetzt komplett missverstanden habe dann sry. Jedenfalls danke fürs Engagement
Grüße
Re: Rauchmelder V2.4 auf ARM portiert
Hallo zusammen,
bisher gibt es noch keine Testergebnisse "auf breiter Front". Olli hatte zwar die Firmware ordentlich überarbeitet, aber jetzt wäre es schon gut, wenn ein paar mehr Leute drauf schauen könnten, ob auch alles so funktioniert wie erwartet.
Da ich diesen Stand nicht gleich ins Git unter "Releases" stellen will, hänge ich es hier an. Dann stolpern vielleicht auch ein paar mehr Leute drüber und vielleicht (wäre sehr hilfreich für die gesamte Community!) postet der eine oder andere sien Feedback.
Grüße
Christian
bisher gibt es noch keine Testergebnisse "auf breiter Front". Olli hatte zwar die Firmware ordentlich überarbeitet, aber jetzt wäre es schon gut, wenn ein paar mehr Leute drauf schauen könnten, ob auch alles so funktioniert wie erwartet.
Da ich diesen Stand nicht gleich ins Git unter "Releases" stellen will, hänge ich es hier an. Dann stolpern vielleicht auch ein paar mehr Leute drüber und vielleicht (wäre sehr hilfreich für die gesamte Community!) postet der eine oder andere sien Feedback.
Grüße
Christian
- Dateianhänge
-
- RM-BCU1_Release_2021-01-18.zip
- (135.88 KiB) 369-mal heruntergeladen
Re: Rauchmelder V2.4 auf ARM portiert
Hallo zusammen,
könnte bitte mal jemand hier in die Tests mit einsteigen, der am besten selbst die FW übersetzt und geflasht hat? Also möglichst nicht meine Version hier vom letzten Beitrag nutzt?
Ich hatte es schon bei Olli angesprochen und irgendwie verhalten sich unsere Module leicht anders bezüglich der Timings, wann auf den Bus gesendet wird. Das mag für die eigentliche Funktion vielleicht keine Auswirkung haben, aber wir sollten dem dennoch auf den Grund gehen. Mir kommt das etwas spanisch vor.
Fragen, die zu klären wären:
Läuft das bei bei euch auch so ab?
1. ich stelle auf alle 5 Minuten zyklisch die Werte abfragen. Das erste mal, nachdem das Gerät ein "reset" bekam, kommt bei mir nach 16 Sekunden eine Rückmeldung.
2. Die zweite Meldung folgt ziemlich exakt eine Minute nachdem die erste Ausgabe gestartet hatte
3. Die dritte Meldung folgt 5 Minuten später.
4. Die vierte Meldung folgt 5 Minuten später. Usw.
Auch wenn das schön ist, dass dann alle ~5 min. die Werte geliefert werden:
Aber wie kommt es zu den Abweichungen zu den eingestellten 5 Minuten zwischen den Rückmeldungen? Bei mir scheinen das 593 bzw. 594ms pro 5 Minuten zu sein. Das kann ja schlecht die Abweichung im Oszillator sein. Tickt da was in der sblib nicht korrekt? In der App?
Hier ein Auszug meines Mitschnitts.
Grüße
Christian
könnte bitte mal jemand hier in die Tests mit einsteigen, der am besten selbst die FW übersetzt und geflasht hat? Also möglichst nicht meine Version hier vom letzten Beitrag nutzt?
Ich hatte es schon bei Olli angesprochen und irgendwie verhalten sich unsere Module leicht anders bezüglich der Timings, wann auf den Bus gesendet wird. Das mag für die eigentliche Funktion vielleicht keine Auswirkung haben, aber wir sollten dem dennoch auf den Grund gehen. Mir kommt das etwas spanisch vor.
Fragen, die zu klären wären:
Läuft das bei bei euch auch so ab?
1. ich stelle auf alle 5 Minuten zyklisch die Werte abfragen. Das erste mal, nachdem das Gerät ein "reset" bekam, kommt bei mir nach 16 Sekunden eine Rückmeldung.
2. Die zweite Meldung folgt ziemlich exakt eine Minute nachdem die erste Ausgabe gestartet hatte
3. Die dritte Meldung folgt 5 Minuten später.
4. Die vierte Meldung folgt 5 Minuten später. Usw.
Auch wenn das schön ist, dass dann alle ~5 min. die Werte geliefert werden:
Aber wie kommt es zu den Abweichungen zu den eingestellten 5 Minuten zwischen den Rückmeldungen? Bei mir scheinen das 593 bzw. 594ms pro 5 Minuten zu sein. Das kann ja schlecht die Abweichung im Oszillator sein. Tickt da was in der sblib nicht korrekt? In der App?
- 12:53:31,980
- 12:58:32,574
- 13:03:33,168
[...] - 13:07:02,059
- 13:12:02,653
Hier ein Auszug meines Mitschnitts.
Code: Alles auswählen
# Zeit Dienst Flags Prio Quelladresse Quellname Zieladresse Zielname Rout Typ DPT Info
108 12:52:15,754 vom Bus System 1.2.24 Rauchmelder test 0.0.0 - 5 MemoryResponse (S=4) Count=1, Address=$010D, Data=$FF
109 12:52:15,756 zum Bus System 0.0.0 - 1.2.24 Rauchmelder test 5 T_ACK (S=4)
110 12:52:15,777 zum Bus System 0.0.0 - 1.2.24 Rauchmelder test 5 Neustarten (S=11)
111 12:52:15,798 zum Bus System 0.0.0 - 1.2.24 Rauchmelder test 5 T_Disconnect
112 12:52:31,864 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/14 Fehlfunktion - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
113 12:52:33,865 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/13 Batterie leer - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
114 12:52:35,969 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/12 Fehlercode - Status 5 GroupValueWrite 6.* 8-Bit vorzeichenbehaftet $00 | 0 %
115 12:52:37,876 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/11 Temperatur - Status 5 GroupValueWrite 9.001 Temperatur (°C) 0C 7E | 23 °C
116 12:52:39,880 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/10 BatSpannung - Status 5 GroupValueWrite 9.020 Spannung (mV) 00 00 | 0 mV
117 12:52:45,891 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/7 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
118 12:52:47,898 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/6 Seriennummer - Status 5 GroupValueWrite 12.* 4-Byte vorzeichenlos 00 00 00 00
119 12:53:31,980 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/14 Fehlfunktion - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
120 12:53:33,984 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/13 Batterie leer - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
121 12:53:36,230 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/12 Fehlercode - Status 5 GroupValueWrite 6.* 8-Bit vorzeichenbehaftet $00 | 0 %
122 12:53:37,994 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/11 Temperatur - Status 5 GroupValueWrite 9.001 Temperatur (°C) 0C 7E | 23 °C
123 12:53:39,998 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/10 BatSpannung - Status 5 GroupValueWrite 9.020 Spannung (mV) 00 00 | 0 mV
124 12:53:46,010 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/7 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
125 12:53:48,017 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/6 Seriennummer - Status 5 GroupValueWrite 12.* 4-Byte vorzeichenlos SE RI EN NR
126 12:58:32,574 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/14 Fehlfunktion - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
127 12:58:34,578 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/13 Batterie leer - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
128 12:58:36,660 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/12 Fehlercode - Status 5 GroupValueWrite 6.* 8-Bit vorzeichenbehaftet $00 | 0 %
129 12:58:38,588 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/11 Temperatur - Status 5 GroupValueWrite 9.001 Temperatur (°C) 0C 7E | 23 °C
130 12:58:40,592 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/10 BatSpannung - Status 5 GroupValueWrite 9.020 Spannung (mV) 00 00 | 0 mV
131 12:58:46,604 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/7 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
132 12:58:48,611 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/6 Seriennummer - Status 5 GroupValueWrite 12.* 4-Byte vorzeichenlos SE RI EN NR
133 13:03:33,168 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/14 Fehlfunktion - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
134 13:03:35,172 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/13 Batterie leer - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
135 13:03:37,451 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/12 Fehlercode - Status 5 GroupValueWrite 6.* 8-Bit vorzeichenbehaftet $00 | 0 %
136 13:03:39,183 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/11 Temperatur - Status 5 GroupValueWrite 9.001 Temperatur (°C) 0C 7E | 23 °C
137 13:03:41,187 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/10 BatSpannung - Status 5 GroupValueWrite 9.020 Spannung (mV) 00 00 | 0 mV
138 13:03:47,198 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/7 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
139 13:03:49,205 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/6 Seriennummer - Status 5 GroupValueWrite 12.* 4-Byte vorzeichenlos SE RI EN NR
140 13:05:45,735 zum Bus System 0.0.0 - 1.2.24 Rauchmelder test 5 T_Connect
141 13:05:45,756 zum Bus System 0.0.0 - 1.2.24 Rauchmelder test 5 DeviceDescriptorRead (S=0) DescriptorType=0
142 13:05:45,817 vom Bus System 1.2.24 Rauchmelder test 0.0.0 - 5 T_ACK (S=0)
143 13:05:45,842 vom Bus System 1.2.24 Rauchmelder test 0.0.0 - 5 DeviceDescriptorResponse (S=0) DescriptorType=0, DescriptorData=00 12
144 13:05:45,844 zum Bus System 0.0.0 - 1.2.24 Rauchmelder test 5 T_ACK (S=0)
145 13:05:45,868 zum Bus System 0.0.0 - 1.2.24 Rauchmelder test 5 Neustarten (S=1)
146 13:05:45,889 zum Bus System 0.0.0 - 1.2.24 Rauchmelder test 5 T_Disconnect
147 13:06:01,940 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/14 Fehlfunktion - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
148 13:06:03,944 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/13 Batterie leer - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
149 13:06:06,138 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/12 Fehlercode - Status 5 GroupValueWrite 6.* 8-Bit vorzeichenbehaftet $00 | 0 %
150 13:06:07,955 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/11 Temperatur - Status 5 GroupValueWrite 9.001 Temperatur (°C) 0C 7E | 23 °C
151 13:06:09,959 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/10 BatSpannung - Status 5 GroupValueWrite 9.020 Spannung (mV) 00 00 | 0 mV
152 13:06:15,971 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/7 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
153 13:06:17,977 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/6 Seriennummer - Status 5 GroupValueWrite 12.* 4-Byte vorzeichenlos 00 00 00 00
154 13:07:02,059 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/14 Fehlfunktion - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
155 13:07:04,063 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/13 Batterie leer - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
156 13:07:06,347 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/12 Fehlercode - Status 5 GroupValueWrite 6.* 8-Bit vorzeichenbehaftet $00 | 0 %
157 13:07:08,074 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/11 Temperatur - Status 5 GroupValueWrite 9.001 Temperatur (°C) 0C 8A | 23,24 °C
158 13:07:10,078 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/10 BatSpannung - Status 5 GroupValueWrite 9.020 Spannung (mV) 00 00 | 0 mV
159 13:07:16,090 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/7 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
160 13:07:18,096 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/6 Seriennummer - Status 5 GroupValueWrite 12.* 4-Byte vorzeichenlos SE RI EN NR
161 13:12:02,653 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/14 Fehlfunktion - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
162 13:12:04,657 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/13 Batterie leer - Status 5 GroupValueWrite 1.001 Schalten $00 | Aus
163 13:12:06,839 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/12 Fehlercode - Status 5 GroupValueWrite 6.* 8-Bit vorzeichenbehaftet $00 | 0 %
164 13:12:08,668 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/11 Temperatur - Status 5 GroupValueWrite 9.001 Temperatur (°C) 0C 8A | 23,24 °C
165 13:12:10,672 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/10 BatSpannung - Status 5 GroupValueWrite 9.020 Spannung (mV) 00 00 | 0 mV
166 13:12:16,684 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/7 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
167 13:12:18,690 vom Bus Niedrig 1.2.24 Rauchmelder test 3/2/6 Seriennummer - Status 5 GroupValueWrite 12.* 4-Byte vorzeichenlos SE RI EN NR
Christian
Re: Rauchmelder V2.4 auf ARM portiert
Hallo,
die Fehler mit der frühen Nachrichtenversendung und em zeitlichen Versatz zur eingestellten Zykluszeit wurden gefixt:
https://github.com/selfbus/software-arm ... b257dc7fd2
Es waren die Initialisierungen von 2 Zählern falsch und die Zykluszeit des timers musste um 1 ms gekürzt werden.
Nun wird von 0-499 (also 500 Schitte = 500ms gezählt). Vorher wurde von 0 bis 500 gezählt, also 501 Schritte = 501ms.
Da der Zähler nach 500ms imeer wieder neu startet und damit dann die Minuten gezählt werden, wurde jede Minute die Zykluszeit um 120ms versetzt (60s/500ms * 1ms = 120ms)
Grüße,
Olli
die Fehler mit der frühen Nachrichtenversendung und em zeitlichen Versatz zur eingestellten Zykluszeit wurden gefixt:
https://github.com/selfbus/software-arm ... b257dc7fd2
Es waren die Initialisierungen von 2 Zählern falsch und die Zykluszeit des timers musste um 1 ms gekürzt werden.
Nun wird von 0-499 (also 500 Schitte = 500ms gezählt). Vorher wurde von 0 bis 500 gezählt, also 501 Schritte = 501ms.
Da der Zähler nach 500ms imeer wieder neu startet und damit dann die Minuten gezählt werden, wurde jede Minute die Zykluszeit um 120ms versetzt (60s/500ms * 1ms = 120ms)
Grüße,
Olli
Re: Rauchmelder V2.4 auf ARM portiert
Hi Olli,
irgendwo muss immer noch ein Schnitzer mit dem Timing sein.
Stell mal bitte auch 5 Minuten bei dir ein.
Aktuell kommen bei mir Meldungen mit folgenden Abständen
- 0 Minuten
- 1 Minute
- 5 Minuten
- 5 Minuten
- 50 Sekunden
- 1 Minute
- 5 Minuten
- 5 Minuten
[...]
Gruß
Christian
irgendwo muss immer noch ein Schnitzer mit dem Timing sein.
Stell mal bitte auch 5 Minuten bei dir ein.
Aktuell kommen bei mir Meldungen mit folgenden Abständen
- 0 Minuten
- 1 Minute
- 5 Minuten
- 5 Minuten
- 50 Sekunden
- 1 Minute
- 5 Minuten
- 5 Minuten
[...]
Gruß
Christian
Code: Alles auswählen
# Dienst Flags Prio Quelladresse Quellname Zieladresse Zeit Zielname Rout Typ DPT Info
7 vom Bus Niedrig 01.02.2024 Rauchmelder test 03.02.2007 09:29:02,918 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
14 vom Bus Niedrig 01.02.2024 Rauchmelder test 03.02.2007 09:30:03,037 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
21 vom Bus Niedrig 01.02.2024 Rauchmelder test 03.02.2007 09:35:03,632 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
28 vom Bus Niedrig 01.02.2024 Rauchmelder test 03.02.2007 09:40:04,226 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
35 vom Bus Niedrig 01.02.2024 Rauchmelder test 03.02.2007 09:40:53,095 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
42 vom Bus Niedrig 01.02.2024 Rauchmelder test 03.02.2007 09:41:53,214 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
49 vom Bus Niedrig 01.02.2024 Rauchmelder test 03.02.2007 09:46:53,810 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
56 vom Bus Niedrig 01.02.2024 Rauchmelder test 03.02.2007 09:51:54,403 Betriebszeit in Sek - Status 5 GroupValueWrite 7.007 Zeit (h) 00 00 | 0 h
Re: Rauchmelder V2.4 auf ARM portiert
Hallo zusammen,
gibt es momentan ein release das problemlos verwendet werden kann? (hab hier 15 Rauchmelder die ich verbauen möchte)
Danke und Gruß
Andreas
gibt es momentan ein release das problemlos verwendet werden kann? (hab hier 15 Rauchmelder die ich verbauen möchte)
Danke und Gruß
Andreas
Re: Rauchmelder V2.4 auf ARM portiert
Hallo,
grundsätzlich ist das aktuelle Projekt auf GiHub meiner Meinung nach lauffähig.
Meine Rauchmelder laufen aktuell auch damit.
Es fehlen allerdings weitere Tests, die du natürlich gerne unterstützen darfst, um eventuelle Probleme zu finden.
Wenn es irgendwelche Probleme gibt, kannst du dich gerne hier im Forum oder auf Slack melden, ich würde dann versuchen, die Fehler zu beheben.
Eventuell kannst du ja versuchen, die Fehler von Doumanix nachzustellen. Bei mir bekomme ich die Fehler nicht nachgestellt.
Grüße,
Olli
grundsätzlich ist das aktuelle Projekt auf GiHub meiner Meinung nach lauffähig.
Meine Rauchmelder laufen aktuell auch damit.
Es fehlen allerdings weitere Tests, die du natürlich gerne unterstützen darfst, um eventuelle Probleme zu finden.
Wenn es irgendwelche Probleme gibt, kannst du dich gerne hier im Forum oder auf Slack melden, ich würde dann versuchen, die Fehler zu beheben.
Eventuell kannst du ja versuchen, die Fehler von Doumanix nachzustellen. Bei mir bekomme ich die Fehler nicht nachgestellt.
Grüße,
Olli
Re: Rauchmelder V2.4 auf ARM portiert
Könntet ihr die eine aktuelle .hex Datei zum flashen bereitstellen, bzw. ich finde sie nicht
im Kompilieren bin ich jetzt nicht so fit...
Die ich auch Github gefunden habe ist schon älter
https://github.com/selfbus/software-rel ... elder-bcu1
im Kompilieren bin ich jetzt nicht so fit...
Die ich auch Github gefunden habe ist schon älter
https://github.com/selfbus/software-rel ... elder-bcu1
Re: Rauchmelder V2.4 auf ARM portiert
Hallo Andreas,
leider habe ich aktuell nicht die Berechtigung auf dem Git software-releases zu schreiben, daher habe ich dir die hex hier angehängt.
Leider ist eine .hex Datei hier nicht zulässig, daher habe ich sie als zip umbenannt.
Also herunterladen und aus dem .zip ein .hex machen und flashen.
Grüße,
Olli
leider habe ich aktuell nicht die Berechtigung auf dem Git software-releases zu schreiben, daher habe ich dir die hex hier angehängt.
Leider ist eine .hex Datei hier nicht zulässig, daher habe ich sie als zip umbenannt.
Also herunterladen und aus dem .zip ein .hex machen und flashen.
Grüße,
Olli
- Dateianhänge
-
- Rauchmelder-bcu1.zip
- (31.92 KiB) 348-mal heruntergeladen