Max Fensterkontakte schreiben nicht ins Log

Begonnen von Roaster, 10 August 2014, 23:19:13

Vorheriges Thema - Nächstes Thema

Roaster

Hi,

Ich habe heute vier Max Fensterkontakte in Betrieb genommen und nach ein paar Tests, die positiv verlaufen sind, an die vorgesehenen Fenster geklebt.

Während der Tests wurde korrekt in die jeweiligen Log-Dateien geschrieben. Auch im weiteren Verlauf meldeten sich zwei der Kontaktschalter (stündlich) im Log mit dem aktuellen Status (closed, battery: ok).
Zwei haben aufgehört zu berichten. Es gibt keinen neueren Logeinträge. Die Fensterkontakte sind mit keinen Thermostaten gepaired. Die habe ich nicht. Am Raspberry arbeitet ein Busware CUL.

Habe ich etwas falsch gemacht? Oder ist es eher umgekehrt, dass sich die beiden anderen Fensterkontakte zuviel melden?

Michael

John

Hi Michael,
soweit die Fensterkontakte mit dem CUL gepaart sind, sollten diese sich zumindest stündlich melden.

Sind die alle Fensterkontakte in deiner fhem.cfg zu finden ?

Ansonsten solltest die stummen nochmals paaren.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Roaster

#2
Hmm ja, es sind alle gepaart. Wenn ich die Fenster öffne, bekomme ich ja auch einen neuen Logeintrag.

Ich habe die beiden, die bisher stumm wurden (also stündlich keinen Kontakt hatten), nur mit dem CUL gepaart. Das lief dann auch eine Stunde gut, aber seither ist wieder Ruhe.

Seltsamerweise sind jetzt von den vier Kontakten jetzt mehr oder weniger verstummt. Stand jetzt (21:52 Uhr) hat nur einer der Kontakte zuletzt um 21:18 Uhr ins Log geschrieben.
Der Rest der Kontakte um 17:42, 17:41 und 19:01.

Die Fensterkontakte sind mittels Include in die fhem.cfg aufgenommen. In meinem Dashboard sehe ich ja alles korrekt, so auch den jeweiligen Zeitpunkt, wann zuletzt der Batterie-Status aktualisiert wurde (siehe Zeitangaben oben).

Ich bin gerade nochmals an eines der fraglichen Fenster hin und habe zur Kontrolle geöffnet und geschlossen. Ergebnis: ein neuer Eintrag im Log.

Irgendwie haben die Kontakte wohl vergessen sich stündlich zu melden.

Mein Auszug aufs der fhem.cfg
# CUL einstellen, wenn nicht automatisch erkannt
define CUL1 CUL /dev/ttyACM0@9600 1234
attr CUL1 rfmode MAX
define cm CUL_MAX 123456
attr cm IODev CUL1

# Kellerfenster einbinden
include /opt/fhem/FHEM/kellerfenster.cfg

und aus dem Include
define KellerFensterWerkstatt MAX ShutterContact 00e9da
attr KellerFensterWerkstatt IODev cm
attr KellerFensterWerkstatt alias Keller Fenster Werkstatt
attr KellerFensterWerkstatt devStateIcon closed:fts_window_roof@green opened:fts_window_roof_open_2@red
attr KellerFensterWerkstatt group Keller
attr KellerFensterWerkstatt room Keller,KellerWerkstatt
define FileLog_KellerFensterWerkstatt FileLog ./log/KellerFensterWerkstatt-%Y.log KellerFensterWerkstatt
attr FileLog_KellerFensterWerkstatt logtype text
attr FileLog_KellerFensterWerkstatt room KellerWerkstatt

der vollständigkeithalber.

Edit: gerade als ich abgesendet habe hat sich wieder einer gemeldet, derjenige der sich zuletzt um 19:01 gemeldet hat - zwei Stunden Unterschied - woher kommt denn das?

Grüße,
Michael

Roaster

Nochmals kurze Rückmeldung: Während zwei der Kontakte sich heute früh korrekt gemeldet haben, sind die anderen  beiden seit gestern Abend still. Es sind nach wie vor die selben, die bisher auch schon Schwierigkeiten machten  :(

Ich werde heute mal neu pairen, obwohl ich dies gestern bereits durchgeführt hatte. Kann man die irgendwie zuverlässig auf Auslieferungszustand zurücksetzen? So wie ich es bisher versucht hatte mit set factoryReset ist es wohl nichts gewesen...

Michael

chris1284

evtl ist die Position der beiden Kontakte die sich nicht melden nicht optimal ...
ich würde sie einfach nochmal abnehmen und in die Nähe des CUL bringen und schauen ob sie sich wieder regelmäßig melden

Gigafix

Eine unterschiedliche Firmware könnte auch die Ursache sein. Ansonsten wäre natürlich ein Reset am Kontakt selbst sehr zu empfehlen - wie Du ja auch schon erwähnt hast.
VM Synology DS918 | CubieTruck |2x HMLAN | HMUSB | 3x HMWLAN | CCU2 | MAX-Cube | nanoCUL | ZWDongle |

Roaster

Zitat von: chris1284 am 12 August 2014, 08:51:38
evtl ist die Position der beiden Kontakte die sich nicht melden nicht optimal ...
ich würde sie einfach nochmal abnehmen und in die Nähe des CUL bringen und schauen ob sie sich wieder regelmäßig melden
Könnte sein, jedoch sind die beiden, die sich immer wieder mal melden sogar weiter weg, als die beiden, die derzeit Probleme machen.

Erklärt natürlich nicht unbedingt das Verhalten, da ja auch bauliche Gegebenheiten hier mit reinspielen, aber zumindest ist es so, dass bei einem der stummen Kontakte, der CUL direkt darüber im EG sitzt. Während die beiden anderen, die sich jedes Mal melden, sich schon im nächsten Kellerraum befinden und somit zumindest durch eine weitere Wand müssen.

Michael

Roaster

Zitat von: Gigafix am 12 August 2014, 09:16:33
Eine unterschiedliche Firmware könnte auch die Ursache sein. Ansonsten wäre natürlich ein Reset am Kontakt selbst sehr zu empfehlen - wie Du ja auch schon erwähnt hast.
Apropos Firmware. Ich habe bei meinen beiden HM Fensterkontakten, durch das vorhandene autocreate in der fhem.cfg, auch automatisch die Firmware dort erhalten.
Bei den Max Fensterkontakten war dies nicht der Fall. Wird die Firmware nicht automatisch zurückgeliefert?

Wie könnte ich nun an die Version kommen? Bzw. woher weiß ich was die aktuelle ist und vor allem wie kann man diese flashen?

Grüße,
Michael

chris1284

Die Entfernung / Wand dazwischen kann relativ egal sein wenn die beiden durch irgendetwas gestört werden und so die Signal kaum /schlecht beim CUL ankommen. War halt ne Vermutung da du in Post 1 schriebst:

Zitatvier Max Fensterkontakte in Betrieb genommen und nach ein paar Tests, die positiv verlaufen sind

und erst nach dem platzieren die Problem kamen  ;)

Roaster

Im Nachhinein betrachtet glaube ich nicht so recht an Probleme mit dem Platzieren oder den Örtlichkeiten generell, weil das Öffnen und Schließen ja korrekt gemeldet wird.

Lediglich das Intervall, bei dem sich die Kontakte freiwillig melden sollten scheint zum Teil unterschiedlich oder gar nicht (mehr) vorhanden zu sein.

Mal sehen was heute noch rauskommt wenn ich zu Hause bin und bei den beiden Problemkindern mal einen Werksreset mache.

Gigafix

Ich hätte schwören können bei meinem zweiten Max Fensterkontakt schon mal die Firmwareversion 1.4 in den Readings gesehen zu haben. Das war aber wohl ein Irrtum. Zumindest konnte ich jetz auch nichts von einer Firmwareversion bei mir erkennen.
Ein Fensterkontakt meldet sich bei mir auch nicht wie gewünscht, der ist aber mit dem Wandthermostat verbunden. Somit denke ich das es daran liegt. Da dieses System mit dem Heizregler ganz gut zusammenarbeitet, will ich das aber vorerst auch nicht ändern.
Wenn du unbewusst einen ähnlichen Fall hast, zB durch schon mal "gebrauchte" Fensterkontakte, wird Dir der Werksreset direkt am Kontakt sicherlich weiterhelfen.
VM Synology DS918 | CubieTruck |2x HMLAN | HMUSB | 3x HMWLAN | CCU2 | MAX-Cube | nanoCUL | ZWDongle |

Roaster

Zwei der Kontakte geben in den Readings die Firware 1.3 aus, die anderen gar nicht. Auch schon mal seltsam, oder?
Ich nutze die Kontakte ohne Thermostate.
Ich habe gestern dann noch einen Werksreset bei denn beiden gemacht und bis so ca.  23.00 Uhr haben dise brav gefunkt.  Mal sehen wie es heute uim laufe des Tages dann aussieht.

Michael

Roaster

Kurze Rückmeldung: es scheint jetzt alles wieder normal zu laufen. Die beiden Kontakte senden wie erwartet jetzt auch wieder Daten.

Danke fürs Mitlesen und den Ideenaustausch!