Echt seltsam… Ich habe es auch auf einem Rpi 3b+ getestet, ohne Probleme.
Hast du noch eine andere Gladys, die auf demselben Gerät Bluetooth nutzt?
Bist du sicher, dass Bluetooth aktiviert ist?
bluetoothctl
> agent on
> power on
pi@gladys:~ $ bluetoothctl
Agent registriert
[bluetooth]# agent on
Agent ist bereits registriert
[bluetooth]# power on
Ändern des Stroms auf ein erfolgreich
[bluetooth]#
Das ist die einzige VM, die Bluetooth verwendet
In den Diskussionen auf dem edlen GitHub habe ich das hier gelesen
Darf ich vorschlagen, einen Hinweis in deiner Readme hinzuzufügen, dass der BLE-Adapter nicht läuft, wenn dein Container nicht im Host-Modus läuft?
Also, ich glaube, du wirst dein Docker-Netzwerk ändern müssen 
Kann man das zum Beispiel am Port 80 ändern?
edit, gladys-net durch host ersetzen, ich verstehe und teste das mal.
Da gibt es eine Berechtigungsgeschichte (Docker), wenn man etwas haben will, das unabhängig vom Netzwerkmodus ist. Ich kümmere mich darum, so schnell wie möglich.
Also, keine Neuigkeiten? Ich veröffentliche gerade die Version v4.0.0-bluetooth.4 mit einigen grafischen Korrekturen und Code-Bereinigungen.
Ich habe gerade den Fortschritt gesehen, wirklich cool!
Am Ende hast du dich für welche Option in deinem PR entschieden?
Schon wieder zurück? Ich habe die Option „Ich mache nichts ohne PG zu konsultieren“ gewählt 
Daher fehlt dieser Teil.
Parallel arbeite ich an Awox Bluetooth, um zu sehen, ob in der Bluetooth-PR etwas vergessen wurde, und habe bestätigt, dass die Bluetooth-abhängigen Dienste gut funktionieren.
Aber Noble ist voller Bugs, ich bin auf eine Verbindung pro Gerät beschränkt, danach ist es verloren… Ich warte auf eine neue Version, die dies beheben wird.
Ja! Nach dem Urlaub antworte ich heute nur auf Nachrichten, aber ab Montag arbeite ich ernsthaft an Gladys weiter.
Ich bin für Lösung Nr. 2, aber nur, wenn es ordentlich gemacht wird.
Meiner Meinung nach sollte kein „generisches“ Event gesendet werden, sondern ein anderes Event pro Dienst. Es wäre zu aufwendig, allen Diensten alle neu erstellten Geräte zu senden. Jeder Dienst sollte nur die neuen Geräte seines eigenen Dienstes erhalten.
Es könnte so etwas sein wie:
this.gladys.event.emit(`${EVENTS.DEVICE.DEVICE_CREATED}.${device.service}`, device);
Was denkst du?
Ich denke, es wäre trotzdem interessant, ein generisches Event zu haben, denn für den Google Home könnte man die neuen Geräte aller Dienste automatisch hinzufügen, damit sie ab ihrer Erstellung berücksichtigt werden, außer durch Benutzeraktionen.
Daher wären beide Typen gut!
Kannst du mir mehr über den Google Home Use Case erzählen?
Wie du sehen konntest (ich erwähne das für die anderen) habe ich auf den Use Case GH im GH-Topic geantwortet:
Ansonsten, um auf deine Frage zum Stand der Dinge zu antworten, ich korrigiere kleine Dinge am Bluetooth mit der Integration des AwoX-Unterdienstes, aber ich warte vor allem auf Feedback von den Testern
Ich denke, ich werde den PR so schnell wie möglich überprüfen, falls es Änderungen gibt, werden sie geringfügig sein oder in einem PR eines Bluetooth-Unterdienstes integriert werden.
Hallo!
Toll, toll dieser Fortschritt!
Beendest du die AwoX-Integration in diesem Bluetooth-PR?
Falls nicht, werde ich versuchen, einige BT-Geräte zu testen, die ich habe!
Ich möchte die BeeWi/Otio-Geräte integrieren, wie gehe ich vor?
Die Geräte: Steckdosen, Feuchtigkeits-/Temperatursensor und Türöffner.
Ich sollte einige Informationen zu den verwendbaren UUIDs und deren Funktion extrahieren können. Aber wie integriere ich sie in einen Subservice? Hast du schon eine Idee für ein Template?
Hallo,
AwoX benötigt Webseiten und einen sehr spezifischen Workflow, das wird also in einem anderen PR sein, aber du kannst dich schon an dem inspirieren, was ich gemacht habe, um deine eigenen „spezifischen“ Dienste zu erstellen. Schau dir nur den AwoX-Teil an (da Bluetooth noch nicht auf master ist, habe ich AwoX ausgehend vom Bluetooth-Zweig begonnen).
@AlexTrovato Ich habe deine Arbeit auf Github gesehen, das ist wirklich toll!
Kann ich jetzt zusammenführen oder hast du noch andere Dinge damit zu tun?
Für mich ist es im Moment in Ordnung, auch wenn es noch keine Rückmeldung von den Tests gibt.
Gladys ist bei mir seit dem letzten Build kaputt. Der Container startet nicht mehr.
/src/server/services/bluetooth/node_modules/@abandonware/noble/lib/hci-socket/hci.js:100
this._deviceId = this._socket.bindRaw(deviceId);
^
Error: ENODEV, No such device
at Hci.init (/src/server/services/bluetooth/node_modules/@abandonware/noble/lib/hci-socket/hci.js:100:35)
at NobleBindings.init (/src/server/services/bluetooth/node_modules/@abandonware/noble/lib/hci-socket/bindings.js:78:13)
at /src/server/services/bluetooth/node_modules/@abandonware/noble/lib/noble.js:60:24
at processTicksAndRejections (internal/process/task_queues.js:79:11) {
errno: 19,
code: 'ENODEV',
syscall: 'bind'
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! gladys-server@ start:prod: `cross-env NODE_ENV=production node index.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the gladys-server@ start:prod script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2020-10-16T20_07_23_616Z-debug.log
Edit: Ich habe ein GitHub-Issue erstellt, um dies zu verfolgen
Hallo, ist das nicht das Problem, das wir mit der Netzwerkgeschichte des Containers hatten, der ‹ host › sein sollte?
Bist du unter Docker?
Falls nicht, muss man bei manueller Ausführung
sudo setcap cap_net_raw+eip $(eval readlink -f "which node")
ausführen.
Ach, aber ich bin auf dem Host. (Docker auf Ubuntu Server 20.04 amd64)
Heute Morgen habe ich versucht, einen Bluetooth-4.0-Dongle anzuschließen, aber auch das stürzt beim Start ab. Auf dem Host kann ich ihn nicht erkennen, also könnte das Problem vielleicht nicht bei Gladys liegen. Ich werde weiter recherchieren