Recently I've been an infrequent user of the experimental driver(CP4). I sometimes encounter issues with it heading off in the wrong direction but have not defined the conditions well enough to submit a problem report. If used for a single target in a session it seems okay.
Invalid pier side response is an older issue that still occurs sometimes. Might be timing related only seen when using an ethernet connection. It seemed to be that some prior command to the mount had not waited for a response. When that response came back the driver confused it to be a response for the most recently issued command.
On the RPI there should be a file put there by the build you did.
I run Ekos and the drivers on the same computer and there I can see the driver. I am unsure whether if the above file was in an equivalent directory on your MAC if that would allow the rolloffino driver to be seen like those drivers provided by the normal install.
On the MAC in your Ekos profile, in addition to the drivers you use from the normal install try adding the rolloffino one using the remote specification.
Just below where you select the drivers is the Remote field showing the syntax to use. If you hover over that field it show some specific examples. You want to use the name of the driver in a quoted string where case and spaces are significant.
indiserver needs to be running on the RPI for it to work, perhaps the use of INDI web manager will take care of that? Port can default to the indiserver's default of 7624
The MAC is running the Ekos client. The RPI server is where the drivers including the roof driver is running. It is on the RPI where you have already built and installed the driver. Then it does not seem there is an additional build needed on the MAC or am I misunderstanding?
Do you just need to be able to refer to the remote roof driver in the Ekos profile editor on the MAC?
I updated the roolloff.ino.standard example with the same structure as the .ar1450 and the how-to description. Its setup is now for the Uno model using pullup resistors. Did a basic test of it using a Uno relay shield. There was an issue after uploading the sketch to the Uno the first use of the connection after that took several seconds to respond. The driver was modified to log a warning before continuing instead of an error. Consider running the build again to pick up these modified files.
From your info about what you are running there should not be a version mismatch issue. I don't understand the Ekos live and websocket relationships but no reason to suspect that or Stellarmate related.
If you have the debug log matching the Kstars log there might be additional info there.
From the Kstars log this is a startup situation, not the case where you were able to close relays and read the switches. It is probably the initial connection message that failed although the logging is not clear about that. What is strange is that it is the Arduino returning an error indicating a syntax error for what is probably the driver's initial canned request for its version number. This could happen I suppose if the baud rates between the two did not match or there was some other communication problem.
This initial exchange between the driver and the Arduino is taking place in the context of establishing the initialization and connection between Ekos and the driver. I think the failure to establish this causes the driver to be shutdown.
by the indiserver. Some debug logging might need elevating to error messages if there is anything helpful there.
Meanwhile perhaps you can watch out for communication errors and and see if there are cases that occur other than when first starting.
The Arduino examples are included in the install and left in place in the 3rdparty sub-directory. Will make that clearer and reference some Arduino SDK doc that describes how to use them.
Attached is a first pass to capture some of this for Jasem's suggestion for a HOWTO. Any suggestions that would make it easier to get started.
On the MacOS. There is a good chance that the driver code will work on the Mac, but it will need to be built and installed according to Mac procedures. The present directions in the INSTALL file did not include any thought given to how that is done. For example the apt-get is a Ubuntu specific command. I did get a Mac but since you said it was the RPI4 you were going to use I have not done anything with it. If you intend to run a Mac in the observatory I can spend more time learning how to use it.
The files you posted appear to be the rolloff debug logs or fragments of, just showing the commands and results, most ending in timeouts. Was one of them in particular associated with the crash?
Do you have the KStars log associated with the crash? Did Kstars put up a message indicating the driver had crashed?
The only time I have had the driver crash was when the version of indi / Kstars it was built against was different from the one installed. Although that always happened when starting. If the version you built against in the ~/Projects tree was the one that was cloned into ~/Projects/indi then it would have been the nightly build.
The Kstars and indi versions running for the testing should be from a nightly or the current stable release since I have been using the driver on those and perhaps the previous release without a rebuild.
Look at the INDI window for the roof driver main tab. It will indicate if it is connected or not. The buttons and status lights will show what switches it has detected as closed. Using the park unpark buttons will try to activate relays.
What code are you running on the Arduino and what kind of roof control do you have or intend to get. Are you presently working using a bench breadboard kind of setup?
I think in the external directions there is a git clone of indi development files. Check
INSTALL.txt it might have been missing from the original.
Krish,We might not have the directory files placed and the defaults set to the expected place.Before running the cmake command. Check that the following things are true.In the ~/Projects there are 2 directories that have been populated "indi" and "indi_3rdparty".In ~Project/indi_3rdparty/indi-rolloffino/ are the files from wotalota github.Your default directory is ~Project/indi_3rdparty/indi-rolloffino/buildI made some edits to the INSTALL file, not checked in yet, to try and be more explicit. Take a look and see if it helps.I'm replacing the readme file with one with examples and more detail about the Arduino sketch. Will attach after getting through a first pass. Any suggestions to improve and additions that would help getting started are appreciated.
It might well have to do with building on a system that does not have KStars installed. The last part is the install which includes making the driver available in the Ekos profile.