nutzt dies auch einer hier? Ich habe das FGW14-USB mit IPS über Serielle SST und dem Modul FGW14 aus IPS 5,0 verbunden.
Unter 4.0 auf Win ist nach einiger Zeit irgendwie die SST gestorben. Keine Reaktion mehr.Im Debug der SST kam nix mehr an. Wenn man einmal das Socket deaktiviert und aktiviert dann läuft es sofort wieder.
Ich hab gedacht naja vielleicht Windows…Nun bin ich auf IPS 5.0 auf den Pi umgezogen und nun nach einiger Zeit das gleiche Verhalten wie auf der alten Konfiguration.
Habt Ihr ähnliche Erfahrungen?
Irgendwie wäre ein Alive nicht schlecht…Also wenn nichts mehr kommt mal Socken neu öffnen. Ich habe zwar einen Workaround der das nächtlich einmal macht aber irgendwie ist das keine Garantie. Sieht aus als ob die je nach Datenmenge irgendwann stirbt.
Ich habe an meinem Windows Rechner einmal das FGW-14 an Com 6 und dann noch den USB-Funk an Com 4,
bei dem FGW-14 kommt es abunzu dazu dass hier einfach der Port stirbt.
Ich muss dann IPS neustarten da ich den Port nicht mehr öffnen kann.
Bei dem USB-Funk Com 4 habe ich diesen Fehler:
27.08.2018 13:53:57*| TimerPool*| EnOcean Gateway FUNK (KeepAlive): Zeitüberschreitung beim Warten auf Antwort
Ok bin ich also schon mal nicht alleine das ist gut oder schlecht für uns.
Ich hab noch etwas weiter gesucht in einem anderem Forum wurde die USB Kabel Länge als Störenfried ausgemacht. Wie lang ist dein Weg zum FGW? Ich habe vielleicht so 2 Meter USB Verlängerung dran.
Also bei mir geht es wenn ich in IPS den Socket schließe und wieder öffne. IPS Neustarten wäre echt blöd.
Ich muss mich mal hin setzen um so ein Alive zu schreiben.
Wir haben ja Funk und USB Anbindung. Die Idee wäre zyklisch per Funk was zu schicken und am USB schauen ob es angekommen ist. Wenn nicht dann USB „Neustarten“
Na ihr macht mir Hoffnung, ich will gerade auf FGW14-USB umstellen, weil ich mit dem Funk immer mal wieder Probleme habe und jetzt lese ich sowas? Aktuell spinnt mein Enocean auch wieder raum, mal kommen keine Rückmeldungen (Senden geht), mal sehr verzögert… meist „spinnt“ es nach einem Enocean-Pi-Neustart, manchmal muss ich einfach Geduld haben und es läuft wieder, manchmal muss ich nochmal neustarten., in einem Fall half auch nur den FAM14 neu zu starten… kennt ihr sowas auch? Ich kann mir eigentlich nicht vorstellen das es am Enocean/Eltako liegt, hab aber noch keine Quelle ausmachen können.
Also FAM Neustarten hatte ich noch nie.
Der Eltako Aufbau ohne irgendwelche Rechneranbindung läuft absolut zuverlässig.
Was ist bisher so hatte:
[ul]
[li]regelmäßig ca. 1-4 Tage- Also FGW Verbindung stirbt ab
[/li][li]häufig - Sehr viele gleichzeitige Befehle von IPS scheint Kollisionen auf dem BUS zu erzeugen und ein Befehl wird mal verschluckt (z.b. ein Rolladen fährt nicht)
[/li][li]selten - Sehr viel Traffic auf dem BUS, vermute ich, stört auch die direkt Eingelernten Komponenten. FUD kann plötzlich nicht mehr richtig geschaltet werden.
[/li][/ul]
Ich hatte bisher keinerlei Probleme und bin gerade am Aufstocken der Enocean-Komponenten.
Bei Homematic kenne ich das Problem sehr gut. Zwei Fensterflügel gleichzeitig schließen geht immer in die Hose oder am 6-Fach Schalter nicht zwischen jedem Tastendruck eine Gedenksekunde einschieben ebenso.
Senden war dauerhaft noch nie ein Problem, klar, wenn mein Haus-Verlassen alle Lichter und alle Rollos schaltet klappt das nicht ohne Pausen, da hab ich mittlerweile zwischen jedem Befehl 200ms Pause, alleine den duty-cycle nicht zu reissen… und damit alles zuverlässig ankommt natürlich.
Ich habe aktuell ca 35 Lampenkreise (mal mit 2x mal mit 4x-Aktoren) und ca 20 Rollos mit Eltako. Dazu noch eine von mir nicht gezählte Anzahl von Steckdosen… ca 25 tippe ich mal.
Ich hatte bislang immer nur beim Empfang von Bestätigungen meine Probleme…
also ich muss sagen vor IPS5 hatte ich eigentlich nie Probleme.
Mein komplettes Haus läuft über Enocean.
Seit dem ich das Windoof neu gemacht habe und ips 5 drauf sind die Fehler ( siehe oben) aufgetreten.
Nach meinen Forumseintrag oben, habe ich die kompletten USB-Treiber rausgeworfen und Neu installiert.
Zudem habe ich die Ports an dem Rechner verändert.
der FGW hing bei mir an USB3.0 nun ist er an 2.0 seit dem kein Problem mehr.
Ich habe zwischen Rechner und FGW Schaltschrank ein 10meter USB Kabel als Verlängerung.
Wie gesagt nie Probleme und seit ich umgestellt habe scheint es wieder zu laufen.
der Funk stick hängt bei mir an einem USB 3.0 Hub diesen Hub betreibe ich nun auch an einem 2.0 mit externer Spannungsversorgung.
Bis jetzt kein keep alive mehr.
Schmeißt mal eure USB-Treiber runter und installiert Sie neu. ändert die Porst und eventuell von 3.0 auf 2.0.
Sollte bei mir wieder ein Kanal sterben, dann melde ich mich.
Also nen paar sind es (steht in der Signatur) plus einige Umstellungen auf den 14er Bus aber auch nur FSB14 plus FHK
Sage mal das System ist ein „Profi“ System und solle das wegstecken.
@Padi2055
Also ich hatte das sterben unter Windows und auch nach Umzug auf dem PI. Daher kommt mir Treiber komisch vor.
Wie schaut es mit dem Verdacht der USB Kabelläge aus?
@Padi2055
Also ich hatte das sterben unter Windows und auch nach Umzug auf dem PI. Daher kommt mir Treiber komisch vor.
Wie schaut es mit dem Verdacht der USB Kabelläge aus?
Ich habe 10 Meter vom USB Port PC zum Schaltschrank FGW.
Das USB kabel liegt mit ca. 15 Netzkabeln + Stromkabeln in einer Kabelführung.
Denke nicht das es daran liegt. Also bei mir war das noch nie ein Problem. Vor dem neuen Windoof lief das System so ca. 1Jahr ohne Probleme.
@ Boui
Ich habe den Funk stick und das FGW 14 in betrieb.
Beides aber über USB.
Also bei mir waren es keine 5 m. Habe aber dennoch nun den PI auf Hutschine dicht am FGW14. Seitdem keine Aussetzer. Hatte mir einen Watchdog gebastelt. Ein Befehl über Funk gesendet und das muss auf dem FGW ankommen. Wenn nicht ist was faul und die SST wird neu gestartet. Ist seit dem nie eingetreten.
Ich hatte das Problem ebenfalls mit dem FGW14-USB, bin daher auf ein FGW14 ohne USB umgestiegen und habe dann über ein USB > RS232 Kabel die Anbindung an IPS gemacht, die seitdem fehlerfrei läuft.
Der Aufbau läuft bei mir auch seit Jahren komplett ohne eine einzige Störung am Raspi. Wichtig ist, dass neben den beiden RS232-Kabeln auch die Masse verbunden wird. Ohne das Massekabel hatte ich mehr Störungen als Signale.
