OWX Next Generation

Begonnen von Prof. Dr. Peter Henning, 09 November 2016, 20:48:30

Vorheriges Thema - Nächstes Thema

UweH

Bei mir läuft's bisher ohne Probleme. Keine Aussetzer, keine bösen Logeinträge, saubere Reconnects. Komme aber erst am nächsten WE dazu, auf meinem Live-System zu testen.

Gruß
Uwe

UweH

Tja...was soll ich sagen...um 14:21 ist meine Testmaschine stehengeblieben (schön zu sehen auf meinem Nextion, weil ich jede Minute die Zeit sende). Dann auf der Konsole den Status von FHEM überprüft (...is running), FHEM gestoppt und in diesem Moment wurde die Zeit wieder gesendet (!).
Logeintrag in diesem Moment:
2017.04.17 15:13:43 1: 192.168.178.37:23 disconnected, waiting to reappear (1wire_Test)
2017.04.17 15:13:43 1: PERL WARNING: Use of uninitialized value $sb in concatenation (.) or string at ./FHEM/11_OWX_TCP.pm line 337.
2017.04.17 15:13:43 1: OWX_TCP::Query 1wire_Test: -9 of 0 bytes in attempt 4 and state opened
2017.04.17 15:13:44 0: Server shutdown

Das LAN-Interface war aber lebendig...

Gruß
Uwe

Prof. Dr. Peter Henning

Offenbar hat das Problem etwas mit dem Timeout beim Öffnen von TCP-Ports zu tun: Der wird nie aktiviert.

Kannst Du bitte mal in 11_OWX_TCP.pm alle

main::DevIo_SimpleReadWithTimeout($hash, $timeout)

durch

main::DevIo_SimpleRead($hash)

ersetzen ?

LG

pah

UweH

Hab ich gemacht, es waren vier, wenn ich richtig gezählt habe.

Gruß
Uwe

ext23

Ich kann es leider nicht testen. Sobald ich die 00_OWX ersetze habe ich wieder das Problem, dass er meine ganze config überschreiben will.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

Aber, um Himmels Willen, woher sollte das den kommen ?

ich habe hier im Developer-Forum mal einen Thread aufgemacht, vielleicht hat jemand von den Anderen eine Idee.

https://forum.fhem.de/index.php/topic,70731.0.html

LG

pah

ext23

Ich kann leider in das Forum nicht schreiben. Leite das mal bitte weiter:

Es geht nicht um ein "Save". Hier wird kein Save ausgeführt, das muss man wenn dann manuell machen! Noch mal kurz zur Problem Beschreibung:
Vorher:
FHEM läuft, keine Änderungen im pending (Also kein rotes Fragezeichen neben "Save config")

Jetzt tausche ich die 00_OWX aus und starte FHEM neu (shutdown restart oder service fhem restart, egal)

Nachher:
FHEM läuft, aber ich sehe jetzt das rote Fragezeichen, schaue ich dort rein sehe ich die maximal anzuzeigender Änderungen (10 oder so). Da ist aber ALLES drin, also wenn ich jetzt save drücke, wird die gesamte config neu geschrieben. Das habe ich einmal gemacht, danach lief aber einiges nicht. Vermutlich macht er nicht alles richtig.
Mache ich aber bevor ich ein save mache ein "rereadcfg" ist alles OK, das Fragezeichen ist auch weg. Aber nur bis zum nächsten Neustart!

Vielleicht hilft die Beschreibung etwas besser. Also es wird hier kein automatisches Save ausgelöst, das ist falsch.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

Hm, ich werde aus der Problembeschreibung imme rnoch nicht schlau.

1. Welche "anstehenden Änderungen" haben denn mit dem Austausch des Moduls zu tun ? Wieso sind das "ca. 10 Änderungen", kannst Du die mal auflisten ? Was genau fehlt in der dann manuell gesicherten Konfigurationsdatei ?

2. Nochmal langsam zum Mitschreiben: Nach dem manuellen Sichern funktioniert alles (kann aber auch nicht sein, weil ja lt. Deiner Aussage etwas in der Konfiguration fehlt) ? Oder was funktioniert NICHT ?

3. Wie genau ist der Ablauf beim Neustart ? Ich könnte mir noch vorstellen, dass die Kiste darüber stolpert, dass in der fhem.save andere Attribute existieren als im aktuell geladenen Modul - das aber sollte nicht zu einem so katastrophalen Fehler führen. Und was genau fehlt hinterher in der Konfigurationsdatei ?

LG

pah

ext23

Hinter dem Fragezeichen sieht man ja alle Änderungen die im "pending" sind, also alles was in den config files geändert wird "wenn" man save drückt. Dort werden aber nur maximal 10 Sachen angezeigt. Die Liste ist in Wirklichkeit aber länger also dort steht dann alles drin was ich als define auf dem System habe. Drücke ich dann save, schreibt der alle config files neu. Ich habe das nur ein mal gemacht, dann wurden aber alle 1-Wire Geräte irgendwie neu angelegt mit neuen namen etc. Habe ich in die config files geschaut fehlten viele Einträge. Ich habe dann nur noch die Kommentare gesehen. Eventuell sind die Änderungen auch in die Hauptkonfiguration (fhem.cfg) gerutscht, das weiß ich nicht. Ich habe mir das nicht so genau angeschaut.

Soll ich die fhem.save vielleicht einfach mal löschen vor dem Neustart? Da stehen doch eh nur die aktuellen Stati alle Geräte drin, oder?

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

Hm, jetzt mal langsam - "nicht so genau angesehen" ist natürlich nicht hilfreich.

1. Nochmal ganz präzise gefragt: Haben nur 1-Wire-Geräte gefehlt bzw. wurden unter anderen Namen angelegt ? Oder war irgendein anderes Gerät davon betroffen ?

2. Kann es sein, dass die Defines der ganzen 1-Wire-Geräte in untergeordneten cfg-Dateien liegen ? Und dass die Geräteerkennung so früh los läuft, dass diese Geräte einfach mit den Default-Namen in der Haupt-Konfiguration neu angelegt werden, weil sie schon auf dem Bus gefunden wurden, bevor die Defines gelesen wurden ?

LG

pah

ext23

1. Ich kann es ja nochmal ausprobieren. Dann mache ich vorher mal ein backup und schau was danach alles nicht mehr geht.

2. Sicher, das kann schon sein. Aber warum dann nur bei dem neuen Modul? Das ist ja noch nie passiert. Und ja, ich habe ca. 10 config files für mein system.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

det.

da ich selbige "Erscheinung" auch hatte, vor einigen Wochen (ich berichtete das und fühlte mich damit leider überhaupt nicht ernst genommen), noch mal meine Anmerkungen zu dem Thema. Bei mir fehlte nach Austausch der OWX Module durch die Neuen und anschließendem Neustart ca. 60% der Zeilen in der fhem.cfg und zwar nicht spezifisch welche, die mit OWX zu tun hatten, sondern auch z-wave Gerätedefinitionen, Wetter, Holiday etc. ... Der Umstieg auf 5.8 war bei mir vorher und ohne Komplikationen, daran lag es nicht.


Peter, kannst Du Deine Neuentwicklung mal auf deutlich schnellerer Hardware (Intel Plattform >2GHz, Dualcore) testen, um auszuschließen, das es sich um Timingprobleme handelt. Die alten asynchronen Module von Norbert liefem bei mir auch nur auf dem RPI und auf dem schnelleren Server nicht.
Dagegen laufen Deine bisherigen Module bei mir so gut, das ich auf die asynchrone Weiterentwicklung gerne verzichten kann.
LG
det.

ext23

Kleine Anmerkung, bei mir läuft auch alles auf einem Server, also kein RPi, Fritzbox oder so ein Spielzeug. Das ist eine 4 Kern Maschine mit 16 GB Ram.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

C0mmanda

Zitat von: det. am 18 April 2017, 12:30:22
da ich selbige "Erscheinung" auch hatte, vor einigen Wochen (ich berichtete das und fühlte mich damit leider überhaupt nicht ernst genommen), noch mal meine Anmerkungen zu dem Thema. Bei mir fehlte nach Austausch der OWX Module durch die Neuen und anschließendem Neustart ca. 60% der Zeilen in der fhem.cfg und zwar nicht spezifisch welche, die mit OWX zu tun hatten, sondern auch z-wave Gerätedefinitionen, Wetter, Holiday etc. ... Der Umstieg auf 5.8 war bei mir vorher und ohne Komplikationen, daran lag es nicht.


Wird vermutlich nicht helfen, aber exakt dieses Problem hatte ich auch vor einigen Wochen mit einer Testversion von OWX.
Hat mit meine komplette Config zerschossen sodaß ich das FHEM komplett neu aufsetzen musste.
Zum "Glück" war es "nur" der Raspi auf dem "nur" meine 1-Wire-Devices laufen und nicht mein Haupt-FHEM.

Ich hatte es da als Anwenderfehler verbucht, aber scheinbar war es das nicht...?

grtz
CmdA

UweH

*fingerheb*
Ich auch. Ab einer bestimmten OWX-Version wurden beim Start von FHEM sämtliche include-Verweise gelöscht. Ich hatte die 1-Wire-Device-Definitionen, FHT, HM485 und einiges andere in externe cfg-Dateien ausgelagert. Die defs der Busmaster usw. standen am Anfang der fhem.cfg. Hat auch lange Zeit funktioniert, bis eben ab einer OWX-Version (schon länger her, nicht mehr nachvollziehbar welche) beim Start dann die includes weg waren und dann alle Devices neu eingelesen wurden. Somit war "shutdown restart" tabu, ich musste auf der Konsole beenden, das Backup der fhem.cfg einspielen und starten...manchmal bis zu 3 Mal, bis es funktioniert hat.
War mir bisher nicht sicher, ob es an OWX gelegen hat, aber wenn ich das hier so lese... :-\
Bin dann später auf configDB umgestiegen, da war der Spuk zu Ende.

Gruß
Uwe