A question came up recently about whether there are any cheap options for controlling AC power distribution from NINA, and that got me thinking about what it would take to write an ASCOM driver for wifi-enabled smart plugs. This would enable folks to use ubiquitous, affordable smart plugs (~$10 ea) with NINA and other observatory control software to automate power to your equipment, at much lower cost than commercial dedicated astronomy power distribution boxes.
This thread will be a log of my progress over the next few days as I (try to) develop a driver for anyone to use.
Equipment: Wemo Mini switches and TP-Link HS100 variants (for now)
I have a bunch of Wemo Mini switches on-hand, and I see many projects online showing how to control these switches programmatically over TCP. These switches are particularly easy to control due to lax security (no encryption). Another well-supported device is the TP-Link HS100 which is quite a bit more complicated, but the reverse-engineered API is well documented. I was hoping to find a more general approach to support any smart plug, but there is no common industry standard protocol for these things, and the vast majority do not provide APIs for security reasons. For now, I'll develop a driver for Wemo switches, and a separate driver for TP-Link switches, and folks will have to stick to specific supported models. I think these smart plugs are the most common but if there is enough demand for one or two others, and if there is clear enough documentation of the protocol for each device, then I could maybe develop additional drivers down the road.
Getting started (development):
I joined the ASCOM developers google group and searched through their forums for switch control projects but found none, so I think this is breaking new ground.
I considered writing an ASCOM "native" driver (directly selectable via the usual ASCOM device selection menu), and was encouraged by a video tutorial on the ASCOM Development Getting Started page which made the process look really simple. I didn't realize until many hours later that that video was posted in 2012 and the driver development workflow and toolset have changed quite a bit since then. I tried anyway.. installed ASCOM templates in Visual Studio and started poking around, but after several hours of spinning my wheels, it became clear that I was in way over my head. It didn't help that I don't have any C# experience and minimal VB experience. There seemed to be no end to complications as far as dependencies and syntax and I'm just not up for learning all of this from scratch right now. The appeal of this approach is that it's architecturally simple, and it would be easy and familiar for operators to setup via the usual device selection menu. This is "Option 1" in the attached topology diagram. I could still explore that further but for now I've set that option aside.
I then started looking more at ASCOM-Alpaca which the ASCOM guys are pushing as the next big evolution in astronomy device connectivity. The whole idea behind Alpaca is to move away from a direct connection architecture to an abstract distributed, networked architecture. Alpaca basically defines standard APIs for various device types over HTTP, such that your astronomy software should no longer care if your devices are connected to the local machine or are some place else on the network. To develop an Alpaca interface for a device, one must write a simple webserver serving the Alpaca protocol and handling device interfaces accordingly. In my case, my target device is already on the same network but uses a different protocol, so what I'll do is write a 2-sided webserver that basically serves as a proxy between the Alpaca client and the remote switch. Sounds easy, in principle. This is "option 2" in the attached diagram. Note that this proxy is basically a standalone program you can either fire up alongside your astronomy software on the same computer, or you can leave it running on some remote computer (e.g. a Raspberry Pi). The user just has to specify the IP address and port of the proxy server in the Alpaca device configuration form, just like you normally select COM ports for locally connected devices through ASCOM device configuration forms.
If you made it this far, what do you think?
Will this be useful to you?
Does it seem like a reasonable approach?
Am I making a mistake going with Java instead of the presumably more versatile and robust modern approach (NodeJs) or some other platform?
Any other tips or suggestions?