This may not be the place for this question, but here goes.
I bought a “5V USB Relay Programmable Computer Control For Smart Home” relay from eBay (for the grand total of £2.50), so I do not expect much from it, however I thought I’d ask the question anyway.
Some background - I am hoping to use the relay to control the roll off roof of my observatory via ASCOM
For ASCOM control, I need to be able to assign a virtual COM Port to the relay so that the Max Pilote ROR driver can
I have seen a GitHub project for implementing operation of the relay (which does work fine as the device is HID compliant). See the wiki here: Driver-less USB relays (HID interface) - V-USB
However, I have tried a multitude of drivers to see if I can get one to work… for example the Eltima Virtual Com Port and the FTDI VCP driver, but I cannot seem to be able to assign a com port to the USB device in device manager.
Does anyone know how to force Windows 10 into using a Com Port for a USB (HID) device?
Does anyone use a USB relay to control their ROR from SGPro?
Why do you need a COM port? Whatever is accessing the device through ASCOM shouldn’t care about the underlying hardware implementation. And if something specifically NEEDS a COM port then that application will be controlling it directly and not through ASCOM.
You need to find an ASCOM driver that knows how to communicate with your relay controller. I’ve no idea if such a thing exists but would not be hopeful. There are a multitude of this sort of relay controller out there and they all tend to be different.
A better option is to find a ROR driver that is designed to work with specific hardware and use that hardware.
BTW the link provides very little that’s of use other than to a developer.
I don’t have SGP with me at the moment, so I can’t check, but don’t all of the devices that get connected to SGP ask for a serial port number to facilitate the connection ? I haven’t seen any other options.
To add to the original question, I once wasted a whole afternoon trying to assign a HID device to a serial port. It turns out that You are trying to make it do two things at once and it can only do one of them. HID is a software protocol that allows you to talk to devices through the USB hardware. A serial port is an old fashioned way of doing serial communications that has a very low overhead because it is purely hardware based and doesn’t have any complex protocols to worry about. A USB connection can only be one of a list of things, two of which are a serial port emulator and a HID device. The low overhead for serial ports is important for hobbyists because it makes devices really easy to program and get them working.
One way around this is to plug your relay into an Arduino (or similar device that has a standard HID library) and have it act as an ASCOM compliant ROR controller that talks to your pc running SGP (Cloudy Nights will give you pointers to a suitable observatory or safety driver that SGP will talk to the Arduino’s on its serial port). Because you are only implementing one command the code should be simple, but I strongly recommend that you add additional protection later to prevent the roof ripping your scope off your mount.
The serial port is in the ASCOM driver, not in SGP, therefore SGP doesn’t actually care how the ASCOM driver communicates with the hardware (this is one of the most important and awesome things about ASCOM from a client perspective!). Lots of things are starting to move away from serial connections which is really nice. My dome communicates via HTTP through the ASCOM driver and SGP is none the wiser. My mount connects via ethernet. I have some devices that use HID. COM ports are slowly going away from astronomy gear.
I’ve tried a few different ROR drivers to find one that works with no luck.
All I’ve seen is ones that work with Com Ports. But I could be looking in the wrong place.
As I see it (and I could be wrong)…
I either need an intermediary bit of kit ie an arduino and someone to point me in the direction of a driver that works. Does the arduino use an FTDI chip? In which case I can use the VCP driver.
Or -
Buy a different relay with known drivers.
For now, all I’m trying to do is operate the relay on a momentary basis ie immediately on and then off again to trigger my garage door opener. The on and off again to close the roof.
The scope won’t be in any initial danger until I’m certain it’s all working. I’ve wasted many months of my summer building the obsy so don’t want it to go to waste!!
I’ve seen Lesvedome but that needs a whole new board and lot of other kit.
One excellent ascom compliant relay and sensor unit is Lunatico Astronomia’s Dragonfly, here. It is an observatory controller and you can use it not only to send a pulse to trigger your roof motor but also power on/off your equipment, link to your weather station and a myriad of other tasks.
I use one in my home observatory and also my shared remote observatory at e-Eye, Spain. The software comes with ascom compliant scripts for your roof and it works seamlessly with SGP.
If your budget can stretch to the Dragonfly, it is a superb piece of very versatile equipment. Jaime at Lunatico is very helpful and gives very good customer service. He also has been known to post on here . . .
There are other usb/ethernet switch relays available, eg KMTronic and you could build your own scripts of course.
The problem is that, as I said before, there is no driver that works with your hardware. The solution is easy, just write a driver that works with your hardware.
As you mention, I know the easiest solution is to write a driver. Unfortunately i am not a .NET developer. By day, I am a front end developer. So, unless you can write an ASCOM driver using Node, React or Angular, my skills will be no good.
I have some java experience but haven’t done any for a couple of years.
I just noticed your title of ASCOM developer. Perhaps you could point me in the right direction? Failing that I will buy hardware with known drivers.
They include templates for every type of driver. 90% of the work is done for you! Even if you’re not a .NET guy, you can clearly at least think in codey ways…that’s enough. Might take a few aborted trips to google, but I bet you can do it.
The GOOD news for you here is this : You’re talking about what has to be THE simplest implementation of THE simplest ASCOM driver there is : The Dome driver. (Here’s all the ASCOM Dome driver knows how to do IDomeV2 Interface as you can see…a ROR doesn’t need to do 3/4 of that or more )
To ASCOM, your roll off roof is just a dome…that can’t do much. It doesn’t rotate, it doesn’t change altitude, it doesn’t park…it basically only does 2 things : Connect/Disconnect, and Open or Close a Shutter. That’s it.
So…seriously…you could write a perfectly functional ROR driver with 2 properties - Connected and ShutterStatus, and 2 methods - OpenShutter and Close Shutter. It might not pass conformance checker yet, but it’ll be enough to get started testing on the table, making that relay go click click.
Go grab the code from that github you linked, find where they’re actually connecting to the relay and telling it what do do, and hack that up to put in the CommandBlind Method, and you’re off to a flying start!
…below this is likely nonsense talk if you’re not into development things. Also sorry for the novel…that got longer than I was anticipating.
Hardware wise my dome was controlled with a Raspberry Pi with an Arduino “Ala-Mode” shield that plugged into the Pi (get it…Raspberry Pi Ala Mode…). I used a couple of Pololu Controllers for the motors, which at the time didn’t have an Arduino library…so I wrote one. I also had a second Arduino that controlled the shutter motor and my light box. The shutter electronics initially required the dome to be parked at a specific position to charge the battery. Eventually I swapped this out for a small solar panel. The two arduinos talked via wireless XBee controllers (serial).
The Raspberry Pi hosted 2 web servers.
Python Flask server that provided an API and proxied the HTTP->Serial calls to the arduino that did all the hardware interfacing (arduino is just better at talking to hardware than a Pi is…). This API is what my ASCOM driver talked to.
An nginx server that provided a reverse proxy to the above Python Flask server and also hosted a simple HTML /Javascript web page that allowed me to open/close/rotate the dome as well as see my security camera that was in the dome.
On the PC side I wrote an ASCOM driver that talked to the Raspberry PI via a RESTful implementation. I also implemented a flatbox inside of SGP (which is there but you all don’t see ) that again talked to the HTTP server via REST. Overlapping calls didn’t matter and multiple clients were a non-issue as that’s just how HTTP works, although I did have to provide protection for the serial ports inside of the Flask server.
Sadly that doesn’t have the most up to date info about the controls. This was prior to moving to the Raspberry Pi and I actually had a small server running on my laptop, directly connected to the Arduino. The Raspberry Pi was later added.
And in another “sadly” the dome has fallen into disrepair and has been completely torn down. If you go through that thread you can see I made some poor material choices.
They might give you some ideas. I was in the same position, head scratching with Visual Studio but the resources on the ASCOM site and working through some examples made it possible. It gives a huge satisfaction when it is done.
That’s exactly what is needed and it should be easy for anyone with the slightest knowledge of software to modify the code to work with different hardware, as long as the hardware is adequate.
One thing though, I’ve had a look at the USB relay devices and they don’t look adequate to me because they don’t provide any inputs. The driver should really have a way to tell where the roof is, notmally by reading the state of the ROR limit switches. These limit switches will be needed to stop the motor when the roof reaches its fully open or fully closed position.
The Velleman K8055 USB experimienters board kit is one that would work, it’s used in the Lesve Dome. The Arduino based controllers are almost as easy to set up though and much of the low level control can be delegated to that.
Well, to be fair, OP did say he was using a garage door opener…so some sort of “stop here” sensors are likely part of the system…relay would just be acting essentially like a remote or wall-mounted push button, if I understand correctly.
I have created a very very rough and ready driver for my relay now using just the basic ideas that @gboulton suggested. Clicking the open / close shutter buttons in SGP trigger the relay as expected.
I agree with @Chris about the use of limit switches and it being useful for the driver to know the position of the roof.
However, my garage door opener is programmed to stop here directly on the door control panel / motor, so the relay should just activate the motor, open the roof all the way, and then the same to close it.
I will eventually probably move to a board with a more in depth driver like the USB 440X or the velleman K8055 but for now, this is just a proof-of-concept to check if my garage door opener can be controlled by computer.
It absolutely won’t pass the conformance checker, (and in fact Conform tells me ‘this 64bit driver is only registered as a 32bit driver’, so conform can’t do anything with it anyway). Need to research about how to register it properly I guess. Google will tell me that hopefully
Now I just need it to stop raining to test it in the obsy.
Might take a few aborted trips to google, but I bet you can do it.
) that again talked to the HTTP server via REST. Overlapping calls didn’t matter and multiple clients were a non-issue as that’s just how HTTP works, although I did have to provide protection for the serial ports inside of the Flask server.