Open Support Ticket Does Not Exist

I am truly dumbfounded and extremely pissed, that you guys have literally removed the ability to create a support ticket from the Particle Website, or buried it so far down, that creating one, is not possible without digging through page after page to find it. I still have not been able to open one.

While this may allow you to run your support team as a skeleton crew, and try to force your customers into your enterprise support system, and save you money, it is BS, and customers who are not aware of this forum, will just dump your product and move to a different controller, if they cant get any support, without having to go to this extent. Especially when your little sales chat bot, is coming up on every single page. All this tells your customer, is that you could care less about the experience, after the sale is over.

It is inexcusable, to offer to provide enterprise level services for additional fees, and not have a simple way, for your developers, or customers, or product creators, to open a simple support ticket in less than 3 clicks from the home page, for an issue that you are effectively creating due to negligence.

Using flow charts, to redirect the user in a circle, only makes this process that much more frustrating too, as it rarely is yielding useful results and often just leads you in a circle until you end up back where you started. Especially when the error I am currently seeing, is due to issues with your backend, either not functioning correctly, or not updating correctly. Issues that have now gone unfixed, since around the time you launched the SparkCore and Electons. Yes, that is how far back this issue has gone.

I have two devices down in the last 24 hrs, and troubleshooting two entirely different issues, with both of them. The first device, is an issue with a boron, and what I am referring to above. That device, has been working without issues until today. The only thing I did, was to move the device from one product to another, but the device never changed ownership during this time. Then it went to a flashing blue mode, and keeps getting stuck there now. Now also cant flash over USB and must use serial too.

I originally suspected that it was still trying to pickup the wrong firmware from the previous product, which it was and it did, which is a truly massive oversight, in both security and reliability, as it was still attempting to redownload the firmware from a product, that it is no longer attached to, and considering that the device was not changing ownership, this is not only a massive problem, but was also not the first time this has happened to me, while working with Particle’s Backend.

This bug has existed in your backend, for over 10 years now, and its about time you addressed it, as now, instead of dealing with just a down Argon, which started doing a really faint flashing in red last night, and will not reconnect to the cloud now, and which appears to be dead in the water ever since yesterday. Now, I am also dealing with this other issue, for like the 4th time now, and could not even open a support ticket to have you address this directly, and am having to do this in your open forum, which I am extremely pissed about, as this shows, a complete disregard for privacy and security of your customers, and is extremely unprofessional too.

That is not appropriate, and you will never justify making your customers, who are dealing with software bugs which you have failed to address for over a decade now, jump through hoops like this, in order to get a support ticket opened.

I have updated the bootloader and firmware and system partition to 5.2.0. I have removed the device from the product entirely, and have tried flashing Tinker 5.2.0 to the device at least five times. Before when this occurred, an issue with your backend was causing this very same problem for me. It is also not allowing me to flash the device over usb after doing this and requiring i use serial to complete the flash too, but it is not changing anything, and still remains flashing blue after flashing it this way, even when I use tinker. It’s stuck in an update loop because of this problem. This needs to be fixed, now please.

Whatever quarantine you have on your backend that the customer is not able to clear out or see, and I am not talking about when a new device is added to a product, and it gets quarantined for an incorrect firmware version. This issue, creates a problem, every single time I have attempted to move devices between products and even when removing them from products. The function which is executed when you remove a device from a product, may remove it from the product, but unless you update the backend accordingly, this issue will never go away. Every time I have run into this problem, it effectively stalls development on that device entirely for days, if not longer, and this not acceptable, as unless i have another unit standing by Im stuck, because of your inability to triage an issues i have reported at least 3 different times now before today. Even then, i still have to go through this bs every single time.

I understand that moving devices between products is not something which needs to occur often, but you literally have button in console specifically for this, and I get it is necessary to have security in place here, to keep bad actors from trying to pull some stuff, but there should never be this much time and effort required to do something so simple, as it never seems to behave the way it should. Especially, when I own the device and have claimed it already, and never unclaimed it, and just need to move it around like this, there are very few circumstances I can even think of, where this additional obfuscated quarantine layer is necessary, other than for SIM Card payment issues, or of any benefit to the customer, ever, as it is a redundancy, that doesn’t function correctly, and only turns this, into another problem to traverse, which should not exist. The only reason I am not scratching my head on how to fix this, and sinking hours more of my time into this, is because it is the 4th time its happened now.

This also, effectively kills the ability to pull off any type of ownership change, without an email or post like this, making that feature more trouble than it is worth, as well as it feeling like it is deceptive and false advertising too, as this should never be necessary at all, but in very rare circumstances, like a customer doing this to 10 devices in the span of an hour or something along those lines, as that would potentially suggest a potential security concern, but not for a single device change within the same account, and never unclaiming the device. This will also continue to cause problems with product rollouts too.

Please fix whatever issue has been left lingering for this long, which is responsible for this disastrous experience. Please also provide a better quarantine solution, which properly accounts for these kinds of changes, and doesn’t leave my device stuck in limbo or trying to access firmware, it should not be able to access any longer, once the device is removed from the product in the console.

If necessary, in these scenarios, just add a provision to check for this issue, and then to flash tinker instead, and to automatically upload the most recent bootloader and system part too, as leaving it with Tinker in place, and a matching bootloader and system parts, instead of attempting to contact a product it can no longer access the firmware for, or shouldn’t be able to. This is a much better solution, that forcing the device into some kind of quarantine, that the customer or developer, cannot see or access, while not ever reverting the device back to its default state, when it was removed from the product.

As due to how the update process works for products, this will inevitably be solved by the update process, once it gets past this issue, just by rebooting the device once it has been added to a new product, as it will attempt to pickup the default firmware from the new product then, or if the device is not added to a product, the customer can flash their new firmware to the device more easily, as it will be in its default state, with Tinker in place, after being removed from the product. Because that isn’t occurring at all, or is not working correctly, you will often find the device stuck in this state, due to this issue, and spending this much time or more, to get the issues fixed, is not appropriate, for a bug you have not gotten around to, for over a decade now.

This is not a complicated fix, as you just need to tell the backend, that when a device is attempting to connect to a product, which it doesn’t belong to, or has been removed from, but the ownership is still valid and hasn’t changed, then it will either be placed into quarantine so the developer, can deicide how to address it themselves, or if the device was offline when the device was removed from the product, then when it attempts to reconnect to the backend, it should perform a product check, to see if it belongs to another product on the account, and if it does, make the necessary updates to backend settings to account for this, and if it doesn’t, then send it Tinker, along with the most recent version of the System Part and Bootloader. Bam. Done. Fixed.

Otherwise it will either end up trying to load the old firmware from the previous product, which should never be allowed, or if there is not a base firmware attached to the product it was moved to yet, it will have no idea how to handle this scenario, as it is has not been given working instructions for this scenario, and how to handle it, and why you should just send it Tinker in this instance, as at least Tinker, it will allow it reconnect to the cloud correctly, so the update process can take over from there. Also please ensure, that in this scenario, the device also updates the bootloader and system parts too, by ensuring they are the all the same versions as the current firmware and bootloader and systen part are. This alone will fix 99% of my issues here.

Please fix this process, as once I start shipping these out, this is also going to create a bunch of completely unnecessary troubleshooting issues and steps and delays, if a customer attempts to move the device to a different account or they send it back, and the Boron is still usable, and can then be setup in a refurbed product, or sent back to the customer after being tested. There are significantly better and safer ways, to handle this scenario, than telling the device to give up, until your team releases it, which is where it is currently stuck still, now over 48 hrs later.

As for my Argon issue, which is completely unrelated to the firs issue, can you please advise here too, as none of the led troubleshooting data covers this kind flashing i am currently seeing. It is also showing the micro LED in orange too, when it flashes red like this. I have tried changing USB cables and power adapters too, so I know this issue is not that. It appears to be stuck, in a low power mode or something like that. If the device is dead in the water, I would like to know why.

Any ideas?? Thank you!


Hi @sdevo619 - thanks for your feedback. I understand your concern around support but we design our support model such that the best way to get support while on the free tier is through the forums. I appreciate your point that this isn’t as obvious as it could be to users who aren’t aware of the forums, and we’ll try to make that clearer. Email support is included for Growth customers so you are always welcome to upgrade to a paid account if you would like email support.

Regarding your frustration with quarantine - as you point out this is designed for security but in practice can lead to some gotchas and negative experiences. We have plans to make some changes to the Console and some of the ownership models that underpin the platform to eliminate these gotchas.

Regarding the Argon issue, I’ll let someone else from the team jump in to answer that one.


Could you include a video of the Argon blinking? I’m not clear on what it’s actually doing.

Are you able to change into other modes? Unplug the USB cable, hold down the MODE button, then plug in the USB cable and continue to hold down MODE. Does the LED blink magenta (red and blue at the same time), then blinking yellow? Once blinking yellow, release MODE, and you can use Web Device Doctor to get further diagnostics.

If not, it could be a 3.3V regulator issue. If you have a DMM, measuring the voltage of 3V3 and VUSB would be helpful.

1 Like