Actually I'm successfully using RollOff.ino (with some modifications) with my long-standing roof controller built around a R-Pi. I've had to bring out the relevant lines and attach them to an Arduino (a Nano 33 BLE in my case) but it all works fine. I'm also using a weather input -- in my case (for now) the WeeWX driver, where the WeeWX is running on a R-Pi too (reading from a Davis thingie).

However I have a CloudWatcher, which is much more adapted to an observatory: the rain sensor is much, much more sensitive. There is a driver for that in INDI, but I want to make a new driver. The latest version of CloudWatcher includes an SQM-quality light meter. I am the author of the macOS version of the CloudWatcher app and I have agreed with Lunatico a new format for the JSON file produced by their(Windows) and my (macOS) app. This includes the SQM value too.

I want to write an are INDI driver for this but am having trouble making a build environment on macOS. Then I will have to face the problem of getting JSON data from a file instead of via TCP.

But we will get there eventually !

Cheers,
Richard

PS: I recommend Lunatico's CloudWatcher - it's sensitive and well adapted to observatory use.

Hi Richard,

Thanks for that.

I thought I might get a quick and dirty weather station going, but it's too hard, and doesn't really include rain, which is the must-have component.

My rolloff.ino software seems to work in a test rig, so I can start to implement that.

Then I'll go the Cloudwatcher route. Do you have the Cloudwatcher on the RPi as well?

Thanks for that,

Kind regards

Steve.

Do you have the Cloudwatcher on the RPi as well?

That's an interesting question. The IDE I use for CloudWatcher can build for R-Pi as well. In fact it's what I use for my R-Pi-based roof controller. So I'm pretty sure I could build a version quickly. But my past experience is that spacings and text sizes are not the same on macOS and Rasbian. I would have to change every one of them manually, and there are thousands of them ! Otherwise the quick working version would be unusable because it's illegible.

But I'll give it a try,

The other thing is that the macOS app is not free -- I have to cover the cost of the 99€ annual fee to remain an Apple developer somehow. But the R-Pi is a different ecosystem and, if I can find the time to do the port, it'll be free for R-Pi.

There is already a CloudWatcher AAG INDI driver for RPi, so it should be OK.

If it doesn't work, I'd like to know before I go down that route!!

If you're able to give it a spin, I'd love to know.

Kind regards

Steve.

There is already a CloudWatcher AAG INDI driver for RPi

I know there is, but (a) it doesn't support the new SQM ability, (b) it needs a direct connection (serial via USB) to the R-Pi. This is fine if you have no other use for the CloudWatcher.

But the native (Windows) CloudWatcher app, and my macOS one, both support remote use via a dedicated transfer file, and they use the same transfer file so can interoperate. So you can have a Master version running in the observatory and a client running in your office, and the client(s) can have independent parameter setting so, for example can respond to different thresholds. They also both generate a range of additional files like the ClarityII (Boltwood) format files.

In fact I will test the R-Pi function exactly in this remote/client setup.

So I want to keep my CloudWatcher hardware with its present connections and that's why I want to write an INDI driver which uses the JSON file instead.

It turned out to be much more work than I expected to get the R-Pi version working. CloudWatcher on the Mac uses scripting for many features which, in an INDI environment, will be handled directly by a client. So I've stripped them out, which removes a potential major headache oil porting.
But, it's been in development for well over a decade and uses various things which are now defunct, or were never available on R-Pi (these are mostly to do with preferences, of which there are hundreds). So I've had to rewrite quite large bits of it. Now it's working, but it still has the GUI peculiarities which will need tuning and adjustment. So, a work in progress, but, there is progress !

Hi Richard,

That sounds great. I have the Weather Radio Arduino bit working perfectly. The Json seems fine, the INDI client connects and recognises it, but Ekos doesn't seem to collect any data. I don't really understand what's going on.

I'm going to send you a PM.

Kind regards

Steve.

I'm following up on a call with Stephen following his PM. I'm attaching a couple of PDF files which show the connection between various things in the observatory, and the equivalent in my office/workshop where most of the hardware is emulated with either duplicated or representative hardware. The CloudWatcher hardware is on the top row and feeds a local computer (a Mac mini) via a USB/RS232 converter and, as well as displaying results locally, outputs a range of transfer files:

• a binary file (identical to the file used by Lunatico in their Windows software) which enables remote instances of CloudWatcher, including the R-Pi version I'm now working on.
• a file in the same format as the ClarityII file produced by the Boltwood sensor (extended to include SQM value)
• a JSON file with current values
• a rolling file containing selected values covering the last 24 hours
• an archive file appending current values to all historical values

This is why I'm reluctant to use the dedicated INDI driver for CloudWatcher and would prefer to develop a driver to read the JSON file.

Hi Richard,

Very cool. The attitude sensor, what is that? Does it work out the tilt of your scope?

How much of this can you link into INDI?

Kind regards

Steve.

The attitude sensors measure the attitude, essentially pitch (altitude) and roll (hour angle), or something equivalent. There is a unique combination of the two which indicates a safe park position, and that is what is checked in the Pi-Box software.

All of the items in the purple-coloured boxes are already linked. The ones in the paler purple are on my list of drivers/connections to make. The Pi-Box stuff is all linked via my version of the rolloff.ino driver, except I need to extend it a bit to handle the emergency and safety stop responses.

Cheers,
Richard

I haven't said until now is why the items in the file interfaces (seeing, SQM/darkness and weather/clouds) are interesting. You asked during the call. It's because I would like to find a way to include them in the FITS headers to help in weighting or eliminating images during processing in PixInsight.

There is so much information on weather, it would really be nice to have another tab in Ekos to store the readings, don't you think?

I wonder if we can suggest it as a proposal.

Kind regards

Steve.