Search results for:

Video of mesh with two lamps (I took the third lamp out of the network to try to get more old-school BLE to work).

https://youtu.be/exl_n-F5o-s

By the way, my two Thingy:52 devices are now paper weights because the batteries no longer charge. They are three-wire batteries and I don't want to spend over $10 each to replace them. I have five pucks that are not being used that I am trying to make work with my Sengled BT lamps.

At this point I am nearly ready to throw in the towel and just create an nRF Mesh with the Sengled lamps. Easy, done.

Then use the nRF DKs to burn a Bluetooth Mesh Lamp Switch sample to the DK. Easy, Done.

Used the DK and SWD interface to send that same program with a new board style to the Feather. Easy, Done.

And..... throw the puck.js devices back into the junk drawer?

They are such nice hardware devices but I just can not figure out how to get them to do what I want then to do. Just turn the darn lamps on and off.

Productizing for the mass market takes a lot of engineering.

On my Sengled lamps, I can use their app to connect to the lamps and turn them off and on, easy peasy.

But... the Sengled app does not give me any engineering data such as device addresses or attribute stuff.

I can delete the lamps from the Sengled app and use nRF Connect to see what that can find...

@Gordon , this conversation and other jig discussions seem very old. I have a SWD breakout board from Adafruit https://www.adafruit.com/product/2743 and only want to program a couple of boards from the nrf52-DK. I have already done similar with other boards such as the https://www.adafruit.com/product/4062 .

The lab bench stuff works fine with the Feather but I would like to use some of these unused Pucks I have lying around.

I'd even be OK now with having someone else help me hold some wires against the SWIO and SWCLK flat pads on the puck.

Do you know what pins I would need to connect (manually or via jig) to program from the DK?

SWIO/SWCLK
GndDet / Gnd / Vref

?

Thanks for any help. This type of stuff tends to sit around for years until I get back to some need. I just want a puck to turn on some Bluetooth Mesh Lights.

I used nRF Mesh on my phone to create a mesh of the lamps and programmed my DKs and Feathers to be a mesh light switch. That works.

I read that I should be able to find the regular gatt attributes/characteristics and bang away at that directly from a simple puck.js program but I could never diagnose what the attributes and values were in my Sengled Lamps. My tech terms could be off.

It really shouldn't be this hard but hacking is such as it is.

The models that I am reading about is best visualized by the smart light example.

In that scenario, the lights have unlimited power and form the backbone of the mesh but there are BLE devices that are low power and wake only when programmed. In the lights model they often use the switches as the battery powered BLE activator of lighting control messages.

The Mesh model has a concept of "Friend" nodes where the friend node acts like a queue for their respective registered BLE friends. When the BLE wakes, the friend gives it all of its queued messages. With security being a big part of the Mesh specs, there are keys required to participate. BLE devices have all of their messages queued by their friend and if there is a key change they get their queued key messages and can still participate.

In my Puck model, I would have several (depending on the area desired to cover) powered nodes. They could be anything from small dev boards to smart lights. They would form the backbone of the mesh.

The pucks would then wake only when programmed and grabbed their queued messages (actions, mgmt or security messages)

This whole concept has now become a learning exercise for me. I bought a few Mesh devices to start my experimentation and will then take one of my four pucks and try to reflash it be a Mesh device. Worst case, I ruin one puck. Best case is that I learn a lot about Mesh :)

edit - yes, there are proxy nodes that can let standard devices participate in the Mesh. I just haven't gotten to that part yet.

Following up on the last part of the above post...

The Puck.js product seems to be the marriage of excellent hardware design && the Espruino javascript interpreter that is flashed onto the hardware. The combo gives the great solution that we have all been enjoying.

In order to move to the BT Mesh tinkering it seems that one would need to take the puck hardware and flash a totally new firmware to it using the Zephyr ecosystem tools. The Nordic chipset seems like it would be compatible.

Not sure I want to go there now but I will continue looking into it.

My goal was to learn more about BT Mesh while gaining the extra range of puck coverage.

I think my range was limited by the possible low antenna performance of the pi-zero-w computer that was hosting the BT/MQTT Hub service.

From what I have learned so far about BT Mesh is that all of the devices in the mesh need to be playing along with the new mesh protocols. It is not a transparent extension mechanism for devices.

This means that in order for the puck to become part of the mesh network it has to use the mesh protocols.

Getting this thread started in case there are others out there interested in this.

I'll post my progress here and hope that others want to play along.

Thanks, I'll look into the process for using a dongle BT receiver on the Pi-Z-W.

Adding that would probably be the quickest and most effective solution in my specific case. Doing a mesh type model might be a good theoretical exercise for me to learn more but to get running quickly the antenna is probably easiest.

I think I am right on the edge. When I tried the same system model using a Pi-4 (more capacity than needed for this simple scenario) it seemed to perform a bit better. Maybe the Pi-4 internal antenna is just different enough from the Pi-Z to give me that little extra margin I needed.

Then again, a Pi-z with antenna might be equal in price to a Pi-4. Hmmm. I'll test with the 4 again to see how often that one is out of range.

Thanks, I'll get back this later and report out on my findings.

FYI - to determine if both the system and my Mom are OK, I look at things like

1. Temperature of the puck (higher when she is wearing it as opposed to lying on the counter top)
   
2. Motion, obviously
   
3. RSSI changes as she is in one room versus the other
   
4. Presence, obviously
   

It is the "Present" flag that concerns me. What if she falls in the far area of the kitchen where I know there is a dead spot. No horrible pun intended :)

I should move the RSSI under the Presence so make them easy to compare.

I'm using the Espruino Hub to (Puck <--> MQTT) and Node-Red quite nicely.

The problem I am having is that the Pi-Zero-W (or the puck itself) goes out of range pretty quickly.

Has anyone thought about a type of repeater hub that can repeat BT messages across the network as MQTT but some how deduplicate if the same messsage is received on both the hub and repeater?

My Mom is using it as an alert device so that we children can get a SMS whenever she presses the button. It works really well except when she is farther away from the pi-z-hub.

Any advice or pointers would be greatly appreciated.

Re:
Advertising

Data that is received via bluetooth advertising will be relayed over
MQTT in the following format:

/ble/presence/DEVICE - 1 or 0 depending on whether device has been seen or not
/ble/advertise/DEVICE - JSON for device's broadcast name, rssi and manufacturer-specific data (if mqtt_advertise=true in config.json -the default)
/ble/advertise/DEVICE/manufacturer/COMPANY - Manufacturer-specific data (without leading company code) encoded in base16. To decode use var data = Buffer.from(msg.payload, 'hex'); (if mqtt_advertise_manufacturer_data=true in config.json - the default)
/ble/advertise/DEVICE/rssi - Device signal strength
/ble/advertise/DEVICE/SERVICE - Raw service data (as a JSON Array of bytes) (if mqtt_advertise_service_data=true in config.json)
/ble/advertise/DEVICE/PRETTY or /ble/PRETTY/DEVICE - Decoded service data based on the decoding in attributes.js
    1809 decodes to temp (Temperature in C)
    180f decodes to battery
    feaa decodes to url (Eddystone)
    2a6d decodes to pressure (Pressure in pa)
    2a6e decodes to temp (Temperature in C)
    2a6f decodes to humidity (Humidity in %)
    ffff decodes to data (This is not a standard - however it's useful for debugging or quick tests)
/ble/json/DEVICE/UUID - Decoded service data (as above) as JSON, eg /ble/json/DEVICE/1809 => {"temp":16.5} (if mqtt_format_json=true in config.json - the default)
/ble/advertise/DEVICE/espruino - If manufacturer data is broadcast Espruino's manufacturer ID 0x0590 and it is valid JSON, it is rebroadcast. If an object like {"a":1,"b":2} is sent,
/ble/advertise/DEVICE/a and /ble/advertise/DEVICE/b will also be sent. (A JSON5 parser is used, so the more compact {a:1,b:2} is also valid).

I have multiple devices and would like to register for messages from any of them. Sometimes I take one to my Mom's house where one is in use for her to have a panic button that sends me an SMS when she presses it. I have a lab setup at home here. I have another one etc etc.

Rather than having to change the ID for each environment it would be nice to register for any messages coming from manufacturer ID == x.

Is it correct that that isn't available using the current broadcasting/registration model?

p.s. I have done both a) most of the logic/programming/timers in the puck.js code and b) the logic/program/timers in Node-Red.

This code version is where nearly all of the logic is one in Node-Red.

can make a new thread if it gets meaty. Pros/cons?

This seems pretty basic.

If I save a "program" to flash, will it execute again to reload the functions and watches if the battery is changed?

Thanks

var presses = 0;
clearWatch();
clearTimeout();
clearInterval();

flashingLedInterval=0;

setWatch(function() {
  presses++;
  console.log("Pressed");
  NRF.setAdvertising({
    0x1811 : [presses],
    0x180F : [E.getBattery()],
    0x1809 : [Math.round(E.getTemperature())]
  });
}, BTN, { edge:"rising", repeat:true, debounce:25 });


// Interval to update advertising values
setInterval(function() {
  NRF.setAdvertising({
    0x1811 : [presses],
    0x180F : [E.getBattery()],
    0x1809 : [Math.round(E.getTemperature())]
  });
}, 30000);    // 30 sec

function startFlashing(pin, period) {
  var on = false;
  flashingLedInterval = setInterval(function() {
    on = !on;
    digitalWrite(pin, on);
  }, period);
}

function stopFlashing(pin) {
  clearInterval(flashingLedInterval);
  digitalWrite(pin, off);
}

Awesome, that worked. Both fixes.

I can't tell you how much I appreciate this help.

I think I did the appropriate amount of trying/learning/failing on my own but started running out of things to try.

I had much of this working a while back but am starting a new project from scratch.

To start back at step 0, I am just trying to advertise a couple of puck metrics and pick them up in Node-Red.

Here is the puck code...

var presses = 0;
clearWatch();
clearTimeout();
clearInterval();

setWatch(function() {
  presses++;
  console.log("Pressed");
  NRF.setAdvertising({
    manufacturer: 0x0590, 
    0x1811 : [presses],
    0x180F : [E.getBattery()],
    0x1809 : [Math.round(E.getTemperature())]
  });
}, BTN, { edge:"rising", repeat:true, debounce:25 });


// Interval to update advertising values
setInterval(function() {
  NRF.setAdvertising({
    manufacturer: 0x0590, 
    0x1811 : [presses],
    0x180F : [E.getBattery()-1],
    0x1809 : [Math.round(E.getTemperature())]
  });
}, 30000);    // 30 sec

On the pi node-red flow I have very simple mqtt receivers and debug statements.

The battery and temp are coming through just fine but I cannot get the presses 0x1811 to work.

At first I subscribed to /ble/advertise/e9:1d:0b:37:51:d3/1811 which was not working.

Then I read more closely in the instructions which said

/ble/advertise/DEVICE/SERVICE - Raw service data (as a JSON Array of
bytes) (if mqtt_advertise_service_data=true in config.json)

So maybe my config.json had that turned off, which it did. I also saw in the config the ability to name services so I tried to put a name to 0x1811 but might be doing that wrong.

I set these two changes from the default config.json.

.
.
  "// We can add our own custom advertising UUIDs here with names to help decode them":0,
  "advertised_services" : {
    "1811" : {
      "presses" : "level"
    }
  },
.
.
  "// Send /ble/advertise/ad:dr:es:ss/uuid raw service data":0,
  "mqtt_advertise_service_data": true,

I know I am doing something stupid wrong and I used to have this all working fine.

Can anyone spot my error?

Thanks

@Gordon not sure how authoritative this is...

https://randomnerdtutorials.com/upgrade-from-node-red-contrib-ui-to-node-red-dashboard/
Upgrade from Node-RED-Contrib-UI to Node-RED-Dashboard

[NEW GUIDE] Learn how to use Node-RED Dashboard with your Raspberry Pi

If you followed the Build a Home Automation System for $100 course prior to August 27 2016, you know that I’ve used Node-RED-Contrib-UI to build the user interface for the home automation system. But, sadly the guy that developed the Node-RED-Contrib-UI will no longer be able to update that package.

Luckily, the Node-RED team announced that Node-RED-Contribu-UI will continue to be developed under a new name: Node-RED-Dashboard.

By the way, if this is allowed here... if anyone wants to tinker with Twilio it would help us both if you use my referral code. We each get a $10usd credit if you use my link.
http://www.twilio.com/referral/akNa6G

Twilio is cheap for low volume scenarios. It is like $1/mo base plus 1/7 penny per SMS.

I'm working with the dashboards now. What are all of your opinions on the two flavors of Node-Red dashboards. It looks like the node-red-contrib-ui one is being deprecated and going to node-red-dashboard .

The problem I think I see is that it is hard to move back and forth between the two. I am a total rookie but when I built a flow in the older one and tried to switch to the newer one there were a lot of errors even beyond the obvious UI nodes. Not sure.

Anyway, I have moved to the newer dashboard and have two tabs: "Home" for the puck and "Rpi" for the host pi metrics.

I have mirror systems running on a Pi-zero-w and a Pi-4. I was tinkering with the RPi dashboard and the Pi-4 helps me test out the fan control portion of the system that activates on temp>x. My screenshot is on the Pi-4 but the only difference is that on a Pi-zero-w the utilization is greater. Still low on the zero but not that low.

@Gordon , your suggestions for formatting the SMS messages worked really well. Using the Node-Red function block I can change my SMS Alert Messages to be more reader friendly instead of the engineering geek cryptic integer and T/F payload data points.

I super appreciate the help given here. I have enough SW Dev background to know that various things can be done but I didn't know how to get them done in this Espruino / Node-Red environment.

I now have

1. Button Press alerts with a 10 second grace period where the wearer can cancel the pending alert.
   
2. Motion detection with a 1 hour countdown timer. Detected motion will always reset the countdown so that the SMS Lack of Motion alert fires after 1 hour of no motion (only during normal waking hours).
   
3. Battery Level is recorded with all messages
   
4. RSSI can be used to determine if the Espruino has left the building. The 'left the building' state can halt the lack of motion timer. Obviously, if the puck has moved out of range then the motion event can't reset the timer.
   

Well, I am glad I saw your note early. I was building out a modification to Try-4 building out my custom wave pattern when I saw your suggestion.

Your way is MUCH easier :)

I'll figure it out, but it would be helpful to others to have Try 6 example in https://www.espruino.com/Flashing+Lights be a quick blink every x secs type of flash.

Asymmetric setting of the pin. Just a quick-blink to indicate a particular state is engaged. For example, if my Motion-Detection state is detecting motion, I would prefer quick-flash rather than full-on blue.

1100000000110000000011000000001100000000