Open JsBergbau opened 4 years ago
dbaba
commented
4 years ago This node never checks the item automatically but just shows the current state of bluetooth discovery mode (scanning mode). So if some apps/programs using Bluetooth modify the scanning mode, the checkbox state is affected as well. I'd say you're using such apps/programs on your machine. Could you please review these applications' bluetooth settings/behavior?
JsBergbau
commented
4 years ago Its a Raspbian lite without a graphical UI, so I don't think that there is running anything which automatically scans. I have two nodes. One Generic BLE in, one Generic BLE out. If I change anything in Generic BLE in, the checkbox is checked of this node. If I go then to the second node "Generic BLE out", the checkbox remains unchecked. Only if in both nodes the checkbox is unchecked, I can connect. Otherwise connect message is ignored and itemstate of both stays "missing".
Xlagrap
commented
3 years ago Hello,
I have exactly the same problem.
Thanks for your help.
saket424
commented
3 years ago Can there be a programmatic way to uncheck it each time the flow is started or re-deployed ? Currently, I have to do it manually to get it out of missing state. Sounds like I am not alone. Thanks
saket424
commented
3 years ago For those of you encountering this issue, Issuing a POST http request to stop and start scanning gets it out of the "missing" state to the "disconnected" state.
http://nodered-ipaddress:1880/__blescan/stop followed by http://nodered-ipaddress:1880/__blescan/start
After that, the connect inject request to Generic BLE In succeeds and puts the device in the "connected" state
dbaba
commented
3 years ago @saket424 Thank you for the info. Can you please share your flow file by pasting it to the comment? It would help find a possible bug.
saket424
commented
3 years ago @dbaba , here you go
[{"id":"413088b0.de1958","type":"Generic BLE in","z":"d6e3a422.f03728","name":"","genericBle":"a77b35cb.3c0c18","useString":false,"notification":true,"x":510,"y":300,"wires":[["8770bd28.0aa68"]]},{"id":"8770bd28.0aa68","type":"debug","z":"d6e3a422.f03728","name":"","active":true,"console":"false","complete":"false","x":760,"y":300,"wires":[]},{"id":"3967cbff.15d304","type":"Generic BLE out","z":"d6e3a422.f03728","name":"","genericBle":"a77b35cb.3c0c18","x":740,"y":120,"wires":[]},{"id":"a6eb169.e8c2ae8","type":"inject","z":"d6e3a422.f03728","name":"Get All Readable Attributes","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"360","crontab":"","once":false,"onceDelay":"","topic":"","payload":"","payloadType":"date","x":190,"y":140,"wires":[["413088b0.de1958"]]},{"id":"5163b4c5.844bec","type":"inject","z":"d6e3a422.f03728","name":"Start Temperature Notify Events for 5 seconds","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"","topic":"ef6802019b3549339b1052ffa9740042","payload":"{\"notify\":true,\"period\":500000}","payloadType":"json","x":210,"y":260,"wires":[["413088b0.de1958"]]},{"id":"65289e7c.e643e","type":"inject","z":"d6e3a422.f03728","name":"Connect a Thingy52 SensorTag","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"360","topic":"connect","payload":"","payloadType":"date","x":450,"y":40,"wires":[["3967cbff.15d304"]]},{"id":"d34c63ce.3b5a3","type":"inject","z":"d6e3a422.f03728","name":"Disconnect a Thingy52 SensorTag","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"","topic":"disconnect","payload":"","payloadType":"date","x":210,"y":380,"wires":[["413088b0.de1958"]]},{"id":"cc2622f4.b8e26","type":"comment","z":"d6e3a422.f03728","name":"Perform after connected","info":"","x":180,"y":100,"wires":[]},{"id":"7fdef2c1.e999fc","type":"comment","z":"d6e3a422.f03728","name":"Perform after Temperature Measurement Started","info":"","x":250,"y":200,"wires":[]},{"id":"a1e31a24.9544c8","type":"comment","z":"d6e3a422.f03728","name":"Disconnect a peripheral device","info":"","x":200,"y":340,"wires":[]},{"id":"84ced536.ffc428","type":"inject","z":"d6e3a422.f03728","name":"Enable Temperature Characteristic","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"","topic":"","payload":"{\"ef6802069b3549339b1052ffa97400\":\"0001\"}","payloadType":"json","x":460,"y":80,"wires":[["3967cbff.15d304"]]},{"id":"29bbf7e7.14b228","type":"comment","z":"d6e3a422.f03728","name":"StopBLEscan","info":"","x":170,"y":440,"wires":[]},{"id":"35dd5a90.ed5a36","type":"inject","z":"d6e3a422.f03728","name":"stopScanning","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"str","x":220,"y":620,"wires":[["e138d6d1.fd67e8"]]},{"id":"e138d6d1.fd67e8","type":"http request","z":"d6e3a422.f03728","name":"","method":"POST","ret":"obj","paytoqs":"ignore","url":"http://192.168.155.102:1880/__blescan/stop","tls":"","persist":false,"proxy":"","authType":"","x":550,"y":620,"wires":[["eff64f9d.b1375"]]},{"id":"eff64f9d.b1375","type":"debug","z":"d6e3a422.f03728","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":850,"y":620,"wires":[]},{"id":"ac692620.d48108","type":"inject","z":"d6e3a422.f03728","name":"startScanning","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"str","x":230,"y":540,"wires":[["5057f2be.c5807c"]]},{"id":"5057f2be.c5807c","type":"http request","z":"d6e3a422.f03728","name":"","method":"POST","ret":"obj","paytoqs":"ignore","url":"http://192.168.155.102:1880/__blescan/start","tls":"","persist":false,"proxy":"","authType":"","x":560,"y":540,"wires":[["b4a62891.7c5dd8"]]},{"id":"b4a62891.7c5dd8","type":"debug","z":"d6e3a422.f03728","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":860,"y":540,"wires":[]},{"id":"a77b35cb.3c0c18","type":"Generic BLE","localName":"Thingy","address":"ef:0a:f1:95:fc:e1","uuid":"ef0af195fce1","characteristics":[]}]
theelims
commented
3 years ago I'm plagued by this bug as well. The work around provided with the HTTP POST did mostly work for me. Interestingly sending the restart scan command to the BLE in node did not solve it. It must be the HTTP POST command. Easy enough to automate, though. Moreover this effect seems to be device dependent. I did not experience this problem when connecting to an Arduino Nano 33 BLE running the LED sample sketch. Where as an other device was constantly in the "missing" deadlock. Occasionally the workaround couldn't solve the problem when it was stuck in the "missing" deadlock. Then not even scan in the node did work anymore and I had to reboot the system.
aries84ct
commented
3 years ago For those of you encountering this issue, Issuing a POST http request to stop and start scanning gets it out of the "missing" state to the "disconnected" state.
http://nodered-ipaddress:1880/__blescan/stop followed by http://nodered-ipaddress:1880/__blescan/start
After that, the connect inject request to Generic BLE In succeeds and puts the device in the "connected" state
Thanks for the POST tip, it works :)
If you change something on the BLE node, BLE scanning gets automatically enabled/checked
However this behaviour is undesired, because you can't connect when Node shows "missing". If you disable "BLE Scanning" than you can connect immediately.