CUL schaltet ploetzlich ab
Michael Bussmann
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
Rudolf Koenig
> 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.
Michael Bussmann
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 <b...@mb-net.net>
BOFH excuse #271:
The kernel license has expired
Michael Bussmann
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 <b...@mb-net.net>
Top 100 things you don't want the sysadmin to say:
52. NO! Not _that_ button!
Rudolf Koenig
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
Michael Bussmann
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 <b...@mb-net.net>
Q: What's the definition of a minor second interval?
A: Two Soprano Sax players reading off the same part.
Michael Bussmann
[ 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,
Waldemar Porscha
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
Dirk 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!
Waldemar Porscha
On 4 Apr., 18:53, Dirk Tostmann <tostm...@gmail.com> 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
Michael Bussmann
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 <b...@mb-net.net>
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"
Michael Bussmann
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 <b...@mb-net.net>
Faellt der Bauer tot vom Traktor, steht in der Naehe ein Reaktor!
Rudolf Koenig
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.
Michael Bussmann
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!
Um mal hier den aktuellen Stand durchzugeben: Mit dem neuen CUL (Besten
Dank für den tollen Service) läuft nun alles tadellos. Mit der 1.37 werden
beim RFR nun auch bis zu 3 Telegramme in einer RFR-Meldung zusammengefasst.
Kleiner Schönheitsfehler: Wenn der Buffer voll ist, wird als letztes
Zeichen der Typ übermittelt, was bei fhem zu einer Logmeldung führt. Das
fällt im Normalbetrieb aber gar nicht auf.
| 2010.05.01 02:16:13 4: cul868: 0102UT584F4269C4F7;T584F436900F7;T584F446900F6;T
| [... normale Behandlung der ersten 3 Telegramme]
| 2010.05.01 02:16:13 4: cul_og: T
| 2010.05.01 02:16:13 3: cul_og: Unknown code T, help me!
Mit freundlichen Grüßen,
Michael Bussmann
--
Michael Bussmann <b...@mb-net.net>
BOFH excuse #73:
Daemons did it
Ext23
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.