Hello zusammen,
immer wieder kommt es bei meinem CUN zu Problemen, ähnlich derer,
welche scheinbar auch mit den CUL auftreten.
### cut begin ###
2010.01.24 07:48:24 2: FS20 ds_00_bn1 on
2010.01.24 07:48:24 2: FS20 set ro_00 on-for-timer 20
2010.01.24 07:48:24 2: FS20 set ro_02 on-for-timer 20
2010.01.24 07:48:24 2: FS20 set ro_01 on-for-timer 30
2010.01.24 15:36:15 1: 10.0.0.240:2323 disconnected, waiting to
reappear
2010.01.24 15:36:20 1: CUL 10.0.0.240:2323 reappeared (CUL)
2010.01.24 16:33:54 2: FS20 ds_00_bn1 off
2010.01.24 17:06:35 2: FS20 ds_00_bn0 off
2010.01.24 17:06:35 2: FS20 set ro_00 off-for-timer 18
2010.01.24 17:06:35 2: FS20 set ro_02 off-for-timer 18
2010.01.24 17:06:35 2: FS20 set ro_01 off-for-timer 30
2010.01.24 17:21:36 1: 10.0.0.240:2323 disconnected, waiting to
reappear
2010.01.24 17:21:41 1: CUL 10.0.0.240:2323 reappeared (CUL)
2010.01.24 17:52:30 2: FS20 fb04_00_bn1 toggle
.
.
.
2010.01.24 18:08:30 2: FS20 set di_00 on
2010.01.24 18:08:31 1: 10.0.0.240:2323 disconnected, waiting to
reappear
2010.01.24 18:08:36 1: CUL 10.0.0.240:2323 reappeared (CUL)
2010.01.24 18:08:54 2: FS20 set di_00 off
.
.
.
2010.01.25 07:42:25 2: FS20 set ro_01 on-for-timer 30
2010.01.25 09:00:34 1: 10.0.0.240:2323 disconnected, waiting to
reappear
2010.01.25 09:00:39 1: CUL 10.0.0.240:2323 reappeared (CUL)
### cut end ###
Meine Frage an Rudi wäre nun, ob man vielleicht ähnlich wie für das
FHZ ein Keep-Alive (damals per 'set FHZ time' gelöst) senden könnte.
Natürlich könnte man jetzt minütig einen Befehl ausführen
(Statusabfrage), aber ich denke doch, dass ein richtiges Keep-Alive im
Code besser wäre um solche Probleme aus der Welt zu schaffen.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Gerhard Pfeffer wrote:
> Hello zusammen,
>
> immer wieder kommt es bei meinem CUN zu Problemen, ähnlich derer,
> welche scheinbar auch mit den CUL auftreten.
[...]
>
> Meine Frage an Rudi wäre nun, ob man vielleicht ähnlich wie für das
> FHZ ein Keep-Alive (damals per 'set FHZ time' gelöst) senden könnte.
> Natürlich könnte man jetzt minütig einen Befehl ausführen
> (Statusabfrage), aber ich denke doch, dass ein richtiges Keep-Alive im
> Code besser wäre um solche Probleme aus der Welt zu schaffen.
Ich würde vor der Umgehung des Problems schon gerne erst einmal dem
eigentlichen Problem auf den Grund gehen. Ich habe jedenfalls keine
CUN-Disconnects, allerdings habe ich auch noch einen at-Job laufen
(aus der Anfangszeit von CUN, als der sich immer weghängte):
define at_get_CUN_version at +*00:01 { \
fhem("get CUL2 version");; \
}
Ich hab' ja nix gegen 'nen keep-alive in FHEM, sofern der notwendig ist;
aber ist denn schon sicher, daß es ein Problem den CUN generell ist, das
auch nicht in der culfw korrigiert werden kann? (Falls ja, habe ich das
hier übersehen, dann: sorry.)
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
> > Meine Frage an Rudi w re nun, ob man vielleicht hnlich wie f r das
> > FHZ ein Keep-Alive (damals per 'set FHZ time' gel st) senden k nnte.
> > Nat rlich k nnte man jetzt min tig einen Befehl ausf hren
> > (Statusabfrage), aber ich denke doch, dass ein richtiges Keep-Alive im
> > Code besser w re um solche Probleme aus der Welt zu schaffen.
>
> Ich w rde vor der Umgehung des Problems schon gerne erst einmal dem
> eigentlichen Problem auf den Grund gehen. Ich habe jedenfalls keine
> CUN-Disconnects, allerdings habe ich auch noch einen at-Job laufen
> (aus der Anfangszeit von CUN, als der sich immer wegh ngte):
Gebe ich dir natürlich recht. Wenn eine richtige Lösung möglich wäre,
dann spricht auch nichts dagegen.
Leider tritt das Problem sehr unregelmäßig auf... gibt Tage, da
passiert es gar nicht - heute hatte ich es bereits zwei Mal.
Besonders behilflich kann ich aufgrund meines mangelhaften Wissens in
dem Bereich auch nicht sein - einen Zugang freischalten oder nach
Anleitung etwas probieren werd ich aber gerne machen. ;-)
> define at_get_CUN_version at +*00:01 { \
> fhem("get CUL2 version");; \
>
> }
Du hast nicht vielleicht Lust, die Zeile einmal aus deiner Config
auszukommentieren und dann ein paar Tage zu testen?
Grüße,
Gerhard
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
HI all,
ich betreibe einen CUN seit ca. 6 Monaten (einen der ersten
Pre-Reseale-Geräte).
CUN-Disconnects hatte ich bis dato keine. Es gab mal das FHT Problem,
was aber seit Firmware (1.32 ?? glaub ich) gefixt ist, wo sich der CUN
ab und an mal aufhängte.
Ansonsten würde ich mal auf die Ethernet-Verkabelung tippen. Mehr als 3
Switches ? Leitung voll mit Media-Streams ? die FHEM-Kiste voll mit
Media-Server ?
Ich glaub eher nicht, dass das Problem am/im CUN liegt.
Gruß,
Olaf
Gerhard Pfeffer schrieb:
>>> Meine Frage an Rudi w re nun, ob man vielleicht hnlich wie f r das
>>> FHZ ein Keep-Alive (damals per 'set FHZ time' gel st) senden k nnte.
>>> Nat rlich k nnte man jetzt min tig einen Befehl ausf hren
>>> (Statusabfrage), aber ich denke doch, dass ein richtiges Keep-Alive im
>>> Code besser w re um solche Probleme aus der Welt zu schaffen.
>> Ich w rde vor der Umgehung des Problems schon gerne erst einmal dem
>> eigentlichen Problem auf den Grund gehen. Ich habe jedenfalls keine
>> CUN-Disconnects, allerdings habe ich auch noch einen at-Job laufen
>> (aus der Anfangszeit von CUN, als der sich immer wegh ngte):
>
> Gebe ich dir natürlich recht. Wenn eine richtige Lösung möglich wäre,
> dann spricht auch nichts dagegen.
> Leider tritt das Problem sehr unregelmäßig auf... gibt Tage, da
> passiert es gar nicht - heute hatte ich es bereits zwei Mal.
> Besonders behilflich kann ich aufgrund meines mangelhaften Wissens in
> dem Bereich auch nicht sein - einen Zugang freischalten oder nach
> Anleitung etwas probieren werd ich aber gerne machen. ;-)
>
>> define at_get_CUN_version at +*00:01 { \
>> fhem("get CUL2 version");; \
>>
>> }
>
> Du hast nicht vielleicht Lust, die Zeile einmal aus deiner Config
> auszukommentieren und dann ein paar Tage zu testen?
>
> Grüße,
> Gerhard
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Gerhard Pfeffer wrote:
> Du hast nicht vielleicht Lust, die Zeile einmal aus deiner Config
> auszukommentieren und dann ein paar Tage zu testen?
2010.01.25 13:16:52 5: Cmd: >setstate at_get_CUN_version Next: 13:17:04<
2010.01.25 13:16:52 3: Please define at_get_CUN_version first
==> done. Mal gucken, was passiert ;)
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
On 25 Jan., 13:17, "Kai 'wusel' Siering"
wrote:
> Gerhard Pfeffer wrote:
> > Du hast nicht vielleicht Lust, die Zeile einmal aus deiner Config
> > auszukommentieren und dann ein paar Tage zu testen?
>
> 2010.01.25 13:16:52 5: Cmd: >setstate at_get_CUN_version Next: 13:17:04<
> 2010.01.25 13:16:52 3: Please define at_get_CUN_version first
>
> ==> done. Mal gucken, was passiert ;)
> kai
Bin ich jetzt allerdings auch gespannt. ;-)
Bzw. hast du sonst noch irgendwelche at-jobs, die aktiv Aktoren
stören?
Greetz,
Gerhard
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
>> 2010.01.25 13:16:52 5: Cmd: >setstate at_get_CUN_version Next: 13:17:04<
>> 2010.01.25 13:16:52 3: Please define at_get_CUN_version first
>>
>> ==> done. Mal gucken, was passiert ;)
>
> Bin ich jetzt allerdings auch gespannt. ;-)
> Bzw. hast du sonst noch irgendwelche at-jobs, die aktiv Aktoren
> stören?
"aktiv Aktoren stören"? Äh ... Also, das ist mein alter FHEM, der
nur noch solange läuft, bis ich die Werte der Sensoren auf dem
neuen FHEM in RRD drin habe (möglichst ohne meine alte "at notify
rrd-Skript-Aufrufen-was-rrdtool-füttert.sh"-Krücke) -- senden tut
der normalerweise nix mehr, der lauscht nur noch andächtig. Der
CUN dient zur Abdeckung des 1. OGs (FHEM steht im EG).
2010.01.25 21:04:53 3: CUL2: T8670E882 -56
... noch rennt der CUN ;)
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Also solange 'fhem' aktiv Daten sendet, glaube ich nicht, dass du
Probleme bekommen wirst.
Bei mir tritt der Effekt besonders dann auf, wenn ich länger nicht
daheim bin. Bei mir gibt es dann zweimal täglich einen 'Aufruf' vom
Helligkeitssensor, der meine Rollläden hoch- und hinunter fahren
lässt. Ansonsten gibt es nur Meldungen von meinen FHTs und S555TH, die
eintrudeln, solange alles funktioniert.
Greetz,
Gerhard
On 25 Jan., 21:08, "Kai 'wusel' Siering"
wrote:
> >> 2010.01.25 13:16:52 5: Cmd: >setstate at_get_CUN_version Next: 13:17:04<
> >> 2010.01.25 13:16:52 3: Please define at_get_CUN_version first
>
> >> ==> done. Mal gucken, was passiert ;)
>
> > Bin ich jetzt allerdings auch gespannt. ;-)
> > Bzw. hast du sonst noch irgendwelche at-jobs, die aktiv Aktoren
> > st ren?
>
> "aktiv Aktoren st ren"? h ... Also, das ist mein alter FHEM, der
> nur noch solange l uft, bis ich die Werte der Sensoren auf dem
> neuen FHEM in RRD drin habe (m glichst ohne meine alte "at notify
> rrd-Skript-Aufrufen-was-rrdtool-f ttert.sh"-Kr cke) -- senden tut
> der normalerweise nix mehr, der lauscht nur noch and chtig. Der
> CUN dient zur Abdeckung des 1. OGs (FHEM steht im EG).
>
> 2010.01.25 21:04:53 3: CUL2: T8670E882 -56
>
> ... noch rennt der CUN ;)
> kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Gerhard Pfeffer wrote:
> Also solange 'fhem' aktiv Daten sendet, glaube ich nicht, dass du
> Probleme bekommen wirst.
Ist nichts konfiguriert, FS20 habe ich aus der Konfiguration komplett ent-
fernt (aus hier schon diskutierten Gründen ;)).
> Bei mir tritt der Effekt besonders dann auf, wenn ich länger nicht
> daheim bin. Bei mir gibt es dann zweimal täglich einen 'Aufruf' vom
> Helligkeitssensor, der meine Rollläden hoch- und hinunter fahren
> lässt. Ansonsten gibt es nur Meldungen von meinen FHTs und S555TH, die
> eintrudeln, solange alles funktioniert.
Nun, jenes FHEM hat von vormals 4 noch 2 Sensoren, 1 CUL im EG per USB, 1
CUN per Netz im OG. Gesendet wird nix, Empfangen jede Menge: 2x HMS100TF,
1x HMS100TFK, 3x FHT80TF, 4x FHT, 8x SxxxTH, 3x EM -- naja, und FS20 wird
natürlich auch empfangen, nur in fhem.cfg gibt's keine Geräte und es gibt
auch kein autogenerate in der Version ;) Wenn Deine CUN-Laufzeit nicht nullt,
also kein Restart stattfindet, vermutete ich das Problem eher auf Netzwerk-
eben ...
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
> Nun, jenes FHEM hat von vormals 4 noch 2 Sensoren, 1 CUL im EG per USB, 1
> CUN per Netz im OG. Gesendet wird nix, Empfangen jede Menge: 2x HMS100TF,
> 1x HMS100TFK, 3x FHT80TF, 4x FHT, 8x SxxxTH, 3x EM -- naja, und FS20 wird
> nat rlich auch empfangen, nur in fhem.cfg gibt's keine Ger te und es gibt
> auch kein autogenerate in der Version ;) Wenn Deine CUN-Laufzeit nicht nullt,
> also kein Restart stattfindet, vermutete ich das Problem eher auf Netzwerk-
> eben ...
Hab gerade nochmals nachgesehen - vorgestern gab es tatsächlich einen
Reset vom CUN.
### cut begin ###
2010.01.24 18:08:30 2: FS20 set di_00 on
2010.01.24 18:08:31 1: 10.0.0.240:2323 disconnected, waiting to
reappear
2010.01.24 18:08:36 1: CUL 10.0.0.240:2323 reappeared (CUL)
### cut begin ###
Was eben auch recht gut mit der jetzigen Uptime zusammen passt...
### cui begin ###
get CUL uptime
CUL uptime => 00FC834B
### cut end ###
00FC834B = 16548683/125/60/60 = 36,77
Bei den gestrigen reconnects, war aber wieder nichts (seither gab es
auch keine weiteren).
Zu meiner Netzwerkkonfiguration gibt es eigentlich nichts
nennenswertes zu sagen.
8-Port-Gigabit-Switch in meinen Arbeitszimmer, dort steht auch der
Server mit fhem. An dem hängen ein paar Komponenten und ein Uplink zum
Router (inkl. 4-Port-Switch) mit einem ca. 15 Meter Kabel, an dem ich
jetzt das CUN auch angeschlossen habe (als einzige
Netzwerkkomponente).
Greetz,
Gerhard
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Am 26.01.2010 um 07:01 schrieb Gerhard Pfeffer:
> 8-Port-Gigabit-Switch in meinen Arbeitszimmer, dort steht auch der
Der Ethernetchip des CUN macht nur 10MBit. Das ist eigentlich nicht das
Problem jedoch haben wir schon Switches erlebt die mit derartigen alten
Geschwindigkeiten Probleme hatten.
Vielleicht sollte man da mal testen ...
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
> Der Ethernetchip des CUN macht nur 10MBit. Das ist eigentlich nicht das
> Problem jedoch haben wir schon Switches erlebt die mit derartigen alten
> Geschwindigkeiten Probleme hatten.
>
> Vielleicht sollte man da mal testen ...
Der CUN hängt aber auch nur am Router mit 10/100mBit und da der Server
nicht mehr der Jüngste ist, kann der auch nur 100mBit. Gigabit gibts
eigentlich nur zwischen dem NAS und div. Clients. Kann aber gerne
einmal testen, wie die Datenrate (und ob sie Konstant bleibt) bei
einem 'dd' über die beiden Switches.
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
> Ansonsten w rde ich mal auf die Ethernet-Verkabelung tippen. Mehr als 3
> Switches ? Leitung voll mit Media-Streams ? die FHEM-Kiste voll mit
> Media-Server ?
>
> Ich glaub eher nicht, dass das Problem am/im CUN liegt.
Also ich will auch nicht sagen, dass es am CUN selbst liegt - eben
einfach nur heraus finden, woran.
Über die Leitung bringe ich gut 10mBit konstant drüber (heute
getestet) (Gigabit-Switch <-> Router) und es sind eben auch nur diese
beiden Switches im Netz.
Die Leitung selbst ist während meiner Abwesenheit nicht mehr belegt,
als das ich per Weboberfläche auf fhem zugreife und fhem eben Daten
vom CUN kriegt.
Auf dem Server läuft außer fhem ein Mail- und WWW-Server, werden aber
beide nur sehr minimal genutzt.
Aber heute gibt es auch noch keine Ausfälle zu beklagen. Ich warte
jetzt einmal den heutigen Abend ab - da bin ich wieder daheim und kann
auch herum probieren. ;-)
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Gerhard Pfeffer wrote:
> Olaf Droegehorn wrote:
>> Ansonsten w rde ich mal auf die Ethernet-Verkabelung tippen. Mehr als 3
>> Switches ? Leitung voll mit Media-Streams ? die FHEM-Kiste voll mit
>> Media-Server ?
>>
>> Ich glaub eher nicht, dass das Problem am/im CUN liegt.
>
> Also ich will auch nicht sagen, dass es am CUN selbst liegt - eben
> einfach nur heraus finden, woran.
> Über die Leitung bringe ich gut 10mBit konstant drüber (heute
> getestet) (Gigabit-Switch <-> Router) und es sind eben auch nur diese
> beiden Switches im Netz.
10 M_Bit_/sec? Also, kommt natürlich drauf an, wer was macht, aber
über 100 MBit/sec-Netze sollten schon 10-12 MByte/sec gehen, als
sowas bei 80 bis 100 MBit/sec. Wenn Du einen ollen WRT54G oder so-
was als Router einsetzt und von dem Daten erzeugen läßt, mißt Du
die CPU-Geschwindigkeit, nichts anderes.
Von (decent) PC A über LAN zu (decent) PC B sollten die 100 MBit/sec
je nach Protokoll usw. schon drin sein, *auch über den Switch eines
WRT54G* (um mal eine gängige Routerklasse zu nennen; Fritz!Box der
7170er-Generation ist nicht wesnetlich anders). Wenn der Router so
ein älteres embedded Teilchen ist, dann *routet* der mit ca. 20 MBit/sec
max ... Aber im LAN dürfte ja kein Routing greifen, es sei denn Du
verwendest (wie ich) auf dem gleichen Netz verschiedene IP-Bereiche.
> Die Leitung selbst ist während meiner Abwesenheit nicht mehr belegt,
> als das ich per Weboberfläche auf fhem zugreife und fhem eben Daten
> vom CUN kriegt.
> Auf dem Server läuft außer fhem ein Mail- und WWW-Server, werden aber
> beide nur sehr minimal genutzt.
>
> Aber heute gibt es auch noch keine Ausfälle zu beklagen. Ich warte
> jetzt einmal den heutigen Abend ab - da bin ich wieder daheim und kann
> auch herum probieren. ;-)
Also mein letzter DISCONNECT war lt. Logfile der vom USB-CUL, als ich
die am 22.01.10 umsteckte => auch ohne zu sendenden Daten oder "get
version"- Trigger hängt sich mein CUN nicht weg ...
(Nachdem die Temperaturen nun in rrds landen, werde ich den CUN logisch
vom alten auf den neuen FHEM umziehen, damit auch das Obergeschoß davon
abgedeckt wird. Ich erwarte aber keine Änderung in der Erreichbarkeit
meines CUN, nur weil ich eine neuere FHEM-Version nutzen werde ;))
Ciao,
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Mein CUN läuft ohne solche Disconnects durch...
a.
On 25.01.10 11:09, "Kai 'wusel' Siering" wrote:
> Gerhard Pfeffer wrote:
>> Hello zusammen,
>>
>> immer wieder kommt es bei meinem CUN zu Problemen, ähnlich derer,
>> welche scheinbar auch mit den CUL auftreten.
> [...]
>>
>> Meine Frage an Rudi wäre nun, ob man vielleicht ähnlich wie für das
>> FHZ ein Keep-Alive (damals per 'set FHZ time' gelöst) senden könnte.
>> Natürlich könnte man jetzt minütig einen Befehl ausführen
>> (Statusabfrage), aber ich denke doch, dass ein richtiges Keep-Alive im
>> Code besser wäre um solche Probleme aus der Welt zu schaffen.
>
> Ich würde vor der Umgehung des Problems schon gerne erst einmal dem
> eigentlichen Problem auf den Grund gehen. Ich habe jedenfalls keine
> CUN-Disconnects, allerdings habe ich auch noch einen at-Job laufen
> (aus der Anfangszeit von CUN, als der sich immer weghängte):
>
> define at_get_CUN_version at +*00:01 { \
> fhem("get CUL2 version");; \
> }
>
> Ich hab' ja nix gegen 'nen keep-alive in FHEM, sofern der notwendig ist;
> aber ist denn schon sicher, daß es ein Problem den CUN generell ist, das
> auch nicht in der culfw korrigiert werden kann? (Falls ja, habe ich das
> hier übersehen, dann: sorry.)
> kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
> 10 M_Bit_/sec? Also, kommt natürlich drauf an, wer was macht, aber
> über 100 MBit/sec-Netze sollten schon 10-12 MByte/sec gehen, als
> sowas bei 80 bis 100 MBit/sec. Wenn Du einen ollen WRT54G oder so-
> was als Router einsetzt und von dem Daten erzeugen läßt, mißt Du
> die CPU-Geschwindigkeit, nichts anderes.
> Von (decent) PC A über LAN zu (decent) PC B sollten die 100 MBit/sec
> je nach Protokoll usw. schon drin sein, *auch über den Switch eines
> WRT54G* (um mal eine gängige Routerklasse zu nennen; Fritz!Box der
> 7170er-Generation ist nicht wesnetlich anders). Wenn der Router so
> ein älteres embedded Teilchen ist, dann *routet* der mit ca. 20 MBit/sec
> max ... Aber im LAN dürfte ja kein Routing greifen, es sei denn Du
> verwendest (wie ich) auf dem gleichen Netz verschiedene IP-Bereiche.
*grml* - ja klar meinte ich 10MB/sec. Ich sollte mir echt abgewöhnen
drei Sachen nebenher zu machen. :-/
Und du hast den Nagel schon auf den Kopf getroffen. Handelt sich bei
meinen Router um einen WRT54G.
> Also mein letzter DISCONNECT war lt. Logfile der vom USB-CUL, als ich
> die am 22.01.10 umsteckte => auch ohne zu sendenden Daten oder "get
> version"- Trigger hängt sich mein CUN nicht weg ...
>
> (Nachdem die Temperaturen nun in rrds landen, werde ich den CUN logisch
> vom alten auf den neuen FHEM umziehen, damit auch das Obergeschoß davon
> abgedeckt wird. Ich erwarte aber keine Änderung in der Erreichbarkeit
> meines CUN, nur weil ich eine neuere FHEM-Version nutzen werde ;))
Auch jetzt kann ich noch immer kein disconnect vermelden. Dafür
funktioniert zB mein fs20su nicht, der gerade einmal 2 1/2 vom CUN weg
und durch eine dünne Wand getrennt ist.
*noch weiter probiert hab*
Der 4 Meter weiter entfernte fs20du nimmt ebenfalls keinen Befehl an,
mein Piri im Nebenraum vom Dimmer hingegen gibt brav laut und das CUN
kann auch den daneben montierten fs20su problemlos schalten.
Ich versteh die Welt nicht mehr. :-(
Grüße,
Gerhard
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
Originally posted by: <email address deleted>
Salve,
> Also mein letzter DISCONNECT war lt. Logfile der vom USB-CUL, als ich
> die am 22.01.10 umsteckte => auch ohne zu sendenden Daten oder "get
> version"- Trigger hängt sich mein CUN nicht weg ...
>
> (Nachdem die Temperaturen nun in rrds landen, werde ich den CUN logisch
> vom alten auf den neuen FHEM umziehen, damit auch das Obergeschoß davon
> abgedeckt wird. Ich erwarte aber keine Änderung in der Erreichbarkeit
> meines CUN, nur weil ich eine neuere FHEM-Version nutzen werde ;))
seit heute habe ich Probleme, allerdings habe ich hier auch ein wenig
unsanft am Netz rumgewerkelt und der CUN hängt an dem Switchport einer
FB51xx, die hinter einem 100-MBit-Switch hängt, der an einem 1 GBit-
Switch hängt, der letztlich auf dem 1-GB-Geschoß-Switch aufschlägt.
Letzterer geht auf den baugleichen 1-GBit-Switch im EG, an dem direkt
derzeit 1 der Sheeva-Plug (FHEM-Server) als auch der (Linux-) Router
im Keller je über GBit hängen. Die FB51xx hat heute Nacht vorübergehend
keinen Strom gehabt, ergo der CUN keinen Link; ich habe CUN nicht re-
startet sondern nur die FB wieder energetisch bedient.
2010.02.06 04:23:09 1: 193.x.x.x:2323 disconnected, waiting to reappear
2010.02.06 04:26:24 1: CUL 193.x.x.x:2323 reappeared (CUN)
2010.02.06 17:08:20 1: 193.x.x.x:2323 disconnected, waiting to reappear
2010.02.06 17:08:27 1: CUL 193.x.x.x:2323 reappeared (CUN)
(Jeweils durch händisches "get CUN version" reanimiert.) Letztes Lebens-
zeichen grade war:
2010.02.06 16:48:38 3: CUN: HDBF60096014120E02069616BB04000500E7
2010.02.06 16:48:38 3: CUN: Unknown code 811a04xx0510a001dbf600000096014120e02069616bb04000500e7, help me!
2010.02.06 17:08:27 1: CUL 193.x.x.x:2323 reappeared (CUN)
Keine Ahnung, ob ein Zusammenhang besteht; ich werde es weiter beobach-
ten und berichten.
kai
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.
> seit heute habe ich Probleme, allerdings habe ich hier auch ein wenig
> unsanft am Netz rumgewerkelt und der CUN hängt an dem Switchport einer
> FB51xx, die hinter einem 100-MBit-Switch hängt, der an einem 1 GBit-
> Switch hängt, der letztlich auf dem 1-GB-Geschoß-Switch aufschlägt.
> Letzterer geht auf den baugleichen 1-GBit-Switch im EG, an dem direkt
> derzeit 1 der Sheeva-Plug (FHEM-Server) als auch der (Linux-) Router
> im Keller je über GBit hängen. Die FB51xx hat heute Nacht vorübergehend
> keinen Strom gehabt, ergo der CUN keinen Link; ich habe CUN nicht re-
> startet sondern nur die FB wieder energetisch bedient.
>
> 2010.02.06 04:23:09 1: 193.x.x.x:2323 disconnected, waiting to reappear
> 2010.02.06 04:26:24 1: CUL 193.x.x.x:2323 reappeared (CUN)
> 2010.02.06 17:08:20 1: 193.x.x.x:2323 disconnected, waiting to reappear
> 2010.02.06 17:08:27 1: CUL 193.x.x.x:2323 reappeared (CUN)
>
> (Jeweils durch händisches "get CUN version" reanimiert.) Letztes Lebens-
> zeichen grade war:
>
> 2010.02.06 16:48:38 3: CUN: HDBF60096014120E02069616BB04000500E7
> 2010.02.06 16:48:38 3: CUN: Unknown code 811a04xx0510a001dbf600000096014120e02069616bb04000500e7, help me!
> 2010.02.06 17:08:27 1: CUL 193.x.x.x:2323 reappeared (CUN)
>
> Keine Ahnung, ob ein Zusammenhang besteht; ich werde es weiter beobach-
> ten und berichten.
> kai
Zur Zeit läuft mein CUN relativ stabil. Erst zwei reconnects im
Februar. Das warum würde mich zwar nach wie vor interessieren, aber
solange es nur so selten auftritt, kann man da wohl nur schwer etwas
in Erfahrung bringen. :-/
--
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com.
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en.