Probleme mit "define initialUsbCheck notify global:INITIALIZED usb create"

Begonnen von Joachim, 30 Januar 2014, 13:03:49

Vorheriges Thema - Nächstes Thema

Joachim

@ Rudi,
da es mir in der letzten Zeit desöfteren aufgefallen ist, dass

define initialUsbCheck notify global:INITIALIZED usb create

mekwürdige Sachen macht, möchte ich vorschlagen, dieses future standartgemäß zu deaktivieren.

Siehe:
http://forum.fhem.de/index.php/topic,19484.0.html
http://forum.fhem.de/index.php/topic,18595.msg125432.html#msg125432

wahrscheinlich gibt es noch weitere Beispiele.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

rudolfkoenig

Beim implementieren des usb Kommandos habe ich schon befuerchtet, das solche Faelle auftreten werden, dass es so wenig wird, habe ich aber nicht erwartet. Ueber diese Zeile freuen sich tausende von fhem-Anfaenger, ohne zu wissen, dass sie existiert -> sie bleibt drin.

Im ersten Link erwaehnten Eintraege sollten nicht vom autocreate kommen, da autocreate keine Geraete anfasst, die bereits im FHEM definiert sind. Die im zweiten Link genannter Haenger ist ein Problem, da ist wohl der Linux-Treiber kaputt, da FHEM mit einem timeout zu liest. Ist fuer mich kein Grund fuer einen Umbau.

Bin gerne bereit das autocreate Modul anzupassen, damit es weniger Aerger gibt, dazu brauche ich aber mehr Hilfe.


Joachim

Moin Rudi,
beim Anpassen kann ich Dir leider nicht wirklich helfen (Zeit und Wisen).
Fakt ist allerdings, dass das Autocreate unerwünschte, und tw. sehr schwer zu findende Nebenwirkungen hat.
Ich weiß natürlich um das Problem, aber gerade Anfänger können sich das nicht erklären, deshalb mein Vorschlag, es standartgemäß zu deaktivieren.
Wenn es eine bessere Lösung gibt, habe ich da auch nichts gegen.
Ich werde dass im Forum mal im Auge behalten, und wenn weitere Probleme auftauchen, in diesem Tread Bericht erstatten.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

betateilchen

Zitat von: Joachim am 30 Januar 2014, 13:54:03Fakt ist allerdings, dass das Autocreate unerwünschte, und tw. sehr schwer zu findende Nebenwirkungen hat.

*unterschreib*

zwei Nächte schon deswegen mit Fehlersuchen verbracht...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Wernieman

Bzw. explizit nochmals in der Anfängerdoku (sofern sie gelesen wird) auf die Möglichkeit des Deaktivieren zur Fehlersuche hinweisen ....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

tagedieb

Hallo Joachim
vielen Dank für den schnellen Hinweis

Hallo und guten abend

ich habe heute mal eine eigenartige Frage: mir ist heute in meiner Logdatei folgenden Eintrag aufgefallen und ich kann diesen nicht zuordnen
Code:
2014.02.02 20:53:24 3: Opening CUL device /dev/ttyAMA0   ist klar
2014.02.02 20:53:24 3: Setting CUL baudrate to 38400           das auch
2014.02.02 20:53:25 3: CUL device opened                              das auch
2014.02.02 20:53:25 3: Opening TCM310 device /dev/ttyAMA0        weder in der Config noch am Raspi     oder FB
2014.02.02 20:53:25 3: Setting TCM310 baudrate to 57600
2014.02.02 20:53:25 3: TCM310 device opened
2014.02.02 20:53:25 3: Opening FRM device /dev/ttyAMA0             dies genauso wie TCM310
2014.02.02 20:53:25 3: Setting FRM baudrate to 57600
2014.02.02 20:53:25 3: FRM device opened
2014.02.02 20:53:30 1: usb create end



ich habe vor kurzem mein FHEM auf einem Raspi installiert und die FB fungiert als Remoteserver
am Raspi ist ein Netzteil, ein Cul 886 V.157 und ein USBBluetooth für die Tastatur
an der FB schon immer eine USB Festplatte

Kann mir das bitte jemand erklären?
Würde mich über Hilfe zur Herkunft dieser Einträge sehr freuen

heute früh sah meine Logdatei noch so aus:

2014.02.02 08:37:52 3: telnetPort: port 7072 opened
2014.02.02 08:37:53 3: WEB: port 8083 opened
2014.02.02 08:37:53 3: WEBphone: port 8084 opened
2014.02.02 08:37:53 3: WEBtablet: port 8085 opened
2014.02.02 08:37:54 2: eventTypes: loaded 2372 events from ./log/eventTypes.txt
2014.02.02 08:37:54 3: FHEM2FHEM opening Remoteserver at 192.168.1.10:7072
2014.02.02 08:37:54 3: FHEM2FHEM device opened (Remoteserver)
2014.02.02 08:37:54 3: Opening CUL_0 device /dev/ttyACM0
2014.02.02 08:37:54 3: Setting CUL_0 baudrate to 9600
2014.02.02 08:37:55 3: CUL_0 device opened
2014.02.02 08:37:55 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2014.02.02 08:37:55 2: Switched CUL_0 rfmode to HomeMatic

und dann das
2014.02.02 08:38:18 1: usb create starting
2014.02.02 08:38:20 3: Opening CUL device /dev/ttyAMA0
2014.02.02 08:38:20 3: Setting CUL baudrate to 38400
2014.02.02 08:38:20 3: CUL device opened
2014.02.02 08:38:20 3: Opening TCM310 device /dev/ttyAMA0
2014.02.02 08:38:20 3: Setting TCM310 baudrate to 57600
2014.02.02 08:38:20 3: TCM310 device opened
2014.02.02 08:38:20 3: Opening FRM device /dev/ttyAMA0
2014.02.02 08:38:20 3: Setting FRM baudrate to 57600
2014.02.02 08:38:20 3: FRM device opened


2014.02.02 11:07:37 1: update 8 file(s) have been updated.

gegen 16.02 habe ich dann FHEM neu gestartet und ab hier gab es diesen Eintrag


2014.02.02 16:02:41 3: Opening CUL_0 device /dev/ttyACM0
2014.02.02 16:02:42 3: Setting CUL_0 baudrate to 9600
2014.02.02 16:02:42 3: CUL_0 device opened
2014.02.02 16:02:42 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux
2014.02.02 16:02:42 2: Switched CUL_0 rfmode to HomeMatic


2014.02.02 16:03:20 1: usb create starting
2014.02.02 16:03:22 3: Opening CUL device /dev/ttyAMA0
2014.02.02 16:03:22 3: Setting CUL baudrate to 38400
2014.02.02 16:03:22 3: CUL device opened
2014.02.02 16:03:22 3: Opening TCM310 device /dev/ttyAMA0
2014.02.02 16:03:22 3: Setting TCM310 baudrate to 57600
2014.02.02 16:03:22 3: TCM310 device opened
2014.02.02 16:03:22 3: Opening FRM device /dev/ttyAMA0
2014.02.02 16:03:22 3: Setting FRM baudrate to 57600
2014.02.02 16:03:22 3: FRM device opened
2014.02.02 16:03:27 1: usb create end


usb create nur zu deaktivieren ? doch es muss doch eine Ursache geben? denn nach diesem Erscheinen zeigten mir ALLE Homematic Heizungsthermostate MISSING ACK an - und get config dieser Thermostate, dauert ewig

Gruss tagedieb
FHEM 5.6 auf Cubitruck
CUL und Cul 868 und 2 HM LAN an Zbox
Remoteserver auf 2.Zboxi
HM-CC-RT-DN,HM-LC-Bl1PBU-FM,HM-LC-SW1-FM,HM-LC-SW4-PCB,HM-LC-Sw1PBU-FM,HM-PB-2-WM55,HM-PB-6-WM55,HM-SCI-3-FM,HM-SEC-RHS,HM-SEC-SC,HM-SEC-SC-2,HM-SEC-TIS,HM-WDS10-TH-O u.viele mehr
diverse IT Empfänger und LW3

rudolfkoenig

Zitatund ich kann diesen nicht zuordnen
... aber zufaellig die Diskussion mit dem passenden Betreff erwischt?

Es ist mir nicht bekannt, dass autocreate von irgendeinem Modul wieder automatisch eingetragen wird.
Vielleicht sollte ich meine Formulierungen bei usb create (obwohl sie in einem "Klammer" von "usb create" Meldungen stehen) noch verstaendlicher Formulieren. Leider bedeutet das einiges an Umbau, da autocreate auch die "normalen" DevIo Routinen verwendet.

betateilchen

Gestern abend noch ein paar Performance-Tests zu dem Thema gemacht. Die wichtigsten Erkenntnisse:

Ein aktiviertes usb-create verzögert den Start meiner fhem-Installation auf eine Gesamtlänge von über 3 Minuten.
Bei einem deaktiviertem usb-create dauert ein fhem-Start unter 15 Sekunden.

Ergo: bei mir nach der Erstinbetriebnahme immer abgeschaltet. :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Kannst Du bitte das Log hier einstellen, damit ich darueber nachdenken kann?
Das Abschalten des notify finde ich in Ordnung, es sollte nur fuer Anfaenger das Leben vereinfachen.

betateilchen

Das Log aus meinem System kann ich Dir frühestens am Sonntag abend posten 8)

Aber es sieht genau so aus, wie die anderen Beispiele hier im Forum, in denen  usb create versucht, alle USB ports mit allen möglichen Devicetypen zu initialiseren, was absolut keinen Sinn macht.

Das hier ist ok - das ist auch bei mir in der fhem.cfg manuell so vorgegeben:


2014.02.02 16:02:41 3: Opening CUL_0 device /dev/ttyACM0
2014.02.02 16:02:42 3: Setting CUL_0 baudrate to 9600
2014.02.02 16:02:42 3: CUL_0 device opened
2014.02.02 16:02:42 3: CUL_0: Possible commands: BCFiAZEGMRTVWXefmltux


aber DAS HIER macht usb create völlig sinnloserweise (denn bei mir gibt es kein TCM310, kein FRM device und ein CUL wurde im Vorfeld ja bereits als CUL_0 erzeugt) bei jedem Systemstart:


2014.02.02 16:03:20 1: usb create starting
2014.02.02 16:03:22 3: Opening CUL device /dev/ttyAMA0
2014.02.02 16:03:22 3: Setting CUL baudrate to 38400
2014.02.02 16:03:22 3: CUL device opened
2014.02.02 16:03:22 3: Opening TCM310 device /dev/ttyAMA0
2014.02.02 16:03:22 3: Setting TCM310 baudrate to 57600
2014.02.02 16:03:22 3: TCM310 device opened
2014.02.02 16:03:22 3: Opening FRM device /dev/ttyAMA0
2014.02.02 16:03:22 3: Setting FRM baudrate to 57600
2014.02.02 16:03:22 3: FRM device opened
2014.02.02 16:03:27 1: usb create end


und überschreibt damit dreimal die Initialisierung für ein Device, das in wirklich gar nicht existiert.

Meiner Meinung nach sollte usb create überhaupt nicht versuchen, irgendwelche devices anzulegen, wenn bereits ein Kommunikationsgerät (im Beispiel das CUL_0) definiert/vorhanden ist. Denn in diesem Fall kann man davon ausgehen, dass der fhem-Benutzer sich über den Inhalt seiner Installation bewußt ist und die nicht funktionierende "künstliche Intelligenz" von usb create überhaupt nicht mehr braucht.

ZitatUeber diese Zeile freuen sich tausende von fhem-Anfaenger, ohne zu wissen, dass sie existiert -> sie bleibt drin.

Ob man so pauschal sagen kann, dass sich tausende von Leuten darüber freuen, weiss ich nicht. Vielleicht wissen tausende von Leuten auch einfach gar nicht, dass alles noch runder laufen könnte, wenn es diese Zeile gar nicht gäbe. Anzunehmen, dass alle zufrieden sind, nur weil sie nichts sagen, ist im Leben oft ein Irrtum ;)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatAber es sieht genau so aus, wie die anderen Beispiele hier im Forum
Das Prinzip ist mir schon klar, ich wollte nur an deinem Beispiel sehen, ob es in autocreate noch Fehler (nach meiner Definition) sind.

Zitatwas absolut keinen Sinn macht.
Das ist hoechstens relativ, und nicht mal da bin ich sicher. Z.Bsp. weiss FHEM nicht, ob du an der AMA nicht ein COC/etc angeschlossen hast. Wenn du an der USB0 etwas angeschlossen hast, dann sollte USB0 nicht nochmal geprueft werden. Ueber die Autocreate-Deaktivierung nach dem ersten Geraet habe ich auch schon nachgedacht, bin aber z.Zt. der Ansicht, dass der Benutzer dieses notify deaktivieren soll, falls es stoert.

ZitatAnzunehmen, dass alle zufrieden sind, nur weil sie nichts sagen, ist im Leben oft ein Irrtum
Nicht in diesem Fall.

betateilchen

Zitat von: rudolfkoenig am 04 Februar 2014, 12:18:28Z.Bsp. weiss FHEM nicht, ob du an der AMA nicht ein COC/etc angeschlossen hast.

Muss fhem auch nicht wissen, da es
a) fhem Installationen geben kann, in denen es überhaupt keine Komponenten an USB gibt
b) ein COC nix mit usb zu tun hat

Zitat von: rudolfkoenig am 04 Februar 2014, 12:18:28Wenn du an der USB0 etwas angeschlossen hast, dann sollte USB0 nicht nochmal geprueft werden.

ja, sollte nicht...

Zitat von: rudolfkoenig am 04 Februar 2014, 12:18:28bin aber z.Zt. der Ansicht, dass der Benutzer dieses notify deaktivieren soll, falls es stoert.

Du widersprichst Dir gerade, ich hoffe, Du merkst das selbst:

Auf der einen Seite bist Du stolz darauf, dass sich User Deiner Meinung nach über etwas freuen, von dem sie gar nicht wissen, dass es existiert.
Andererseits erwartest Du aber, dass der User etwas deaktivieren soll, von dem er Deiner Aussage nach überhaupt nicht weiß, dass es existiert.

Ein automatisches Deaktivieren nach dem ersten I/O-Device ist m.E. ein sinnvoller Weg. Wenn ich als User dann irgendwann weitere Komponenten in Betrieb nehme, bin ich mir in aller Regel darüber bewußt, dass ich diese neuen Komponenten auch in fhem einrichten muss.

Und JA, das notify stört, sobald das erste Ein-/Ausgabegerät vorhanden ist, immer mehr als dass es nützt.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatAndererseits erwartest Du aber, dass der User etwas deaktivieren soll, von dem er Deiner Aussage nach überhaupt nicht weiß, dass es existiert.

Er wird es schon finden, wenn es stoert. Und ich gehe davon aus, dass es die grosse Mehrheit nicht stoert.

ZitatWenn ich als User dann irgendwann weitere Komponenten in Betrieb nehme, bin ich mir in aller Regel darüber bewußt, dass ich diese neuen Komponenten auch in fhem einrichten muss.

Eben nicht, den ersten hast du ja auch schon nicht eingerichtet.

betateilchen

#13
Zitat von: rudolfkoenig am 04 Februar 2014, 12:39:51Eben nicht, den ersten hast du ja auch schon nicht eingerichtet.

Doch.

Zitat von: rudolfkoenig am 04 Februar 2014, 12:39:51Er wird es schon finden, wenn es stoert.

Das ist mal wieder eine typische Rudi-Antwort...

Ein Benutzer muss erstmal auf die Idee kommen, dass irgendwelche "eigenartigen Symptome" (wie bei mir der ewig lange Systemstart) etwas mit irgendeiner nicht auf Anhieb sichtbaren Automatikfunktion zu tun haben könnte. Ich bin auf diesen Zusammenhang gestern auch nur gestoßen, als ich nach meinem Shutdown-Problem geforscht habe.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

tagedieb

Hallo zusammen
nachdem ich define initialUsbCheck notify global:INITIALIZED usb create
deaktiviert habe - zeigten meine Heizungsthermostate "alle naselang" MISSING ACK
und CMDs_done fand ich nirgends nur noch CMDs_pending
ich habe mal meine Logs durchgesehen und festgestellt,das bei meinem FHEM die ominösen Einträge nach diesem Update erfolgten
vielleicht hilft das irgend wie weiter

2014.02.01 19:59:39 1: backup done: FHEM-20140201_195813.tar.gz (13585818 Bytes)
2014.02.01 19:59:39 3: update get http://fhem.de/fhemupdate4/svn/FHEM/10_CUL_HM.pm
2014.02.01 19:59:39 1: update Can't write ./FHEM/10_CUL_HM.pm: Permission denied
2014.02.01 19:59:39 3: update get http://fhem.de/fhemupdate4/svn/FHEM/46_TRX_WEATHER.pm
2014.02.01 19:59:39 3: update get http://fhem.de/fhemupdate4/svn/FHEM/98_HMinfo.pm
2014.02.01 19:59:40 3: update get http://fhem.de/fhemupdate4/svn/FHEM/HMConfig.pm
2014.02.01 19:59:40 1: update 3 file(s) have been updated.


neue Geräte wurden im Febr weder vor noch nach dem Update hinzugefügt


Gruss tagedieb
FHEM 5.6 auf Cubitruck
CUL und Cul 868 und 2 HM LAN an Zbox
Remoteserver auf 2.Zboxi
HM-CC-RT-DN,HM-LC-Bl1PBU-FM,HM-LC-SW1-FM,HM-LC-SW4-PCB,HM-LC-Sw1PBU-FM,HM-PB-2-WM55,HM-PB-6-WM55,HM-SCI-3-FM,HM-SEC-RHS,HM-SEC-SC,HM-SEC-SC-2,HM-SEC-TIS,HM-WDS10-TH-O u.viele mehr
diverse IT Empfänger und LW3