Peter, I have decided not to use the Pi (for now). Since I need to have the windows PC in the observatory anyway the Pi sort of lost its advantage. I can not run everything from it anyway.
My current idea is to run everything except the dome from wINDY. The dome is slaved to the telescope in the Ascom driver so it should move according to the scope position. I don't really need any separate dome control or movement.
Do you think that this may work?
During the Dome driver development we discussed to create a "Sync" driver to sync telescope and dome, but finally the idea of add sync capabilities in the Dome driver itself, prevailed. The other idea were more flexible.
However it could be possible to write a "sync only" Dome driver in Linux than snoops to the "wrapper" Dome driver in Windows and also snoops the Telescope Driver to perform only the Sync functionality. The Windows Dome wrapper must disable the sync properties, and use only the most simple command, like open/close, position and configurations.
Helge, I also like your solution, at least for now.
As an FYI, I am working on a Raspberry Pi3 /Piface Digital 2 controller. For the first rendition it will be for a ROR but hope to expand to a dome a bit later. One-Wire, and other relay/IO cards should be easy to support, at least I am trying to make it so.
I started one last year based on an IoT framework, but that turned out to be to limiting both for long term support and to get connections into the various client software packages. I have just started coding the new version, so nothing right away. The Server is in "C" and won't know about ASCOM, INDI or the Web...
The current vision to to have a configured server that runs 24/7 to keep the observatory "safe" and "ready". The server will be responsible for keeping the observatory safe: closed if raining, closes if no activity, turn on heat/cooling if cold, damp or hot and so on. At some point the server will be able to send an email or text "FIRE".. well, hope not that one.
Separate processes (communication through IPC) will handle the INDI interface, and serial (?) interface to Ascom and a Web interface. This way if an interface fails, the server still operates. I'll start a thread once the system has a heart beat. These interfaces will issue "requests" not commands, the server will in most cases be able to ignore requests that put the system in danger. There may be an over ride that is password protected via the web interface... TBD.
Well, that's enough for now. Hopefully it will be workable and worth the wait... For those with a ROR, especially one with a garage door opener, AstroBerry-Piface and some scripting in EKOS should get you started. That's my plan if the mechanics are done before my controller.
Thanks for your info. You really seem to have started something. I'm looking forward to see the results of that.
I just found out the other day that Kstars in the Windows version is not supporting plate solving. That was probably the final drop that will force me to leave Kstars and Indi all together. I really liked the idea of remote control and all the other features, but it seems like Kstars is primarily for Linux users and not so much for us Windowsers.
I have been testing Sequence Generator Pro in parallell with Kstars and it does very much the same things. It is not free and it does not have the same remote operation capabilities, but it is created for Windows and it works for me. I can remote operate it through TeamViewer though.
Seems like I have a spare RaspberryPi.
Helge, we've been exploring along similar paths and I do understand. I downloaded the trial SGP but didn't have time to understand it and the trial period is I'm sure over. RTS2 and/or SGL are on my fall back path from KStars/EKOS. I'm pretty optimistic at the moment though. Once I get the hardware up (rebuilding the scope mount too, I will revisit if needed.
For all the talk on all sides, cross platform operation just doesn't seem to be there yet. If you want to run INDI/EKOs, I would personally use a Linux system. If you have to have ASCOM, then Windows based computers. I know people are doing the mixed platform thing, I just don't have the patience nor see the need (computers are sooooo cheap).
For now, I need an observatory controller that will protect the equipment. Here, that really means some heat when it's cold or damp. The heater will probably be a light bulb, won't take much, but would help a lot. As long as I can talk to it with INDI, ASCOM and across the network I should be covered.
Astrometry.net is not supported locally yet on the Windows machine. However, you can install astrometry.net on the Raspberry PI and use everything else from Windows. Ekos supports remote astrometry.net solver on the Pi.