OWX Next Generation

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

Vorheriges Thema - Nächstes Thema

UweH

Hallo pah,

die Version 6.3alpha4 hat bei mir jeweils ca. 20 min gebraucht, um eine unterbrochene/wiederhergestellte Verbindung zu "bemerken". FHEM stand während dieser Zeit still.

Bei der aktuellen 6.3alpha5 nun ist das bisher auch ohne timeout und opendelay kein Problem, innerhalb von ein paar Minuten wird das Interface auf "disconnected" gesetzt und ebenso schnell wieder erkannt. Ein Schalten von DS2413-Aktoren ist aber weiterhin im asynchron-Modus danach nicht möglich. Was ich bisher nur einmal erwähnt habe: Ein angeschlossener DS18B20 wird im asynchronen Modus nicht gelesen.

Im synchronen Modus ist alles ok. Nach dem Wiederaufbau der Verbindung können die Aktoren geschaltet werden.

Danke und Gruß
Uwe

Prof. Dr. Peter Henning

DS2413 ist allerdings getestet. Muss ich nochmal durchziehen. 18B20 ??? Hm, liefert keine anderen Daten, als die 1820er. wundert miuch.

Next Version ist alpha6, anbei. Habe heute auf einer längeren Bahnfahrt die Hauptprobleme von OWLCD ebenfalls geknackt.

LG

pah

UweH

Synchron gibt's keine Probleme mit dem 18B20, bei asynchron wird 85° angezeigt.

Gruß
Uwe

Prof. Dr. Peter Henning

#108
OK, hier das letzte der Module angepasst auf asynchronen Betrieb: OWLCD Version 6.3

Es ist inzwischen auch relativ klar, warum es im asynchronen Betrieb noch manchmal Probleme gibt, die das OWX-System lahmlegen. Das wird der nächste und hoffentlich vorletzte Schritt der Umstellung sein.

Mein Produktivsystem läuft mit all den neuen Modulen stabil - allerdings musste ich bei 3 der 5 1-Wire Busse ebenfalls auf den synchronen Betrieb zurückgehen.

LG

pah

UweH

Funktioniert, die LCD-Geometrie musste ich aber direkt im Modul eintragen, per Attribut hat das Display nicht wie gewünscht reagiert.

Seit einigen Tagen schon klackern die Relais der Aktoren wie wild, befeuert durch Schaltbefehle alle paar Sekunden. Nun flackert auch das Display vor sich hin, auch hier alle paar Sekunden neuer Zeilenaufbau. Ich lass das jetzt mal rödeln...Bisher alles gut. :)

Gruß
Uwe

Prof. Dr. Peter Henning

Attribute sehe ich mir an, kann aber wegen Abwesenheit nächste Woche werden.

Achtung, beim Austesten bitte das hier beachten: https://forum.fhem.de/index.php/topic,68895.msg610092.html#msg610092

LG

pah

UweH

Zitat von: Prof. Dr. Peter Henning am 23 März 2017, 11:35:50
Attribute sehe ich mir an, kann aber wegen Abwesenheit nächste Woche werden.
Kein Problem, bis dahin flackert und klackert es hier munter weiter.
Zitat
...bitte das hier beachten:
Ja, Danke, hatte ich gesehen und so ähnlich betrifft es mich ja auch.
Im Log gibt's übrigens keine bösen Einträge.
Alles wird gut.

Gruß
Uwe

Prof. Dr. Peter Henning

Bei mir läuft übrigens auch ein DS18B20 mit Abfragen alle 15 Sekunden problemlos asynchron, und zwar mit anderen Devices gemischt. Ich hänge nochmal die dabei benutzen Versionen an:

LG

pah

UweH

ZitatIch hänge nochmal die dabei benutzen Versionen an
Die OWX ist neuer als meine (6.3alpha5)

Wenn ich den DS18B20 asynchron mit anderen Devices an den USB-Busmaster hänge, dann funktioniert er problemlos. Asynchron am LAN-Interface will er mir weismachen, dass ich 85° im Arbeitszimmer habe.
Ich glaube aber eher, dass der DS18B20 eine Macke hat. Mit einem anderen läuft das jetzt.

Gruß
Uwe

enno

@pah: Ich hatte deine letzte Version bei mir gestern eingebaut. Gleiches Ergebnis wie davor. Asynchron werden alle Devices erkannt, aber die Readings nicht uebernommen. Synchron läuft es normal. Da ich ausser mit Logs nicht helfen kann halte ich mich mit weiteren Tests erst mal zurück. Wenn ich unterstützen kann, dann bitte kurze Meldung.

Gruss
Enno
Einfacher FHEM Anwender auf Intel®NUC

UweH

Moin,

gestern habe ich die 6.3alpha7 testweise auf mein Livesystem aufgespielt (4 LAN-Interfaces, kein USB, ca. 50 1-Wire-Devices). Danach ist FHEM zwei mal stehengeblieben...einfach so. Zurück auf 6.3alpha4, heute morgen steht FHEM wieder.
Auf meinem Testsystem (2x LAN-, 1x USB-Interface, 12 Devices) läuft die 6.3alpha7 ohne Probleme.
Ich meine mal gelesen zu haben, dass FHEM auf schnellerer Hardware Timing-Probleme hat. FHEM läuft bei mir mit Ubuntu MATE auf einem Zotac MAG mit einem Intel Atom 330 1,6GHz, 2GB RAM und einer Kingston 60GB SSD. Mein Testsystem ist sogar noch etwas fixer, Zotac ZBOX mit Intel Celeron 1,6GHz und 4 GB RAM. Da läuft's aber...

Zu schnell?

Gruß
Uwe

UweH

Sodele...mehrfach getestet. Jede OWX-Version über 6.1alpha2 führt irgendwann zum Stillstand von FHEM. Mal nach 2 Stunden, mal nach 5...unterschiedlich.
Ohne Eintrag im Log. Bleibt einfach stehen, ist über FHEMWEB nicht mehr erreichbar, läuft aber im Hintergrund noch weiter (wird bei Statusabfrage auf der Konsole als "running" geführt). Nach dem Neustart über die Konsole ist - wie schon angesprochen - Port 7072 nicht erreichbar. Das passiert bei einem stop/start über die Konsole bei Version 6.1alpha2 nicht.
Wie schon geschrieben, ich kann leider nicht mit Logeinträgen dienen, da steht nichts drin.

Gruß
Uwe

ext23

Ich hab jetzt auch mal die Version 6.3alpha7 installiert. Wenn ASYNCHRONOUS noch auf 0 steht, bekomme ich immer:
2017.03.27 13:41:18 2 : OWX_SER::Query attempted to write to Active device MP00202
2017.03.27 13:41:18 1 : OWX_SER::Search reset failed on bus MP00202

stelle ich es auf 1 ist der Fehler weg, iButtons werden auch richtig erkannt aber das OWLCD zeigt nur noch Matsch und die GPIOs kann ich auch nicht steuern. Ich hab die angepasst OWLCD laufen aus dem anderen Thread wo es um die GPIOs ging.

/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

@ext23:

Bitte mal Folgendes versuchen:
- Starten mit asychronous=0, dann das Kommando "set ... reopen" absetzen
- Im Log nachsehen, ob das Device neu initialisiert wird
- Kommando "get ... devices" absetzen.

LG

pah

ext23

#119
OK nach dem reopen ist der Fehler weg. iButtons und LCD gpios funktionieren auch mit gpiobit nur das Display zeigt immer noch Matsch an. Kann es sein das der die Angaben in den Attributen ignoriert? Also die LCD Daten?

Achso und das Modul zerhaut mir die komplette config. Ich dachte letztens das war ein Fehler von mir aber nee es ist jetzt wieder so das in der save config queue quasi meine ganze config drin ist und wenn ich das übernehme sind alle kommentare weg in den config files und die häfte fehlt. Da ist also noch etwas anderes nicht OK. ein rereadcfg behebt es bis zum nächsten FHEM restart.

Ich hab jetzt wieder die ausm Update drauf.

Gruß
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)