Benutze CUL V2 mit FHEM auf einer Buffalo Linkstation mit ca 10 FS20
und 8 FHT80 Geräten, die ca. 12 Termostaten bedienen.
An sich funktioniert alles, allerdings ist der Empfang in letzter Zeit
sporadisch unzuverlässig. Sender werden mal bestens Empfangen und am
nächsten Tag oder gar in der nächsten Stunde nicht mehr. Die Sender
sind es nicht: direkt (ohne FHEM) angesprochene Aktoren schalten und
das FS20 Analysetool von ELV zeigt, das Hauscode und Adresse okay sind
und auch immer abgestrahlt werden.
FHEM zeigt oft einfach keinerlei Empfang. Aktionen die ich über die
Weboberfläche auslöse funktionieren aber einwandfrei.
FHT Daten kommen ebenfalls unzuverlässig rein, die Raumtemperatur wird
z.b. mit unter über Tage nicht aktualisiert. Stellen der FHTs geht oft
aber nicht immer, ein Pairingproblem ist es nicht, ich habe auch keine
LOVF Meldungen (jedenfalls nicht wenn ich nicht zum testen massenhaft
FHT desired temp Änderungen lossende), zumal die auch den EMPFANG von
FS20 Sendern nicht behindern sollten (mir ist klar, das die
Kommunikation mit FHTs idR bidirektional ist.). Die Situation
verbessert sich auch nicht, wenn ich das CUL powercycle (wie man es
bei Sendezeitproblemen erwarten würde)
Die Komunikation mit dem RFR Modul geht nicht mehr zuverlässig, das
Teil reagiert nur noch sporadisch (ich hielt das bisher immer für eine
Problem des RFR CULs)
Ich habe auch eine paar FHTTK deren Statusänderung ebenfalls mitunter
über Stunden nicht erkannt wird, obwohl die gepairten FHTs in üblicher
Zeit auf WindowTemp umschalten.
Bei der Suche nach möglichen Ursachen habe ich den Loglevel
hochgedreht und nun kriege ich ellenlange Listings, die so aussehen:
2011.01.05 01:06:08 4: Connection accepted from 127.0.0.1:4174
2011.01.05 01:06:08 4: Connection accepted from 127.0.0.1:4175
2011.01.05 01:06:08 4: Connection closed for 127.0.0.1:4174
2011.01.05 01:06:09 4: Connection closed for 127.0.0.1:4175
2011.01.05 01:06:18 4: Connection accepted from 127.0.0.1:4176
2011.01.05 01:06:18 4: Connection closed for 127.0.0.1:4176
2011.01.05 01:06:18 4: Connection accepted from 127.0.0.1:4177
2011.01.05 01:06:18 4: Connection closed for 127.0.0.1:4177
2011.01.05 01:06:22 4: Connection accepted from 127.0.0.1:4178
2011.01.05 01:06:22 4: Connection closed for 127.0.0.1:4178
2011.01.05 01:06:23 4: Connection accepted from 127.0.0.1:4179
2011.01.05 01:06:23 4: Connection closed for 127.0.0.1:4179
2011.01.05 01:06:32 4: Connection accepted from 127.0.0.1:4180
2011.01.05 01:06:32 4: Connection closed for 127.0.0.1:4180
2011.01.05 01:06:32 4: Connection accepted from 127.0.0.1:4181
2011.01.05 01:06:32 4: Connection closed for 127.0.0.1:4181
Ist das eigentlich normal?
Wenn nein, was kann das sein?
Wenn ja, sonst jemand Vorschläge?
--
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.
> 2011.01.05 01:06:32 4: Connection closed for 127.0.0.1:4181
>
> Ist das eigentlich normal?
Ein externes Programm (frontend?) verbindet sich regelmaessig mit fhem. pgm2
macht das nicht, alle anderen frontends schon. Mit verbose 5 muesste man die
Details sehen.
> Wenn ja, sonst jemand Vorschläge?
Was passiert wenn man CUL und RFR tauscht?
Ist evtl neuerdings eine Funkstoerung vorhanden? Sowas kann man auch mit einem
CUL und ein Terminalprogramm (nicht fhem!) sehen, indem man auf dem CUL X08
einschaltet. Falls da ununterbrochen "rf" kommt, dann ist was komisch Fuer ein
FS20 signal sind ca 150 rf's normal, fuer eine FHTTK Meldung ca 50-100. Die
Quelle kann man evtl mit "X80" eingraenzen: beim ganz schwachen Signal wird ein
a ausgegeben, beim ganz starken ein p.
--
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.
> Ein externes Programm (frontend?) verbindet sich regelmaessig mit fhem. pgm2
> macht das nicht, alle anderen frontends schon. Mit verbose 5 muesste man die
> Details sehen.
Ja, verwende ein externes Frontend. Sehe ich mir mal mit 5 an (bisher
4)
> > Wenn ja, sonst jemand Vorschl ge?
>
> Was passiert wenn man CUL und RFR tauscht?
Noch nicht probiert, werd ich mal versuchen, die Idee ging mir auch
schon durch den Kopf.
> Ist evtl neuerdings eine Funkstoerung vorhanden? Sowas kann man auch mit einem
> CUL und ein Terminalprogramm (nicht fhem!) sehen, indem man auf dem CUL X08
> einschaltet. Falls da ununterbrochen "rf" kommt, dann ist was komisch Fuer ein
> FS20 signal sind ca 150 rf's normal, fuer eine FHTTK Meldung ca 50-100. Die
> Quelle kann man evtl mit "X80" eingraenzen: beim ganz schwachen Signal wird ein
> a ausgegeben, beim ganz starken ein p.
Das werde ich mal probieren, danke.
--
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.
Am Mittwoch 05 Januar 2011 schrieb Zrrronggg!:
> Benutze CUL V2 mit FHEM auf einer Buffalo Linkstation mit ca 10 FS20
> und 8 FHT80 Geräten, die ca. 12 Termostaten bedienen.
>
> An sich funktioniert alles, allerdings ist der Empfang in letzter Zeit
> sporadisch unzuverlässig. Sender werden mal bestens Empfangen und am
> nächsten Tag oder gar in der nächsten Stunde nicht mehr. Die Sender
> sind es nicht: direkt (ohne FHEM) angesprochene Aktoren schalten und
> das FS20 Analysetool von ELV zeigt, das Hauscode und Adresse okay sind
> und auch immer abgestrahlt werden.
> [...]
schau dir mal folgenden thread von mir an:
http://groups.google.com/group/fhem-users/t/aac1e6a8fa62ccfe
vielleicht hilft es dir ja weiter..
--
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.
Danke, den hatte ich schonmal gelesen, aber wieder vergessen... Hm...
Ich habe ansonsten erstmal RFR und "normalen" CUL getauscht, mit dem
Ergebniss, das der jetzige RFR überhaupt nichts mehr macht.
Die Situation ist aber nach wie vor uneinheitlich. Relativ gute
Ergebnisse bezüglich der Kommunikation mit den FHTs habe ich mit dem
Aufweiten der Bandbreite auf 464 khz gemacht.
Dennoch: sporadische EOB, ohne das sensationell viele FHT Kommandos
raus gingen, ich schliesse auf gestörte Kommunikation. Ebenso nach wie
vor sporadisch kein Empfang von FS20 Sendern.
Ich muss also weiter suchen. Werde mal die FS20 Steckdosen stromlos
machen nach deinem Bericht.
naja, erstmal Flanken ansehen.
On 7 Jan., 12:06, Martin Fischer wrote:
> Am Mittwoch 05 Januar 2011 schrieb Zrrronggg!:
>
> > Benutze CUL V2 mit FHEM auf einer Buffalo Linkstation mit ca 10 FS20
> > und 8 FHT80 Geräten, die ca. 12 Termostaten bedienen.
>
> > An sich funktioniert alles, allerdings ist der Empfang in letzter Zeit
> > sporadisch unzuverlässig. Sender werden mal bestens Empfangen und am
> > nächsten Tag oder gar in der nächsten Stunde nicht mehr. Die Sender
> > sind es nicht: direkt (ohne FHEM) angesprochene Aktoren schalten und
> > das FS20 Analysetool von ELV zeigt, das Hauscode und Adresse okay sind
> > und auch immer abgestrahlt werden.
> > [...]
>
> schau dir mal folgenden thread von mir an:http://groups.google.com/group/fhem-users/t/aac1e6a8fa62ccfe
>
> vielleicht hilft es dir ja weiter..
--
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.
Ich habe jetzt erstmal zur Beobachtung inform mitlaufen lassen.
Auffällig ist, das eigentlich dauernd allerlei Meldungen reinkommen,
im Schnitt alle 10 Sekunden irgendwas, sieht auch alles völlig normal
aus: FHT Meldungen (8 Stück hab ich), FHTTK Meldungen, IR Auslösungen
etc.
Plötzlich kommt NICHTS mehr. Wenn man dann mit der Weboberfläche
irgendwas macht, ist das zu sehen, (Renderer Meldungen und was immer
man ausgelöst hat) aber es gibt keinerlei Einkommendes, keine FHTTK
Meldungen, keine FHT Meldungen ....
Ich hab jetzt inform timer laufen um mal zu sehen, wann das so
passiert.
Bis dahin hab ich die Frage ob es dafür ausser massiven Funkproblemen
andere Erklärungen geben könnte wie: ich hab die doku nicht richtig
gelesen, in der irgendwo steht, das "inform on" nur 12 Stunden ausgibt
und sich dann abschaltet, oder inform gibt meldungen nicht mehr aus,
wenn xyz...
On 8 Jan., 14:17, "Zrrronggg!" wrote:
> Danke, den hatte ich schonmal gelesen, aber wieder vergessen... Hm...
>
> Ich habe ansonsten erstmal RFR und "normalen" CUL getauscht, mit dem
> Ergebniss, das der jetzige RFR überhaupt nichts mehr macht.
> Die Situation ist aber nach wie vor uneinheitlich. Relativ gute
> Ergebnisse bezüglich der Kommunikation mit den FHTs habe ich mit dem
> Aufweiten der Bandbreite auf 464 khz gemacht.
>
> Dennoch: sporadische EOB, ohne das sensationell viele FHT Kommandos
> raus gingen, ich schliesse auf gestörte Kommunikation. Ebenso nach wie
> vor sporadisch kein Empfang von FS20 Sendern.
>
> Ich muss also weiter suchen. Werde mal die FS20 Steckdosen stromlos
> machen nach deinem Bericht.
>
> naja, erstmal Flanken ansehen.
>
> On 7 Jan., 12:06, Martin Fischer wrote:
>
>
>
> > Am Mittwoch 05 Januar 2011 schrieb Zrrronggg!:
>
> > > Benutze CUL V2 mit FHEM auf einer Buffalo Linkstation mit ca 10 FS20
> > > und 8 FHT80 Geräten, die ca. 12 Termostaten bedienen.
>
> > > An sich funktioniert alles, allerdings ist der Empfang in letzter Zeit
> > > sporadisch unzuverlässig. Sender werden mal bestens Empfangen und am
> > > nächsten Tag oder gar in der nächsten Stunde nicht mehr. Die Sender
> > > sind es nicht: direkt (ohne FHEM) angesprochene Aktoren schalten und
> > > das FS20 Analysetool von ELV zeigt, das Hauscode und Adresse okay sind
> > > und auch immer abgestrahlt werden.
> > > [...]
>
> > schau dir mal folgenden thread von mir an:http://groups.google.com/group/fhem-users/t/aac1e6a8fa62ccfe
>
> > vielleicht hilft es dir ja weiter..
--
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.
> gelesen, in der irgendwo steht, das "inform on" nur 12 Stunden ausgibt
> und sich dann abschaltet, oder inform gibt meldungen nicht mehr aus,
> wenn xyz...
Inform hat keinen Ablauf-Timer, aber in der neuesten Version einen optionalen
Parameter zum filtern (regexp).
--
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.
> Inform hat keinen Ablauf-Timer,
danke
> aber in der neuesten Version einen optionalen
> Parameter zum filtern (regexp).
Sehr schön, denn die ganzen Renderer Meldungen sind bei meinem Problem
nicht dienlich.
--
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.
Sehr seltsamer Effekt: Am Funk liegt's vielleicht nicht.
Heute das selbe wie gester: irgendwann kommen keine externen Events
mehr in inform vor.
inform timer zeigt folgendes: Gestern gegen 18:00 Uhr FHEM restartet
und seit dem inform laufen.
Es kommen reichlich Meldungen rein, vor allem FHTTK und allerlei FHT
Zeug, das ich durch report2 anfordere (report1 interessiert mich nicht
so, daher ist mir auch egal, dass die Daten nach ein paar Tagen nicht
kommen. report2 255 setze ich aber je FHT 1x pro Woche), ausserdem IR
Melder soweit getriggert.
Und auch alle ausgehenden und internen Sachen (Renderer etc).
Dann um 2:01:08 in der Nacht die letzte FHT actuator Meldung und
dannach kommt NIX externes mehr.
Keine FHT Meldungen, keine FHTTK, keine IR, keine Fernbedienung ...
nix. Interner Kram und alles Augehende wird weiter angezeigt.
Das ging bis heute gegen 17:30 so. Ab da hat es sich nicht etwa gelöst
(was auf Funkverschmutzung durch irgendein Gerät bei Nachbarn
hindeuten würde) sondern ich habe FHEM rebootet (nicht etwa das CUL)
und SOFORT kommt wieder alles rein, schon die erste Meldung nach
"inform timer" ist ein kompletter FHT report2. Auch alles andere wie
FHTTTK kommt wieder reichlich rein.
Als nächstes überprüft, ob ich um 02:00 irgendwas seltsames mache...
ich habe 2 Zeitgesteuerte Kommandos (at) die in der Zeit was machen,
die sind aber beide unauffällig (Licht überall ausmachen, falls es
noch an ist, Heizung im Flur runter und Rolllade in der Küche zu und
Einfahrtstor zumachen, falls es noch auf ist.)
Okay, ich warte nun mal ab, ob das morgen
a) zur selben Zeit aufhört
oder
b) nach der selben Zeit seit dem letzten Reboot von FHEM.
Andere Ideen jemand?
--
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.
Originally posted by: <email address deleted>
On 15 Jan., 18:04, "Zrrronggg!" wrote:
> a) zur selben Zeit aufhört
> oder
> b) nach der selben Zeit seit dem letzten Reboot von FHEM.
>
> Andere Ideen jemand?
Setzt Du noch RFR ein? Oder ist das beim derzeitigen Setup
abgeschaltet?
Ich hatte einen ähnlichen Effekt als ich eine CUL V3.2 als Basis am
FHEM und eine CUL_RFR V2 eingesetzt habe. Ich hatte erst gedacht, dass
das Problem an einem neuen Kopp-Funkschalter liegt, das war aber ein
Fehlschluss.
Bei mir lief es auch jeweils nach dem Neustart von FHEM wieder für ein
bis zwei Tage. Ausstecken der Basis CUL war nicht notwendig.
Ich habe danach RFR abgeschaltet und keine Probleme mehr gehabt (auch
ohne irgendwelche CUL-Firmware Änderungen). Siehe auch
https://groups.google.com/group/cul-fans/browse_thread/thread/79f99a4e258a88a7
Nach dem Tipp von Michael Bussmann die V2 als Basis einzusetzen und
die V3.2 als RFR (siehe Thread https://groups.google.com/group/cul-fans/browse_thread/thread/a44305c605e22bea
CUL fans groups) habe ich dies jetzt seit mehr als einer Woche im
Einsatz. Dies läuft bisher anscheinend stabil.
Ich habe allerdings bei Wechsel RFR und Basis CUL von Firmware 1.39
auf 1.40 gewechselt und dabei wurden beide CULs komplett
zurückgesetzt. Mit 1.39 wollte es zuerst nicht laufen.
Keine Ahnung, ob der Firmware-Upgrade einen Einfluss auf das Verhalten
hat.
--
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.
Originally posted by: <email address deleted>
Ich vergass noch: Vor dem Tausch der Basis und RFR CUL hatte ich
Probleme, dass die Temperatur von FHT80B nicht mehr angezeigt wurde.
Seit ich die CUL V2 als Basis einsetze funktioniert das problemlos.
--
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.
Der RFR ist noch konfiguriert und auch eingesteckt. Kommunikation
findet aber nach allem was ich sehe keine statt. Ich werd ihn mal aus
der Konfig rausnehmen und auch auschalten.
Der neue Versuch ist übrigens bereits zuende: Die letzte Meldung kam
um 18:44 also nur etwas mehr als eine Stunde nach restart.
--
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.
Neustrat von FHEM: Sofort neue FHT Meldugnen: Im Klo ist's kalt.
--
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.
> Andere Ideen jemand?
WENN ein fhem Neustart IMMER hilft, dann liegt es entweder an der USB
Kommunikation, oder der Funkchip (CC1101) will nicht mehr empfangen, da beides
bei einem fhem Neustart initialisiert wird. Falls es nochmal passiert, bitte
im fhem "X21" durchfuehren, und schauen, ob es hilft.
--
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.
Das Spiel inzwischen noch 2x gehabt.
Ja, Neustart hilft (bisher) IMMER, ich habe eben bemerkt, dass auch
Neuladen der Config hilft. (ich nehme an, dabei wird auch neu
initialisiert.)
Wenn der Zustand erreicht ist, SENDET das CUL weiterhin, per
Weboberfläche oder durch "at" durchgeführte FS20 Kommandos werden
abgesetzt und schalten auch. FHT einstellen geht aber nicht: Wäre ja
aufgrund der gestörten bidirektionalen Kommunikation erklärlich.
> Falls es nochmal passiert, bitte
> im fhem "X21" durchfuehren, und schauen, ob es hilft.
Mach ich.
--
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.
Wieder passiert, X21 hat keinen Effekt, diesmal auch nicht rereadcfg.
Restart FHEM klappt sofort.
Ich hatte auch 1-2 Verdachtsmomente, was das Problem auslösen könnte,
die sich aber alle bei Versuchen nicht reproduzieren liessen. Im
Moment ist weder eine zeitliche Komponente noch eine bestimmtes
Kommando im Zusammenhang mit dem "Empfangsende" sicher erkennbar.
On 16 Jan., 13:35, "Zrrronggg!" wrote:
> Das Spiel inzwischen noch 2x gehabt.
>
> Ja, Neustart hilft (bisher) IMMER, ich habe eben bemerkt, dass auch
> Neuladen der Config hilft. (ich nehme an, dabei wird auch neu
> initialisiert.)
>
> Wenn der Zustand erreicht ist, SENDET das CUL weiterhin, per
> Weboberfläche oder durch "at" durchgeführte FS20 Kommandos werden
> abgesetzt und schalten auch. FHT einstellen geht aber nicht: Wäre ja
> aufgrund der gestörten bidirektionalen Kommunikation erklärlich.
>
> > Falls es nochmal passiert, bitte
> > im fhem "X21" durchfuehren, und schauen, ob es hilft.
>
> Mach ich.
--
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.
Läuft der CUL mit default-Hex-File? Nicht dass dem der Speicher aufgrund zu vieler Features (Buffer) ausgeht ...
Am 16.01.2011 um 18:19 schrieb Zrrronggg!:
> Ich hatte auch 1-2 Verdachtsmomente, was das Problem auslösen könnte,
> die sich aber alle bei Versuchen nicht reproduzieren liessen. Im
> Moment ist weder eine zeitliche Komponente noch eine bestimmtes
> Kommando im Zusammenhang mit dem "Empfangsende" sicher erkennbar.
--
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.
> Läuft der CUL mit default-Hex-File?
Äh ... was?
Ich kann am CUL nix verändern, da ich das Thema "Rumfummeln an CUL
Firmware mit Mac OS X" noch nicht ganz zum Abschluss gebracht habe.
VERSION V 1.38 CUL868#0d;#0a;
Sagt es.
Oder was meinst du?
--
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.
Ohne das es 100% reproduzierbar wäre habe ich den Eindruck, dass die
"Empfangslaehmung" am haeufigsten nach dem Wechseln der Frequenz des
CUL auftritt.
Was ich mache ist folgendes: Bei Aktoren im Aussenbereich hatte ich
mal den Eindruck, das die durch überlagernde Funksignale anderer
868.35 Mhz Geräte - z.b. von Nachbarn - gestört wurden. Ich setze an
solche Aktoren die Schaltsingalee 2x (also tatsaechlich sogar 6x) ab.
Dazu wechsele ich dir Frequenz des CUL zuerst auf 868,8, (was die FS20
Aktoren noch gut empfangen), sende, wechsele auf 868,35 und sende
nochmal.
Ob es das tatsächlich bringt habe ich nicht streng untersucht, vom
Gefühl her hat es die Zuverlässigkeit erhöht, kann aber auch
Selbsttäuschung sein. Ich weiss von mindestes einem FHEM Nutzer, dass
er das selbe macht mit seinem CUL, um Funkkopfhörer zu "umgehen".
Solche Kommandos kommen am Tag ca. 2-5x vor, im Rest der Zeit steht
die Frequenz natürlich auf 868,35 Mhz.
Ich sehe nun, das in der überwiegenden Anzahl der Fälle - aber nicht
in allen - der Frequenzwechsel das letzte war, bevor der Empfang
eingestellt wurde.
Daraufhin habe ich versucht, das zu provozieren, das hat aber NICHT zu
einem eindeutigen Ergebnis geführt, d.h. meist lief es nach dem
Frequenzwechsel munter weiter.
Da muss noch ein anderer Faktor mit im Spiel sein.
Hm. Muss mal testen, auf welcher Frequenz das CUL sendet, wenn das
passiert, vielleicht wird der Wechsel zurück zu 868,35 nicht mehr
durchgeführt. Obwohl ich bei 464 khz Bandbreite auch bei 868,8 Mhz
noch FHT Empfang erwarten würde...
On 16 Jan., 19:54, "Zrrronggg!" wrote:
> > Läuft der CUL mit default-Hex-File?
>
> Äh ... was?
>
> Ich kann am CUL nix verändern, da ich das Thema "Rumfummeln an CUL
> Firmware mit Mac OS X" noch nicht ganz zum Abschluss gebracht habe.
>
> VERSION V 1.38 CUL868#0d;#0a;
>
> Sagt es.
> Oder was meinst du?
--
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.
Okay, wars auch nicht. Im Moment läuft es seit gestern durch (ist
wohl die längste Periode seit dem ich das beobachte)
Zuerst dachte ich: Ha! es liegt am Frequenzwechsel! Ich hatte die
nämlich ausgebaut... dachte ich.
Nur habe ich einen übersehen und letzte Nacht wurde die Frequenz
gewechselt, trotzdem Empfängt das CUL noch.
Langsam bin ich mit meinem Latein am Ende. Wenn das so weitergeht
bastel ich was, was FHEM alle 8 Stunden rebootet und gut ist.
Nur was es ist würde ich ja doch gerne wissen.
--
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.
Hallo,
Am 18.01.2011 15:05, schrieb Zrrronggg!:
> Langsam bin ich mit meinem Latein am Ende. Wenn das so weitergeht
> bastel ich was, was FHEM alle 8 Stunden rebootet und gut ist.
> Nur was es ist würde ich ja doch gerne wissen.
ich würde Dirks Vorschlag nachgehen und den CUL-Puffer (Inhalt und freie
Bytes) alle 30 Minuten oder so mitprotokollieren, um einen Zusammenhang
zu bestätigen oder zu widerlegen.
Grüße,
Boris
--
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.
Hm. okay.
Vorschläge wie ich das am geschicktesten mache?
On 18 Jan., 18:24, Boris Neubert wrote:
> Hallo,
>
> Am 18.01.2011 15:05, schrieb Zrrronggg!:
>
> > Langsam bin ich mit meinem Latein am Ende. Wenn das so weitergeht
> > bastel ich was, was FHEM alle 8 Stunden rebootet und gut ist.
> > Nur was es ist würde ich ja doch gerne wissen.
>
> ich würde Dirks Vorschlag nachgehen und den CUL-Puffer (Inhalt und freie
> Bytes) alle 30 Minuten oder so mitprotokollieren, um einen Zusammenhang
> zu bestätigen oder zu widerlegen.
>
> Grüße,
> Boris
--
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.
Moment mal, würde X21 nicht den CUL-Puffer loeschen?
On 18 Jan., 19:42, "Zrrronggg!" wrote:
> Hm. okay.
>
> Vorschläge wie ich das am geschicktesten mache?
>
> On 18 Jan., 18:24, Boris Neubert wrote:
>
>
>
> > Hallo,
>
> > Am 18.01.2011 15:05, schrieb Zrrronggg!:
>
> > > Langsam bin ich mit meinem Latein am Ende. Wenn das so weitergeht
> > > bastel ich was, was FHEM alle 8 Stunden rebootet und gut ist.
> > > Nur was es ist würde ich ja doch gerne wissen.
>
> > ich würde Dirks Vorschlag nachgehen und den CUL-Puffer (Inhalt und freie
> > Bytes) alle 30 Minuten oder so mitprotokollieren, um einen Zusammenhang
> > zu bestätigen oder zu widerlegen.
>
> > Grüße,
> > Boris
--
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.
Sorry, erst lesen, dann fragen (ich meine mich)
Kann zu meiner Entschuldigung nur sagen, dass die Information letzlich
recht verstreut ist.
Wenn ich hier durch bin, verbringe ich nochmal ne Stunde im Wiki mit
einem Artikel a la: "die wichtigsten Abfragen und debug Commandos und
die Bedeutung ihres Outputs"
(Aktuell suche ich gerade wie ich die freien Bytes abfrage. Werd's
aber finden.)
On 18 Jan., 20:11, "Zrrronggg!" wrote:
> Moment mal, würde X21 nicht den CUL-Puffer loeschen?
>
> On 18 Jan., 19:42, "Zrrronggg!" wrote:
>
>
>
> > Hm. okay.
>
> > Vorschläge wie ich das am geschicktesten mache?
>
> > On 18 Jan., 18:24, Boris Neubert wrote:
>
> > > Hallo,
>
> > > Am 18.01.2011 15:05, schrieb Zrrronggg!:
>
> > > > Langsam bin ich mit meinem Latein am Ende. Wenn das so weitergeht
> > > > bastel ich was, was FHEM alle 8 Stunden rebootet und gut ist.
> > > > Nur was es ist würde ich ja doch gerne wissen.
>
> > > ich würde Dirks Vorschlag nachgehen und den CUL-Puffer (Inhalt und freie
> > > Bytes) alle 30 Minuten oder so mitprotokollieren, um einen Zusammenhang
> > > zu bestätigen oder zu widerlegen.
>
> > > Grüße,
> > > Boris
--
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.
Am 18.01.2011 21:13, schrieb Zrrronggg!:
> Sorry, erst lesen, dann fragen (ich meine mich)
culfw README, Abschnitt culfw<->PC Protocol (over USB or TCP/IP)
Special control commands for the CUL:
- T02
Return the FHT80b buffer. FHT80b commands are queued in the internal
buffer, which has place for 14 to 31 messages.
A command is removed from the buffer after CUL has received the
acknowledgement from FHT80b.
- T03
Return the size of the remaining FHT80b buffer (bytes, hex).
get myCUL raw T02
get myCUL raw T03
HTH,
Boris
--
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.
Jo hab's, danke.
Wie gross ist der Buffer bei CUL V2 eigentlich bei normaler 1.38
eigentlich?
On 18 Jan., 21:30, Boris Neubert wrote:
> Am 18.01.2011 21:13, schrieb Zrrronggg!:
>
> > Sorry, erst lesen, dann fragen (ich meine mich)
>
> culfw README, Abschnitt culfw<->PC Protocol (over USB or TCP/IP)
>
> Special control commands for the CUL:
> - T02
> Return the FHT80b buffer. FHT80b commands are queued in the internal
> buffer, which has place for 14 to 31 messages.
> A command is removed from the buffer after CUL has received the
> acknowledgement from FHT80b.
> - T03
> Return the size of the remaining FHT80b buffer (bytes, hex).
>
> get myCUL raw T02
> get myCUL raw T03
>
> HTH,
> Boris
--
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.
Wie das eben so ist: Jede Antwort wirft neue Fragen auf.
Nach dem Boris meint ich sollte mir mal den Buffer ansehen hab ich das
gemacht.
Da habe ich jetzt folgenden seltsamen Effekt:
Erstmal Buffer leer gemacht (B00)
Dann eine Temperaturänderung abgesetzt.
Die steht dann im Buffer:
fhem> get CUL1 raw T02
CUL1 raw => 060E:4127 (Heizung Wohnzimmer oben 19,5 Grad)
Bischen warten, FHT80b im Wohnzimmer oben springt auf 19,5 Grad, alles
chic.
Nur im Buffer steht leider immer noch:
fhem> get CUL1 raw T02
CUL1 raw => 060E:4127
Okay, der Wert im Buffer wird erste gelöscht, wenn das FHT80b ein ACK
sendet.
Man könnte also vermuten, schlechte Funkverbindung, das ACK kommt
nicht an.
Das gleichzeitg mitlaufende inform zeigt aber, das vom fraglichen
FHT80b alles mögliche sauber rein kommt:
2011-01-18 23:34:23 FHT hzg_wz_o actuator: 27%
2011-01-18 23:34:25 FHT hzg_wz_o desired-temp: 19.5
...
2011-01-18 23:38:20 FHT hzg_wz_o actuator: 27%
2011-01-18 23:38:21 FHT hzg_wz_o desired-temp: 19.5
15 Minuten später:
die Temperaturänderung auf 19,5 Grad steht immer noch drin. Dahinter
stauen sich sonstige Temperaturänderungen, die nicht ausgeführt
werden. Inform zeigt, dass der Empfang an sich okay ist, es kommen
allerlei Meldungen auch von weit entfernten FHTs rein. Das fragliche
FHT80b ist 4 Meter vom CUL entfernt.
Irgendwann nach ca. 30 Minuten ist es dann endlich raus...
Aged der Buffer eigentlich irgendwie?
Seufz.
On 18 Jan., 21:42, "Zrrronggg!" wrote:
> Jo hab's, danke.
>
> Wie gross ist der Buffer bei CUL V2 eigentlich bei normaler 1.38
> eigentlich?
>
> On 18 Jan., 21:30, Boris Neubert wrote:
>
>
>
> > Am 18.01.2011 21:13, schrieb Zrrronggg!:
>
> > > Sorry, erst lesen, dann fragen (ich meine mich)
>
> > culfw README, Abschnitt culfw<->PC Protocol (over USB or TCP/IP)
>
> > Special control commands for the CUL:
> > - T02
> > Return the FHT80b buffer. FHT80b commands are queued in the internal
> > buffer, which has place for 14 to 31 messages.
> > A command is removed from the buffer after CUL has received the
> > acknowledgement from FHT80b.
> > - T03
> > Return the size of the remaining FHT80b buffer (bytes, hex).
>
> > get myCUL raw T02
> > get myCUL raw T03
>
> > HTH,
> > Boris
--
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.
Hallo,
Am 18.01.2011 23:50, schrieb Zrrronggg!:
> Nur im Buffer steht leider immer noch:
> fhem> get CUL1 raw T02
> CUL1 raw => 060E:4127
>
>
benutzt Du den fhtsoftbuffer? Bitte ausschalten, der funktioniert noch
nicht richtig.
Gruesse,
Boris
--
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.
> Erstmal Buffer leer gemacht (B00)
B00 (== reboot) geht auch, nach T01 ist aber der Puffer auch leer.
> Nur im Buffer steht leider immer noch:
> fhem> get CUL1 raw T02
> CUL1 raw => 060E:4127
Ein FHT-Befehl wird erst dann aus dem culfw Puffer entfernt, wenn das FHT die
letzte Bestaetigung abgeschickt hat (genannt "end-xmit", siehe auch
http://fhemwiki.de/index.php/Maximal_nutzbare_Ger%C3%A4te). Meine FHT's setzen
die Temperatur nicht um, falls die Uebertragung vorher abbricht.
--
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.
Softbuffer ist aus (hatte ich nie an und die Diskussion hier
mitgelesen. Ich hatte es trotzdem nochmal gecheckt, weil mich das
Phänomen sofort an die softbuffer Diskussion erinnerte)
Das erstaunliche war, DAS die Änderung umgesetzt wurde! In jedem Fall
war der buffer heute morgen knack voll, nur noch 4 Bbyte frei, knapp
an EOB vorbeigeschrammelt. Minütliches abfragen pber nacht zeigte,
das über stunden nichts passiert ist. In der ganzen Zeit waren aber
munter reichlich FHT und FHTTK Meldungen eingetroffen, eine massive
funktsörung liegt also eher nicht vor.
Irgendwas ist faul aber ich werde jetzt erstmal bischen testen um ein
klareres Bild zu bekommen, z.b. kann ich das reproduzieren, wenn ja
wie sieht die Kommunikation dann genau aus, kann ich vielleicht
einzelne defekte FHTs isolieren etc.
On 19 Jan., 08:56, Rudolf Koenig wrote:
> > Erstmal Buffer leer gemacht (B00)
>
> B00 (== reboot) geht auch, nach T01 ist aber der Puffer auch leer.
>
> > Nur im Buffer steht leider immer noch:
> > fhem> get CUL1 raw T02
> > CUL1 raw => 060E:4127
>
> Ein FHT-Befehl wird erst dann aus dem culfw Puffer entfernt, wenn das FHT die
> letzte Bestaetigung abgeschickt hat (genannt "end-xmit", siehe auchhttp://fhemwiki.de/index.php/Maximal_nutzbare_Ger%C3%A4te). Meine FHT's setzen
> die Temperatur nicht um, falls die Uebertragung vorher abbricht.
--
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.
Zwischenbericht:
Heute ausführlich Stundenlang zu diversen Tageszeiten diverse
Testscenarien durchgejubelt und den FHT Buffer gequält bis LOVF.
Und was ist? Alles funktioniert BESTENS. Das schlimmste war noch, das
eine FHT Tempänderung mal 6 Minuten gedauert hat.
Mist.
On 19 Jan., 12:49, "Zrrronggg!" wrote:
> Softbuffer ist aus (hatte ich nie an und die Diskussion hier
> mitgelesen. Ich hatte es trotzdem nochmal gecheckt, weil mich das
> Phänomen sofort an die softbuffer Diskussion erinnerte)
>
> Das erstaunliche war, DAS die Änderung umgesetzt wurde! In jedem Fall
> war der buffer heute morgen knack voll, nur noch 4 Bbyte frei, knapp
> an EOB vorbeigeschrammelt. Minütliches abfragen pber nacht zeigte,
> das über stunden nichts passiert ist. In der ganzen Zeit waren aber
> munter reichlich FHT und FHTTK Meldungen eingetroffen, eine massive
> funktsörung liegt also eher nicht vor.
>
> Irgendwas ist faul aber ich werde jetzt erstmal bischen testen um ein
> klareres Bild zu bekommen, z.b. kann ich das reproduzieren, wenn ja
> wie sieht die Kommunikation dann genau aus, kann ich vielleicht
> einzelne defekte FHTs isolieren etc.
>
> On 19 Jan., 08:56, Rudolf Koenig wrote:
>
>
>
> > > Erstmal Buffer leer gemacht (B00)
>
> > B00 (== reboot) geht auch, nach T01 ist aber der Puffer auch leer.
>
> > > Nur im Buffer steht leider immer noch:
> > > fhem> get CUL1 raw T02
> > > CUL1 raw => 060E:4127
>
> > Ein FHT-Befehl wird erst dann aus dem culfw Puffer entfernt, wenn das FHT die
> > letzte Bestaetigung abgeschickt hat (genannt "end-xmit", siehe auchhttp://fhemwiki.de/index.php/Maximal_nutzbare_Ger%C3%A4te). Meine FHT's setzen
> > die Temperatur nicht um, falls die Uebertragung vorher abbricht.
--
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.
So,
umfangreiche Tests gemacht.
- das FHT Problem habe ich erstmal ausgeblendet, es ist bisher auch
nicht mehr aufgetaucht, der Puffer leert sich idR. normal.
- ich habe das Verhalten systematisch und mit Logauswertung
untersucht, 1-2 Dinge mögen früheren unsystematischen Beobachtungen
wiedersprechen, da misstraue ich aber eher den alten Beobachtungen.
- das CUL stellt den Empfang sporadisch ein, SENDET in diesen
Situatione aber weiter.
- das Einstellen des Empfang korreliert nicht gut mit der Zeit: alles
zwischen 2 Stunden und über 30 Stunden ist drin. Der Ausfall
korreliert auch nicht mit der Tageszeit.
- wenn das Empfangsproblem akut ist, hilft: FHEM resetten, set raw
B00, set raw X21 (hier schienen frühere eher unsystemtische Versuche
was anderes zu zeigen) Neu abspeichern der Config über die
Weboberfläche hilft auch, jedoch nicht FHEM>rereadcfg. Macht die
Weboberfläche beim Speicher der Config. was anderes als reread?
- Das Phänomen korreliert NICHT mit dem Buffer Füllungsgrad. In der
Regel ist der Buffer sogar leer, manchmal enthält er ein paar
Kommandos (die natürlich ohne Empfang nicht mehr abgearbeitet werden).
Voller Buffer scheint die Wahrscheinlichkeit des Eintritts nicht zu
erhöhen. Auch durch stundelanges Buffer-zumüllen lässt sich der
Zustand nicht erzwingen. Leeren des Buffers bendet die Empfangsstörung
nicht.
- sehr gut korreliert aber der Fequenzwechsel. Über 90% aller
Empfangsstörungen traten unmittelbar nach einem Frequenzwechsel auf.
Gleichzeitig führt aber nicht JEDER Frequenzwechsel zu der Störung,
insbesondere waren meine Versuche durch wildes Wechseln der Frequenz
per mehrmaligem set CUL1 freq xy den Ausfall zu provozieren erfolglos.
- das Auslösen des folgendesn Scripts erzeugt den Zustand aber so gut
wie immer:
define act_on_Einfahrt_TAST notify Einfahrt_TAST { if ("%" ne "off")
{ fhem("set CUL1 freq 868.80 ;; set tor_sw off ;; set tor_sw on-for-
timer 1 ;; set CUL1 freq 868.35 ;; set tor_sw on-for-timer 1 ;; set
Einfahrt_TAST off ;; set Einfahrt_ZU off ;; set Einfahrt_AUF off") } }
Steht in dem Script irgendwas drin, was besonders bescheuert ist oder
dumm gedacht war von mir?
Nächste Schritte: CULs tauschen um zu sehen, ob's nur an diesem CUL
liegt.
Vermutlich ist das ganze Thema in CUL Fans besser aufgehoben, ich
weiss aber nicht. ob man das dahin verschieben kann.
On 19 Jan., 21:44, "Zrrronggg!" wrote:
> Zwischenbericht:
>
> Heute ausführlich Stundenlang zu diversen Tageszeiten diverse
> Testscenarien durchgejubelt und den FHT Buffer gequält bis LOVF.
>
> Und was ist? Alles funktioniert BESTENS. Das schlimmste war noch, das
> eine FHT Tempänderung mal 6 Minuten gedauert hat.
>
> Mist.
>
> On 19 Jan., 12:49, "Zrrronggg!" wrote:
>
>
>
> > Softbuffer ist aus (hatte ich nie an und die Diskussion hier
> > mitgelesen. Ich hatte es trotzdem nochmal gecheckt, weil mich das
> > Phänomen sofort an die softbuffer Diskussion erinnerte)
>
> > Das erstaunliche war, DAS die Änderung umgesetzt wurde! In jedem Fall
> > war der buffer heute morgen knack voll, nur noch 4 Bbyte frei, knapp
> > an EOB vorbeigeschrammelt. Minütliches abfragen pber nacht zeigte,
> > das über stunden nichts passiert ist. In der ganzen Zeit waren aber
> > munter reichlich FHT und FHTTK Meldungen eingetroffen, eine massive
> > funktsörung liegt also eher nicht vor.
>
> > Irgendwas ist faul aber ich werde jetzt erstmal bischen testen um ein
> > klareres Bild zu bekommen, z.b. kann ich das reproduzieren, wenn ja
> > wie sieht die Kommunikation dann genau aus, kann ich vielleicht
> > einzelne defekte FHTs isolieren etc.
>
> > On 19 Jan., 08:56, Rudolf Koenig wrote:
>
> > > > Erstmal Buffer leer gemacht (B00)
>
> > > B00 (== reboot) geht auch, nach T01 ist aber der Puffer auch leer.
>
> > > > Nur im Buffer steht leider immer noch:
> > > > fhem> get CUL1 raw T02
> > > > CUL1 raw => 060E:4127
>
> > > Ein FHT-Befehl wird erst dann aus dem culfw Puffer entfernt, wenn das FHT die
> > > letzte Bestaetigung abgeschickt hat (genannt "end-xmit", siehe auchhttp://fhemwiki.de/index.php/Maximal_nutzbare_Ger%C3%A4te). Meine FHT's setzen
> > > die Temperatur nicht um, falls die Uebertragung vorher abbricht.
--
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.
> Steht in dem Script irgendwas drin, was besonders bescheuert ist oder
> dumm gedacht war von mir?
Eigentlich war die Frequenzumstellung nicht fuer sowas gedacht. Probleme:
- beim Wechsel werden die Werte in eeprom gespeichert (mit 3
Schreiboperationen). Das eeprom soll "nur" 100.000 Schreiboperationen
aushalten.
- Es kann sein, dass eine Umstellung nicht fehlerfrei durchlaeuft, evtl aber
nur dann wenn man direkt danach was sendet. Um das zu sehen, koennte man die
CC1101 register dumpen (C99), und die mit einem "normalen" Fall vergleichen.
Achtung: manche der hinteren Register sind nicht konstant, da sie die
Ergebnisse der CC1101 internen Feintuning sind nach dem Frequenzwechsel. Da
muss man das beruehmte PDF ausgraben und Einzelwerte vergleichen.
Insgesamt moechte ich dieses Modus-Operandi nicht unterstuetzen, lieber
einen zweiten CUL besorgen oder die Bandbreite ausreichend erhoehen.
--
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.
Okay. Das das ins eeprom geschrieben wird wusste ich nicht, ich ging
davon aus, dass man das noch extra veranlassen müsse.
Dann werd ich das mal ausbauen und anders lösen.
Obwohl rein aus Neugierde werd ich mir vielleicht doch die Register
ansehen.
On 22 Jan., 08:10, Rudolf Koenig wrote:
> > Steht in dem Script irgendwas drin, was besonders bescheuert ist oder
> > dumm gedacht war von mir?
>
> Eigentlich war die Frequenzumstellung nicht fuer sowas gedacht. Probleme:
>
> - beim Wechsel werden die Werte in eeprom gespeichert (mit 3
> Schreiboperationen). Das eeprom soll "nur" 100.000 Schreiboperationen
> aushalten.
>
> - Es kann sein, dass eine Umstellung nicht fehlerfrei durchlaeuft, evtl aber
> nur dann wenn man direkt danach was sendet. Um das zu sehen, koennte man die
> CC1101 register dumpen (C99), und die mit einem "normalen" Fall vergleichen.
> Achtung: manche der hinteren Register sind nicht konstant, da sie die
> Ergebnisse der CC1101 internen Feintuning sind nach dem Frequenzwechsel. Da
> muss man das beruehmte PDF ausgraben und Einzelwerte vergleichen.
>
> Insgesamt moechte ich dieses Modus-Operandi nicht unterstuetzen, lieber
> einen zweiten CUL besorgen oder die Bandbreite ausreichend erhoehen.
--
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.