New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no onData after disconnect #191
Comments
Not sure I fully understand, can you provide steps (like explicit step 1, On Mon, Jul 22, 2013 at 6:37 AM, pacmac notifications@github.com wrote:
Chris Williams @voodootikigod http://twitter.com/voodootikigod | The things I make that you should check out: Help me end the negativity on the internet, share |
In this application I have the host computer, which connects to several microcontrollers via bluetooth serial ports. The host sends a request to each BT device, and the microcontroller replies with the data requested. This all works fine until one of the ports disconnects due to the bluetooth devices going out of range or being switched off etc etc. I use the diconnect callback to echo the disconnection to the console and when I power off the device, the disconnect callback fires and the port gets closed. But when the device is reconnected, it opens the ports and the data request is transmitted using the write() function, however the data transmitted back by the microcontroller in response to the request is not heard by the serialPort onData() function. Let me know if you need anything else ? |
Windows, linux or mac? On Mon, Jul 22, 2013 at 10:19 AM, pacmac notifications@github.com wrote:
Chris Williams @voodootikigod http://twitter.com/voodootikigod | The things I make that you should check out: Help me end the negativity on the internet, share |
My apologies, MAC, I can post some code if needed ? |
Here's the log, there are 2 serial ports:
Device 1, sends and receives data and updates @ 83223 (seconds since midnight). Then I power off and on again device 1 and the disconnect callback registers the disconnect. It then opens the port and writes to it again but never receives a reply. Express server listening on port 3000 Disconnect:/dev/tty.OmniTek_Bluetooth-DevB error: { '0': [Error: Cannot open /dev/tty.SLAB_USBtoUART] } write only > /dev/tty.OmniTek_Bluetooth-DevB error: { '0': [Error: Cannot open /dev/tty.SLAB_USBtoUART] } error: { '0': [Error: Cannot open /dev/tty.SLAB_USBtoUART] } |
that would be great, anything that would help trace this down is much On Mon, Jul 22, 2013 at 10:25 AM, pacmac notifications@github.com wrote:
Chris Williams @voodootikigod http://twitter.com/voodootikigod | The things I make that you should check out: Help me end the negativity on the internet, share |
Ok, I think I have fixed it and discovered the cause. I assumed that I needed to bind the onData() event when the port is initially declared, and that it would survive connects and disconnects, however it appears that each time the port is closed / opened, I have to re-define the onData() event again. Is this working as designed ?? Thanks |
Not sure hadn't considered that workflow when designing, will investigate. On Mon, Jul 22, 2013 at 11:43 AM, pacmac notifications@github.com wrote:
Chris Williams @voodootikigod http://twitter.com/voodootikigod | The things I make that you should check out: Help me end the negativity on the internet, share |
OK, great, I think that might be the same for the other callbacks too. Many Thanks, at least I can continue now |
It seems that possibly the C bindings remove references to the callbacks after the disconnect. There's nothing in our JS that prohibits this use. The event emitter isn't cleared out or anything. |
Closing due to age, if still issue, please resubmit ticket. |
Been trying to debug this for several days, and I think it may be a bug.
After the port is disconnected (by the device being removed) the onData function does not appear to get invoked after the open().
After an open(), data is being transmitted to the device, and data is sent back from the device, however the ondata() function does not appear to be firing.
The text was updated successfully, but these errors were encountered: