reopen funktioniert Update nicht

Begonnen von tantor, 26 Februar 2018, 17:43:30

Vorheriges Thema - Nächstes Thema

Deckoffizier

Hallo,

bin jetzt erst mal verwirrt.
Habe das update erst für die hardwarenahen Dateien durchgeführt .... beim Anwählen von reopen ist die Weboberfläche weg und FHEM nicht zu erreichen.
Nachgezogen update für OWX.

Mit Zeile DevIo_OpenDev($hash, 1, undef); bei Anwahl von Menü reopen  in OWX war bei Anwahl von Menü reopen   vorher    kein Absturz von FHEM.
Nach update mit Zeile $owx->Reopen(); wie gehabt Absturz von FHEM  bei Anwahl von Menü reopen .
Mit einfügen von DevIo_OpenDev($hash, 1, undef);  startet FHEM erst gar nicht mehr.
Also wieder $owx->Reopen(); eingefügt und FHEM läuft startet wenigstens wieder .
Hmm Endeffekt irgendwo eher schlechter für mich als nur Anwender geworden leider.
Busmaster ist LinkUSBi vom Fuchsshop.

Was hierbei auch nicht ganz verstehe ist warum für ROM ID not present angezeigt wird obwohl in den Internals die ROM ID angezeigt wird und das Reading 0 liefert ?
Anbei mal ein List Internals:
   ASYNC      0
   DEF        01.9117A6180000 300
   INTERVAL   300
   IODev      OWio1
   NAME       ROM_ID
   NOTIFYDEV  global
   NR         285
   NTFY_ORDER 50-ROM_ID
   OW_FAMILY  01
   OW_ID      9117A6180000
   PRESENT   
   ROM_ID     01.9117A6180000.59
   STATE      not present
   TYPE       OWID
   READINGS:
     2018-03-09 20:45:56   present         0
     2018-03-09 20:25:26   state           Initialized
Attributes:
   IODev      OWio1
   interval   300
   model      DS2401
   room       OWX
   stateFormat {ReadingsVal($name,"present",0) ? "present" : "not present"}


Gruß
Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

cwagner

#16
Mit dem Austausch der 11_OWX_SER.pm gegen die heute ins Repository gestellte Version 7.08 geht bei mir das reopen wieder ohne Abschmieren von FHEMWEB.
Zwei Hinweise im Log:
2018.03.09 23:28:33 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/11_OWX_SER.pm line 100.
2018.03.09 23:28:33 1: OWX_SER::Define warning: version 7.08 not identical to OWX version 7.08

wobei die zweite Zeile mit anderer (unterschiedlicher) Versionsnummer auch zuvor schon bei jedem Neustart von FHEM genau einmal kam.


Christian
PI 2B+/3B+ Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

Prof. Dr. Peter Henning

Zitatheute ins Repository gestellte Version 7.06

Vorsicht, bitte nicht zur Verwirrung beitragen: Im Repository steht 7.08


Die Warnungsmeldung werde ich beim nächsten Mikro-Release beheben.


@Deckoffizier: Wundert mich, da ist iegrendetwas im System nicht konsistent. Bitte nicht nur Update machen, sondern auch mit "reload 11_OWX_SER" die Hardwaredatei manuell laden, oder FHEM neu starten

Thema "present": Ein Reading present=0 bedeutet, dass der Chip _nicht_ gefunden wurde.

LG

pah

Deckoffizier

Hallo pah,

Danke für die Mühe!
Habe heute morgen noch mal nachgelegt und geupdatet.
Neustart nach update mach ich eigentlich immer .
Nun funktioniert erfreulicher weise wie mein Vorposter geschrieben hat reopen wieder.

Zum Thema reopen gehe ich richtig, dass mit Chip z.B. ein iButton gemeint sein könnte und nicht der
DS2401 selbst ?

Dann wäre alles klar für mich.

Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Prof. Dr. Peter Henning

Der DS2401 und ein iButton sind im Prinzip dasselbe.

LG

pah

Deckoffizier

Hallo pah,

habe keine Ahnung warum, aber nach meinen mehrfach gegen den
Baum gelaufenen FHEM update Versuchen habe ich jetzt

für ROM_ID present stehen mal sehen ob es so bleibt.

Mit freundlichen Gruß
Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Deckoffizier

Hallo pah,

schade hat sich leider zerschlagen musste um FHEM
nach dem heutigen update wieder zum laufen zu bekommen die alte Version von
OWNet.pm zurück kopieren  damit ist ROM_ID
wieder auf not present.

Gruß
Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Prof. Dr. Peter Henning

Nun mal langsam: OWNet.pm ist für OWDevice/OWServer. Heißt das also, dass das OWID-Frontend mit dem OWServer Backend installiert ist ?

LG

pah

Deckoffizier

Hallo pah,

wird jetzt schwierig für mich, wenn ich in der commandref richtig gelesen habe kann
OWID entweder oder von OWServer bzw. OWX genutzt werden.

Nun hatte ich in meiner Unwissenheit wohl ein Teil der Sensoren mit
OWServer eingebunden und neuerdings welche mit OWX ?

Nun habe ich das Device OWServer aus der FHEM Definition gelöscht.

Ebenfalls die dazugehörigen 1Wire Sensoren neu mit OWX eingebunden.
Muss ich jetzt auf dem Server(Linux) auch noch mehr löschen bzw deinstallieren.

Komisch bei dieser ganzen Aktion stand das Device ROM_ID mal wieder auf present aber nach FHEM Neustart
wieder auf not present.

Es handelt sich beim Busmaster um einen LINKUSBi vom Fuchs Shop.

Wenn ich richtig vermute ist dort doch ein DS2401 verbaut?
ROM_ID wird ja angezeigt.
Beide DEF des ROM_ID habe ich ausprobiert also mit Punkt bzw. Leerzeichen.

Was verstehe mache ich hier falsch ?

Danke für eine Erklärung sagt

Hans-Jürgen


FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Prof. Dr. Peter Henning

Ein Interface - egal von welchem Hersteller - kann in der Regel nur von einem Backend bedient werden.  Es gibt eigentlich nur zwei universell verwendbare Backends, die mit der ganzen Bandbreite von 1-Wire Devices kommunizieren können:
- OWFS, als separater Server installierbar und konfigurierbar
- OWX, als Bestandteil von FHEM
Das FHEM-Modul OWServer greift auf OWFS zu und stellt die dort abgefragten Werte in FHEM zur Verfügung, streng genommen ist OWServer also kein Backend, sondern eine Middleware. OWDevice ist ein universelles Frontend für OWServer, also für OWFS im Hintergrund. Allerdings lassen sich auch alle Frontendmodule 21_OW... mit OWServer verwenden, sind m.E. etwas flexibler als OWDevice dabei.

Da ich diese Kombination 21_OW... / OWServer nicht permanent verwende, sondern nur von Zeit zu Zeit teste, kann es dabei zu Problemen kommen.

Das FHEM-Modul OWX greift direkt und ohne OWFS auf das Interface zu, ist also ein echtes Backend. Das habe ich (und das war nicht so wirklich ein Spaß) im letzten Jahr so aufgebohrt, dass es eine FHEM-eigene Verwaltung des 1-Wire Busses macht, also entweder auf die jeweilige Antwort wartet (synchroner Betrieb, kann FHEM ausbremsen) oder nur ab und zu mal vorbeischaut, ob schon eine Antwort da ist (asynchroner Betrieb).

Dabei tritt ein Problem auf: Die Bussuche selbst, also die Abfrage, welche(s) 1-Wire Device(s) auf dem Bus präsent ist bzw. sind, lässt sich kaum auf einen asynchronen Betrieb umstellen. Während einer Abfrage, ob eine bestimmte Device-Id auf dem Bus präsent ist, wird also der asynchrone Betrieb unterbrochen. Ich habe deshalb bei denjenigen meiner Interfaces, die einen DS2401 enthalten, das "Interval" für die Präsenzabfrage auf 86400 Sekunden gestellt. Für zeitkritische Abfragen, etwa für meine Türöffner mit iButton, verwende ich weder OWX, noch OWFS - sondern eine kleine Schleife auf einem Arduino, die alle 250 ms den Bus auf Devices abklopft.

Frontends für OWX sind ebenfalls die 21_OW..-Module...

Aus dem Gesagten ergibt sich, dass OWFS und OWX nicht parallel installiert werden sollten.

LG

pah

Deckoffizier

Hallo pah,

Freue mich über Deine ausführliche und für mich gut verständliche Erklärung zum
Hintergrundwissen der 1Wire Anwendung. Wäre ein guter Zusatz zum Wiki.
Nach meiner eigenen Meinung sollte man Deinen Text erst gelesen und verstanden haben bevor man mit 1Wire beginnt.

Habe erst mal owfs vom Server deinstalliert und es scheint alles weiterhin zu funktionieren.
Scheint in 1Wire etwas wie Highländer zu sein.  ;)

Oh je, schon macht sich die nächste Frage auf, laut Deiner Antwort synchroner Betrieb, kann FHEM ausbremsen.
Hmm OWX läuft ja nun schon eine Weile bei mir im synchronen Betrieb, habe bisher davon nichts weiter gemerkt.

Gibt es da was in pi mal Daumen Anzahl,Art Devices oder Leitungslänge? in Punkto aus bremsen.

Das Thema iButton ist es nur für komplett zeitkritische Anwendungen so nicht  machbar, oder auch für "einfache" Anwesenheitskontrolle(Schlüsselbrett)?
An anderer Stelle hatte ich von Dir gelesen ca. 1 Minute als Abfrage Intervall.

Geht auch OWX zusammen mit einem Relaisboard ? würde mich noch reizen.
Habe hier noch vom Pi einen DS9490R über, mal sehen vielleicht bekomme ich ihn an meinen Server auch noch mit OWX zum laufen.

Viele Grüße und Danke!

Hans-Jürgen





FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,2 1Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Prof. Dr. Peter Henning

ZitatHmm OWX läuft ja nun schon eine Weile bei mir im synchronen Betrieb, habe bisher davon nichts weiter gemerkt
Muss auch nicht - ich habe das mit 4 Interfaces 4 Jahre lang auf meinem Hauptsystem synchron laufen lassen.
ZitatAnwesenheitskontrolle(Schlüsselbrett)
Kein Problem, wenn man man mit dem Zeitfaktor leben kann. Das Problem mit der Bussuche taucht nur auf, wenn noch andere Devices auf dem Bus sind. Ich würde also empfehlen, für das Schlüsselbrett einen eigenen USB/1-Wire Adapter zu spendieren, und mit einem timer (at oder DOIF) alle 10 Sekunden (geht vielleicht auch alle 5 Sekunden, muss man ausprobieren) für jeden iButton ein "get present" absetzen.

Achtung: DS2490 funktioniert mit OWX nicht, weil das über einen anderen USB-Mechanismus läuft. Bin ich leider bisher nicht dazu gekommen.

LG

pah