As far as I know nothing else is needed. The name of the file is not important, the startup procedure works through the .rules files in the directory. I think for testing you can run the starup manually with:
sudo udevadm control --reload-rules && udevadm trigger

Working with just one device plugged in at a time and just one of the two entries in the .rules file.

lsusb shows you the 2341:0043 identifying the Arduino?
ls -l /dev shows you the Arduino as /dev/ttyACM0?
There is no sign of /dev/roofCtrl?

If the one device does not show, remove it and try the other one and switch them in the rules file. You should be able to see one of the devices in the /dir and then be able to make some impact with the rules file. Once you can tell that the file is being seen and can make a difference it might be easier to figure out what is going wrong.

So my mistake, when you do ls/dev/, I still get the old Arduino port names, which I hadn't expected, however, the new names were there. With both ports plugged in the Rolloff roof connects and the driver works as before, the weather station does not.

I have not been able to get any of the arduino-based weather stations to work at all, even without the roof.

I might have to buy the Lunatico AAG CloudWatcher Cloud Detector. What do people think? Acxtually, I think it's probably better for rain, which I think the Arduino doesn't do well and wind.

Kind regards

Steve.

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.