I've been using the Particle platform since January 2016, I've learned a lot from everyone on the forum and have made pretty good strides coming from zero programming to start. I've seen some ups and downs in the Particle OS, watched them bring out the Electron, had my fair share of OS, as well as user firmware, issues and always managed to work through them with the help of the Elite members here. Things have changed since then. I jumped at the chance to have an internet controlled MCU with OTA updates, cloud communications and a web IDE, especially when advertised as "IOT for all!", unfortunately lately this has changed and the IOT for all is "as long as you want to work with cellular", while the WiFi system has taken a backseat. I understand that's their current business model and where their money is, and I'm ok with that.
I recently had a contract for 8 additional access control systems to be installed at the US Naval air station here pulled due to unreliability of the system we are using (Particle). This started after the cloud outage a few weeks ago, I thought we had it taken care of but the problems kept coming up randomly, the only way to fully solve it (so far at least) was to replace the unit in the field, I also had to do this with a few other units across the Gulf Coast. After determining how to get my customers a working and hopefully reliable system again, I came here to try to find some answers in the hopes of salvaging something. Unfortunately I didn't get an answer here so my next move was to send an email to ----- explaining my problem in detail, I received an automated response fairly quickly telling me I would get a reply within 1-3 days or up to 7 days for complex issues. That email was on August 3rd, nine days ago, and as of today I have not gotten a response, and still no resolution to my problems.
I have seen a few other people over the last month or more having issues with Particle emails and how they were either handled or not, I have also seen people ping employees or elite members to get their attention and direct them to their email inbox or reference a post here for assistance. I personally have a business to run, I'm not thrilled about having to come onto a forum as my first line of tech support for an issue, but having to ping someone here after sending an email to the only other alternative is just unaccepatable.
I've always enjoyed the Particle environment and will continue to use them for hobby projects and other non critical household systems, but my time of relying on them for a business product has come and gone, at least as far as I can. I still have a hundred or so other systems still in the field that will stay until I have a suitable replacement.
As someone who has only used Particle devices for non-business purposes. What were you using the Particle Cloud for that made it a critical component? I see the cloud as a great way to update devices and a way of sending metrics. But I wouldn’t make it critical component.
We use the cloud with publish and subscribe to send wiegand data between 2 units for access control. Without the cloud, data can’t be verified and access granted.
If I recall correctly I came across your thread previously, by the sound of it you have not been supported?
Just a quick question if you don’t mind. Is each scan authenticated online against some sort of DB? I recall doing a small access control project where our client had 4 mobile scanners to allow access to training sessions. To avoid any “connectivity issue mishaps” we decided to stored tag numbers locally for each event, or only update as needed. This worked seamlessly, but your scenario might not allow for this.
We initially tried online authentication but the “hand shake” took way too long (couple of seconds but this can be long if you have 300 people queueing). I got tired of running into WiFi roadblocks of high latency internet, weak WiFi hotspots, dead spots… (you name it and we found it) so opted for a version where we stored the card UID’s local. In this case, there are around 350 card ID’s, and 350 name&surname combinations stored at any given time. So far so good
Hey @friedl_1977 thanks for your response. As of now our system sends data over the cloud to an existing access control system stored off site, we are currently working on a system like the one you describe with a local DB on an SD card. While this solution would take care of a lot of our problems, there are other factors that make this situation less than ideal right now. Reports of people having issues getting photons on and off along with this Are Particle Photons going away any time soon?
As well as the Argon not being set up for any kind of product use at this time makes me leary of moving forward. The least concern, although still very important for a system like this is that a lack of reliable cloud communication means that there will be a time when my customers can’t update their stored credentials. This means people who have left the facility will still have access and those who have come in new don’t have access until the issue is resolved, in this case I believe a couple of weeks.
I appreciate the time you took to provide us feedback and I deeply regret the less than satisfactory service you received. I fully appreciate your frustration in not receiving a timely response and I want to assure you that I am taking full responsibility into improving how we can support you and all our community members better.
Due to unplanned turnover in staffing, we have a backlog of issues that is averaging 7.3 days. And while I am actively looking to backfill our resource gaps, please allow me to share with you several initiatives that we are working on to improve the support of our community.
We have improved our help center by organizing our content based on common issues and will continue to make it easier to search our knowledge base for relevant documents
We are improving the quality of our help center by setting goals to drive more unique visits to our knowledge base
To encourage greater engagement of our available help resources, we have set internal goals for our support engineers to direct users to our documentation and create relevant content when there is a gap
We will also be working towards lowering the number of unreplied threads in the community as we rebuild our support staffing
Additionally, we shared our post mortem response to the recent outage and we remain fully committed to improving the stability of our platform in a transparent manner. Thank you for being part of the Particle community and please accept once again our sincere apologies.
Apologies for my delay in response to your feedback, I had Calculus exams and just needed to get that done
I suppose each 'systems architect' or product/system designer has their own opinion and this is simply mine. I have been working with online verification for many years and as great as it seems, I will never solely rely on the online part, especially if it is mission critical. Even with quite expensive and robust measures in place, there are just too many factors of which any one can cause outage as you have experienced. Of course, the rule I live by is you need to determine how critical the systems are. In your case, I would not want any downtime
Pitty about mesh, I think it could've come in handy in this scenario... RIP
Of course I cannot speak on behalf of Particle, but I would be surprised if P1 / Photon for example where to go away. Personally, I have taken the decision to move from Photon and Argon/Boron to P1 and B523 going forward. I have some devices left that I will used not to waste money, but any future designs will be based on these two modules.
I would not necessarily look at centrally stored database as it comes with its own challenges, but it all depends on the scenario as you mentioned, pro's and con's either way. I would maybe consider some sort of Gateway device and then push updates to each device as needed. Each device can then authenticate locally removing even Wifi communication for verification. More redundancy this way If one update/device fails, the others can still function normally.
Again, I think there are many good ways to do this and I think your approach has been solid. I am just not overly eager to put my money on online verification only. This is just my humble opinion based on many years of personal experience with online verification and the headaches it causes when it fails
I for one agree, that relying on the particle.io cloud to be up, AND all your devices being connected all year long is suicide for any mission critical business.
There is no two ways about it looking at track record.
Just to be clear, I was by no mean implicating Particle, but rather multiple providers over the last 20-odd years Just too many things that can affect 'internet connection'... from simple things such as routers, ISP's etc. My experience with Particle has actually be a very good one
I think devices/systems relying on the internet for any sort of connectivity, should have some sort of redundancy in case of mission critical events.
This is not exactly equipment designed for or priced as mission-critical hardware and software. You should not stake your life (or anyone else's) on it working. It does what it does and it gets abused a lot. I've been both pleased and disappointed with Particle features and issues in the past few years, but its important to design a system architecture with the product's strengths and weaknesses in mind.
As a reliability engineer, I think the biggest part of the puzzle people miss is the marriage of firmware, hardware and transport layer is a very difficult target.
First, I would put anything in the field without a hardware watchdog, the attiny13a is a great piece of 50 cent insurance.
Second, local storage is a must of data - the transport layer weather wifi, cellular, bluetooth or LORA will go down.
Third, firmware - and yeah, I’ve written some pretty crappy code too.
We all want the marriage of 100% uptime (it doesn’t exist) with 100% functionality (possible if you do a ton of qa testing and track real usage in the field). But these are are rarely done and are expensive.
I’ve recently been working with MKR1400/MkR1500’s for a client - and it’s no different than particle, but trust me, you’re very much on your own there - not that particle support for people who spend tons of money with them is good, but it seems the user base is a bit more matured in their development abililties.
I understand the frustrations - I’m just not sure it’s all having to do with Particle…
Hey Albert,
There’s been a lot of talk recently about using a hardware watchdog with the Boron line of Particle devices. I noticed you mentioned using a hardware watchdog with ATtiny13a and was wondering how you have configured the device to monitor the SOC. Some folks on the forum have mentioned that driving the RESET pin on the Boron isn’t enough for a reset and that a “hard” power cycle is required. That means I’ll need to find a relay to manually power cycle ~2 amps of power (not happy about this). What are your thoughts on this method?
I am currently researching the best way forward for this (my device is semi-mission critical) and don’t want to reinvent the wheel if someone smarter and more capable than me has already thrashed forward here.
So, our watchdogs, set a pin high when a reset action is performed, this allows us to validate on boot if a watchdog reset is performed, this is not the only device with separate reset issues, if we run into this issue, we’d likely do a hard reset on the modem on reboot of the mcu if the watch dog fire - but on the boron, if there is a timeout, the modem should reset. else wise you could use the code from modemHardReset and HAL_GPIO_WRITE to reset the sara module, but I’d perform that action, then have the watch dog do another reset of the mcu.
We haven’t run into SARA module issues, however, we also leave them on and connected to the internet for a day in the office, as they typically perform OTA updates.
