Problem gelöst! CUL868 funktioniert nach einer Weile nicht mehr...

[skydns]

Hallo,
ich habe seit einer Woche den Signalduino im Einsatz. Bin von den GPIO Ports (mit PiLight) vom Raspi weg, weil der ständige Empfang von Signalen bei mir die CPU Auslastung auf ca. 20% angehoben hat. Um das Problem zu beheben habe ich gelesen, das man es auf den FHEMduino jetzt Signalduino auslagern kann. Nachdem die Teile angekommen sind, habe ich es zusammen gebaut, geflasht auf V3.3.1 und in FHEM eingerichtet. Auf den ersten Blick funktionierte es auch einwandfrei.
Nun habe ich alle Fernbedienungen ausgelesen 4 x InterTechno IT1500. Über Autocreate hat das auch super geklappt, habe auch meine Wetterstation und eine aus der Nachbarschaft gefunden. Da ich die Funksteckdosen u.a. als Zeitschaltuhren über FEHM nutze ist mir aufgefallen, dass das senden über Signalduino nicht so zuverlässig funktioniert.
Also habe ich bei den angelegten Steckdosen IODev von sduino auf CUL868 umgestellt. Das funktioniert dann zuverlässig, bis ein paar Stunden vergangen sind.
Ein blöder Fehler, da erstmal alles gut zu sein scheint.

Nach einiger Zeit, ca. 1 Stunde später, kann ich nichts mehr per CUL868 schalten. Den Signalduino hatte ich weiterhin angeschlossen um die Rückmeldung über die Fernbedienungen abzufangen und den aktuellen Status im FHEM anzuzeigen.

Der Fehler lässt sich dann über "shutdown restart" im FHEM nicht beheben. Erst nach einem Reboot des Raspi läuft wieder alles. Den Signalduino habe ich nun erstmal abgeklemmt. Hat oder hatte jemand mal ein ähnliches Problem? Die angelegten Steckdosen sind doch nicht mehr mit dem sduino gekoppelt, wenn ich IODev auf den CUL868 ändere.

FHEM 5.8
CUL868 V1.66
Signalduino V3.3.1
Sender und Empfänger sind i.O. und funktionieren über GPIO zuverlässig.

Für Tipps bin ich dankbar, ich komme an dieser Stelle erstmal nicht weiter...

Gruß Marco

[Beta-User]

Hallo skydns,

es wäre einfacher zu suchen, wenn Du den angepinnten Beitrag "was sollte ich..." beachtet hättest (list vom CUL und Signalduino).

Die Glaskugel deutet auf einen USB-Konflikt hin (wobei das Auftreten nach 1h untypisch wäre). Sind beide Geräte mit ID definiert (Wiki: Tipp der Woche)?

Gruß, Beta-User

[skydns]

Hi Beta-User,
beide sind by-id definiert. Übernacht hatte ich den Signalduino ab und der Fehler trat dennoch auf.

Fehlerbild: Ich sende z.B. das die Steckdose WZ_B (433MHz) eingeschaltet werden soll, im "Event monitor" sehe ich das es gesendet wurde. Am CUL868 sehe ich, das die LED kurz leuchtet (habe ich so eingestellt, das sie beim senden und empfangen leuchten soll). An der Steckdose WZ_B passiert nix.

Statt einen "reboot" habe ich diesmal nur den CUL868 abgezogen und wieder angesteckt, nun kann ich wieder die Steckdosen schalten. Die Signale der Türkontakte (868Mhz) werden jedoch aktuell nicht empfangen, das sehe ich auch schon an den Türkontakten, da die LED sonst gleich grün wird und aktuell orange leuchtet.

Da es offenbar nicht am Signalduino liegt habe ich ihn wieder in Betrieb genommen und suche den Fehler nun am CUL-Stick 868.

Anbei noch zwei Screenshots vom CUL868 und SIGNALduino

[skydns]

Nach einem "reboot" geht nun wieder alles auf 868Mhz und 433Mhz. Mal sehen wie lange, bin nun erstmal im Garten, tritt der Fehler nachher erneut auf werde ich den CUL868 neu flashen und hoffe das es das Problem löst.

[KölnSolar]

Wenn Du im 868-Modus Probleme hast, mach immer mal ein ccconf. In Deinem Post ist die Bandbreite auf ungewöhnlichen 101 kHz.
Grüße Markus

[skydns]

Aktuell geht der CUL gerade wieder nicht, im Log habe ich ungewöhnliche Einträge vom CUL entdeckt. Ohne das ich am Rechner gearbeitet habe hat er den Frequenzmodus gewechselt.

Code Auswählen Erweitern

2017.03.12 16:28:47 3: CUL868 IT_set: NZ_B off
2017.03.12 16:28:47 2: Switched CUL868 rfmode to SlowRF
2017.03.12 16:28:47 2: IT IODev device didn't answer is command correctly:   raw => OFF
2017.03.12 16:28:47 2: Switched CUL868 rfmode to HomeMatic
2017.03.12 16:28:47 3: CUL868: Unknown code is00010111111111100010001010000001, help me!
2017.03.12 16:28:49 3: CUL868 IT_set: NZ_B on
2017.03.12 16:28:49 2: Switched CUL868 rfmode to SlowRF
2017.03.12 16:28:49 2: IT IODev device didn't answer is command correctly:   raw => OFF
2017.03.12 16:28:49 2: Switched CUL868 rfmode to HomeMatic
2017.03.12 16:28:49 3: CUL868: Unknown code is00010111111111100010001010010001, help me!
2017.03.12 16:29:03 1: Haustür wurde geöffnet
2017.03.12 16:29:11 1: Haustür wurde geschlossen

Normalerweise wird das nicht geloggt.

An der Bandbreite habe ich nichts geändert, ist 101kHz nicht normal?

Gruß Marco

[skydns]

Nun habe ich den CUL geflasht auf Version 1.67 erstmal geht wieder alles, ohne reboot.

CUL V1.67 gibt es da:
https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/

ccconf sieht aktuell so aus: freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB

macht mir aber auch keine Probleme, scheint Standard zu sein.

Ich melde mich wieder, teste erstmal weiter.

[KölnSolar]

jetzt, wo Du das Log gepostet hast schon. Du nutzt scheinbar homematic .  Dein Problem ist das zum senden von 433 erforderliche automatische Umschalten des rfmode von homematic -> slowRf -> homematic. Warum das dann eine zeitlang geht und dann nicht mehr

Ohne das ich am Rechner gearbeitet habe hat er den Frequenzmodus gewechselt.

Aber irgendwas wollte NZ_B schalten, oder ? Und das ist ne IT1500, oder ?
Edit: glaube eher nicht, dass die 1.67 hilft 

[Ralf9]

Wenn Du den CUL868 im Homematic Mode zum senden von IT nutzt, hast Du einige Nachteile.
Beim CUL868 hat das senden von 433MHz nur eine eingeschränkte Reichweite.
In der Zeit wo der CUL868 IT sendet, kann er kein Homematic empfangen oder senden. Es könnte sein, daß Du dadurch z.B. eine Meldung eines Türkontaktes nicht mitbekommst.
Zu homematic mit dem CUL siehe auch hier
https://forum.fhem.de/index.php/topic,68145.msg595998.html#msg595998

Die Probleme beim Senden mit dem Signalduino könnte am ITclock liegen. Beim CUL ist der default ITclock 300. Beim Signalduino ist der default ITclock 250.
Hier habe ich was zur Ermittlung des ITclock geschrieben:
https://forum.fhem.de/index.php/topic,52827.msg604104.html#msg604104


Gruß Ralf

[skydns]

Danke für eure Hilfe, um 18 Uhr sollte NZ_B schalten. In den Attributes war nur bei NZ_B "switchrfmode 1" gesetzt. Das habe ich gelöscht, nun funktioniert alles wie es soll. Immer wenn NZ_B geschaltet wurde führte dies zu einem Fehler im CUL868.

Problem gelöst.