I'm running v2.0.0-alpha.179 and trying to run my code with the wifi connection disabled so I can put the esp32 into AP mode. When attempting to run my code with these arguments - I get the error: Error: unsupported Jaguar define: jag.wifi I was simply following the documentation here: https://github.com/toitlang/jaguar

Sorry about the confusion. We've updated the documentation before getting the release out 😩

Having trouble disabling jag wifi also. Using v2.0.0-alpha.189. -D jag.disabled is now depreciated so I am back to -D jag.wifi=false -D jag.timeout=1m when installing container. OUTPUT: [jaguar] INFO: container 'flowi' installed and started with {jag.wifi: false, jag.timeout: 60} INFO: PROV: Starting worker... [wifi] DEBUG: connecting [wifi] DEBUG: connected [wifi] INFO: network address dynamically assigned through dhcp {ip: 192.168.0.133} etc. My program has no trouble connecting immediately, so wifi obviously not disabled, and after 1 minute my container is unceremoniously stopped as jag restarts its network (which I think was already running). So what does -D jag.wifi=false actually do? Thank you.

I think > By default this runs with a 10 seconds timeout to avoid making the device inaccessible by Jaguar. You can configure the timeout by passing a separate -D jag.timeout option: So you can extend the default timeout

As @addshore said. The

timeout

might need to be clarified. Initially, it was

jag.disabled

and the timeout ensured that your device got accessible again at some point. Now with the

jag.wifi=false

it's not as clear anymore that the timeout means that the container is stopped after the timeout. If you don't want to use Jaguar, consider creating your own envelope using

jag toit tools firmware

(or

toit tools firmware

directly). There is documentation on Toit's github repository, but the OTA tutorial also has a small section: https://docs.toit.io/tutorials/misc/ota/#preparing-the-new-firmware

-D jag.timeout=1m apples both to your container's life and jaguar's -D jag.wifi=false ? And maybe I have totally misunderstood Jaguar's role. I thought jaguar was a usually omnipresent wifi connection that provided OTA updates and serviced network requests from other containers/programs so other containers didn't have to reinvent the wheel. Maybe other containers do reinvent the connection and the only thing jaguar provides (behind the scenes) are the secure credentials it was loaded with (or updated with). But if another container's wifi connection is independant, why does a captiveAP need to disable jaguar? Sorry to be dense, but I sure would like to understand.

The problem is that once a wifi connection is running you can't just start an AP. I don't even know if you can have both at the same time in Toit. Jaguar is primarily a development tool (as there is no authentication...) and we expect final products to replace it with something else (for example Artemis). At home it's often convenient enough to just stick with it though. (I have done that too)

So once jaguar (or any other container's network connection) is running it cannot be closed and an AP started?

You can close it and start an AP, but Jaguar is (by default) always running. So your AP container doesn't work. (Unless we fixed it and you can have both at the same time. Tbh I don't remember anymore).

Got it. Does artemis work the same way?

Artemis only connects at regular intervals to check whether it needs to do a firmware update. So no. But it is more complex and needs a server environment (although you can use ours for reasonable usage). Since it only connects once in a while it is less convenient to develop with it. It's designed for deployed products that need an update from time to time

OK. So develop with jaguar, use -D jag.wifi=disabled to simulate Artemis typical unconnected state, then graduate to Artemis when code stable. I actually hope I'm close! Thank you for your help.

That sounds right.

To prevent you from writing a program that connects to the internet? Why would you need that limitation?

I mean, Artemis tries to connect at regular intervals. But if your AP is running it can't do that. So Artemis has an API to tell it not to connect.

I see. It facilitates an AP connection. But STA connections can coexist.

Yes. Once a sta connection is established all containers reuse that one

In a jaguar environment the jaguar sta connection is typically reused.

Yes

Again, thank you so much for helping me understand what I (and my AI) are doing!!

Happy to help