HM-SEC-SD Rauchmelder RESPONSE TIMEOUT
Closed this issue · 31 comments
Hallo,
zunächst mal vielen Dank für dieses tolle Projekt! Ich habe bereits zwei HM-Lc-SW4 mit der AskSinpp Library gebaut, die hervorragend funktionieren.
Nun möchte ich meine billig-Funk-Rauchmelder auf Homematic umbauen und möchte daher den Rauchmelder Sketch HM-SEC-SD.ino verwenden. Zunächst mal Fragen zur Funktion:
Ich habe mir in dem Rauchmelder ein Signal gesucht, dass bei Alarm einen Hi-Pegel liefert und dieses auf den SENS1_PIN gelegt. Weiterhin habe ich an den SOUND_PIN einen Optokoppler angeschlossen, der den Test-Taster des Rauchmelders überbrückt (Hi-Pegel = Taster drücken). Kann man das so machen oder wie ist das eigentlich gedacht?
Das Peering mit FHEM hat problemlos geklappt. Der Rauchmelder war allerdings sofort auf Daueralarm, da der SOUND_PIN ständig Hi-Pegel hat. Ich konnte in FHEM sehen, wie smoke-Alarm im State hochgezählt wurden. Der SENS1_PIN Eingang scheint also zu funktionieren. Den SOUND_PIN habe ich erst mal wieder abgeklemmt, um den Daueralarm abzuschalten.
Ich habe dann ein set Rauchmelder alarmOff (und auch alarmOn, falls invertierte Logik) gesendet, doch der SOUND_PIN bleibt immer Hi. Und nun bekommt FHEM scheinbar keine Antwort mehr, ich kriege ständig nur noch Fehlermeldungen, siehe log:
2019-08-06_21:34:47 Rauchmelder MISSING ACK
2019-08-06_21:34:56 Rauchmelder unreachable
2019-08-06_21:47:55 Rauchmelder ResndFail
2019-08-06_21:47:55 Rauchmelder RESPONSE TIMEOUT:RegisterRead
RSSI liegt bei -59 und ein Test mit dem HM-Lc-SW4 Sketch zeigt, dass die Hardware bestens funktioniert.
Woran kann das liegen?
Achso, anfangs hatte ich kein Team gebildet, da ich erst später gelesen habe, dass man das scheinbar muss. Inzwischen habe ich aber ein set Rauchmelder peerChan 0 Rauchmelder single set actor gemacht und scheinbar hat der Rauchmelder das Team mit sich selbst gebildet. Also scheint ja schon noch Kommunikation stattzufinden.
Hier die Internals:
DEF 031234 HM_RPI_Modul_MSGCNT 9 HM_RPI_Modul_RAWMSG 0500003B0394410312340312340102C8 HM_RPI_Modul_RSSI -59 HM_RPI_Modul_TIME 2019-08-06 19:57:17 IODev HM_RPI_Modul LASTInputDev HM_RPI_Modul MSGCNT 9 NAME Rauchmelder NOTIFYDEV global NR 392 NTFY_ORDER 50-Rauchmelder STATE unreachable TESTNR 1 TYPE CUL_HM lastMsg No:03 - t:41 s:031234 d:031234 0102C8 peerList self01 protCmdDel 15 protLastRcv 2019-08-06 19:57:16 protRcv 3 last_at:2019-08-06 19:57:16 protRcvB 3 last_at:2019-08-06 19:57:16 protResnd 11 last_at:2019-08-06 22:05:04 protResndFail 11 last_at:2019-08-06 22:05:08 protSnd 20 last_at:2019-08-06 22:04:57 protSndB 31 last_at:2019-08-06 22:05:04 protState CMDs_done_Errors:1 rssi_at_HM_RPI_Modul cnt:9 min:-64 max:-57 avg:-61.11 lst:-59 sdTeam sdLead
Vielen Dank!
Hi,
ich nutze zwar kein FHEM und bin nur in der Homematic Welt auf der CCU unterwegs, aber der HM-Sec-SD lässt das Deaktivieren per Funk generell nicht zu. Auch nicht der originale. Ist bei dem nicht vorgesehen. Das hat manche Leute zu kreativen Ideen beflügelt... 😄
https://www.youtube.com/watch?v=_5_PkoioK5U
Der HM-Sec-SD-2 könnte das Abschalten per Funk erlauben, wenn ich die XML und den Parameter SD_STATE richtig deute.
<frame id="EVENT" direction="to_device" event="true" type="0x41" channel_field="9:0.6">
<parameter type="integer" index="9.7" size="0.1" param="LOWBAT"/>
<parameter type="integer" index="11.0" size="1.0" param="SD_STATE"/>
</frame>
Der HM-Sec-SD-2 arbeitet aber mit einem anderen Teaming (SMOKE_DETECTOR_TEAM_V2) und TRIPLE_BURST.
Hallo,
danke für die Hinweise!
Ich möchte den Rauchmelder aber nicht deaktivieren, sondern ihn per Funk auslösen, so als würde der Test-Taster am Rauchmelder gedrückt werden. Daher zunächst mal die Frage, ob der Ausgang SOUND_PIN dafür geeignet bzw. sogar genau dafür gedacht ist.
Das kann der Originale HM-Sec-SD doch auch, dass man von der CCU aus den Alarm testen kann?!
Somit wäre die Frage, welchen FHEM-Befehl ich senden muss, damit der SOUND_PIN seinen Pegel ändert.
Leider komme ich aber auch gar nicht so weit um das auszuprobieren, da ja bereits die Funkverbindung nicht richtig funktioniert.
Das kann der Originale HM-Sec-SD doch auch, dass man von der CCU aus den Alarm testen kann?!
Nein.
Daher zunächst mal die Frage, ob der Ausgang SOUND_PIN dafür geeignet bzw. sogar genau dafür gedacht ist.
Ja das ist der Ausgang bei Alarm.
Für ein Batteriedevice müsste hier noch statt Idle ein Sleep erfolgen, sowie WOR aktiviert werden.
Der HM-SEC-SD wird im Falle weiterer in einem Team eingebundener HM-SEC-SD vom auslösenden Melder geweckt und ausgelöst.
Eine von der Zentrale initiierte Auslösung ist nicht vorgesehen.
Nabend,
Der HM-SEC-SD wird im Falle weiterer in einem Team eingebundener HM-SEC-SD vom auslösenden Melder geweckt und ausgelöst.
Eine von der Zentrale initiierte Auslösung ist nicht vorgesehen.
Man kann zumindest die Zentrale zum Teamleader machen und so bei allen Rauchmeldern im Team einen Alarm auslösen, steht hier.
Gestern habe ich festgestellt, dass FHEM zu gar keinem HM-Gerät mehr kommuniziert hat. Der Rauchmelder hatte scheinbar den CUL zum Absturz gebracht ... Ein Neustart hat geholfen und dann funktionierte auch der Rauchmelder wieder kurzzeitig. Ich konnte (diesmal kontrolliert) Alarme am Rauchmelder auslösen und FHEM hat diese registriert. Ich habe dann einen virtuellen Teamleader in FHEM erstellt und wollte den Rauchmelder damit peeren, doch nun hängt der Rauchmelder wieder bei MISSING ACK und ist nicht mehr ansprechbar. Also irgendwas stimmt scheinbar mit dem Sketch nicht ...
Für ein Batteriedevice müsste hier noch statt Idle ein Sleep erfolgen, sowie WOR aktiviert werden.
Woher weiß man sowas? Ist das irgendwo dokumentiert oder hat man nur die Chance, sich durch den Sourcecode zu wühlen?
Ich würde auch gern mal ein HM_LC_SWx mit Batteriebetrieb bauen, aber es ist echt schwierig (für mich jedenfalls ;) ), sich die passenden Codeschnipsel aus den verschiedenen Beispielen zusammen zu suchen. Und am Ende bleibt das ungute Gefühl, dass man vielleicht etwas übersehen hat ...
Eigentlich bräuchte ich für den Umbau meiner Rauchmelder nur ein einfaches HM-Device, das einen Eingang und einen Ausgang hat und auf Batteriebetrieb optimiert ist. Den ganzen HM-Sec-Schnick-Schnack brauche ich eigentlich nicht. Gibt es da vielleicht einen passenden Sketch?
Nochmals Danke!
Man kann zumindest die Zentrale zum Teamleader machen und so bei allen Rauchmeldern im Team einen Alarm auslösen, steht hier.
Okay, dann mag das bei FHEM so gehen. Es ist von der CCU aus dennoch nicht möglich, einen Befehl in Richtung des HM-Sec-SD abzusetzen.
Woher weiß man sowas? Ist das irgendwo dokumentiert oder hat man nur die Chance, sich durch den Sourcecode zu wühlen?
Eine Doku gibt es nicht. Es bleibt also nur Letzteres.
Einige Meta-Infos, Code-Snippets und Diskussionen findest du auf asksinpp.de, im HomeMatic Forum oder auch im FHEM Forum.
Neben den Beispielen hier im examples-Ordner findest du auch noch weitere in meinem Repo und es gibt noch etliche Homebrew Devices (die jedoch hauptsächlich nur auf der CCU unterstützt werden).
Bei Tom findest du auch viele Infos. Er hat sehr viel ausführlich dokumentiert.
Das sind erstmal so alle Stellen die mir einfallen.
Ich würde auch gern mal ein HM_LC_SWx mit Batteriebetrieb bauen,
Das wäre ja dann den HM-LC-Sw1-BA-PCB, den gibts schon als fertigen Sketch: https://github.com/pa-pa/AskSinPP/blob/master/examples/HM-LC-SW1-BA-PCB/HM-LC-SW1-BA-PCB.ino
Und am Ende bleibt das ungute Gefühl, dass man vielleicht etwas übersehen hat ...
Das merkt man dann schon... und davon explodiert auch nicht gleich die Zentrale. ;)
Eigentlich bräuchte ich für den Umbau meiner Rauchmelder nur ein einfaches HM-Device, das einen Eingang und einen Ausgang hat und auf Batteriebetrieb optimiert ist
Das hier evtl.: https://github.com/jp112sdl/HB-UNI-SenAct-4-4
Hat 4 Ein- und 4 Ausgänge.
Hab aber keine Ahnung, wie man das in FHEM reinbekommt.
Das sind erstmal so alle Stellen die mir einfallen.
Alles klar, da hab ich ja erstmal ein bisschen Lesestoff :)
Das merkt man dann schon... und davon explodiert auch nicht gleich die Zentrale. ;)
Naja, mal gucken :D
Das Beispiel HB-UNI-SenAct zeigt ja mit #define USE_BATTERY_MODE sehr schön, was man zum Batteriebetrieb braucht. Damit kann ich hoffentlich arbeiten.
Nochmals vielen Dank!
Offen ist nur noch die Frage, warum ich diese Kommunikationsprobleme mit dem HM-Sec-SD habe.
Offen ist nur noch die Frage, warum ich diese Kommunikationsprobleme mit dem HM-Sec-SD habe.
Hast du mal geschaut, was der SD seriell ausgibt, wenn du ihm den Befehl schickst?
Der Rauchmelder berücksichtigt nur Nachrichten vom Typ SensorEventMsg.
Vielleicht müssten für deinen Zweck noch die anderen berücksichtigt werden. Ich kann es nicht testen, da kein FHEM vorhanden.
Aber vielleicht hat @pa-pa noch eine Idee.
Das kann u.U. am CUL liegen. Das FHEM-Forum ist voll mit Beiträgen, wo Homematic mit CUL Probleme macht. Ich werde meine Zeit nicht für Fehlersuche im Zusammenhang mit CUL verschwenden. Bitte nutze einen ordentlichen Homematic-IO. Das HM-MOD-RPI-PCB lässt sich super einfach einbinden und kostet auch nicht die Welt.
Moin,
sorry, ich hatte "CUL" immer für eine Art Oberbegriff gehalten für alle möglichen HM-Adapter und den Begriff offensichtlich falsch verwendet. In Wirklichkeit habe ich das HM-MOD-RPI-PCB.
Bisher hatte ich auch noch mit keinen HM-Gerät Probleme und dass der Raspberry gar nicht mehr kommuniziert ist auch zum ersten Mal passiert.
Nebenbei: Ich weiß, dass ich die fehlerhaften CC1101 Module für die Arduinos habe. Daher führe ich immer zuerst die FreqTest.ino aus (und trage natürlich auch die ermittelte Frequenz in den eigentlichen Sketch ein), dann funktionieren sie hervorragend! Notfalls habe ich aber auch schon die 12pF hier liegen ;) Umbau war aber bisher nicht nötig. Glaube daher nicht, dass es an den Funkmodulen liegt. Denn wie gesagt, andere AskSin-Sketche laufen absolut problemlos, nur der HM-Sec spinnt.
Dann bitte mal, wie Jerome schon gesagt hat, die seriellen Ausgaben aufzeichnen. Ich habe das Example nie mit FHEM ausprobiert.
Nabend,
ich habe jetzt mal mit dem HB-UNI-SenAct-4-4-RC rumprobiert, da man hier wie gesagt per #define USE_BATTERY_MODE auf Batteriebetrieb umschalten kann.
Ohne Battery Mode funktioniert das Teil problemlos in FHEM (mit Verwendung von HMConfig_AskSinPPCustom.pm). Sobald ich das #define USE_BATTERY_MODE aktiviere, verhält es sich genau wie der Rauchmelder: RESPONSE TIMEOUT:RegisterRead
Im Folgenden die serielle Ausgabe bei RESET per Config Button und anschließendes Peering mit FHEM:
debounce
pressed
longpressed
longpressed
RESET
AskSin++ V4.1.0 (Aug 10 2019 22:16:17)
Address Space: 32 - 593
00000000
Init Storage: CAFEEC08
CC init1
CC Version: 14
- ready
Config Freq: 0x2165D2
iVcc: 3086
Activate Cycle Msg
<- 0E 01 86 10 F33401 000000 06 01 00 00 00 - 4927
<- 0E 02 86 10 F33401 000000 06 02 00 00 00 - 5027
<- 0E 03 86 10 F33401 000000 06 03 00 00 00 - 5128
<- 0E 04 86 10 F33401 000000 06 04 00 00 00 - 5228
debounce
pressed
released
<- 1A 05 84 00 F33401 000000 10 F3 34 4A 50 53 45 4E 41 43 54 30 31 10 08 01 00 - 8744-> 10 2D A0 01 4F654B F33401 00 05 00 00 00 00 00 - 8916
<- 0A 2D 80 02 F33401 4F654B 00 - 9033
-> 13 2E A0 01 4F654B F33401 00 08 02 01 0A 4F 0B 65 0C 4B - 9183
<- 0A 2E 80 02 F33401 4F654B 00 - 9304
-> 0B 2F A0 01 4F654B F33401 00 06 - 9445
Activate Cycle Msg
<- 0A 2F 82 02 F33401 4F654B 00 - 9564
-> 10 30 A0 01 4F654B F33401 00 04 00 00 00 00 00 - 12920
<- 16 30 80 10 F33401 4F654B 02 0A 4F 0B 65 0C 4B 02 01 09 01 00 00 - 13056
ignore 0F 81 86 10 50226A 000000 0A 25 04 0F 00 40 - 26386
Der SenAct ist die F33401, der Raspberry hat die 4F654B.
Soweit alles prima. Sende ich dann mit FHEM ein getConfig, passiert in der seriellen Konsole des Arduino nichts mehr und FHEM meldet den Fehler. Das FHEM Log dazu sieht so aus:
2019-08-10_22:20:26 HM_F33401 D-firmware: 1.0
2019-08-10_22:20:26 HM_F33401 D-serialNr: JPSENACT01
2019-08-10_22:20:30 HM_F33401 ResndFail
2019-08-10_22:20:30 HM_F33401 RESPONSE TIMEOUT:RegisterRead
Ohne Battery Mode funktioniert wie gesagt auch das getConfig problemlos.
Scheinbar wird der Arduino nicht vom Funkmodul geweckt!?
Ich hab zwar absolut keinen Plan von FHEM, aber wenn ich mir die HMConfig_AskSinPPCustom.pm anschaue, finde ich dort gar kein Gerät F334 definiert.
Solltest du das vorhandene 'nicht-Batteriegerät' F332 einfach in F334 geändert haben funktioniert das nicht, weil das 'nicht-Batteriegerät' kein BURST zum Aufwecken benötigt.
Moin,
mmh, das ist allerdings interessant. Ich habe die ID nicht manuell geändert, das ist bereits im Sketch über DEV_MODEL so vordefiniert:
#ifdef USE_BATTERY_MODE
#define battOp_ARGUMENT BatterySensor
#define DEV_MODEL 0x34
#define CYCLETIME seconds2ticks(60UL * 60 * 12 * 0.88) // 60 seconds * 60 (= minutes) * 12 (=hours) * corrective factor
#else
#define battOp_ARGUMENT NoBattery
#define DEV_MODEL 0x32
#define CYCLETIME seconds2ticks(60UL * 3 * 0.88) // every 3 minutes
#endif
// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
{0xf3, DEV_MODEL, 0x01},// Device ID
"JPSENACT01", // Device Serial
{0xf3, DEV_MODEL}, // Device Model
0x10, // Firmware Version
as::DeviceType::Switch, // Device Type
{0x01, 0x00} // Info Bytes
};
Werde das heute Abend mal mit 0x32 im Battery Mode testen und berichten.
das ist bereits im Sketch über DEV_MODEL so vordefiniert:
Ja muss so, weil im Homematic Umfeld mit der CCU ein und dasselbe Gerät nicht optional BURST aktivieren kann. Deshalb sind es für die CCU 2 völlig unterschiedliche Gerätetypen.
Und wie gesagt - ich bezog mich auf die HMConfig_AskSinPPCustom.pm - denke ich, dass demnach FHEM den Batterie-Gerätetyp gar nicht kennt. Da steht halt nur F332 drin
Hab's gerade getestet: Mit F332 ist das Device trotz aktiviertem Battery Mode ansprechbar. Funktioniert also scheinbar erst mal.
dass demnach FHEM den Batterie-Gerätetyp gar nicht kennt
Dann wäre wohl jetzt mit geänderter ID mit weiterem Fehlverhalten zu rechnen?! Aber das kann wohl nur @pa-pa beantworten.
edit: Jetzt ist er wieder da: RESPONSE TIMEOUT:RegisterRead
War wohl eher Zufall, dass es beim ersten Mal geklappt hat.
Werde dann nochmal den HM-Sec-SD Sketch testen und auch davon den seriellen Output posten. Womöglich liegt da das Problem doch noch an anderer Stelle.
Mit F332 ist das Device trotz aktiviertem Battery Mode ansprechbar.
Wohl nur für den Moment, wo es noch wach ist.
War wohl eher Zufall, dass es beim ersten Mal geklappt hat.
Ja, es fehlt halt das BURST-Telegramm.
Tja, schade ... Hoffe das ist kein allgemeines Problem zwischen FHEM und AskSin-Devices sondern nur ein Problem der HMConfig_AskSinPPCustom.pm?! Original HM-Geräte, auch batteriebetrieben, funktionieren jedenfalls problemlos.
Gerade den SD wieder geflasht und die serielle Konsole angeschmissen - jetzt funktioniert natürlich alles einwandfrei :/
Naja, kann nicht lange dauern, bis der Fehler wieder auftritt. Hoffe nur, dass ich dann auch zufällig gerade die Konsole mit laufen habe ;)
Der nächste Schritt wäre jetzt
Für ein Batteriedevice müsste hier noch statt Idle ein Sleep erfolgen, sowie WOR aktiviert werden.
Aber bevor ich am Sketch rumbastel, muss ich erst mal sicher sein, dass der SD überhaupt zuverlässig funktioniert.
Auf jeden Fall nochmals vielen Dank bis hierher! Habe schon sehr viel durch Deine Hinweise gelernt :)
Für den Burst-Betrieb muss rxt=>'b' gesetzt sein. Im Prinzip das gesamte Gerät nochmal anlegen, mit richtiger ModelID und dem Burstflag. Wenn es funktioniert bitte nen PR
Für den Burst-Betrieb muss rxt=>'b' gesetzt sein. Im Prinzip das gesamte Gerät nochmal anlegen, mit richtiger ModelID und dem Burstflag. Wenn es funktioniert bitte nen PR
Du meinst in der .pm den ganzen Block für SenAct-4-4 kopieren und in dieser Zeile auf F334 und rxt=>'b' ändern, ja?
$HMConfig::culHmModel{"F332"} = {name=>"HB-UNI-SenAct-4-4-RC",st=>'custom',cyc=>'',rxt=>'',lst=>'1,3:1p.2p.3p.4p,4:5p.6p.7p.8p',chn=>"Sw:1:4,Btn:5:8"};
Nochmal zurück zum Sec-SD:
Er scheint jetzt zu funktionieren :) Beim ersten Mal habe ich den Fehler gemacht und ein set Alarm on direkt an den Rauchmelder gesendet. Das mag er gar nicht und danach spinnt das ganze Funknetzwerk. Dann habe ich einen virtuellen Teamleader erstellt, aber leider das Attribut IODev nicht korrekt definiert, was wiederum zum Lahmlegen des SD führte. Nachdem ich nun alles richtig hingefummelt habe, zeigt der virtuelle Teamleader den Alarm des SD an und kann auch einen Alarm im Team auslösen. Also alles super!
Jetzt müsste nur noch der SENS1_PIN invertiert funktionieren, also Alarm = High. Wo im Arduino Code könnte ich das drehen?
Danke!
Jetzt müsste nur noch der SENS1_PIN invertiert funktionieren, also Alarm = High. Wo im Arduino Code könnte ich das drehen?
AskSinPP/examples/HM-SEC-SD/HM-SEC-SD.ino
Line 143 in 43e3bf0
Nabend,
prima, danke!
Sleep und WOR habe ich auch eingebaut. Der Stromverbrauch schwankt jetzt irgendwo zwischen 5 und 80 uA (Multimeter) und trotzdem ist der SD erreichbar. Perfekt!
Der Rest ist Hardware, das kriege ich allein hin :)
Ach nee, einen habe ich noch:
Laut Doku zum Babbling Idiot soll die Uefuse auf 0xFF gesetzt werden. Das bedeutet ja, dass man den BOD komplett deaktiviert. Das finde ich schon mal merkwürdig ... Und an anderer Stelle habe ich auch gelesen, dass man den BOD auf 1,8 V stellen soll. Macht ja auch irgendwie mehr Sinn oder?!
-> Fehler in der Doku?
Das finde ich schon mal merkwürdig ... Und an anderer Stelle habe ich auch gelesen, dass man den BOD auf 1,8 V stellen soll. Macht ja auch irgendwie mehr Sinn oder?! -> Fehler in der Doku?
Nö, Fehler "an anderer Stelle".
Schlägt die BOD beim Senden zu, hast genau das was du nicht willst: einen BI
Das kann man so nicht sagen. Der (alte) ATMega32 brauch unbedingt BOD aktiviert, da es sont zu Fehlern im EEProm kommt, wenn die Spannung kurz unter die 1,8V fällt. Das hat uns beim Umflaschen der MAX Steckdosen ganz schön genervt. Man muss halt immer das ganze System sehen und da gibt es dann nicht nur eine richtige Lösung.
Kaputtes EEPROM hatte ich noch nie. BI bei BOD hingegen mehr als 1x 😞 Und dann noch als die Frau allein daheim war und ich auf Dienstreise. Das ist richtig doof.
Ich nehme daher wohl lieber das Risiko eines kaputten EEPROMs in Kauf
EEPROM korrupt war bei mir früher bei diversen AVR Projekten auch oft ein Thema. Ich mache deswegen jetzt normalerweise eine CRC oder chksum über den Inhalt.
Für richtige BI Protection mit BOD braucht es imho auch die CC1101 Abschaltung, Schaltung C bei mir
https://github.com/TomMajor/SmartHome/tree/master/Info/Babbling%20Idiot%20Protection#ma%C3%9Fnahmen
Oder halt die Batt.messung unter Last, wenn er damit dann in
hal.activity.sleepForever(hal);
geht sollte es auch passen.
Nabend,
Für richtige BI Protection mit BOD braucht es imho auch die CC1101 Abschaltung, Schaltung C bei mir https://github.com/TomMajor/SmartHome/tree/master/Info/Babbling%20Idiot%20Protection#ma%C3%9Fnahmen
Das meinte ich mit "an anderer Stelle".
Ist die Frage, was der Atmega328P bei Unterspannung so für Blödsinn macht ... Aber da komme ich hoffentlich niemals an, da der 9V Block des RM vermutlich eher leer ist als die 2xAA für den Arduino. Und dann werden einfach immer alle Batterien getauscht.
Soweit funktioniert jetzt bei mir alles, habe allerdings noch ein paar Modifikationen gebraucht. Die Probleme sind:
- Wenn der RM einen Alarm auslöst, triggert er den SENS1_PIN des Arduino, der Arduino aktiviert dann wiederum seinen SOUND_PIN. Somit "drückt" er bei mir den Test-Taster des RM und der Alarm läuft endlos weiter. Der Arduino dürfte (in meiner Anwendung) also den SOUND nicht aktivieren, wenn er an SENS ein Signal sieht.
- Wenn ich den RM per FHEM (Teamleader) auslöse, erhält der Arduino auch einen Alarm vom RM am SENS und meldet somit einen Alarm an FHEM zurück bzw. löst alle Rauchmelder im Team aus. Der Arduino müsste also Signale an SENS ignorieren, wenn er selbst gerade SOUND aktiviert hat.
Punkt 1 habe ich per Software gelöst, sodass SOUND nur noch High werden kann, wenn SENS Low ist (SENS = Low bedeutet bei mir kein Alarm):
void sound (bool on) {
if(digitalRead(senspin) == LOW)
digitalWrite(soundpin,on==true ? HIGH : LOW);
else
digitalWrite(soundpin,LOW);
}
(C++ ist nicht meine Stärke ;) )
Für 2. habe ich keine brauchbare Bedingung in der Software gefunden. Deswegen habe ich einen externen Transistor eingebaut, der SENS gegen Masse zieht, wenn SOUND High ist.
Weitere Problemchen:
- Löst der RM einen Alarm aus, so wird in FHEM
smoke-Alarm-xxwie erwartet hochgezählt. Wird jedoch vom Teamleader (FHEM) ein Alarm ausgelöst, melden die Arduinossmoke-Alarm-0Bzurück. Ich muss also auf 0B filtern, um einen eigenen von einem Remote-Alarm zu unterscheiden. - Die RMs benachrichtigen sich nicht (mehr) gegenseitig, sondern melden sich nur noch bei FHEM. Bin der Meinung, dass das anfangs funktionierte, nach einmal Batterien raus/rein aber plötzlich nicht mehr (es liegt nicht an den oben genannten Modifikationen, sondern hat schon vorher nicht mehr funktioniert).
- Die FHEM-Funktionen teamCall und teamCallBatt haben keine Wirkung. Ob der Arduino gar keine Pulse sendet oder mein RM einfach zu träge reagiert, weiß ich allerdings nicht.
Insgesamt tut es für mich jedenfalls, was es soll. Ich würde meinen Umbau dann auch gerne bei den Projekten posten, wenn gewünscht. Vielleicht habt ihr ja auch noch eine elegantere (Software-) Lösung für Problem 2.
Projektbeschreibung gerne auf https://asksinpp.de/Projekte/
Projektbeschreibung gerne auf https://asksinpp.de/Projekte/
Eieiei, da braucht man ja auch schon wieder einen Lehrgang für ... Wenn ich euch - wie beschrieben - die Bilder und Texte per Mail schicke, macht ihr dann ein Projekt draus? Oder kann ich mir das sparen, weil ihr eh keine Zeit dafür habt?
Ich habe jetzt 8 Rauchmelder umgebaut. 5 davon funktionieren (bisher) perfekt, bei den anderen 3 passiert es häufig (aber nicht immer), dass sie sich nicht mehr abschalten lassen, wenn ich über den virtuellen TeamLeader in FHEM einen Alarm auslöse. Anders ausgedrückt: bei set TeamLeader alarmOn gehen alle 8 an, bei set TeamLeader alarmOff aber meist nur 5 Stück wieder aus. Die anderen 3 stehen dann wiedermal auf "MISSING ACK" und sind erst nach einem Reset des Arduinos wieder ansprechbar. Oftmals hat sich dann auch der HM-MOD-RPI-PCB aufgehangen und muss neu gestartet werden. Solche Probleme kannte ich bisher nicht, deswegen wird das Problem wohl im Arduino-Code zu suchen sein?!
Über die serielle Konsole sieht das so aus:
Erfolgreich alarmOn und alarmOff ausgeführt (hier Rauchmelder 990107):
AskSin++ V4.1.0 (Aug 30 2019 21:41:11)
Address Space: 32 - 73
CC init1
CC Version: 04
- ready
Config Freq: 0x2165D2
<- 0C 01 94 41 990107 990107 01 00 01 - 1470
<- 0C 01 94 41 990107 990107 01 00 01 - 1853
<- 0C 01 94 41 990107 990107 01 00 01 - 2236
-> 0C 93 94 41 111111 111111 01 0B C8 - 2250 // Alarm On
-> 0C 95 94 41 111111 111111 01 0B C8 - 2750
-> 0C 96 94 41 111111 111111 01 0C 01 - 3254 // Alarm Off
-> 0C 98 94 41 111111 111111 01 0C 01 - 3756
Wenn das AlarmOff nicht geklappt hat, sieht es so aus (hier Rauchmelder 990104):
AskSin++ V4.1.0 (Aug 30 2019 21:17:16)
Address Space: 32 - 73
CC init1
CC Version: 04
- ready
Config Freq: 0x216582
<- 0C 01 94 41 990104 990104 01 00 01 - 1468
<- 0C 01 94 41 990104 990104 01 00 01 - 1853
<- 0C 01 94 41 990104 990104 01 00 01 - 2236
-> 0C B7 94 41 111111 111111 01 0B C8 - 2250 // Alarm On
alarmOn wird also noch ausgeführt, danach gibt es keine Kommunikation mehr ...
Also ich bin da leider komplett raus.
Habe weder die Möglichkeit es zu reproduzieren noch irgendwann in meinem Leben mal ein "aufgehängtes HM-MOD-RPI-PCB" gehabt.
Hm - keine AHnung, was da passiert. Kannst Du mal die nachrichten von einem dritten Gerät aufzeichnen lassen. Dann sieht man besser, was wirklich durch die Luft get.
Für die Projektbeschreibung habe ich keine Zeit.