12 replies to this topic

[rkinnett]

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.

 

This latter approach proved to be much easier to develop.  It can be done with any language that supports basic networking (C/C++, C#, VB, Java, Javascript (Ajax, NodeJs), Python, PHP, etc..).  This option is far more flexible than the ASCOM native driver option.  Which platform should I use?  It needs to support basic web server functions and it needs to be deployable as a standalone executable.  NodeJs seems to be the modern way to do this, and there is a way to package a NodeJs server as a standalone executable, so that's an option.  Python is also a good candidate.  Being hard-headed, I took a whole decade step back in technology and started building in plain old Java, mainly for familiarity and fast turnaround.  I immediately found success with this approach by just dropping in sample code for a simple web server, written in only a few dozen lines of code.  Within an hour, I built up a skeleton framework to handle the Alpaca REST interface and I'm already receiving, parsing, and responding to commands.  I haven't started the smart plug side of the proxy yet, so it doesn't actually do anything useful, but I'm very pleased with the direction this is going.

 

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?

 

Thanks

Attached Thumbnails

• 

[rkinnett]

CN member speedster had the idea of skipping ASCOM altogether and instead invoking some sort of command-line utility to control switches.  So I put together a Windows batch file to do this with some Wemo Mini switches I have on hand, and it works great!  I now can now have NINA turn equipment off at the end of the night, and maybe turn on a lamp to wake me up.  I can also have it turn off my Christmas lights!

 

The batch tool should work on any Windows machine, and it may work for other models of Wemo smart plugs, so long as you can find out the local IP address.  

 

https://github.com/r...emo-Smart-Plugs

 

Belkin is selling Wemo Mini smart plugs for $12 ea on their own website.  EDIT:  sold out, sorry.  Best bet is amazon, 2 for $30.

Edited by rkinnett, 26 November 2020 - 02:44 PM.

[sbradley07]

This is pretty nifty.  Nice work!  I didn't know there were smart plugs that were "ip addressable" with a command line.  I've been using Go Smart (Gosund?) smart plugs and power strip for a while to control a lot of my equipment (RH control, exhaust fan, dew heaters, etc) in my observatory, but no really good way to automate things.  I don't think they have the same ability as the Wemo plugs, or at least nothing I could find :-(   I might have to switch to these plugs.  

[mtc]

This is a great development - kudos!

[rkinnett]

Thanks guys!

 

Would love to know if anyone ends up using this.

 

Steve, those Gosund plugs can be hacked with a bit of work.  You would have to solder some wires to an exposed serial port on the PCB and flash open-source Tasmota firmware.  That’s pretty much the approach people are taking with most smart plugs other than the Wemo and TP-Link HS-xxxx plugs.  All smart plugs are by nature IP-addressable but most use encryption to obfuscate proprietary protocol.  The Wemos don’t use any encryption at all for local network transactions, which is terrible for security but makes them very versatile for DIY projects like this.  They can be controlled immediately by curl commands or scripts like mine as soon as you get it set up on your network. No firmware hacking or mucking about with keys needed.  Controlling the TP-Link switches is a bit more complicated.  Someone inspected the firmware and decoded the encryption method and that enabled folks to write routines to mimic TP-Link control apps, but if I understand correctly this takes a bit more work to configure a script to handle encryption and handshaking.  

 

I bought a pair of TP-Link HS103P2s to play with and will try to make a similar batch script to control those after they arrive this weekend.

 

I also intend to finish the ASCOM driver for one or both of these switch types.  The batch file was fun and immediately provided a way to control the switches from NINA but that won’t help folks using SGP or other software.

 

Cheers

 

EDIT:  I changed the name of the github repo, and that changed the url, so I updated that in my earlier post, and here it is again:  https://github.com/r...emo-Smart-Plugs

Edited by rkinnett, 26 November 2020 - 02:45 PM.

[sbradley07]

You would have to solder some wires to an exposed serial port on the PCB and flash open-source Tasmota firmware. 

Cool, another project!  I'll look into the firmware.  I haven't tackled any hacks that require soldering, but always willing to try something new.  

 

As for your development, I think Alpaca is the right way to go.  Since the proxy can co-reside with the ASCOM software (ie. NINA), it's logically no different than an ASCOM native driver, but it's more extensible and, shall we say, future-ready.  

[speedster]

Thank you Ryan!  My Wemo mini will be here next week and i will definitely use this.

[speedster]

In NINA command line, you just put "wemo 192.168.1.100 off"?  Bat file in NINA folder?  System32 folder?.   I'm going to like the NINA command line.  "timeout 60 & 192.168.1.100 off & shutdown /s /f" I think would pause 60 seconds while NINA parked the mount, then kill power to the mount, then shutdown the laptop. 

Edited by speedster, 27 November 2020 - 11:43 PM.

[rkinnett]

You can put the batch file anywhere, and provide the full path in the script execution utility in NINA. I suppose you could string commands together like that but I’m not sure why you would need to.  You can do each of those operations as separate events in the sequencer.

 

The ASCOM driver works!  I’m just polishing things up a bit and will figure out how to build a standalone executable, then I’ll post on github.

 

That will give a bit better flexibility than the batch file. You can control the switch from the equipment page or the imaging page, or within a sequence.  Should also play nicely with SGP et al.

Edited by rkinnett, 29 November 2020 - 06:45 PM.

[speedster]

Please post the link here when you have it ready.  Looking forward to it.  Thanks for all the hard work.

[rkinnett]

I got a bit carried away with this, but it works great and the experience was worthwhile.

 

The source code and executables are posted here:

https://github.com/r...emo-Smart-Plugs

 

The exe should work in 64-bit Windows but may get flagged by your antivirus because it involves a lot of HTTP calls to variable IP addresses (especially the scan feature).  The executable jar file should work on other platforms with less hassle, so long as you have Java already installed.

 

Follow the instructions on the readme at the link above.  You'll need to install ASCOM-remote.

 

Please let me know if the instructions or interfaces aren't clear.

 

This first version only works with one switch at a time.  I'll expand it soon to handle multiple switches.

Attached Thumbnails

• 

[magiclight]

Would there be a similar option for a DC wifi switch ?

[rkinnett]

Would there be a similar option for a DC wifi switch ?

Not that I'm aware of, but it wouldn't be hard to build such a thing for a small fraction of the cost of off-the-shelf ASCOM-enabled astro-dedicated DC power distribution boxes.

 

I see some wifi-enabled power relays that could be used to connect and disconnect DC power, but I haven't found any that don't insist you use their proprietary cloud service.  If I were to build something for myself, I would get an esp8266 relay board and program the ASCOM-remote protocol right onto it.  That would be a fun project!