-
Would a simple vibration detector be suitable for zero battery drain option at a push?
Not sure how sensitive they are, but worth playing with. Possibly coupled with magnetometer variances followed by a vibration signal to indicate a motion followed by a sudden stop.Another method could be based on a magnet mounted on rubber bands that would oscillate following a abrupt stop. Use the magnetometer to learn the polarity variances following various motions.
Not as solid state but may have some experimental legs in it?
-
All what you say makes sense Gordon following on from my recent tests.
I may help to make it clear what I am attempting and how I am progressing so far.
The project is to set a range of Puck's to broadcast primarily motion detection but also temperature, light level, magnetometer, voltage readings and battery condition. The target uses are:
a) Motion detection to turn lights on and off and act as intrusion detection.
b) Pool water level detection and temperature using a floating magnet in the pool skimmer and a waterproof remote temperature IC. (Currently working using a Photon device and a solar panel / battery circuit)
c) Soil moisture detection to trigger irrigation and monitor soil moisture over time.
All of this was to be monitored, recorded and acted on using an externally situated Pi3 running node-red. Trigger actions are handled with a combination of IFTTT event handlers and notifications, and data logging using an SQL database.
I must say that I am very happy with what has been achieved so far and most of the elements are working very well, but I feel it's not fully optimised yet.
Initially I experimented with code that you posted to set up advertising a simple value:
setInterval(function() { NRF.setAdvertising({ 0x1809 : [Math.round(E.getTemperature())] }); }, 30000);
It's clear now that this will set broadcasting up continuously the temperature reading, and update it every 30 seconds. All very good.
I modified the code to send a second parameter to see if it was possible to send multiple sensors in the same broadcast command. For example:
setInterval(function() { NRF.setAdvertising({ 0x1809 : [Math.round(E.getTemperature())], 0x2a00 : [Math.floor((Math.random() * 10) + 1)] }); }, 30000);
Setting up a /ble/advertise/fd:f9:15:7f:43:07/# MQTT listener showed both values correctly and were also filterable using /0X809 and /0x2a00 in the filter.
Adding a third or fourth value also worked until I more data to the array like a string of characters to represent the mag array, or just a random "Hello world" string. This broke the advertisement and threw an error in the Puck console. I believe it was a ble size error.
Removing some of the data lines or shortening the strings sent fixed the error and all was good once more.
To get around the problem, I divided the messaging up into multiple advertisements delayed by 5 seconds using setTimeout() functions. All these were wrapped in a 60 second setInterval() function to refresh the data readings.
One other important discovery was that if you want to advertise an important event, you must stop other events from being advertised, or at least being refreshed, otherwise the event may be lost. This was the case for a motion detect event. To handle this I recorded state of the motion detector to suppress broadcasting of other data.
Motion detection was also set up to be broadcast on a state change using a setWatch() function. This was the number one priority broadcast event so had to broadcast as soon as it occurred.
Using this method led me to believe there is an advertise period (backed up by some NRF documents). The fully working code I used is:
//7f:9a Motion detector code digitalPulse(LED1,true,1000); pinMode(D1, 'input_pulldown'); pinMode(D30, 'input'); var state =0; var zero = Puck.mag(); NRF.setTxPower(4); // Full Power advertising function motion(){ digitalPulse(LED3,true,100); advertise(1); } function reset(){ digitalPulse(LED2,true,100); advertise(0); } function advertise(pinState){ state = pinState; NRF.setAdvertising({ 0x2a00 : [state] }); } setWatch(motion, D1, {repeat:true,edge:'rising',debounce:100}); setWatch(reset, D1, {repeat:true,edge:'falling',debounce:100}); setInterval(function () { setTimeout(function(){ if(state === 0){ NRF.setAdvertising({ 0x2a01 : [String(E.getTemperature())] }); } },1); setTimeout(function(){ var volts = analogRead(D30)*6.6; volts = Math.round(volts * 100) / 100; if(state === 0){ NRF.setAdvertising({ 0x2a02 : [String(volts)] }); } },5000); setTimeout(function(){ if(state === 0){ NRF.setAdvertising({ 0x180f : [Puck.getBatteryPercentage()] }); } },10000); setTimeout(function(){ if(state === 0){ NRF.setAdvertising({ 0x2a03 : [String(NRF.getBattery())] }); } },15000); setTimeout(function(){ if(state === 0){ NRF.setAdvertising({ 0x2a04 : [String(Puck.light())] }); } },20000); setTimeout(function(){ if(state === 0){ NRF.setAdvertising({ 0x2a05 : [String(getMag())] }); } },25000); },60000); function getMag(){ p = Puck.mag(); p.x -= zero.x; p.y -= zero.y; p.z -= zero.z; var s = Math.sqrt(p.x*p.x + p.y*p.y + p.z*p.z); return Math.round(s * 100 ) / 100; }
If anyone would like to see the node-red flow and view some of the output data I have attach then to this post.
Finally a note about the battery life. If you simply watch all events from a Puck, you see a stream of RSSI adverts with the puck name:
9/01/2017, 11:06:3194b19651.0be4b8
/ble/advertise/fd:f9:15:7f:43:07 : msg.payload : string [34]
{"rssi":-99,"name":"Puck.js 4307"}
19/01/2017, 11:06:3194b19651.0be4b8
/ble/advertise/fd:f9:15:7f:43:07/rssi : msg.payload : string [3]
-99These occur continously, so the thought of of being able to have a multiplexing array of adverts that use the same broadcast stream would be really cool. Having it all handled in the command NRF.setAdvertising({id,[payload1]},{id,[payload2]},id{id,[payload3]}, options) whoud be a simple way to set up non colliding event data as you suggested. Further options could be added to have a priority flag that ensured a motion event could be prioritised over another to be re-advertised on change.
My current Puck battery life is holding out apart from initial uploading hundreds of times the code, but when left to advertise, appears to be steady. Temperature does effect the battery readings so you do have to watch trends over time.
All food for thought and possibly outside the normal methods of ble data coms. -
OK Thanks Gordon,
I have tested that the advertising does indeed continue. The data doesn't change until you call the function again.
What appears to be crucial to ensure the data has a fair chance of being picked up is to stagger the advertising interval and different setTimeout() periods that do not overlap too much. Setting them to the same interval tends to block each other.
I remember reading in some NRF documentation that there is a random figure deployed in the advertising and switching of one of the three advertising channels to avoid collisions. I am also sure there was a duration setting as well to stop the advertising after a period of time.
What would be the method to stop any previous advertising setup to reduce power and reduce the possibility of collisions if any?
One other method to achieve this would be in the payload data rather than the channel as in a key pair payload. This would reduce the data allowed but for telemetry data should be fine.
-
I am using the Puck to advertise multiple sensors and to do this I set up a delay to sequence each sensor value. When monitored on node-red it would appear that the advertised value is only sent once or again if the value changes in the time before the next sensor value is advertised.
This is OK for most uses, but if the Pi misses an advertisement data can be lost, like a motion sensor pulse.
The question I have is, is an advertise duration option available? I know the advertise interval is, but how long it advertises for the set interval before it stops I am not sure.
When you monitor RSSI it appears to be a constant stream of advertisements. Is this possible to set up with NRF.
Perhaps it is set to only re-advertise onChange()?
-
Forgot to add that the Pucks are on the same table as the Pi's. All within a metre or two. One thing did come to mind in that in the scan there are around 10 advertising devices near the Pi. If there are so many, could they be delaying the responses, or blocking the responses from the Puck that is trying to respond?
Perhaps I should increase the power to 0dBm to see if it improves the results?
Also, having the EspruinoHub report the results of the scan does seem an additional overhead in the timing. I wonder if it's possible to mute the scan results to see if the writing to console may be making a difference?
-
It's a bit of a mix of fortunes really.
Raspian has been shipping node-red for some time and it comes with node 0.10.29 pre-installed. The Rpi3 compiled and ran using v0.10.27 but the disconnection errors were creating problems as reported in the other thread.The older Rpi2 would not compile EspruinoHub using v0.10.27 hence the drive to go up in revision. Now its on node v4.7.2 everything compiles and works in read mode, but not write. I still think you may have something about the dongle drivers etc. I think it's worth getting a second BLE dongle and re-try.
Thank you for all your efforts. It must be a nightmare trying to juggle so many OS versions and hardware revisions.
FYI When we spoke about this during the Kickstarter funding, I did ask about doing this as a bridge to get the Pucks into an IoT system that is web connected. node-red does a good job at bridging this technology, but you also recommended backing the new Onion project, which I did. I expect my Onion to be in Spain next week, so am intrigued to know if EspruinoHub will work for the Onion also.
-
Hi @Gordon,
The new build for the Rp2 I have, reports:Error Connecting: Error: Command Disallowed
The Rp3 build using exactly the same OS and versions of node etc, does not return an error as it does connect OK, but is still very flakey.
The scan stopped and scan started messages are displayed as you hinted to, but it will possibly work once on first launch, but after a few unsuccessful attempt to write, it exits due to no scan results:
Scanning stopped.
disconnected!
Scanning started.
Scanning started.
Scanning stopped.
Scanning stopped.
Scanning stopped.
Scanning stopped.
Timed out getting services. Disconnecting.
Scanning started.
BLE broken? No advertising packets in 10 seconds - restarting!BTW, was this update intended to help fix the RP2 disconnection thread
http://forum.espruino.com/conversations/297940/ or this thread? -
The dongle is a Trust 18187 bluetooth 4 dongle.
I have now duplicated a working install flow for the Pi3 and Pi2 that throws virtually no errors and installs more up to date versions of node and npm and node-red.
The first thing I did is NOT use the Raspian Lite build. Instead I installed Raspian Jessie full version to the sd card and proceeded with the following steps:
node-red-stop
sudo apt-get remove nodered
sudo apt-get remove nodejs nodejs-legacy
sudo apt-get remove npm # if you installed npmcurl -sL https://deb.nodesource.com/setup_4.x | sudo bash -
sudo apt-get install -y build-essential python-rpi.gpio nodejsnode -v
v4.7.2npm -v
2.15.11sudo npm -g install npm node-gyp
npm -v
4.0.5sudo npm cache clean
sudo npm install -g --unsafe-perm node-redsudo apt-get install mosquitto mosquitto-clients
sudo apt-get install bluetooth libbluetooth-dev libudev-devgit clone https://github.com/espruino/EspruinoHub
cd EspruinoHub
npm install
sudo setcap cap_net_raw+eip $(eval readlink -f `which node`)
./start.shTo get node-red running from the command line:
node-red-pi --max-old-space-size=128
Both Pi's ran and could see all the devices, but the Pi2 could not write any data.
I will now try another bluetooth dongle to see if that is the problem. -
-
Hi Gordon,
I have built a new Pi3 installation with node at 4.7.2 and npm at 4.0.5 and tried both versions of EspruinoHub on github, yours and @dklinkman and tested on two Pucks, one at 1.9 and the other the latest beta from yesterday and I still get time out errors:MQTT>/ble/write/c6:62:41:ed:7f:9a/nus/nus_tx => "LED1.set();\n" Service 6e400001b5a3f393e0a9e50e24dcca9e Characteristic 6e400002b5a3f393e0a9e50e24dcca9e <Connect> Connected. Getting Services... Scanning restarted... Scanning restarted... Scanning restarted... <Connect> Timed out getting services. Disconnecting. BLE broken? No advertising packets in 10 seconds - restarting!
Sometimes it connects, but mostly it fails. I am running out of things to try. Is there any debug info available to get to the bottom of this?
-
-
-
-
I am working on this now @gordon.
I wanted the lite version to enable max disk space for data logging. The only missing package was git on the lite Raspian build. It was included on the full version, which also includes node-red and nodejs installed.I am trying to work out exactly what the right sequence is for getting a Pi working correctly and it is proving to be a challenge.
The problem I am having now is that the EspruinoHub builds and runs but any write attempt to a Puck produces a connection error:
MQTT>/ble/write/c6:62:41:ed:7f:9a/nus/nus_tx => "LED1.set();\n" Service 6e400001b5a3f393e0a9e50e24dcca9e Characteristic 6e400002b5a3f393e0a9e50e24dcca9e <Connect> Error Connecting MQTT>/ble/write/c6:62:41:ed:7f:9a/nus/nus_tx => "LED1.set();\n" Service 6e400001b5a3f393e0a9e50e24dcca9e Characteristic 6e400002b5a3f393e0a9e50e24dcca9e <Connect> Error Connecting Mon Jan 09 2017 19:56:22 GMT+0100 (CET) 0d:25:f9:7c:fc:bd - ? (RSSI -90) 51:48:02:6a:53:7f - ? (RSSI -57) 63:ca:e3:eb:70:13 - ? (RSSI -68) 6c:44:6f:bd:c8:68 - ? (RSSI -90) 77:e3:27:ba:50:5e - ? (RSSI -65) 7a:db:3d:87:00:b6 - ? (RSSI -77) b4:18:d1:ea:c6:9c - ? (RSSI -59) b8:27:eb:09:dd:d5 - EspruinoHub (RSSI -81) b8:e8:56:34:55:03 - ? (RSSI -92) c6:62:41:ed:7f:9a - Puck.js 7f9a (RSSI -77) c8:69:cd:5f:da:d4 - ? (RSSI -87) f2:0f:7b:b3:b2:70 - Puck (RSSI -89) 1809 => {"temp":4} 180f => {"battery":100} 2a00 => {"type":"Buffer","data":[80,117,99,107,78,97,109,101]} fd:f9:15:7f:43:07 - Puck.js 4307 (RSSI -85) 2a00 => {"type":"Buffer","data":[3]}
I am not completely happy with nodejs at version 0.10.12 and have just managed to find a way to upgrade it to 7.4 on the Pi, but I have yet to build the rest of the packages based on this version.
Everything was retrospectively patched just to get the EspruinoHub compiled without errors.
I need to find a workflow that builds everything correctly and it's taking multiple attempts to work this out.I will report back when I have an update.
-
Following on from some online searching I decided to upgrade node from 0.10.12 to the latest version using the following commands:
npm cache clean -f
npm install -g n
n stableAfter a re-compile it all worked!
I was under the understanding that the latest version of npm would not work on the Pi and is why you enter:sudo npm -g install npm node-gyp
I think this is where node goes down to 0.10??
Anyway, the package complied with lot's of depreciated warnings but now runs.
I will now try to re-produce the install without ending up with node at 0.10.nn. This may also be the root cause of the other problems I have with EspruinoHub crashing when connecting to a Puck. -
Yes, I did what most guidelines recommend and that is to apt-get update / upgrade etc.
So the sequence as far as I remember I tried twice was:
1) Download latest minimal Raspberry jessie, followed by apt-get update and apt-get upgrade.
For the node, nodered, npm, mosquitto and bluetooth installs I did each stage one at a time and followed any recommendations to run apt-get autoremove.
Each stage was straight forward with one or two warnings all the way except for EspruinoHub.
Prior to git cloning, I needed to run apt-get install git as it was not included on the jessie image.
The rest of the problems appeared following the node install of EspruinoHub.
The fact that it was exactly the same on two clean attempts made me think it could be the hardware platform was out of step. It uses a third party bluetooth USB dongle, but the OS was happy with the dongle in the full graphics install of Raspbian as I could see the Pucks in the list of devices to pair to.
If anyone else has any clues or needs a fuller description of what I did, I have included the entire install log in this response. Perhaps it will give some clues as to where I have gone wrong.
-
I have a Raspberry Pi 3 and 2 and have successfully installed the EspruinoHub software on the Pi 3, but am having real problems in compiling the code on the Pi2. The following is an extract of the install and errors following the compile. Any help to diagnose why it is failing to compile would be very gratefullly received.
Thank you.
pi@raspberrypi2:~/EspruinoHub $ npm install npm WARN npm npm does not support Node.js v0.10.29 npm WARN npm You should probably upgrade to a newer version of node as we npm WARN npm can't make any promises that npm will work with this version. npm WARN npm You can find the latest version at https://nodejs.org/ > usb@1.2.0 install /home/pi/EspruinoHub/node_modules/usb > node-pre-gyp install --fallback-to-build node-pre-gyp ERR! Tried to download: https://github.com/tessel/node-usb/releases/download/1.2.0/usb_bindings-v1.2.0-node-v11-linux-arm.tar.gz node-pre-gyp ERR! Pre-built binaries not found for usb@1.2.0 and node@0.10.29 (node-v11 ABI) (falling back to source compile with node-gyp) make: Entering directory '/home/pi/EspruinoHub/node_modules/usb/build' CC(target) Release/obj.target/libusb/libusb/libusb/core.o --- Snip --- npm WARN optional SKIPPING OPTIONAL DEPENDENCY: xpc-connection@~0.1.4 (node_modules/bleno/node_modules/xpc-connection): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for xpc-connection@0.1.4: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"}) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: xpc-connection@~0.1.4 (node_modules/noble/node_modules/xpc-connection): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for xpc-connection@0.1.4: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"arm"}) npm WARN EspruinoHub@0.0.0 No repository field. npm WARN EspruinoHub@0.0.0 license should be a valid SPDX license expression pi@raspberrypi2:~/EspruinoHub $ pi@raspberrypi2:~/EspruinoHub $ cd .. pi@raspberrypi2:~ $ node -v v0.10.29 pi@raspberrypi2:~ $ sudo setcap cap_net_raw+eip $(eval readlink -f `which node`) pi@raspberrypi2:~ $ pi@raspberrypi2:~ $ pi@raspberrypi2:~ $ cd EspruinoHub/ pi@raspberrypi2:~/EspruinoHub $ ./start.sh setterm: terminal xterm-256color does not support --blank /home/pi/EspruinoHub/node_modules/mqtt/lib/connect/index.js:100 const isSecure = ['mqtts', 'wss'].indexOf(opts.protocol) !== -1 ^^^^^ SyntaxError: Use of const in strict mode. at Module._compile (module.js:439:25) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Module.require (module.js:364:17) at require (module.js:380:17) at Object.<anonymous> (/home/pi/EspruinoHub/node_modules/mqtt/mqtt.js:12:15) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) pi@raspberrypi2:~/EspruinoHub $
-
Sorry @Spocki I should remember to do this:
http://forum.espruino.com/comments/13394953/
It is part of the thread:
http://forum.espruino.com/conversations/298092/ -
Ok so it's more acid testing and development than actual deployment. It's great that you are taking the time to get to the bottom of the connection behaviours.
I am also a user of the Particle Photon devices that provide me with low power remote solutions over WiFi. For these device's during test I use a 3.7v LiPo battery that gives me hours and hours of use. I wonder if the Puck's will tolerate the 3.7 to 4v of a LiPo? Perhaps a small voltage regulator is required? I see there is a thread about a making a shield/jacket for the Puck. This includes a secondary battery supply. Sounds a good idea to me especially for long testing periods.
-
@dlinkman I am testing the ability to log data from the Puck over long periods and have had great results in using NRF.setAdvertising() in a setInterval() function.
Each time the setInterval() runs (say every 5 seconds) the data that gets advertised is updated. Using node-red to watch these values change allows me to create database entries over time, like temperature, battery level etc.
Had it running for days now and the battery is still at 100%.
Basically no need to connect if you are only reading values.
-
@Ollie I am with you on your comments and suggestions. It seems there is a lot to do to get the Pucks to be useful to the average maker.
Standalone, Puck to Puck and web IDE it appears to be reasonably stable, but right from the beginning of the Kickstarter project I was hoping for some form of bridge to the real world of IoT via the Internet.
I have so far made good progress with node-red despite it's set-up requirements, but it is still in it's early stages of Puck development / integration. However I have every confidence that these glitches will be ironed out. Hopefully @Gordon will be able to contribute soon on this.
As far as I see it, the main sticking point is in the lack of clear beginners guidelines on how we can communicate data from and to the Puck. Most of my time spent has been in trying to simply understand how to send a few bytes of data in the correct GAT standard. @dklinkman has some interesting posts on data formatting etc and worth checking out.
I was wondering if it would be possible to start a Puck related "How To" guide for sending / broadcasting data using the correct data types and standards? Probably something that should be set up a bit like the Bluetooth SIG has for industry standard communications, but in more friendly to read way.
All this being said, I think the Puck is a great project and will / is becoming an integral part of my currently growing IoT home.
-
-
Just to add a little more info to this thread.
I have a new Pi 3, and installed all the node-red and EspruinoHub software as documented to the latest minimal install of Raspbian jessie.Everything appears to work as expected as far as monitoring the Pucks, but writing crashes the EspruinoHub almost every time.
I have tested with @dklinkman version and also tried the beta 1.9.12. It appears slightly more stable and I have manage one or two writes to two different Puck's, but 9 times out of 10 it fails and the EspruinoHub restarts.
The error usually get is an out of bounds error, or timed out getting services message.
I have also tried using the HTTP proxy setting for the Pi bluetooth, but this made little or no difference.
Node-red is currently at version 0.15.12
Any help towards fixing this would be very useful if anyone has any further suggestions.
-
Hi Gordon, DrAzzy,
I tried your suggestion to check the if the socket is closed before attempting a request. The results are varied. I can call around 30 requests in a row using a 10 second interval, but eventually the socket remains open and no further requests are possible.
I tried using a local server, my Raspberry Pi to simply echo back a status check and being local the response was very fast but I was unable to request as many calls as using an external website. Strange.
Will continue to test with other parameters.
Thanks for the really helpful comments Gordon.
The strings conversions was principally to overcome floating point numbers from the temperature readings (- minus values) and decimal points in voltage readings, but I guess I should move on and byte convert the values as much of the ble specification is set up as. Most coding is based on a quick and dirty work around. I had to write some code in node-red to convert strings to floats (see the flows attached in my last post) but I actually like the idea of compressing it all into bytes.
I will need to think about priority queuing, but I am sure using a setWatch() function and increment counter as you suggest, I would get a really solid working model. I actually forgot that I had written some code years ago that counted the motion events over time, and only reacted if the value exceed a threshold. This reduced the noise you get when wind occasionally set the PIR detector.
OK, V2 is now under way using an array of bytes with some code to convert values back. At worst I can use one advertising command for motion and a less frequent less important advert for cumulative data.