CUL schaltet ploetzlich ab

[Guest]

Originally posted by: <email address deleted>

Hallo zusammen,

Seit Samstag spiele ich etwas mit dem CUL und fhem herum, zur Zeit
hauptsächlich,
um Meßdaten aus den 6 FHT80b, 8 S300TH und 1 KS300 auszulesen.  Das
funktioniert eigentlich auch recht gut, allerdings ist nun 3 mal etwas
passiert, was ich
mir nicht ganz erklären kann.  Vielleicht hat jemand dasselbe erlebt
und hat ggf. eine
Lösung oder Debugvorschläge. (fhem aus CVS, culfw 1.35)

Nach einigen Stunden Betrieb (meist >12h) werden keinerlei Daten mehr
vom CUL an
fhem gemeldet. fhem selbst läuft, ist ansprechbar und versucht z.B.
auch at-Kommandos
loszuwerden.  /dev/ttyACM0 war die ganze Zeit vorhanden, es kam auch
zu keinem Reset
auf USB.  Beim ersten Mal habe ich fhem neugestartet und es lief auf
Anhieb wieder.  Beim
zweiten Mal ging ich etwas sanfter vor und fand heraus, daß es
aureicht, mit verbose 21 den
CUL wieder zum empfangen zu überreden.  So wie ich die culfw-Doku
verstanden habe, könnte
das ein Zeichen sein, daß der Empfänger des CUL abgeschaltet hat und
durch das X21 wieder
aktiviert wurde.

Hat jemand eine Idee, was das Problem sein könnte?  Im Moment nutze
ich den Watchdog,
um o.g. Kommando abzusetzen, wenn keine Daten mehr ankommen, aber das
sollte
nur eine Notlösung sein.

Schon jetzt vielen Dank.

Mit freundlichen Grüßen,
MB

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

On Thu, Mar 04, 2010 at 02:41:31AM -0800, Michael Bussmann wrote:
> könnte das ein Zeichen sein, daß der Empfänger des CUL abgeschaltet hat und
> durch das X21 wieder aktiviert wurde.

Koenntest Du in so einem Fall folgende Ausgaben sammeln, und uns mitteilen:
- get CUL raw X
- get CUL raw C35

Ich vermute das Problem im Zusammenhang mit der FHT Kommunikation, und wuerde
mich deswegen interessieren, ob es beim abgeschalteter FHT-Funktionalitaet
(CUL-ID 0000, bzw. set CUL raw t010000) es auch auftritt.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Re,

On 2010-03-04 12:35:06 +0100, Rudolf Koenig wrote:

> Koenntest Du in so einem Fall folgende Ausgaben sammeln, und uns mitteilen:

Ich schalte den Watchdog mal aus, warte auf den nächsten Aussetzer und
setze dann mal die Befehle ab.

Bis dann,
MB

--
Michael Bussmann
BOFH excuse #271:
The kernel license has expired

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Moin,

On 2010-03-04 17:09:00 +0100, Michael Bussmann wrote:

> > Koenntest Du in so einem Fall folgende Ausgaben sammeln, und uns mitteilen:
> Ich schalte den Watchdog mal aus, warte auf den nächsten Aussetzer und
> setze dann mal die Befehle ab.

(Nach etwas Nachdenken: Warum selber machen, wenn man es automatisieren
kann?).

Heute ist es wieder passiert.  Hier mal ein Log-Ausschnitt.  Am 13:27 wurde
es ruhig.  Die Ergebnisse von C35 und X (wobei die Werte im Normalzustand
nicht anders sind):

| 2010.03.05 13:33:31 3: cul868 raw => C35 = 0D / 13
| 2010.03.05 13:33:36 3: cul868 raw => 21  900

Erst ein X21 lässt die Sache wieder starten:

| 2010.03.05 13:46:01 4: set cul868 verbose 21
| 2010.03.05 13:46:21 4: cul868: K01589138 -54.5

Das Ganze etwas ausführlicher:

| 2010.03.05 13:26:51 4: cul868: K61952149 -38
| 2010.03.05 13:26:51 4: CUL_WS S300TH Test1: T: 19.5  H: 49.2
| 2010.03.05 13:27:01 4: cul868: T1E3A00A61C -78.5
| 2010.03.05 13:27:01 4: FHT OGL_sz actuator: 11%
| 2010.03.05 13:27:05 4: cul868: K1740100700FB10 -84.5
| 2010.03.05 13:27:05 4: KS300 1234: 810d04xx4027a0017104017000bf01
| 2010.03.05 13:27:16 4: cul868: T1E3A4269A5 -78
| 2010.03.05 13:27:16 4: cul868: T1E3A436900 -78
| 2010.03.05 13:27:16 4: FHT OGL_sz measured-temp: 16.5 (Celsius)
| 2010.03.05 13:27:17 4: cul868: T1E3A446900 -78.5
| 2010.03.05 13:27:17 4: FHT OGL_sz battery: ok
| 2010.03.05 13:27:17 4: FHT OGL_sz lowtemp: ok
| 2010.03.05 13:27:17 4: FHT OGL_sz window: closed
| 2010.03.05 13:27:17 4: FHT OGL_sz windowsensor: ok
| 2010.03.05 13:27:17 4: FHT OGL_sz warnings: none
| 2010.03.05 13:33:31 3: Watchdog cul_WD3 triggered
| 2010.03.05 13:33:31 3: cul868 raw => C35 = 0D / 13
| 2010.03.05 13:33:36 3: Watchdog cul_WD2 triggered
| 2010.03.05 13:33:36 3: cul868 raw => 21  900
| 2010.03.05 13:46:01 3: Watchdog cul_WD1 triggered
| 2010.03.05 13:46:01 4: set cul868 verbose 21
| 2010.03.05 13:46:21 4: cul868: K01589138 -54.5
| 2010.03.05 13:46:21 4: CUL_WS S300TH Flur_unten: T: 15.8  H: 38.9
| 2010.03.05 13:46:21 4: cul868: T1E3A00A615 -78
| 2010.03.05 13:46:21 4: FHT OGL_sz actuator: 8%
| 2010.03.05 13:46:25 4: cul868: K11485146 -64.5
| 2010.03.05 13:46:25 4: CUL_WS S300TH Flur_oben: T: 14.8  H: 46.5

Ich lasse es demnächst mal ohne FHT-Unterstützung laufen.

MfG
MB

--
Michael Bussmann
Top 100 things you don't want the sysadmin to say:
   52. NO!  Not _that_ button!

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Ich lasse es demnächst mal ohne FHT-Unterstützung laufen.

Ich meine das kannst Du vergessen. Ich habe erwartet, dass der CC1101 nicht
mehr im Empfangsmodus ist weil der FHT Code nach dem Senden es vergessen hat
zurueckzudrehen. Aber laut:

> | 2010.03.05 13:33:31 3: cul868 raw => C35 = 0D / 13

ist der CC1101 in status MARCSTATE_RX, also normal. Ich sehe nun zwei neue
Moeglichkeiten:
- irgendein anderes CC1101 Parameter ist ueberschrieben/umgekippt. Das koennte
  man mit C99 rausholen (leider funktioniert das nicht so recht ueber fhem, nur
  direkt), und es zu analysieren dauert auch laenger, da manche der Parameter
  (Kalibrierungswerte) sich aendern duerfen.

- Der Hardware hat was, waere interessant mit einem zweiten Geraet zu testen.
  Evtl hilft auch neu flashen.

Wenn jemand weitere Ideen hat...

Gruss,
  Rudi

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Re,

On 2010-03-05 15:41:24 +0100, Rudolf Koenig wrote:

> - irgendein anderes CC1101 Parameter ist ueberschrieben/umgekippt. Das koennte
>   man mit C99 rausholen (leider funktioniert das nicht so recht ueber fhem, nur
>   direkt), und es zu analysieren dauert auch laenger, da manche der Parameter
>   (Kalibrierungswerte) sich aendern duerfen.
>
> - Der Hardware hat was, waere interessant mit einem zweiten Geraet zu testen.
>   Evtl hilft auch neu flashen.

Das wäre natürlich herb.  Nun ja, nächste Woche bin ich wieder vor Ort,
dann flashe ich mal neu.  Es ist immerhin beruhigend, daß es kein
allgemeines Problem ist.  Da der CUL gerade mal ein paar Tage alt ist,
sollte bei einem Defekt ein Tausch möglich sein.  Ist natürlich nur
peinlich, wenn der Fehler bei busware nicht auftritt...

Auf jeden Fall herzlichen Dank für Deine Hilfe!

MfG
MB

--
Michael Bussmann
Q: What's the definition of a minor second interval?
A: Two Soprano Sax players reading off the same part.

[Guest]

Originally posted by: <email address deleted>

Re,

[ Es ist zwar schon einige Zeit her, aber ich wollte dennoch eine kurze
Rückmeldung geben ]

On 2010-03-05 15:41:24 +0100, Rudolf Koenig wrote:

> ist der CC1101 in status MARCSTATE_RX, also normal. Ich sehe nun zwei neue
> Moeglichkeiten:
>
> - Der Hardware hat was, waere interessant mit einem zweiten Geraet zu testen.
>   Evtl hilft auch neu flashen.

Da ohnehin ein zweiter CUL für die 1. Etage geplant war, habe ich direkt
mal zugeschlagen.  Und siehe da: Bei dem neuen CUL tritt das Problem nicht
auf.  Weder als "Haupt"-Gerät, noch als RFR.  Umgekehrt bleibt der alte in
beiden Modi weiterhin hängen.

Damit dürfte Deine Vermutung, daß es die Hardware ist, zutreffen.

Frohe Ostern,
MB

--
Michael Bussmann

[Guest]

Originally posted by: <email address deleted>

Hi allerseits,

leider hab ich das hier jetzt erst gelesen. Ich habe die gleichen
Symptome (ohne FHT), ich nutze derzeit den CUL um 6 S300TH zu lesen
und um 4 FS20 Geräte zu steuern, die außerhalb der Reichweite meiner
FHZ sind. Auch ich habe mir damit beholfen (nach vielem rumprobieren),
daß ich über einen Timer alle 6h ein verbose 21 an den CUL schicke.
Ich hab damals geschaut, und da sonst keiner das Problem hatte, hab
ich das auf das Zusammenspiel von FritzBox und CUL geschoben. Immerhin
läuft es ja jetzt so, wie es soll.

Wollte das hier nur mitteilen, interessant ist ja, daß ich nicht der
einzige bin, das Problem aber wohl sehr selten auftritt...

Gruß, Waldemar

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[tostmann]

                                                 

Am 04.04.2010 um 18:21 schrieb Waldemar Porscha:

> Auch ich habe mir damit beholfen (nach vielem rumprobieren),
> daß ich über einen Timer alle 6h ein verbose 21 an den CUL schicke.

Also dann ist es wiederum unwahrscheinlich, dass ein Hardwaredefekt vorliegt ... aber wir finden das raus!

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

On 4 Apr., 18:53, Dirk Tostmann wrote:
> Also dann ist es wiederum unwahrscheinlich, dass ein Hardwaredefekt vorliegt ... aber wir finden das raus!

Kann ich irgendwie helfen? Bin auch an einer Lösung interessiert.
Allerdings kann ich erst ab dem 15.4., bin bis dahin noch im Urlaub...

Gruß, Waldemar

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

[ Repost, wg. falscher Absenderadresse ]

Re,

On 2010-04-04 18:53:59 +0200, Dirk Tostmann wrote:

> Also dann ist es wiederum unwahrscheinlich, dass ein Hardwaredefekt vorliegt ... aber wir finden das raus!

Zumindest mit der ersten Aussage dürftest Du Recht haben: Gestern nacht ist
bei mir erstmals auch der neue (bislang problemlos) CUL als RFR
ausgefallen.  An 2 Hardwaredefekte glaube ich nun auch wieder nicht
(vorausgesetzt, es ist tatsächlich der gleiche Fehler).

Was mir in den Logs aufgefallen ist, sind die eingebetteten LOVF Meldugen.
Zu dem Zeitpunkt hätten der RFR eigentlich gar keine "normalen" Nachrichten
aussenden dürfen.  Außer den relay-Meldungen, die aber m.W. nicht dem 1%
Limit unterliegen (oder liege ich da falsch?)

| 2010.04.05 18:43:11 4: cul_og: T1E3A4269B1EFLOVFK216211641
| 2010.04.05 18:44:33 4: cul_og: T1E3A00A600 -84
| 2010.04.05 18:44:42 4: cul_og: K171521750248F2 -75
| 2010.04.05 18:44:45 4: cul_og: LOVFLOVF
| 2010.04.05 18:44:45 2: cul_og: unknown message LOVFLOVF
| 2010.04.05 18:46:30 4: cul_og: T1E3A00A600 -83.5

Dann tauchen noch einige Meldungen auf, die ich keinem Gerät zuordnen kann:

| 2010.04.05 19:34:33 4: cul_og: F663A -50
| 2010.04.05 19:34:33 2: cul_og: unknown message F663A

sowie seltsam formatierte Meldungen:

| 2010.04.05 19:34:49 4: cul_og: T27396669FF2FT27396669FF2FT

Allerdings lief der RFR noch einige Zeit, um dann unvermittelt aufzuhören:

| 2010.04.05 22:41:22 2: cul_og: unknown message LOVFLOVF
| 2010.04.05 22:42:21 4: cul_og: T1E3A00A600 -84.5
| 2010.04.05 22:43:43 4: cul_og: K21626163 -62
| 2010.04.05 22:44:13 4: cul_og: LOVFLOVF
| 2010.04.05 22:44:13 2: cul_og: unknown message LOVFLOVF
| 2010.04.05 22:44:17 4: cul_og: T1E3A00A600 -84.5
| 2010.04.05 22:46:13 4: cul_og: T1E3A00A600 -85
| 2010.04.05 22:48:09 4: cul_og: T1E3A00A600 -84.5
| 2010.04.05 22:48:43 4: cul_og: K176530070048D2 -75
| 2010.04.05 22:49:36 4: cul_og: T344D446900E8K2161516318
| 2010.04.05 22:50:05 4: cul_og: T1E3A00A600 -85
| 2010.04.05 22:51:15 4: cul_og: K176440070048D2 -75

Das war dann auch das letzte Lebenszeichen.

Ok, aber dies hat wohl alles nichts mehr mit fhem zu tun.  Sollen wir die
Diskussion lieber auf cul-fans fortsetzen?

MfG
MB

--
Michael Bussmann
I hate them all, I hate them all, I hate myself for hating them; So drink
some more, I'll love them all; I'll drink even more, I'll hate them even
more than I did before.
   -- The Strokes, "The Other Side"

[Guest]

Originally posted by: <email address deleted>

Re,

On 2010-04-06 12:53:33 +0200, Michael Bussmann wrote:

> Zumindest mit der ersten Aussage dürftest Du Recht haben: Gestern nacht ist
> bei mir erstmals auch der neue (bislang problemlos) CUL als RFR
> ausgefallen.  An 2 Hardwaredefekte glaube ich nun auch wieder nicht

Ok, auch auf die Gefahr hin, für völlig bekloppt gehalten zu werden:
Kommando zurück.  Der o.g. Ausfall lag nicht am CUL, sondern am
Stromnetz (zu meiner Entlastung sei gesagt, daß ich zur Zeit nicht vor
Ort bin). Zumindest habe ich die genaue Zeit, wann die Sicherung
rausflog

MfG
MB

--
Michael Bussmann
Faellt der Bauer tot vom Traktor, steht in der Naehe ein Reaktor!

[rudolfkoenig]

                                                   

> Was mir in den Logs aufgefallen ist, sind die eingebetteten LOVF Meldugen.

LOVF: Limit Overflow: das CUL will (soll?) zuviel senden, z.Bsp wg. zu vielen
angeschlossenen FHT's. Siehe auch 2. Wert von "get CUL raw X", der die aktuell
verfuegbare Sendezeit in 10ms Einheiten anzeigt.


> | 2010.04.05 18:43:11 4: cul_og: T1E3A4269B1EFLOVFK216211641

Das CUL im RFR Modus sendet eine Meldung erst dann aus, wenn mind. fuer 16ms
Funkstille herrscht. Wenn das laenger nicht der Fall ist, dann laufen mehrere
Meldungen im Puffer auf, die (noch) nicht voneinander getrennt sind, ich
arbeite dran.


> | 2010.04.05 19:34:33 4: cul_og: F663A -50

Nachricht mit korrekter FS20 checksum. Da der Checksum aber nur 1 Byte ist,
kann sowas beim schlechten Empfang schon vorkommen.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

[ext23]

                                                 

Ich hatte eben genau dasselbe Problem das nichts mehr empfangen wurde. Erst
hat noch ein restart von FHEM geholfen, dann lief der S300TH zumindest aber
vom EM1000EM kam nichts mehr. get CUL1 raw X und get CUL1 raw C35 lieferten
die richtigen Werte und das mit dem verbose hat er nicht angenommen. Dann
habe ich die Firmware neu geflashed und jetzt geht wieder alles, sehr
komisch, ich hoffe das tritt nicht noch öfter auf.*

*Ich werd die Sache mal weiter beobachten. Im Moment betreibe ich nur ein
EM1000EM und diesen S300TH, beides im nachbar raum und auf dem Balkon aber
der Empfang ist nicht der renner, da fällt es erst nach 2 h auf wenn dann
wirklich garnichts empfangen wurde oO.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com