[_red]

We're a industrial-control company whose traditional UI has been standard win32 applications - we've slowing converting our stack over to a web interface but as our UI needs to talk to lots of local devices, we've hit the problems you described.

Our solution has been to basically mandate that the user install either a small embedded device (ie. RPI or equiv) or manually launch a container. These essentially just serve as a local websocket / api router so Chrome connects to some local "device/container" and then that connects to all the local devices.

Although this is a logistical hurdle, its actually simplified other aspects of development since now this device/container has a bit of intelligence and can act as real middleware to simplify what the UI needs to contemplate. Basically MVC-style development using hardware bits as Controller.

[noduerme]

That's cool. I guess our problem could be described as allowing non-technical users to control the in-shop devices from an app on their phone (both android and iOS) without knowing the local IP at all. Like, how do we determine the shifting dynamic IP of our in local routing system from an app served from the cloud ...and the answer unfortunately is we can't. We have to serve the app locally in each facility.

[_red]

Thats something similar to what we are doing...

* Local RPI / Container connects to message queue in cloud * Web User inputs request to Web UI (cloud) * Local RPI / Container retrieves request via queue and access final device * Reports status back to queue which is then reported by Web UI

Basically the local device is your router using whatever message queue you want.