Viability of Mesh based Smart-Home

argon
xenon
Tags: #<Tag:0x00007f0394a63ad0> #<Tag:0x00007f0394a63850>

#1

This is a thread that was splitt of this thread to avoid deviating from the original topic there.

Hence the “out of order” discusion :wink:

The intended target can be found here


Using Particle Mesh Devices with the OpenThread Border Router
#2

I’ve hit a roadblock, and rather than start over, I’ve been rat-holing around it… I have 4 Xenons on a mesh net, with one of them in the Particle Ethernet shield doing the gateway function. Moving the network to another place works well, if I can get a wired Ethernet with DHCP. BUT, I can’t figure out how to change the gateway to use a static IP/mask/gateway config… And, I haven’t been able to get an Argon on my existing mesh net (I guess it wants to have a unique net-name since it has a gateway function…). So, I don’t have an easy way to use the Ethernet shield when I can’t get DHCP, and use WiFi as a backup when I move my sensor cluster around.

  • I’d love an easy way to ask my Argon for it’s WiFi MAC address (so O can add a label, to make it easy to whitelist on a wifi net with a “Captive Portal”.
  • I hope I can find a way to use VS Code to configure my WiFi credentials as part of flashing my code. (If I can also give the mesh network name, maybe that’s how I can get the Argon on my test net?)
  • I haven’t worked out how to use the web IDE to upload a sketch without blowing away the underlaying mesh-net config… I’m guessing that is a soon-to-come feature? That’s why I’m going through the VS Code learing curve now, but I have yet to successfully get that tool-chain to flash a sketch and keep my mesh config.

When these things fail, I go back to deleting and adding the xenon back to my test network, and iterate…

I did get my Rasp Pi 3B+ for trying OTBR as a mesh-RF packet sniffer, but I am just starting the OTBR config. Still feels like a long way to go…


#3

Welcome to the club! Soon you’ll be able to have a xenon+ethernet gw plus an argon gw in your mesh network. It’s an HA config and you just need to pony up a little dough for the subscription fee. :roll_eyes:

Looks like there a growing set of hobbyists that want to set their mesh nodes free from the limitations of the particle cloud and non-functioning pricing…

Do you want to communicate from mesh nodes to the particle cloud or more general internet connections? I.e., do you want to use the particle cloud communication stuff or do you expect to use it because you’re more or less forced to?


#4

How easy? Have you tried WiFi.macAddress() or in Listening Mode sending m to the device?
Both should hand you back the MAC address.

There are some options again

  • via code WiFi.setCredentials()
  • via the VS Code Terminal and Listening and sending w
  • via VS Code Terminal and CLI particel serial wifi

Not sure how to not keep the mesh assignment :confused:


As for pricing:
Particle is just starting the journey into mesh products and hence had/has to assume some things about expected utilisation and revenue.
As it was with Gen1&2 devices, the pricing had to undergo several iterations once the assumtions where replaced with real life experience.
I’d not be surprised to see the same thing happen once Gen3 gets traction with product creators and prosumers.

My personal take on it is that Particle very much values the contributions of hobbyists but they are not the clientele that keeps the business running but needs high revenue product creators on whose shoulders the hobbyist support can rest and strive.
Currently only Gen2 products are actively supporting the Gen1, 2 & 3 hobbyist engagement of Particle but once Gen3 takes off and revenue from there startes coming in Particle can maybe re-think the pricing based on hard figures.


#5

My ideal project is smart-home like, with devices around the house perfoming some fairly basic tasks. But, rather than just being bespoke processors per-room, I want them to communicate a hub in the building, with a bit more capability to log all the data, track thresholds on some sensors, then make some decisions and send data back to those devices, and has a local display/console. At some point, I might want to share some selected small subset of the data to the web, but I don’t want this functionality to depend on data going to the cloud, and another site (IFTTT, MQTT, etc.) to do that logging/deciding/communicating, just to transit home again for displaying. (How reliable is your ISP at home? What happens in a storm, or a local power outage? Battery-backed nodes could keep doing what they do.

With the announcement of the Mesh devices, I stopped thinking about trying to use NRF24L01+ boards for the node-to-node communications. Now, I thought, nodes could local.publish data, other nodes could react on their own. Additional functions came to mind. I’d have more CPU speed and RAM than originally planned. I made my pre-order, and then I upped the order after the Spectra 2018 conference. I waited anxiously.

Now I’m here, sharing my notes, and looking for clues from others, thryng to make this dream come true. While I think this functionality may be interesting to many folks, I don’t think I have the breadth to make this a product (making it more flexible, and easy-to-use for the non-technical homeowners), but there’s enough upside for me to keep at it, as long as the puzzles appear to be interesting, and solvable at some point.

@tve; I don’t need H/A, per se. But while developing, I may be at home where I can use wired ethernet easily, or I may take a tub of project hardware to Hacker Dojo to brainstorm around others (but where wifi is the only access… either via whitelist, or using a Captive-Portal interface). It’s a shame to lose that flexibility, but that may be the only choice in the short term to allow mobility of my testbed. (I don’t know how easy it will be to use my Argon with two different SSIDs without needing to re-install it… Photons did this well, I hope the legacy code is there.)

@ScruffR; I’ve tried using the web IDE to load basic example code (like Blink…), but when I upload it to my RC.27 Xenons, they blink, but go into no-network blinking green as well… I have to reflash the basic code to restor the Xenon to see the network, but then Blink is gone. That’s why I’m struggling to learn the VS Code tool, to find out how to add the Marco Polo code to Blink, and discover how to flash my boards from VS Code…

Is my application too far afield for what the Mesh devices can do? Am I trying to do something that the code can’t do yet? (If so, is it a “future feature” or “not on the roadmap”? You probably don’t know, but maybe someone (@rickkas7?) can offer a clue?)

 Best regards.  Hacking begins - NOW!

#6

That is possible via Mesh.publish() and Mesh.subscribe().

As is currently stands, the moment you add a second devices that can be a gateway your mesh is considered a HA mesh whether you need the fallback feature or not.

Yes that is possible and the docs even state that the Argon can store twice as many alternative SSIDs than the Photon.
However, since WiFi stability isn’t up to Particle’s standards yet, you may experience bumps that are expected to be ironed out in the next few RCs

Can you try uploading the new firmware via USB? You can download the binary from Web IDE and then flash that via CLI.
Although I so far had little issues updating my Xenons OTA the sub-par WiFi stability of Argons may well contribute to the issues you’re seeing.

The main concern for me would be the max distance between nodes inside. Other than that I can’t see too many obstacles to achieve what you want - once the stability and feature set has settled at a viable level.

BTW, in your original post you talked about road blocks with regards to obtaining the MAC address of your Argon and some other issues. Did you look into my suggestions?


#7

@ScruffR, Thanks for forking the thread. I hope this can get a bit more visibility. Thank you for all the assorted clues. I understand that you’re not a Particle person, but you seem to have significant experience with the various hardware over time. Thank you for being an active part of the forums.

I had tried the “M” with a terminal program on USB to no avail… but I missed that the device must be in Listening mode for that. I’ll try that up next.

I’d seen the OS API reference once, but then lost the link and kept winding up in the Tutorial section. I’ve spent a couple hours in the API section, and some of the references I’ve seen in the comments are making more sense.

If I set up a basic blink in the Web IDE, there is no START OpenThread, no setting the Ethernet detection, none of the other things referenced in the Hello World thread (and the file @rocksetta posted to his code seems to be missing, so I don’t have the code as a reference, just the discussions). But I’m inferring from the discussions that I need to add that extra mesh-stuff to my basic blink, in order to have it blink, and still breathe cyan. I’m wondering if I should just try to set up a sketch for two xenons, each with a switch and an LED, and mesh-publish the switch state, and the LED would be mesh-subscribed to the switch state… but there is more learning to try it, more complexity to fail end-to-end… maybe just a basic sketch to read a switch, and serial.pring the switch state with a delay… A simple Loop, but having the serial would help me a LOT towards testing and debugging.

It’s not so much that I want a copy-n-paste solution, but this is sufficiently different from what I’ve done with other hardware platforms that I’m a Noob on Particle Mesh… It’s hard for us to find the basic answers on the web. Searching the forums works if you have a good idea of the keywords you need. Reading anything you find helps you find keywords, then you need to find a command reference to decide if those are helpful. Essentially, you need to build a fairly good knowledge base before you can become proficient at finding the basic things. :-/

I can’t find a good Hackster (or Particle) project showing the useful code clues. When I can finally figure it out, I’ll try to write one. I’ve set up a Wiki while I’m learning, which is getting broader every weekend, but it’s still not something that can be considered a guide for a Noob. :frowning: But, if I cannot find a good guide, then there is a need for a good guide, and I’ll write it when I can get enough clues. :slight_smile:


#8

@ScruffR, regarding uplaoding sketches “blowing away” the mesh network… Let me describe the symptoms, maybe they will light a light bulb for you, and you can use that liht to show me a better way. :wink:

I start by flashing a xenon using the steps you outlined oh-so-well (DFU mode, rc.27 code and tinker, then Listening mode, bootloader), and my board starts to breathe cyan again… I can see the board again in the Particle cloud.

In the web IDE, I select the “Blink-an-led” sketch. It includes the beakn library. I used this originally on Photons. I upload that, and it blinks, but the RGB LED does a fast grean blink, and the Particle dashboard no longer can communicate with that Xenon…

I thought a Blink would be pretty low-hanging fruit, to make sure I can layer a sketch on top of the mesh network, and then start adding particle.publish-type stuff, and then try mesh.publish and subscribe… This is why I’m stymied. Maybe it’s my expectations that need adjustments? :slight_smile:


#9

Some Success! After a full re-flash of my Xenon #3 (DFU & Listening modes), I still had to re-add my device back (scan the data matrix, cooperating deice…) and go it back on the cloud. Next I spent time in the Web IDE (https://build.particle.io/) and the API (https://docs.particle.io/reference/device-os/firmware/xenon/), and many iterations of verifying the code to get syntaxes right. (I think we’re still on rc.27…)

In the code below, it’s a UNIXtime-like string of digits, but it changes every second, which is what I wanted to see. It validated that I can use serial.print (and I’m happy to see that we have printf as well without adding a library!), and now I can work on adding a few analog and i2c sensors. When I can see sensor data on serial.print, I’ll try onverting the time, and then particle.publish and mesh.publish…

So, without any mesh-related things in my sketch, I now have a working test sketch that I can use on my Xenons as a baseline. On to some iterations! :slight_smile: Thanks @ScruffR, @rocksetta, @tve and others for the breadcrumbs you’ve left here on the forums. :slight_smile:

uint16_t currentTime = 0;
uint16_t resetTime = 0;

void setup() {
  Serial.begin(9600);   // open serial over USB
  // On Windows it will be necessary to implement the following line:
  // Make sure your Serial Terminal app is closed before powering your device
  // Now open your Serial Terminal!
  while(!Serial.isConnected()) Particle.process();

  //Serial1.begin(9600);  // open serial over TX and RX pins

  Serial.println("Hello Computer");
  //Serial1.println("Hello Serial 1");
  
  waitUntil(Particle.connected);

  while (resetTime < 1514764800 && millis() < 20000);
    {
        resetTime = Time.now();
        delay(10);
    } 
}

void loop() {
float voltage = analogRead(BATT) * 0.0011224;
Serial.print("Batt Volts: "); Serial.println(voltage);
currentTime = Time.now();
Serial.print("Time started: "); Serial.println(currentTime);
delay(1000);
}

#10

As the pricing structure currently stands, you cannot have whole home automation using mesh, it just isn’t reasonably priced. I do feel like they were somewhat condescending for home users in their article to explain the reason for price structure and question how we would even use numerous nodes, I can easily think of 100+ that I was going to use in my house alone.

Personally I think they’re being short sighted in their price structure and are crippling the large growth that’s possible for them in the home automation sector. But hey, to each their own and they’re following the direction that they feel is best for them. No problem with that, but I’m having to adjust course due to that and will be sticking with Particle strictly as a proof of concept unless things change in the meantime.


#11

This should only ever be necessary once to update to a new device OS version. After that, Safe Mode should be the way out of any deadend you may find yourself in.
I’d have to test, but my feeling is that the delay() calls in the BlinkAnLED sample causes the trouble with your mesh devices - our common take on such issues is “don’t use delay, but a non-blocking approach” (e.g. millis() timing).

If you want a test setup for mesh, you can use @ninjatill’s Marco-Polo-Heartbeat.