Yes if the ls -l /dev/roofCtrl you will see it just links to one of the /dev/ttyACMn connections. Same with the one assigned to the weather nano.
So hopefully you can now communicate with both drivers and not have to deal with confusion between the when making the initial connection.

I don't have anything to offer with the choice of weather station. But if I followed along right you have fixed the build errors you were having on the Arduino side and can receive JSON strings at the driver. You mentioned timeout warnings and partial strings. So you might be getting close with the Weather Radio? Assuming you are past the obvious things like baud rate settings perhaps being specific with what you are seeing and posting the logs and examples of the partial JSON strings might assist those with Weather Radio installs to understand where you are with the debugging.
There is also apparently the option of using WiFi with the Weather Radio.
github.com/indilib/indi-3rdparty/blob/ma...adme-WeatherRadio.md

So I'm alternating between WeatherRadio and indiduinoMETEO, they both seem to have the same problem. If I use METEOtest, all the hardware works nicely through the Serial connection. When I switch back to either of the other ones, the driver doesn't connect. Also there is nothing in the logs. I've switched on all the options I can find, like 'verbose' etc. The baud rate is set properly, but the connection tag is red. As far as I can see the difference is firmata. Indi-rolloffino also does work and that doesn't use firmata.

I feel a bit lost.

I could potentially hand-roll my own third party driver based on the indi-rolloffino driver, but it seems like a lot of hard work. That's why I'm thinking of moving away from INDI-duino to Cloudwatcher etc. And obviously there is a cost involved.

Kind regards

Steve.

Actually, there is something in the WeatherRadio log, but not InduinoMETEO

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.