I’ve been working on a script to allow TCode devices to work with Stash with multi-axis support.
There are a lot more features I am working on, but I reached a point where I figured it was best to get it out in the wild for some feedback.
I would like to add more hotkeys, but would love some ideas on how best to lay that out. My primary focus is ease of use, so I don’t want to just map everything to random keys. Any suggestions are appreciated.
As of now, press F2 to open the settings when a scene page is open. Configure the device IP, axes, etc and enjoy.
The scroll wheel controls the L0 axis currently, for ease of adjustment. Holding the ‘Windows’ key makes the wheel adjust the lower limit.
Shift saves the current limits allowing them to be jumped back to by click the mouse wheel.
haven’t yet tried this but to get the script to run properly on my internal instance of stash i had to change the @match/@include to point to my internal domain for stash and also needed to modify the connectWS function to work for TLS secured sites (all my internal and external sites are signed)
/* Adjuster */
function connectWS(loc){
if (socket && socket.readyState === 1) {
// Socket already connected and ready
return 1;
}
if (socket && socket.readyState === 0) {
// Socket is already connecting
return 0;
}
// Determine the correct WebSocket protocol based on the page's protocol
const protocol = window.location.protocol === 'https:' ? 'wss://' : 'ws://';
// Connect to WebSocket
debug("Connecting to " + protocol + loc + '/ws');
socket = new WebSocket(protocol + loc + '/ws');
return -1;
}
It should be possible to tie this in with StashInteractiveTools. I was already developing this, for personal use, before that was released. It just wasn’t very user-friendly because I was running a web server to pass the other axes scripts. That plugin just made it easier to package this for others to use.
That code isn’t technically correct. Even if the site is https, if the ESP32 itself doesn’t support wss it’ll fail. By default the WiFi builds of TCodeESP32 seems to be only ws. Looking at the code, it does appear to have options to compile it as wss.
Browsers will typically block ws on https and wss on http.
Is there a reason you are using https even locally? I think the correct solution here is to have the user setting include the protocol.
I am working on some workaround code for connecting even with a mismatch, but I don’t know if it’ll end up being too slow.
Ah interesting so they would actually need to both be https…
I have a domain for services on my network mydomain.com, any external services are https using caddy as a reverse proxy e.g. https://movies.mydomain.com for jellyfin.
For internal only services i use lan.mydomain.com to make them easier to get to so i dont have to memorize IP and port e.g. porn.lan.mydomain.com for stash or unifi.lan.mydomain.com for my Unifi network controller. I got really annoyed of browsers saying “UNSAFE UNSAFE ARE YOU SURE YOU WANT TO CONTINUE?!?!?!” so I have caddy acquire a wildcard certificate for *.lan.mydomain.com so any services on my internal network are automatically grouped under the same TLS cert and I can access them over HTTPS and make my browser shut the hell up. So basically I did all that cause I was annoyed at the “Are you sure you want to continue to unsafe site” popup
I actually never set up my SR6 running TcodeESP32 with a domain, i only ever used it with tcode.local or the IP address but if i have to I could get it on my network as something like sr6.lan.mydomain.com
I actually spent a couple hours last night trying to use AI to help me understand what changes might be needed to make your browser script be part of the served React page. It seemed to come up with something but i ran into build issues so i took a step back and was gonna try to build it up piece by piece based on its suggestions. I was honestly impressed with Gemini 2.5Pros ability to understand the StashInteractiveTools plugin and your browser script and put them together in a nice way with new react components.
I haven’t used caddy, but I use nginx for reverse proxying and it has a ws option, so if caddy does, that would work. I pushed an update to the devel branch that would let you add the protocol to the settings and has some minor improvements to a part of the movement code.
I think a lot of the code will need to be reworked more than just put in. A lot of the calls to the plugin can be refactored if it becomes part of the plugin itself.
I see mention of USB support how do you use the a USB device like an SR6. If I use the web address of it tcode.local its really jerky and responds intermittently.
@Spunkle I hope you don’t mind but I used your work to help generate the a patch for the StashInteractiveTools plugin to drive the device from the React side, see my comment here for more details.
It’s working! but there’s almost certainly a lot of cleanup work needed since im not a web dev and i was heavily relying on AI to help write this.
That is on the planned list, but isn’t currently supported.
That’s why I release code under the GPL, so it can be modified and released for others.
That’s pretty nice. I notice it dropped several of the features. Namely the shortcut keys, random motion, and it appears the command queue. The queue was added to prevent the lag you mentioned you are having.
It looks like the code is sending each axis individually to move with the ‘\n’ appended, instead of queuing them on the device.
The device only moves when a ‘\n’ is sent. So instead of sending them for each axis, it improves performance to send all of the axes motions to the device and then only send ‘\n’ once. Even my script could use some work in this regard, but it doesn’t lag currently.
I like the work. I might try to polish it up a bit later this week, and submit a pull request, when I have a chance.
