Hallo zusammen,
seit dem letzten Update am WE funktioniert der Befehl "reopen" des 1Wire-USB-Adapter in FHEM nicht mehr. Nachem ich 11_OWX.pm vom 25.02 zurückgespielt habe funktioniert es wieder. Die 1Wire Version ist von 7.08 auf 7.06 zurück gestuft worden. Kennt jemand den Fehler, oder weiß was zu tun ist?
Zitat11_OWX.pm
Diese Datei kenne ich nicht.
Welches Interface wird verwendet ?
LG
pah
Meine natürlich 10_OWX.pm und ich verwende ein USB-Adapter mit einem Ds2450 drauf.
Gesendet von meinem SM-G930F mit Tapatalk
Sorry, habe mich bei dem Adapter vertan. Ich habe einen usb-FTDI_FT232R_USB_UART im Einsatz.
Zitat10_OWX.pm
Gibt es aber auch nicht ...
reopen sollte eigentlich nur für Firmata-Devices totgelegt sein.
LG
pah
Hallo pah,
Ich denke er hat den denkovi busmaster.
Der hat genau diesen ftdi im def wenn er als by-id angelegt ist.
Mit reopen startet ein aktuelles fhem neu.
Can't locate object method "Reopen" via package "OWX_SER" at ./FHEM/00_OWX.pm line 1072. 2018.02.28 21:05:54 1: Including fhem.cfg
Busmaster denkovi ds2480:
defmod 1wire OWX /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE002xu-if00-port0
attr 1wire DbLogExclude .*
attr 1wire group System-Hardware
attr 1wire interval 300
attr 1wire room SYSTEM
attr 1wire verbose 0
Ich wiederhole es mal mit verbose 4
Mit dem Handy online, daher kurz gefasst...
Verbose 4
Can't locate object method "Reopen" via package "OWX_SER" at ./FHEM/00_OWX.pm line 1072.
2018.02.28 21:11:18 1: Including fhem.cfg
2018.02.28 21:11:18 3: telnetPort: port 7072 opened
2018.02.28 21:11:18 3: WEB: port 8083 opened
2018.02.28 21:11:18 2: eventTypes: loaded 1054 events from ./log/eventTypes.txt
2018.02.28 21:11:19 3: TelegramBot_Define TelegramBot: called 2018.02.28 21:11:21 1: OWX_SER::Define warning: version 7.05 not identical to OWX version 7.08
2018.02.28 21:11:21 3: Opening 1wire device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE002xu-if00-port0
2018.02.28 21:11:21 3: 1wire device opened
2018.02.28 21:11:21 3: OWX_SER: opened serial device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE002xu-if00-port0: Illegal seek
Mit dem Handy online, daher kurz gefasst...
Ist ein ähnlicher Adapter wie der Denkovi.
Ich habe den gleichen Log-Eintrag mit der aktuellen OWX.pm
Gesendet von meinem SM-G930F mit Tapatalk
Zitat von: tantor am 28 Februar 2018, 21:40:37
Ist ein ähnlicher Adapter wie der Denkovi.
Ich habe den gleichen Log-Eintrag mit der aktuellen OWX.pm
Gesendet von meinem SM-G930F mit Tapatalk
Hat zumindest den gleichen USB rs232 Wandler drauf. ;-)
Mit dem Handy online, daher kurz gefasst...
Derzeit nicht an Deck.
LG
pah
für mich hat der Bug keine Eile. Ich brauch kein Reopen Befehl.
Beim Initialen Start von fhem läuft alles sauber hoch.
Hätte es ohne diesen thread gar nicht gemerkt. 😉
Mit dem Handy online, daher kurz gefasst...
noch ein Betroffener:
https://forum.fhem.de/index.php/topic,18996.msg776451.html#msg776451
Bin auch betroffen und sehr darauf angewiesen. Durch EMV Probleme im Sicherungsschrank verliert der USB Hub immer wieder die Verbindung zu meinem LinkUSBi Adapter http://www.fuchs-shop.com/de/shop/17/1/13372210/ (http://www.fuchs-shop.com/de/shop/17/1/13372210/).
Jedenfalls hat das bisher immer super funktioniert. Würde mich über eine schnelle Lösung wirklich sehr freuen.
Hier noch mein define:
define If_1W.00 OWX /dev/ttyUSB_LinkUSBi
attr If_1W.00 asynchronous 0
attr If_1W.00 dokick 0
attr If_1W.00 group HWInterfaces,1-Wire
attr If_1W.00 icon cul_usb
attr If_1W.00 room Technik Fhem
Edit: Habe jetzt in der Datei 00_OWX.pm in der Zeile 1072 den "alten" Befehl für reopen eingefügt:
DevIo_OpenDev($hash, 1, undef);
statt
$owx->Reopen();
Funktioniert also für mich erstmal.
Viele Grüße
Martin
Problem scheint gelöst.
Aus irgendeinem Grund waren die vier hardwarenahen Dateien 11_OWX ... auf dem Versionsstand 7.05 - also November 2017. Wundert mich etwas, weil ich die nach meiner Protokollierung mindestens auf Version 7.06 eingecheckt hatte....
Aber egal: Alle vier gerade in Version 7.08 neu eingecheckt. Reopen funktioniert wie gewohn bei USB und TCP-Devices, bei FRM und CCC-Devices ist es derzeit funktionslos.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 09 März 2018, 18:21:24
Problem scheint gelöst.
Aus irgendeinem Grund waren die vier hardwarenahen Dateien 11_OWX ... auf dem Versionsstand 7.05 - also November 2017. Wundert mich etwas, weil ich die nach meiner Protokollierung mindestens auf Version 7.06 eingecheckt hatte....
Aber egal: Alle vier gerade in Version 7.08 neu eingecheckt. Reopen funktioniert wie gewohn bei USB und TCP-Devices, bei FRM und CCC-Devices ist es derzeit funktionslos.
LG
pah
Prima! Werde es morgen mit dem Update ausprobieren. Vorab schon einmal besten Dank!
Gesendet von meinem SM-G930F mit Tapatalk
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
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
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
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
Der DS2401 und ein iButton sind im Prinzip dasselbe.
LG
pah
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
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
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
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
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
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
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