Hallo
ich verwende auf meinem Raspberry pi 3 das Enocean Aufsteckmodul . Hierzu habe ich wie in der Fhem Anleitung beschrieben
https://wiki.fhem.de/wiki/EnOcean_Starter_Guide
https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth
die ttyAMA0 umgestellt. Enocean funktioniert auch soweit.
Nun wollte ich in Fhem den flower power Pflanzensensor integrieren. Hierzu benötige ich Bluetooth.
Wenn ich das Bluetooth aktiviere erhalte ich "No default controller available"
Was kann das sein ?
Hi,
was sagt ls -l /dev/ser*
Gruß Otto
Hallo,
habe ein ähnliches Problem:
Ich bin noch neu bei FHEM, hatte mir als eine Instanz installiert auf meine Raspberry Pi 3 und war mit den ersten Schritten erfolgreich, bspw. Philips Hue Steuerung. Ich wollte dann mit dem PRESENCE Modul weiter machen und habe gelesen das ich dafür (logischerweise) Bluetooth benötige (ist für mich das passende Verfahren). Also auch bluetoothctl aufgerufen und das gleich Ergebnisse wie der Threadstarter. Habe einige Foren durchsucht aber überall hiess es Bluetooth funktioniert out of the box mit der aktuellen jessie oder jessie-lite Distribution.
Habe also zwei frische Installationen getestet (lite und full) und bei beiden funktionierte Bluetooth sofort.
Dann habe ich fhem wieder installiert (apt install fhem) und noch über CPAN JSON nachinstalliert und plötzlich funktioniert Bluetooth nicht mehr. Daher meine Vermutung das das nicht mit Enocean zusammenhängt.
Bei mir ergibt
➜ ~ ls -l /dev/ser*
lrwxrwxrwx 1 root root 7 Mar 23 05:41 /dev/serial1 -> ttyAMA0
Irgendjemand eine Idee warum Bluetooth plötzlich nicht mehr klappt? (Ich werde nochmal testen ob es an fhem oder JSON liegt)
Hmm ... ok, kann das selber beantworten ... nachdem ich
# define initialUsbCheck notify global:INITIALIZED usb create
auskommentiert habe, funktioniert Bluetooth wieder.
Moin,
auch wenn es nichts bringt: das macht man im Webfrontend mit
attr initialUsbCheck disable 1
:-X
Gruß Otto
Was meinst Du mit "auch wenn es nichts bringt..."?
Das ich das lieber im Frontend machen sollte? Ich mache tatsächlich das meiste inzwischen im Frontend, aber in diesem Fall war ich der Meinung das es besser ist einen Wert gar nicht erst zu definieren statt erst ein define und dann disable zu machen?! Ich habe es nur bewusst auskommentiert stehen gelassen weil ich auch noch mit USB-Dongles testen will.
Moin,
ich mache alles im Webfrontend und schaue die fhem.cfg eigentlich nie an. Und ich mag die immer wiederkehrenden endlosen Diskussionen darüber nicht.
Mit dem attribute ist es eindeutig geregelt und jederzeit änderbar.
Wobei ich der Meinung bin, dass mir diese Funktion irgendwie "überholt" scheint und die Aktivierung per default besser in eine Deaktivierung per default umgewandelt werden sollte. Ich habe hier im Forum den Eindruck, bei vielen stört diese Funktion. Ob sie wirklich jemandem nutzt kann ich nicht einschätzen. Erst recht nicht wie das Verhältnis ist.
Ich habe in meinem Installationsscript attr initialUsbCheck disable 1 fest mit drin.
Gruß Otto