Issue 1
I have one mesh network that consists of 5 XENONS and 1 BORON. Although I have a XENON labeled XENON 2 it does not show up anywhere in my devices on the IDE or the APP. I had a XENON labeled XENON 6 but I removed it from the mesh, it is no longer powered and has not been for weeks yet that one shows up in the IDE in my list of devices and also on the app. I would imagine XENON 6 is still somewhere floating among the cloud. No telling where XENON 2 is in the cloud even though it is working correctly in my mesh and doing what it should do.
Issue 2
The XENON in my mesh labeled XENON 5 is dropping offline rather frequently. All of the other XENONs are running the exact same firmware and do not exhibit this behavior. I wanted to remove XENON 5 from the mesh and add a brand new one in its place. I guess I have to call that one XENON 7 (see issue 1). I use a watchdog timer on my BORON. From previous experience, I have found that the watchdog interferes with the pairing process. So, I flashed TINKER to my BORON for the pariing process. I get to the point of the setup where I have scanned my BORON and I get an error message that it is on a different mesh network then the XENON I am trying to pair to it. How can that be when I only have ONE mesh network?
Also, is it just me or has anyone else found it frustrating to scan the QR codes on the devices? It takes several tries and getting the camera at a “lucky” angle with just the right amount of light. To date, I have found nothing consistent or easy about pairing mesh devices. It is always a hair pulling hour or so if you manage to complete it.
Thanks for reading and I look forward to your suggestions. I am going to have a shot of whiskey right now.
EDIT
I tried again with the XENON and now when I get to choosing which mesh network to join, it doesn’t find any networks. If I attempt to add the existing BORON to a mesh network and type in the name of my mesh network, it says, “you already own a network by this name, please choose another name”
This from you can’t make it up files.
Before the latest iOS release I was able to solve similar problems by setting up a new network from scratch. Since that February update claiming devices with the app fails, when it requires a sw update. But if you stuck anyway it could be something to try.
Sorry, I meant “Before the latest Particle iOS App release (2.8.2) …”
Before that release setting up a new network via the iOS App, with devices in an existing network worked (in order to change gateway device for a bunch of Argons). Also if a SW update was required during setup. And afterwards not (setup proces stops when the SW update is to begin, with errors on both app and device).
Updating iOS did not make a difference to this issue.
So I am stuck, but it might work for you, as I have not seen anybody else having this issue.
@thrmttnw that’s really interesting to learn that you are unable to claim devices with a mobile app. This is the first time I hear it (i maintain & develop our iOS app), but given how complex the whole mesh setup is on the code side, there’s definitely a chance for that. We will be releasing app update within next couple of weeks, and we will make sure to retest all the flows again. Sorry to hear about your experience. In the future please reach out to our support when such things happen, so engineering learns about these problems as soon as possible.
Also @thrmttnw are you saying that DeviceOS update via mobile app is not working for you? That’s another issue that should be reported to support so we can investigate and fix this. Even though there’s a chance that the problem is mobile app, but this can also happen because you try to upgrade from unsupported deviceOS version, which would require you to update device via CLI. Please don’t hesitate to contact support. People working there are supper friendly
@jackpot, can you please wait longer in “scanning for networks” screen? We are trying to address the issue on DeviceOS side, but usually all networks only appear on 2nd scan. What I mean that when DeviceOS first returns networks seen by device, the list is incomplete. There’s I believe 5 seconds timeout and app requests to rescan networks. The second DeviceOS response usually contains more networks. App only reports that problem when there’s a ID mismatch between network you chose to join, and network stored on device you try to use as commissioner (assisting device). So I only see three options here:
You have more than 1 network (you might not know about it?) and letting joiner device scan longer will reveal them.
Network definition somehow got corrupted and that would be a bug in DeviceOS that requires further investigation
As for QR codes, I noticed that app scans them best if sticker is directly in the middle of the screen. I will make a note to myself to add some visual guide to help determine that best spot on the screen :). In dark environments scanning is somewhat more challenging. Also old apple devices struggle more with scanning (i’m looking at you iphone 5). Last but not least, some specific matrices (I think that depends on the pattern around corners of the matrix) are damaged more easily than the others. For some of my devices that are “worn” the most, I ended up recreating the matrices and storing those images on my computer desktop. I think if you reach out to our support, they will assist you with generating new matrices to see if that helps solving the scanning issue.
I am confused about “wait longer”. I was not aware there is an option for me to control the scan time? Perhaps you address that in your description to scan a second time? I promise you, I scanned several times same result.
I do have more then one network now. At the time I only had one. I also had followed the RESET procedure to clear the setup flag and got the same result. I now have 2 networks, one of which I am using. Mysteriously, one of the networks created in my attempts to resolve has disappeared. AFAIK there is no way to presently delete a network by the user. Where it went and how is something you can perhaps figure out by viewing logs unavailable to me.
I am glad to hear that you are upgrading the scan feature to make it easier. Something to note, I have also had difficulty scanning in bright light. Seems the light and angle are hypersensitive in my experience. This is of significance because I use a watchdog and the time available to scan and add a new device is directly related to my watchdog. I have had to comment it out or lengthen the time to allow for pairing to occur. Also for the record, while I did have an iPhone 5 many years ago, I have been using a X for about the last 6 months and a 6 in between the two. But all of my mesh experience has been with the X.
To sum it up, what I ended up having to do was RESET all devices in my mesh (clear setup flags). Start them in SAFE mode, flash TINKER to them and then build the mesh all over again using a new network. If you look at my account you will see 2 networks. One shows 2 Xenon’s and 0 gateways but if you drill down there are no devices listed. The other correctly shows 6 devices total with 5 Xenon’s and 1 gateway. The third network as previously noted is lost in cyber space.
Thanks for your reply I look forward to your reply
What I mean is just leave app in scanning view. In that screen you only see networks that are within reach for device you are paired with. What this means is that if you power off every device you have but the one you are trying to setup, nothing will appear on that list (even if you have X networks seen in the console). The re-scan is triggered automatically every few seconds (just like iphone keeps refreshing wifi list in settings and sometimes it takes a while for a desired wifi to appear). So if you are in the screen of mesh networks, you can see activity indicator starts spinning again ~5 seconds after list is rendered. It will keep updating the list every 5 or so seconds.
Thank you for letting me know this isn’t clear. We’ve been seeing those screens for almost 10 months now… everything is super clear to us and even though we try to do user testing, some of these UX things are missed. I will try to promote to make changes to this screen to provide more info about what is happening.
As you have noted, you cannot destroy networks in console. Networks are destroyed on backend when there are no devices left on the network. Simply reseting device using RESET button, doesn’t remove it from the network. It resets network credentials on device only, but cloud is unaware of that. To get it deleted on the backend you have to do one of the following:
If device still has network info on it (meaning it wasn’t reset using hardware buttons), you can start the setup flow (using mobile app) and when prompted to leave network just confirm the acction.
If device was reset using hardware buttons, the fastest way to remove it from the network on cloud would be to start setup flow on mobile for that device and when prompted, select to join existing network. We always remove device from the cloud before we attempt to join different network. For devices that have network info on them we prompt the user for confirmation. For devices that don’t have network info on them (that were reset using hardware buttons) we remove them from any existing networks silently.
Hope this explains some of the concepts that are not intuitive.
Noted thanks for the reply I’ll give it a go next time I have the issue-hopefully never. It is a lengthy process and nothing has been consistent to this point. Lots of hair pulling. That is not to say I don’t understand the difficulty of reinventing the wheel so to speak.
I’ll reoky here with further issues to keep you informed and thanks for your patience with my frustration.
I would further recommend the team looks in to watchdog issue within mesh. It has caused considerable problems in my experience. I am not at my PC but there other posts with issues involving watchdog problems.
Thanks @jackpot. This is way beyond something I can dig into (i’m a mobile engineer), but I will post this to our internal slack so that our support is aware of these problems (if they aren’t by now :)). I’ve heard engineering discussion about issues causing devices to disconnect (and start blinking green) and I know that these are addressed with every DeviceOS update, but that’s unfortunately as much as i know.
Yes, the forced device OS update during the claiming proces is not working. The devices have only been OS updated via the iOS App (forced), when setting up a mesh network with fresh devices, changing Mesh gateway for a network by setting up a new network, or in a few instances via the WebIDE. So should be compatible.
Okay, thanks. Please consider making Device OS update during claiming a device via the iOS App strongly recommended not forced.
A few of many reasons for this: This way users can get on with their projects in parallel with the debugging proces with particle.io. When debugging an issue, forced changes to the configuration is a no-no. Often user apps depend on an older OS release while waiting for a fix in a future release. Etc.
Best with the QR code in the middle yes. Also it seems to work best (or at all) when aligning the display and QR code orientation. If the QR code square is seen at a 10-45 degree angle in the display, it is not working (well) on my iPhone 7+. In other apps using QR code scanning there is a guide drawn on the display.
So here is how I got out of this deadlock in three hours time, if others get in similar situation.
The target for all this was to get the Gateway Boron back in standalone mode without leaving the old network of Xenons behind in a messy mesh, and update all devices from 0.8.0 to 0.9.0.
For the Boron i did particle identify and particle device add via particle cli. Still in the mesh network then. I SW updated the Boron and all Xenons from 0.8.0 to 0.9.0 via web ide.
I could not SW update Xenons with particle CLI in DFU mode (Found no device in DFU mode), despite being able to particle identify in listening mode ?!?
All Xenons and lastly the Boron where then unclaimed, set up with the App until “remove from network” option, then cancelled. Unclaiming then had to be done using the App as WebIDE would not unclaim (“Bummer …”).
I did experience that two of the Xenons could not be SW/Firmware updated with the web IDE in normal mode either. Just after an update failed the device went into panic with SOS 1. Not too different from doing it during setup with the App.
In the end I succeeded in SW updating these two Xenons in safe mode via the Web IDE.
All this also successfully removed that network from the console, phew.
Way too difficult just to get back to start, so Argons go back in the box, no more mesh until Q4? and I can finally spend a bit of time on my projects with Boron and Argon.
