Hallo zusammen,
heute morgen war ich verwundert, dass Lampen im Haus nicht automatisch
ausgegangen sind. Der Blick ins System ergab, dass die Kommunikation
zwischen CUL 868 und dem Rechner nicht funktionierte. Wäre ja nicht ganz so
schlimm, wenn eine automatische Initialisierung der Schnittstelle
funktioniert hätte. Mein FHEM läuft auf einem Windowsrechner. Nun habe ich
weitere Ungereimtheiten im Vergleich zu einem Linuxsystem festgestellt.
Insbesondere:
Das Abziehen eines CUL und wieder Einstecken führt im Gegensatz zu Linux zu
keiner Neuinitialisierung -> Folge Kommunikation mit CUL funktioniert nicht.
Das Neustarten von FHEM in solchem Fall hilft auch nicht weiter,
CUL-Status zeigt dann opened aber Kommunikations mit CUL funktioniert
nicht.
Erst das Deaktivieren, Aktivieren des Treibers und das erneute Starten von
FHEM führt zum Erfolg: CUL-Status: initialized
Nun stellt sich die Frage, welcher Teil der Software führt unter Windows zu
diesem unglücklichen Verhalten?
Liegt es am USB-Treiber von Busware, am nachinstallierten Serialport 0.22,
an CUL-Firmware, an FHEM selbst oder einfach am Zusammenspiel der einzelnen
Komponenten unter Windows.
Dass es besser funktionieren kann, insbesondere die Neuinitialisierung der
COM-Schnittstelle, sieht man unter Linux (Fritzbox).
Welches Betriebssystem nun besser ist, möchte ich an dieser Stelle nicht
diskutieren.
Hat jemand mögliche Lösungsansätze das Problem einzukreisen oder gar zu
beheben?
Gruß
Damian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo,
ich vermute das es nicht um das "bessere" Betriebssystem geht (so es dass
den überhaupt gibt) sondern um das Betriebssystem welches ein USB-Gerät
automatisch neu initialisiert wenn es sich wieder am System anmeldet ohne
sich vorher evtl. korrekt abgemeldet zu haben.
Windows kann das nicht - Supportanfrage bitte nach Redmont stellen.
Linux kann damit umgehen - kein Support in dieser Hinsicht nötig.
Ob du in FHEM mit einem watchdog den Treiber unter Windows deaktiviern und
nach x sekunden wieder aktivieren kannst wäre die eigentliche Frage.
Ob das geht können dir hier nur die FHEM-Windows-Profis beantworten.
Um deine Frage zu beantworten:
>> Nun stellt sich die Frage, welcher Teil der Software führt unter Windows
zu diesem unglücklichen Verhalten?
evtl. Windows
P.S.: Auch wenn es deine Frage nicht so beantwortet wie du es vllt. gerne
gelesen hättest.
Ich greife auch mit Windows auf meine FHEM-Installation zu - aber bei mir
läuft FHEM auf einer FritzBox (Linux).
Ob dir hier jemand helfen kann - es wird sich zeigen.
Grüße
Am Donnerstag, 8. November 2012 19:05:29 UTC+1 schrieb Damian:
>
> Hallo zusammen,
>
> heute morgen war ich verwundert, dass Lampen im Haus nicht automatisch
> ausgegangen sind. Der Blick ins System ergab, dass die Kommunikation
> zwischen CUL 868 und dem Rechner nicht funktionierte. Wäre ja nicht ganz so
> schlimm, wenn eine automatische Initialisierung der Schnittstelle
> funktioniert hätte. Mein FHEM läuft auf einem Windowsrechner. Nun habe ich
> weitere Ungereimtheiten im Vergleich zu einem Linuxsystem festgestellt.
>
> Insbesondere:
>
> Das Abziehen eines CUL und wieder Einstecken führt im Gegensatz zu Linux
> zu keiner Neuinitialisierung -> Folge Kommunikation mit CUL funktioniert
> nicht.
>
> Das Neustarten von FHEM in solchem Fall hilft auch nicht weiter,
> CUL-Status zeigt dann opened aber Kommunikations mit CUL funktioniert
> nicht.
>
> Erst das Deaktivieren, Aktivieren des Treibers und das erneute Starten von
> FHEM führt zum Erfolg: CUL-Status: initialized
>
> Nun stellt sich die Frage, welcher Teil der Software führt unter Windows
> zu diesem unglücklichen Verhalten?
>
> Liegt es am USB-Treiber von Busware, am nachinstallierten Serialport 0.22,
> an CUL-Firmware, an FHEM selbst oder einfach am Zusammenspiel der einzelnen
> Komponenten unter Windows.
>
> Dass es besser funktionieren kann, insbesondere die Neuinitialisierung der
> COM-Schnittstelle, sieht man unter Linux (Fritzbox).
>
> Welches Betriebssystem nun besser ist, möchte ich an dieser Stelle nicht
> diskutieren.
>
> Hat jemand mögliche Lösungsansätze das Problem einzukreisen oder gar zu
> beheben?
>
> Gruß
>
> Damian
>
>
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> ich vermute das es nicht um das "bessere" Betriebssystem geht (so es dass
> den überhaupt gibt) sondern um das Betriebssystem welches ein USB-Gerät
> automatisch neu initialisiert wenn es sich wieder am System anmeldet ohne
> sich vorher evtl. korrekt abgemeldet zu haben.
>
> Windows kann das nicht - Supportanfrage bitte nach Redmont stellen.
>
>
das wage ich mal zu bezweifeln, dass Windows das nicht mitbekommt, wenn ein
Treiber sauber programmiert ist.
Wenn du ein USB-Stick unter Windows einfach abziehst und wieder einsteckst,
kannst auf diesem einfach weiterarbeiten - das System bekommt es
selbstverständlich mit und initialisiert den auch.
Einen Stick vorher sauber abzumelden, macht man um sicherzustellen, dass
keine gepufferten Daten verloren gehen.
Gruß
Damian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo,
also hackt es ja am Treiber wie du schreibst.
Also Anfrage an busware.de ;-)
Wobei unter Windows das BS dann gerne hergeht und den Stick erstmal
überprüfen will wenn er einfach so abgezogen wurde.
Und solange die Erlaubnis zur Überprüfung (oder die Ablehnung) aussteht
kann Windows auch auf den Stick weder schreibend noch lesend zugreifen.
Grüße
Am Donnerstag, 8. November 2012 20:55:32 UTC+1 schrieb Damian:
>
>
> ich vermute das es nicht um das "bessere" Betriebssystem geht (so es dass
>> den überhaupt gibt) sondern um das Betriebssystem welches ein USB-Gerät
>> automatisch neu initialisiert wenn es sich wieder am System anmeldet ohne
>> sich vorher evtl. korrekt abgemeldet zu haben.
>>
>> Windows kann das nicht - Supportanfrage bitte nach Redmont stellen.
>>
>>
> das wage ich mal zu bezweifeln, dass Windows das nicht mitbekommt, wenn
> ein Treiber sauber programmiert ist.
>
> Wenn du ein USB-Stick unter Windows einfach abziehst und wieder
> einsteckst, kannst auf diesem einfach weiterarbeiten - das System bekommt
> es selbstverständlich mit und initialisiert den auch.
>
> Einen Stick vorher sauber abzumelden, macht man um sicherzustellen, dass
> keine gepufferten Daten verloren gehen.
>
> Gruß
>
> Damian
>
>
>
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
also hackt es ja am Treiber wie du schreibst.
> Also Anfrage an busware.de ;-)
Auch hier bin ich mir nicht sicher, denn beim Abziehen von CUL verschwindet
der entsprechende Eintrag im Geräte-Manager und erscheint wieder nach dem
Einstecken. Unter Gerätestatus steht: Das Gerät funktioniert einwandfrei.
Es kann also durchaus an den anderen bereits genannten Komponenten liegen.
Wobei unter Windows das BS dann gerne hergeht und den Stick erstmal
> überprüfen will wenn er einfach so abgezogen wurde.
>
nur wenn Dateninkonsistenz festgestellt wird, im Normalfall ist das *nicht*der Fall - probier einfach aus.
Es sei denn du ziehst den Stick während eines Schreibvorgangs oder wenn
anstehende Daten noch nicht geschrieben wurden ab.
Ich würde dir auch nicht raten unter Linux einen Stick zu diesem Zeitpunkt
abzuziehen;)
> Und solange die Erlaubnis zur Überprüfung (oder die Ablehnung) aussteht
> kann Windows auch auf den Stick weder schreibend noch lesend zugreifen.
>
siehe oben
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Ich habe mal weiter geforscht. Am USB-Treiber liegt es wohl nicht.
Denn, wenn ich CUL abziehe, so dass der Eintrag im Geräte-Manager
verschwindet, bekommt FHEM davon nichts mit, der Zustand steht weiter auf
initialized und man kann über web ohne Fehlermeldung im Log (verbose 3) die
Lampen munter vor sich hin und her schalten, nur das diese nicht angehen.
Liegt wahrscheinlich an serialport, der das Nicht-Vorhanden-Sein des
Gerätes an FHEM nicht weiter gibt.
Gruß
Damian
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com