Nodemcu mit Tasmota und 2-Relais

[Beta-User]

Ich weiß...

Es ist zwar dein Thread, aber insgesamt ist es nicht glücklich, ein völlig anderes Thema hier dazwischenzuschieben.

Das "Problem" ist doch, dass jeder, der den Thread ggf. irgendwann wiederfindet, mit diesen ganz anderen Themen wenig anfangen kann und dann nicht weiterlesen wird, selbst wenn es dann irgendwann wieder um das eigentliche Thema geht.

Ich bin - jedenfalls bei nicht "gelösten" Themen - nicht willens, Leute zu supporten, die nicht eine gewisse "Grundhygiene" einhalten wollen und daher voraussichtlich aus diesem Thread raus. Aber Tasmota+MQTT2_DEVICE+attrTemplate für Shutter könnt ihr dann ja auch alleine, ist kein Hexenwerk (es sei denn, man stellt sich ungeschickt an).

[ghostrider]

Hallo Joachim,

so ich habe jetzt rausgefunden das mein FHEM-Backup 191 MB groß ist und entpackt 3,1 GB groß ist erklärt natürlich warum es nicht funktioniert hat.
Anbei habe ich die LOG von 2020.12 die 2020-11 ist 61 MB groß müsste ich woanders ablegen vielleicht erkennst du so schon in der 2020-11 einen Fehler ?!

Vermutlich nicht...
...aber "sein" Thread

Naja, "normalerweise": /opt/fhem/log/fhem-2020-12.log

Bzw. halt das aktuellste "dort"...

Oder wenn du wieder drauf kommst eben "rückwirkend" schauen was drin steht während du nicht drauf gekommen bist...

Gruß, Joachim

[ghostrider]

So jetzt gehts

[MadMax-FHEM]

Also ich würde erst mal den initialUsbCheck deaktivieren:

Code Auswählen Erweitern


attr initialUsbCheck  disable 1


Hast du selber schon mal reingeschaut?

Interessant wäre halt zu wissen wann du mal gestartet hast und NICHT drauf gekommen bist.

Ansonsten sehe ich eben ziemlich viel connect/disconnect von CUL...

Evtl. dauert der Start (durch initialUsbCheck) zu lange und fhem wird daraufhin vom OS? (systemd?) neu gestartet und wieder neu gestartet usw.

Dann kommst du nat. nicht drauf, weil es ja zwar "da" ist aber auch immer wieder "weg"

Mehr kann ich jetzt nicht sehen...

Gruß, Joachim

[ghostrider]

Also das ich nochmal drauf kam war wohl irgendwie Zufall.
Das mit dem USB Check kann sein da ich den CUL abgezogen habe um jeden HARDWARE  Fehler ggf. auszuschließen.
Habe auch die  log von 11-2020 hochgeladen das Problem besteht schon länger als Dezember.

Das Pi OS lief aber ohne Probleme  kam zumindest immer zuverlässig in die ssh Konsole.

Habe eben auf einem Ubuntu Notebook Fhem installiert und mein Backup eingespielt scheint bisher ohne Probleme zu laufen.
Werde es jetzt einigemale neu starten und beobachten.
Dann wieder den Pi neu installieren und dort das Backup einspielen

[MadMax-FHEM]

Naja, wenn du den CUL abziehst warum disablest du dann nicht auch das IODev?

Hast du jetzt initialUsbCheck disabled?

Sind deine CUL bzw. USB-Dvices by-id eingebunden?
Wenn nicht kann es (wird es) sein, dass fhem auf einer neuen/anderen Plattform nicht läuft/drauf zugreifen kann...

Viel Erfolg, Joachim

[ghostrider]

Hallo Joachim,

ich habe jetzt neu auf dem raspberry aufgesetzt 1. test funktioniert, nachdem ich das Backup zurückgespielt habe kein Aufruf mehr möglich.

Dann habe ich gesehen das die CPU-Last auf 100% war daraufhin habe ich wie empfohlen den USB Check über die SSh in der Fhem.CFG auskommentiert ?!

Jeztz scheint es wieder einwandfrei zu laufen seit 1 Std. zumindest.

Ist dieser Ansatz so zu empfehlen ? Bzw. kannst du mir erklären warum was passiert Es wurde ja nichts geändert und plötzlich verursacht es so ein Problem ?

[MadMax-FHEM]

Ist dieser Ansatz so zu empfehlen ? Bzw. kannst du mir erklären warum was passiert Es wurde ja nichts geändert und plötzlich verursacht es so ein Problem ?

Welcher Ansatz?

initialUsbCheck disablen?

Warum nicht?

Läuft bei mir IMMER so...

Wenn du deine USB-Gerätschaften bereits definiert hast (am besten per by-id am zweitbesten per by-path am schlechtesten per /dev/ttyUSBx) und weißt wie du ein neues USB-Dingens definieren musst, dann ist initialUsbCheck unnötig bzw. (wie in deinem Fall) kontraproduktiv...


Vermutlich passiert folgendes:

initialUsbCheck prüft alles was an USB steckt durch und versucht herauszufinden "was es ist"...
...bzgl. fhem.

Da geht die CPU schon mal hoch

U.U. dauert das systemd zu lange (oder was auch immer) und dann wird eben neu gestartet (zumindest sieht einiges in deinem Log so aus) und dann eben von vorne usw.

Gruß, Joachim

[Beta-User]

Wenn du deine USB-Gerätschaften bereits definiert hast (am besten per by-id am zweitbesten per by-path am schlechtesten per /dev/ttyUSBx) und weißt wie du ein neues USB-Dingens definieren musst, dann ist initialUsbCheck unnötig bzw. (wie in deinem Fall) kontraproduktiv...

Man kann "usb scan" etc. auch jederzeit von der Kommandozeile aus aufrufen (und sollte dann nur die "Nacharbeiten" noch machen, also eindeutige Adressierung UND (!) ggf. Setzen einer HmID, wenn man je noch Homematic mit einem CUL-Device machen wollte...).

Vermutlich passiert folgendes:

initialUsbCheck prüft alles was an USB steckt durch und versucht herauszufinden "was es ist"...

Jein. Es prüft zusätzlich auch, was an der seriellen GPIO-Schnittstelle (UART) zu finden ist. Vermutlich dauert es genau deshalb genau nur bei Pi so lange, dass dieser Effekt eintritt . Das Problem ist, dass für jede Schnittstelle dann alle möglichen Typen durchgetestet werden und jedesmal zwischendurch immer mal wieder auch die Baudrate geändert werden muss und dann gewartet, bis das umgesetzt ist...

[ghostrider]

Ok,
meine Überlegung war nur das es eben ohne Änderung passiert wie z.B. ein neu angeschlossenen Gerät am UsB oder so?
Vielleicht hängt es mit einem Update von Fhem bzw. dem Pi zusammen  ?!

Das mit den USB Geräten einrichten muss ich mir ansehen wie ich  das ändern kann.

Hatte das damals so aus einem Toutorial übernommen  für die Fgem Installation und war froh das es klappte .