Hallo,
kann man beim HM-SEC-SCo (Tür-/Fensterkontakt) die LED ausschalten?
Frank
Ein get <SCo> reglist liefert mir:
list: register | range | peer | description
0: cyclicInfoMsg | literal | | cyclic message options:on_100,off,on
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
0: sabotageMsg | literal | | enable sabotage message options:off,on
0: transmDevTryMax | 1 to 10 | | max message re-transmit
1: eventDlyTime | 0 to 7620s | | filters short events, causes reporting delay
1: ledOnTime | 0 to 1.275s | | LED ontime
1: msgScPosA | literal | | Message for position A options:closed,open,noMsg
1: msgScPosB | literal | | Message for position B options:closed,open,noMsg
1: sign | literal | | signature (AES) options:off,on
1: transmitTryMax | 1 to 10 | | max message re-transmit
4: expectAES | literal | required | expect AES options:off,on
4: peerNeedsBurst | literal | required | peer expects burst options:on,off
Ich würde vermuten, dass das Setzen der ledOnTime den gewünschten Effekt auslöst.
ABER: es ist mir nicht gelungen, das Register zu ändern. Weder das Setzen auf 0 noch auf 1 ändert irgendwas am Verhalten.
Der Wert des Registers wird auch nicht ausgelesen und angezeigt.
R-ledOnTime set_0 s
ändert sich auch nach einem neuen getConfig nicht.
Firmware des ausgetesteten SCo ist 1.0. Jibbet wat frischeret?
@Martin: Ich glaube, da stimmt was mit der Registertabelle für die SCo's nicht...
Zitat von: Pfriemler am 27 November 2016, 16:57:36
Firmware des ausgetesteten SCo ist 1.0. Jibbet wat frischeret?
Hi pfriemler,
habe ich vor ein paar Tagen gefunden und installiert -> http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update#Tool_zur_Firmware_Versionspr.C3.BCfung
Hübsche Sache 8)
Gruß Otto
Kenn ich Otto, hab ich auch, aber dort sind nur die Updateables drin. Einige Geräte sind m.W. irgendwann einfach mit neuer Firmware erschienen, ohne dass es die zum Update zum Herunterladen gab.
geht nich gips nich
Moin,
ich habe erst in den letzten Wochen ne ganze Reihe SCo als Bausätze gekauft und gebaut. Die haben alle die 1.0
Gruß Otto
@Martin: Kannst Du bitte bei dem Device mal nachsehen: Das Reading ledOnTime wird nicht gesetzt.
gibts beim SCO nicht - bug in meinem Code.
Korrigiert (sorry)
Hallo Martin,
vielen Dank für deine Hilfe. Leider funktioniert das Setzen von "ledOnTime" noch nicht. Im Reading steht weiterhin "set_0". Mehrfaches Drücken der Anlerntaste und erneutes pairing bringt keine Besserung.
fhem ist auf dem aktuellen Stand (von gerade eben). Ich nutze die TSCUL-Firmware und habe u.a. "10_CUL_HM.pm" vom Update ausgeschlossen. Ist dies das Problem?
Viele Grüße
Frank
Martin sagte doch, dass es ein Bug war und der SCo kein solches Register hat... also wird das Setzen auch künftig nicht funktionieren.
Ich denke, dass nach einem Update von HMConfig.pm (unabhängig von 10_CUL) der Versuch einer solchen Registermanipulation gleich zurückgewiesen wird (unknown register) - genau wie es sein soll.
geht nich gips nich
Hi,
Naja, zumindest ist bei mir das Register in der regTable noch drin:
HMConfig.pm 12707 2016-12-03 18:39:36Z martinp876
list: register | range | peer | description
0: cyclicInfoMsg | literal | | cyclic message options:on_100,on,off
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
0: sabotageMsg | literal | | enable sabotage message options:on,off
0: transmDevTryMax | 1 to 10 | | max message re-transmit
1: eventDlyTime | 0 to 7620s | | filters short events, causes reporting delay
1: ledOnTime | 0 to 1.275s | | LED ontime
1: msgScPosA | literal | | Message for position A options:open,closed,noMsg
1: msgScPosB | literal | | Message for position B options:open,closed,noMsg
1: sign | literal | | signature (AES) options:on,off
1: transmitTryMax | 1 to 10 | | max message re-transmit
4: expectAES | literal | required | expect AES options:on,off
4: peerNeedsBurst | literal | required | peer expects burst options:on,off
Gruß Otto
Ich habe ein fhem-Update gemacht, das Device zurückgesetzt und ein neues Pairing gemacht. Nun ist das Reading "ledOnTime" futsch, d.h. nix mehr einzustellen :-\
Hallo,
abschalten geht nicht, ist Absicht (hatte ja auch Martin schon geschrieben):
http://www.elv.de/topic/abschalten-der-geraete-led-nicht-moeglich.html
Viele Grüße
Michael
Vielen Dank für die Info. Das ist auch meiner Sicht aber keinen Sinn ...
wie wäre es mit einem wunschzettel an eq3.
Gute Idee ... der wird bestimmt voll werden. Aber die fokussieren sich ja nur noch auf IP.
Ein Wunschzettel wäre toll! Ich würde gerne die rote LED geziehlt blinken lassen in gewissen Abständen, wenn das Fenster geöffnet ist, aber eine Taupunktberechnung innen/außen zum Ergebnis kommt, dass das Lüften kontraproduktiv ist. Da würde sich die rote LED als Warnelement (z.B. kurzes Aufblitzen alle 10s) wirklich anbieten... 8)
Wie warnt ihr davor? Möglich ist ja auch noch die TTS-Ausgabe und/oder irgendeine Push-Message aufs Handy. Aber so eine Möglichkeit direkt am Ort des Geschehens wäre natürlich am Besten. Man könnte dann ja auch nach 5min ohne Reaktion einfach den Rollladen schließen. :P Aber ich schweife vom Thema ab und werde OT.
Der Wunsch krankt wie bei vielen anderen Geräten an der fehlenden Dualität (m.W. ist der Regensensor der einzige Sensor, der einen von außen schaltbaren Aktorkanal (Sensorheizung) besitzt). eq3 kennt sonst fast nur Aktoren oder Sensoren.
Die Sensoren sind also zumeist als Batteriegeräte nicht von außen aufweckbar (eigentlich gut, weil das sehr zu Lasten der Batterielebensdauer ginge. Einzig der Modus Rotblinken ließe sich theoretisch im Rahmen einer Quittierung einschalten, also wenn der SCo zyklisch oder wegen Zustandsänderung eine Meldung absetzt.
Was ginge: FHEM könnte die Quittierung aktiv blockieren, also etwa die Taupunkte innen und außen zyklisch berechnen und damit ein Flag setzen, ob dem SCo quittiert werden sollte: also Du machst Fenster auf und guckst: grün ok, bei rot lieber gleich wieder schließen.
Ich habe das mal experimentell mit meinem Garagentor gemacht: ein Short auf einer Fernbedienung wurde von dieser mit grün = zu oder rot = auf quittiert, ein long hat dann den Antrieb gestartet. Gelöst habe ich das praktisch über das peering mit einem virtuellen Kanal (vccu oder dummy), bei denen man ja anders als bei realen Geräten per attr peerIDs die Peerpartner direkt setzen kann.
Hat sich aber praktisch nicht bewährt, auch wegen ständiger Meckereien der HM-peerChecks und Co.
Jm2c.
via Tapatalk
Dank dir für die Antwort - hatte mir schon gedacht, dass das nur über Trixereien möglich ist. Und das mit den Meckereien in den PeerChecks würde mich irgendwann auch tierisch nerven... :D
Also das sieht dämlich aus, erfüllt aber seinen Zweck.
Das sieht in der Tat "dämlich" aus. Dann lieber Kappe ab, ein paar Mal mit einem dicken schwarzen Edding tupfen und Kappe wieder drauf. So bleibt eine geringe Restlichtmenge, die als Diagnose auch hilfreich sein kann. Den Knopf drückt man nach erfolgter Durchkonfiguration ja eigentlich nie wieder.
Aber jeder wie er mag. ;D