-
-
I work from home (and live in NYC where food delivery is ubiquitous), so I would say that I'm probably connected far more than I'm disconnected. I have on more than one occasion gone almost a week without leaving the apartment.
I've run the SetConnectionInterval() call, so I'll see if that helps.
BTW, while I connected via the IDE to do that, I did a call to Puck.getBatteryPercentage() to see where I was at after three days on the new battery, and it returned 100, so I'm not sure if that means my drain is really low or if the unrealistically high value means that the function is not returning the proper value. :-)
-
-
Update: So everything has been working pretty much perfectly now, but there's just one problem. I've gone through 2 batteries over the last almost 2 months.
The first battery I just attributed to the heavy load from all the experimentation and testing and bugs leading to infinite connect/disconnect loops. :) But the second battery did not experience anything but normal (and what should be low-drain) use as the beacon that I built it to be.
I'm attaching a file of all the code that has been running on the puck this whole time. Maybe someone can spot something I did wrong to put an undue draw on the power. I'm already going to comment out the lightshows that happen on connect and disconnect, so that should help (although I spend a lot of time at home, so those should not be firing that much anyway) and I'll add a counter to increment on each connect and disconnect, so the next time the battery dies I can get an idea of how much activity there has been.
But if this keeps up and there's no obvious fix, maybe I should get the pixl instead for its ability to be plugged into a wall socket for power?
-
Ok, so I upgraded the firmware and applied the NRF.setSecurity() call and everything seems to be working just fine. It's still getting the random MAC, but with the PIN, I'm not bothering with the whitelist, so that's fine.
The only thing I noticed is that the pin only comes into play when connecting with the phone. When I try to connect to the Puck via the IDE, it connects without asking for anything.
It's not really a big deal, since I'm six floors up and I doubt my neighbors are really into hacking, but I was just curious if that was as designed and/or if there was a way to make the PIN always necessary.
-
-
-
I came up with an imperfect hacky workaround... I set up the whitelisting code to capture the MAC address of the most recently rejected connection attempt, and then I set a watch for a medium-length button press that whitelists that captured MAC. So whenever my phone ends up with a different MAC, and the connection is rejected, I can tell the puck to accept it and then try again.
But obviously, if there's any way I can revert to how the puck was behaving a couple of days ago, that would be infinitely more preferable.
-
So near as I can figure, this is what seems to be the case:
Apparently, on android phones, there is a security feature where they randomize their MAC address each time the transmitter is restarted for BLE advertising.
The phone's BT does have a fixed MAC address. And from the beginning, the Puck would see that fixed address in "addr" in "NRF.on('connect',function(addr){...})".
Ever since I made the "NRF.setServices(undefined, { hid : kb.report });" call, the "addr" variable in the NRF.on event has been resolving to the random MAC instead.
Forgetting the device on my phone did not change anything, the Puck still showed up in the discovered devices with the HID icon instead of the BT icon next to it. But I was able to change the advertised name on the Puck to something new, and now it shows up with the new name and the default BT icon, so that much appears to be resolved, but the random MAC is still ending up in "addr".
So the question is how to revert the NRF.on('connect') behavior back to how it was before, where the addr argument resolves to the real fixed address instead of the advertised random one.
-
Hmm. So I added the NRF.setServices() call to my code and uploaded it with the IDE. The problem is that now, for some reason, when my phone connects, it's MAC address is being reported as something other than what it had been reporting before. And on top of that, it appears that the address changes each time I toggle BT off and on again on my phone.
The problem with that being that my whitelist function is completely useless now.
I tried performing a hard reset to undo the changes and start over, but it's still exhibiting the same behavior that started after the NRF.setServices() call.
How can I undo what I just did?!?!
-
-
btw, I tried the code you suggested to make the puck an HID device, and I got an error:
>var controls = require("ble_hid_controls"); Uncaught Error: Module ble_hid_controls not found at line 1 col 42 var controls = require("ble_hid_controls");
I don't know if I need to do something first to make that module available.
I'm using the Windows executable version of the Espruino IDE, if that makes a difference.
-
-
Oh, one thing that I know is definitely not correct in my code (but not fatally) is the fact that even the long-presses of the button set off the short-press function. I figure that, as written, the short-press watch is watching for presses of at least 50ms rather than just around 50ms, so the long-press sets off both watches.
What's a better set of arguments for the watch to detect, say, a press of between 50ms-100ms?
-
I'm almost hesitant to post this, because I recognize that the code is sloppy (my javascript fluency is cursory at best) and there are probably several much better ways of doing what I did (particularly the LED stuff), but just in case anyone might find this useful, here's the code I'm running on the puck:
// // toggle LED states, based on bits in ldn // 1: Red, 2: Green, 4: Blue // function toggle(ldn) { if(ldn&1) digitalWrite(LED1,digitalRead(LED1)?0:1); if(ldn&2) digitalWrite(LED2,digitalRead(LED2)?0:1); if(ldn&4) digitalWrite(LED3,digitalRead(LED3)?0:1); } // // Flash LEDs based on bits in z // one time for i milliseconds // function wink(z,i) { digitalWrite([LED3,LED2,LED1],z); setTimeout("digitalWrite([LED1,LED2,LED3], 0);", i); // one more LED turnoff, just to be sure setTimeout("digitalWrite([LED3,LED2,LED1], 0);", (i*2)+1000); } // // flash each LED in sequence for i milliseconds // repeat lp times // // function lightshow(i,lp) { for(x=0; x<lp; x++) { setTimeout("digitalWrite([LED3,LED2,LED1], 4);", (i*((3*x)+0))); setTimeout("digitalWrite([LED3,LED2,LED1], 2);", (i*((3*x)+1))); setTimeout("digitalWrite([LED3,LED2,LED1], 1);", (i*((3*x)+2))); } setTimeout("digitalWrite([LED3,LED2,LED1], 0);", (i*((3*lp)+0))); // one more LED turnoff, just to be sure setTimeout("digitalWrite([LED3,LED2,LED1], 0);", (i*(3*lp))+1000); } // // flash LED based on bits in l, i times, for d milliseconds each time // function blink(l,i,d) { var tf1 = "toggle("+l+");"; inid = setInterval(tf1,i); var tf2 = "clearInterval("+inid+");"; setTimeout(tf2,d*i*2); // one more LED turnoff, just to be sure setTimeout("digitalWrite([LED3,LED2,LED1], 0);", (d*i*2)+1000); } // // periodically tell the LEDs to turn off in case an LED // is left on because I wrote the above functions poorly // // every 15 minutes // var autoLEDOffIntID = setInterval("digitalWrite([LED3,LED2,LED1],0);",1000*60*15); // // Code to whitelist devices for connections // Only allow: // 11:22:33:44:55:66 (my phone) // aa:bb:cc:dd:ee:ff (BLE adapter on my laptop) // var curConnect = "x"; NRF.on('connect',function(addr) { if ((addr!="11:22:33:44:55:66 public") && (addr!="aa:bb:cc:dd:ee:ff public")) { blink(1,100,20); // OUTPUT - 20 quick red flashes when rejecting a non-whitelisted connection NRF.disconnect(); } curConnect = addr; if (curConnect == "11:22:33:44:55:66 public") lightshow(100,10); // OUTPUT - celebration lights when connecting to my phone else wink(4,1500); // OUTPUT - 1 long blue when connecting to anything else }); NRF.on('disconnect',function() { curConnect = "x"; blink(5,500,5); // OUTPUT - 5 medium red&blue flashes when disconnecting }); // // Code to toggle Bluetooth on long button press // var locked = false; setWatch(function() { locked = !locked; wink(locked?1:2,300); // OUTPUT - 1 quick red or green for inactive/active if (locked) NRF.sleep(); else NRF.wake(); }, BTN, {repeat:true, edge:"rising", debounce:1000}); // // Code to report connection status quick button press // setWatch(function() { if (locked) wink(1,2000); // OUTPUT - very long red if BT off else { if (curConnect == "x") wink(4,2000); // OUTPUT - very long blue if BT on but not connected else wink(2,2000); // OUTPUT - very long green if BT on and connected } }, BTN, {repeat:true, edge:"rising", debounce:50});
-
-
-
So it works and it also doesn't work. The SmartLock part of it works fine, as long as I stay paired.
But if the connection is broken for any reason (I turn off BT on my phone, I go far away, I turn off BT on the puck, etc...), it does not automatically get re-established. Now, from looking around a bit, I think that's probably a bug with Android and/or my Pixel 3. However, even when I try to manually repair by going into "previously connected devices" and clicking "Connect" next to the Puck entry, nothing happens. I have to forget the connection completely and re-pair by picking "pair new device". The Puck doesn't even show up in the list of devices for my phone to connect to until I forget it first, but it's still advertising, as I can see it in the list of devices when I scan from my PC, so obviously the phone is filtering out discovered devices that it hasn't forgotten yet.
So I'm not sure if the inability to manually reconnect without forgetting first is a bug on the phone side or on the puck side. My next step is to test similar conditions with a BT speaker that I have, so I can see if it's an issue with the phone.
-
The puck arrived today; it looks pretty cool. Only recently however did I catch the part that my Windows 7 laptop is not compatible as-is with the Web IDE tool to communicate with the Puck, so I have to wait until tomorrow for the BLE adapter to be delivered before I can proceed. :-) But I managed to update the firmware using nRF Connect from my phone at least.
So I figure I'll run the whitelisting code (NRF.on('connect',function(addr) {...) to prevent any device besides my phone and my laptop to connect to the puck, and I'll run the code to toggle the BT with the button press.
So, if I understand correctly, once I get the IDE tool connected and running, all I have to do is put those two bits of code into the editor on the right side, then click the Send button and the puck will be all set for what I want. And then, once I confirm that everything is good, run save() to save the code to flash for when the battery dies in a year and I'm all set. I can also be extra safe and run the NRF.setServices() code to disable the console and prevent any further changes (although I think that's redundant with the whitelist, or am I overlooking something?) unless the puck is reset by removing the battery.
That should cover it, I think. Yes?
-
-
Cool, thanks!
Yeah, I figured that there were some basic initial tasks that would need to be done regardless of the eventual implementation. I probably will want to add a pin for the pairing and code to toggle discoverability with the button press. It looks like there's enough documentation around to figure out how to do all that. :)
-
Hi! I just discovered puck.js and pixl.js and I think it might be a solution to an issue I've been having and I wanted to see what people familiar with the devices thought about it.
So Android has a "SmartLock" feature that lets me define criteria for circumstances for which the phone should not automatically lock (requiring the PIN to be re-entered) as long at the criteria are true. One criterion is GPS location, so basically you can say that the phone should not lock as long as it is at your home. Another criterion is a BT pairing with a trusted device, for instance, your phone should not lock as long as it is paired with your car's BT.
The GPS criterion does not work particularly well for my home because I live in an apartment and the device frequently loses track of where it is (it works just fine when I'm at my parent's house though).
So what I would like to be able to do is have some sort of BT device that sits in my apartment that I can have my phone stay paired with, thus invoking the SmartLock "keep unlocked" function based on the trusted device pairing. I have a BT speaker, but that's not an option because it then hijacks either the phone calls or the media output, and disabling those also breaks the pairing. So I need something that will stay paired, but also not hijack any features from the phone. And also I'd preferably like to keep it plugged into a power supply, so the pixl seems like a better choice for this than the puck, but I can go with either.
Am I correct in thinking that either of these devices would do exactly what I need here?
Also, since I don't actually need the device to do anything, can I just take it out of the box, power it up, and just pair my phone with it, or is there still some manual programming that needs to be done?
I ran the setConnectionInterval call, but I think what really fixed things was removing the LED lightshows that I would launch on connects and disconnects, as well as removing this setInterval call that I had in my code:
which was there because sometimes the light shows would persist.