MAX! Fensterkontakte senden nach gewisser Zeit keine Daten mehr an FHEM?

Begonnen von -kw, 15 August 2019, 22:30:48

Vorheriges Thema - Nächstes Thema

-kw

Hallo,

ich habe einen nanoCUL (culfw 1.67) an einem rpi mit fhem auf Docker laufen. Daran gekoppelt habe ich zwei MAX! Fensterkontakte, welche im FHEM auch funktionieren und ihren Status bei Öffnen/Schließen senden. In FHEM wird der Status aktualisiert und notifiys getriggert - also alles wie es sein soll.

ABER: Das funktioniert nur ein paar Minuten (ca. 5min). Danach kann ich die Kontakte öffnen/schließen, sie blinken auch (senden also offenbar etwas), aber fhem aktualisiert die Information (opened/closed) nicht mehr. In den meisten Fällen reicht es, die Batterien aus den Kontakten zu entfernen, wenige Sekunden zu warten und wieder einzulegen. Manchmal (nach ein paar Stunden) klappt das nicht mehr und ich muss den gesamten rpi neu starten. Die Zeiten sind bei den Fensterkontakten auch unterschiedlich, manchmal funktioniert auch nur einer der beiden nicht.

Dazu meine Fragen:
Hat dieses Verhalten schon mal jemand beobachtet?
Könnte der nanoCUL falsch programmiert sein?
Haben die Fensterkontakte einen "Standby-Modus"?
Was kann ich tun, damit die Verarbeitung durchgehend ist?  :'(

Ich danke euch schon mal :)

Wzut

Ich tippe auf nicht richtig gepaired mit deinem cm Device.
Werfe doch einfach mal statt die Batterien raus zu nehmen den pairmode an und beobachte den event Monitor & Log beim open/close
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

-kw

Hallo Wzut.

Danke für deine Antwort!
Ich habe genau das getan, doch leider bleibt der event Monitor leer. Es kommen keine Einträge von den betroffenen Geräten dazu :/

Maui

Moin,

wenn du sagst sie blinken, wie häufig tun sie das?
Wenn sie richtig gepairt sind (und ein ACK kommt) dann sollten Sie beim öffnen nur 1x leuchten und beim Schließen ebenfalls nur 1x.

Gruß
Maui

-kw

Hallo Maui,

danke für Antwort!

Der Blinkvorgang dauert beim Öffnen/Schließen ca. 4 Sekunden und die Türkontakte blinken dabei 3 mal. Also anders als bei dir beschrieben.
Außerdem ändert sich der Status in FHEM von "opened", bzw. "closed" während des Blinkens in "opened (rf error)", bzw. "closed (rf error)" nach dem Blinken.

Wie habe ich die Türkontakte gepairt?
Zunächst habe ich das Modul CULMAX0

define Max1 CUL_MAX 123456
attr CUL868 rfmode MAX


Aus dem entferne ich nun die Batterien, lege sie neu ein und öffne den Kontakt. Daraufhin erstellt FHEM via autocreate ein neues Device.

define MAX_Kontakt_Wohnzimmer MAX ShutterContact 151cfe

Damit ist der Pairvorgang abgeschlossen. Denke ich zumindest. :P

Habe das mehrfach probiert, immer gleiches Ergebnis  :-\

Wzut

Zitat von: -kw am 19 August 2019, 17:21:58
Denke ich zumindest.
Denken ist Glücksache, Wiki lesen und befolgen ist da zielführender, gerade die FKs sind da oft etwas mädchenhaft. (und rot ist eh ein no go )
Ein Blick ins Log könnte auch hilfreich sein, garantiert sind da einige Meldungen in der Queue
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Maui

Schau dir mal die Anleitung der FKs an. Da steht wie du die sauber resettest, Batterie raus reicht nicht.

-kw

Zitat von: Maui am 19 August 2019, 19:35:18
Da steht wie du die sauber resettest, Batterie raus reicht nicht.

Ich glaube das war es >.<
Zumindest blinkt die LED nur einmal und das "(rf error)" ist weg. Ich beobachte das noch, aber kann mir sehr gut vorstellen, dass das der Fehler war. DANKE!!

@Wzut:
Das Wiki habe ich selbstverständlich schon gelesen, aber leider dort keine Antwort gefunden :/ Was meinst du mit "rot ist ein no go"?

-kw

Ich muss meine Nachricht von gestern leider nochmal revidieren.

Seit heute morgen blinken die Türkontakte wieder 3mal beim öffnen/schließen und in FHEM passiert nichts - auch der Event Monitor hat keine Einträge dazu. :'(

Ich habe den Pi neu gestartet und es funktioniert wieder. Jetzt fasse ich das ganze nicht mehr an und prüfe, ob es morgen wieder nicht geht. Jetzt erscheint im Event Log übrigens auch etwas :}

2019-08-20 18:58:54.046 MAX MAX_Kontakt_Wohnungstuer battery: ok
2019-08-20 18:58:54.046 MAX MAX_Kontakt_Wohnungstuer batteryState: ok
2019-08-20 18:58:54.046 MAX MAX_Kontakt_Wohnungstuer onoff: 0
2019-08-20 18:58:54.046 MAX MAX_Kontakt_Wohnungstuer closed
2019-08-20 18:58:54.046 MAX MAX_Kontakt_Wohnungstuer RSSI: -61

Wzut

Zitat von: -kw am 19 August 2019, 22:55:26
Was meinst du mit "rot ist ein no go"?
Sorry , da war ich geistig bei HM (die haben eine Duo LED) , MAX mit seiner grünen LED blinkt bei OK einmal und bei NOK 3x
Aber dein Fehler klingt nach einem CUL Problem, als würde der sich nach Zeit X ein Nickerchen gönnen. Ich würde im Fehlerfall da mal ansetzen :
regiert er noch auf Kommandos wie get ccconf oder get credits10ms ? Wenn nein ihm mal ein reopen schicken.
oder schaltet den Pi die USB Ports ab ? siehe https://forum.fhem.de/index.php/topic,75898.msg968491.html#msg968491
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

-kw

Nicht so schlimm, kann ja mal passieren :P

Auf die Befehle reagiert ohne Probleme:
CUL868 ccconf => freq:6588.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
CUL868 credit10ms => 900


Betrieben wird der Pi über einen USB-Port am Router. Es kann also gut sein, dass die Stromaufnahme zu gering ist. Ich habe das gar nicht gewusst, dass die nach einer Weile abgeschaltet werden. Ich habe die Anleitung befolgt. Mal schauen, ob es etwas bewirkt. Wenn nicht, muss ich mich nach einem extra Netzteil umsehen ;) Ich melde mich am Wochenende, da ich die kommenden zwei Tage nicht zu Hause sein werde.

Vielen lieben Dank auf jeden Fall! =)

-kw

Heyho,

mein "Langzeittest" hat ergeben: IT WORKS!
Es lang anscheinend tatsächlich nur an der Stromversorgung! Sehr interessant. Vielen Dank für die Hilfe!  :)