You are standing in front of an electrical panel, both hands busy, and you want a photo of it filed as a task in Odoo before you walk away.
No phone out of the pocket, no app to open, no form to fill in later from memory. Just look, capture, and keep working. That was the brief behind this session, and the tool for the job was a pair of Ray-Ban Meta glasses.
The glasses are great at the capture part. They take a photo, a video clip or a voice note the moment you tap the temple or say the word. The hard part is everything that happens after the shutter: getting that media out of the phone and into the right place in our ERP, without it turning into a pile of files nobody ever sorts.
The constraint that shaped everything
We use the no-display Ray-Ban Meta model, and it is worth being honest about what that means: these glasses expose no developer API. There is no SDK to push a photo to a server, no webhook the glasses can call. Media lands in your phone's gallery through the Meta companion app, and that is the only handle you get.
So the integration could not start at the glasses. It had to start at the phone, at the exact moment you decide a capture is worth keeping. On Android, that moment has a name: the share sheet.
A PWA that lives in the share sheet
The answer is a small Progressive Web App built around the Web Share Target API. Once installed, it registers itself as a destination in Android's share menu, right next to the messaging and email apps. You open the capture in the gallery, tap share, and pick our app.
What happens next is deliberately boring, because boring is reliable. A service worker intercepts the shared files, stashes them in the browser's local storage, and opens a review screen. There you see the photo or play the clip, type a short title and an optional description, and press one button. The app uploads everything to Odoo and shows you the task number it just created.
The whole front end is three small files: a manifest that declares the share target, a service worker that catches the upload, and a couple of HTML pages. No framework, no build step. It is served as plain static files from nginx, which means there is nothing extra to keep running and very little that can break on the web tier.
The Odoo side: one webhook, one task
On the Odoo end lives a tiny module called glasses_capture. It adds a single HTTP endpoint that accepts the uploaded files plus the title and description, and creates a task in a project called Capturas Gafas, with each file attached. That is the entire job: turn a multipart upload into a task you can triage later from your desk.
A couple of small touches make the result pleasant to live with. The task name is automatically prefixed with a tag per kind of media it carries, so a mixed upload reads as [photo][video] obra at a glance. If the share carried location data, it is appended to the description. The endpoint is protected by a bearer token, so not just anyone can drop tasks into the ERP.
The multi-database trap
The most interesting bug never reached the user, because it showed up the first time we pointed the PWA at the real server. The webhook worked perfectly in tests and returned a flat 404 in production. The difference: production serves several databases behind one Odoo, and a route on a multi-database server is only reachable before a database is chosen if the controller declares itself as public and the module is loaded server-wide.
In other words, a webhook that has to resolve its own target database cannot rely on the usual session and must be wired into Odoo's database-agnostic routing on purpose. Once the module was added to the server-wide list and the route opened up the right way, the 404 turned into a clean rejection or success, exactly as designed. It is the kind of detail that is obvious in hindsight and invisible until you hit it.
Getting it online
Putting the PWA on the public internet took a short detour. A share target needs HTTPS, so the app needed a real subdomain with a real certificate. The first domain we tried would not validate, because one of its DNS servers was lagging badly and the certificate authority kept failing the challenge. Rather than wait on a stuck nameserver, we moved the app to a healthy zone, the certificate issued in seconds, and the capture flow was live.
There is a lesson there we keep relearning: when a deploy stalls on something outside your own code, the fastest fix is often to route around the broken part rather than to fight it.
What this is, and what it is not
While building this we took a careful look at Meta's own developer toolkit for its smart glasses. It is real, but it targets the Ray-Ban Display product, a different device with a screen in the lens. That toolkit is for webapps that render on the glasses themselves. Our glasses have no screen and no such API, so none of it applies to this use case. The honest design here is not glasses-side code at all; it is meeting the media where it actually lands, in the phone's share sheet.
Where it runs now
The module is installed on our production Odoo, the PWA is live over HTTPS, and the round trip has been tested end to end: capture on the glasses, share from the gallery, review, send, and watch a task appear in Capturas Gafas with the photo attached. It is a small piece of plumbing, but it closes a real gap: the one between seeing something worth recording and having it safely filed where the rest of the work lives.
The next obvious step is voice. The same pipeline that carries a photo can carry an audio note, and the same machine that runs our other assistants can turn that note into a transcript and a ready-to-read task description. The glasses already capture sound. We just have to keep meeting it where it lands.