@timx Yes. The extra $15 isn’t very relevant for me as I’ll have to design my own PCB anyway. If I can buy preloaded P0 modules from Particle that’s great. I can also flash my own modules with the Adafruit firmware, but if possible I’d like to avoid it.
Adafruit is missing the OTA updates and many other things, so there’s drawbacks with both solutions. The biggest drawback with Adafruit is that this is their only product based on the P0 module. If they decide that they’re not making enough money from it, they can just ditch the product and leave me in the dirt. Particle has a solid ecosystem built up around this device, but I have to be able to connect to AWS, so if Particle does not solve that I’ll have to use the Adafruit firmware.
I dunno for sure, but I think Particle is basically selling the Photon at a loss as their marketing push toward Makers? Their main business model is to create a great API and then sell server services that makes it fast to roll out new internet-connected hardware. The more Makers they get on board, the higher their sales volume will be. I’ve seen some of the Hangouts they’ve posted on Youtube and I really like their thinking. I think it’s a good model both for me and for them.
I agree, I need/want to be able to dial in an AWS API gateway endpoint (HTTPS).
I see that as a) more efficient than going via a webhook that requires their server processing of the request and response b) a form of independence from where-ever particle heads
I’m really interested in using HTTPS for AWS as well, are you planning on doing this using a photon or electron?
The reason I ask, I’m trying to weigh up the difference between using webhooks (potentially costly if calling more than every ~5 minutes with a large fleet of devices) compared to using HTTPS directly - which on an electron I imagine could use substantial data if you are re-establishing a secure connection every time you post to AWS.
Agreed, for the same reasons.
It actually doesn’t make commercial sense for Particle to route all webhooks at volume through their service. a) another link in the chain prone to failure, and the device registration failures the other month affected me. b) why chain multiple services together when its just another layer of cost?
My photon devices are pinging every 15 seconds, I’m not quite so data constrained for re-establishing SSL, but its an interesting consideration.
That would have been my guess as well. My assumption was that these webhooks would be Lambda functions (I think Particle is on AWS?) and hence not too costly in the scheme of things. However they seem to be having difficulty managing scaling. I’ve been following the Particle network status email list for about a year and I have to say I’m a bit concerned at how often we get ‘webhook delays’ or ‘webhooks not firing’ and then an explanation saying they have adjusted something or added capacity. (The last of these was mere hours ago).
Webhooks probably won’t be super critical in my application, but I would think for many, these interruptions won’t be acceptable - especially when paying rollout pricing and above.
network status email list???!!! How do I subscribe?
I routinely get problems with my customers and all I have is, ‘is your Wifi working?’ if I don’t know its actually webhooks. I’ve got cloudwatch observing my AWS side of things, with appropriate alarming, but if they’re dropping webhooks on their end then thats invisible to me.
I do believe they’re with AWS, east coast, my guess is custom managed servers as HTTP gateway integration isn’t something they support (they would if they were using it). I’ve paired my http gateway services and lambda to be also on the east coast to reduce latency, while I run my customer facing services from West coast (closer to Australia etc).
Good points regarding AWS location, my servers are currently in Sydney (Most of my customers are currently in NZ) but I might shift the backend to East Coast.
hello bbs, wondering if there are any updates on this issue? I use the Particle photon but couldn’t get the https work using glowfi.sh’s library
Here are my issues:
the red blinking: no matter how adjust my code, eventually the device will turn to sos mode, indicated by red blinking led. Although some people said the working time can be prolonged by increasing delay time between each loop, the hardware will be crashed eventually.
Before firmware crash, I cannot send request successfully as well (what I use currently as a trial is GET https://www.example.com, whose request can be found using curl -v https://www.example.com).
The error information shown to me is matrixSslNewClientSession: -10. And I noticed that the available memory monitored by System.freememory() is decreased continuously, leading to final crash of whole device…
I would like to have a try using the example code, however, it looks like there are no server named api.glowfi.sh using either webrowser, nslookup, or curl… Can some one let me know I can I register an account on glowfi.sh?
@michaelT
Thanks to glowfi.sh I was able to build the code for my particle electron and tried to https post a data to my server however I only got errors.
I only changed host and ad_endpoint, se_endpoint and removed “Authorization: Basic XXXX…XXX\r\n” in the httpRequestContent[]
Following is the result. Is there anybody can help solving this issue?
Using 2048 bit RSA private key
Keys Loaded
New Session key!:
free memory: 0
matrixSslNewClientSession:1
free memory 3: 63160
Bytes sent Successfully?!: 92
matrixSslSentData: 0
Sent Successfully?!, everything good
matrixSslGetReadbuf: 6000
HttpClient> Done before full len
0
HttpClient> Done before full len
0
HttpClient> Done before full len
0
HttpClient> Done before full len
0
HttpClient> Done before full len
2655
Received: 2655
certCb invoked: 45
WARNING: Certificate date window validation not implemented
SUCCESS: Validated!
matrixSslReceivedData: Tx: 2655 Len: 0 rc: 1
