I am a graduate student and have had trouble getting my ARGONs to connect to the Particle Cloud here at school. The IT Network guys setup a special IoT network for us, and it works great with the PHOTON and other WiFi IoT devices, but NOT the ARGON. (@micromet you might be interested in this)
I recently found out that our university blocks all incoming UDP traffic, and this seems to be the reason that my ARGON never breathes cyan, only flashes cyan with one red blink at the end and then starts over. I am almost positive this is the reason it won’t connect, as the PHOTON uses TCP and has no issues.
Additionally, the IT guys showed me that the ARGON associated and successfully connected with the network, so I imagine that the blinking cyan is cause by no acknowledgement/ response from the Particle Cloud due to my school blocking all incoming UDP traffic.
SO, my question is: is it possible to force the ARGON to communicate with the Particle Cloud over TCP instead of UDP?
It does sound like the blocking of UDP traffic is the issue here about not getting your device online. All mesh devices, including the Argon, are only able to talk to the Particle cloud through UDP. So unfortunately, there are no TCP options at this time.
I’m not certain, but I believe if your school allowed for inbound and outbound UDP traffic over 5684, it should get online. I’m not 100% though, @avtolstoy can fact check me on this one!
EDIT: I’d originally typed 5683 UDP but this is incorrect. It is actually 5684!
@SammyG I’d like to make a small correction: it’s UDP 5684 defined as coaps (DTLS-secured CoAP). Devices connecting over TCP will use 5683 defined as coap [1].
At the moment Gen 3 devices also use ephemeral random source ports when establishing connections. The source port range is [49152, 65535] for Argons, Borons and Xenons with Ethernet FeatherWing and [40000, 49000] for Xenons connecting through a gateway.
Thats a bummer though… there’s no way I could get the university to allow traffic through a range of ports, let alone even getting them to open up one port would be difficult.
So now I have a new question: How can I use the ARGON without having it connect to the particle cloud?
I realize I would lose a lot of functionality, but as of right now I can’t use my ARGONs at all.
Would I have to run SYSTEM_MODE(MANUAL) and then call Particle.disconnect()?
Basically, I would like it to run just like any other esp32 device.
Again the goal here would be to have the device completely bypass the particle cloud interaction, since this is what is being blocked by my school. I could still do other internet things with it as long as they were TCP.
You would run SYSTEM_MODE(MANUAL) or SEMI-AUTOMATIC I think would work as well. You do not have to call Particle.disconnect() because the cloud will not try to start at boot-up... you first have to call Particle.connect() when in those system modes if you want the cloud. You should note, you might not be able to do first-time setups or add any devices onto the mesh without cloud access via UDP. You could put the Argon onto a hotspot to do first-time setups and then switch back over to the university WiFi after that is complete.
Good luck. I think your university is crippling your functionality but it is what it is.
Yeah unfortunately I think we’re little fish to the university, they have bigger problems I suppose.
Anyway, I have been setting them up on my phone hotspot to get around the situation you were talking about.
I’ll mess around with the system modes and see what I can do.
Could a mesh network of XENONs/ ARGONs work if the ARGON is not connected to the Particle Cloud?
The mesh network should continue to function unhindered despite loss of cloud access via the Argon. You will have the constant blinking green status LED on all the devices though (annoying if nothing else.) You can also use SYSTEM_THREAD(ENABLE) if you run into any hang-ups from the missing cloud... but in my very simple testing in non-threaded mode, if the cloud is lost, mesh continues to function without problems. The Argon does have its stability problems with WiFi loss. It seems to lock up and be unresponsive when the WiFi comes back. Not sure how that will affect you but they should be releasing further fixes for that issue, hopefully soon.