Done, done and done.
The code that limits the dust cover position for the light source was removed on August 17th 2017
Updated the repository, as this is a good fix.
So in a month or so, I will start updating my obsy to get it ready for the autum, and close to robotic?.....
Initially I would just use indi_wiringpi_gpio to se if microswitches was triggered to see if roof is open close, and mount is parked. At the moment there is no good way to to tell the mount or dome drivers to 'care about' the switch states.
I could implement a update in the mount and dome driver I'm using, but it seams a little hackish.
So what about a indi_sense auxiliary device that mounts, domes, 'and more?', could snoop on to sense state of physical devices.
If there is a superclass with 'bool mountIsParked', 'bool domeIsOpen', 'bool domeIsClosed', etc, then other sensing could be added as a subclass without any changes to the overall device.
I would add a config tab to setup witch wiringpi_gpio pins that checks mount parking and dome state, but other hardware like @Gonzo's gyro to test mount park state 'could' be added as a subclass that implements the 'bool mountIsParked' method.
Is this something others think is good, nice or necessary? Is this a good way in doing this, or is there a better way?
Like to hear what you think.
First of all, thanks for being so patient and locating the issue.
My servers are remote, so I do not do any dist upgrades remotely.
For me the imaging seson is pretty much over at april 22. as there is no more true nighttime here in at my latitude. I will try to image the next full moon, but then there will be no more imaging before ~ August 22.
I have several things to fix / upgrade in my obsy, and one of them is using wiringpi_gpio to sense roof state, and telescope parking in an attemp to move to a closed loop robotic observatory
I will then collect my servers from the remote location, take them home, and get everything up to code.
For now all of INDI works with the setup I have, but as you say it's likely for issues to arise eventually.
~/Projects/indi $ git log -1
Date: Sun Apr 8 21:36:55 2018 +0300
Fix armhf build on Launchpad
gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Raspbian 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.9.2 (Raspbian 4.9.2-10+deb8u1)
I'm getting rid of my OSSAG to get a fully working no hastle guide camera.
I know from other posts that the Lodestar and Lodestar x2 works great. Is this the same for the CoStar? www.firstlightoptics.com/guide-cameras/s...cmos-autoguider.html
The Lodestar is a little to expencive for me, and with a short focal lenght, I do not think I need it.
The CoStar seams like a nice guider, but it is of cource the functionality with indi and ekos that is top priority
Sorry to hear that you are having sutch dificulties with this driver.
For some reason I cannot reproduce this still.
I Recompiled the wiringpi library and indi_wiringpi_gpio with no issues.
I have however not updated the wiringpi library in quite a while, as the version i'm using works, and I have not made any dev to the driver in a while.
Just to be sure, I'll upload the library I'm using to google drive. I you have time to test if it makes any difference, that would be great.
Link to the lib drive.google.com/open?id=15V7A0tJ4mlCVVq5E8bYl2UfD7hR6iBTF