> If i am right...My question now its... A0,A1,A2,A3 pins from arduino board, where should be connect in relays >module?

Yes that seems correct. The A0 - A3 pins are not for the relays (output), they are predefined to be input pins.
If you are just playing, any old on/off switch can be used to test the input pins. Connection outlined in previous reply.
Send a open request from the driver, that should result in the N1 relay activating. wait a bit then close the switch connected to A0. You will see the INDI driver change to the opened state.

Read More...

Javier,
The arduino.cc Uno Rev 3 is the one I was thinking of.
The arduino.cc Relay shield you linked will provide the easiest installation. It uses fixed assigned pins on the Arduino Uno. Those pin numbers are used by default in the rolloff.ino.standard.
For a one button controller use relay 1, for two button use relay 1 for open and relay 2 to close. The normally open relay connector is used along with the common.

On the input side the default pins will be A0 to indicate fully opened and A1 for fully closed. You can see these definitions at the start of rolloff.ino.standard. The uno's builtin pullup resistors are used so switch opened will be pulled up to the positive value. When the switches are closed your connection will be from the pin via the switch to one of the ground pins.
Given these hardware selections you will not need to make any changes to the ino code. Rename the sketch to rolloff.ino and place it in a sub directory named rolloff. Then use the Arduino IDE to load the sketch onto the board. Then you get the USB connection from the driver working.
Could bench test when you get the controller or get the controller working safely and reliably on the roof and then introduce the uno connection.

Read More...

For the small difference in price I really like the official arduino.cc products. There is a new variation of the Uno, I would use the latest version of the original standard Uno design. Same with the relay shield, arduino.cc rather than 3rd party or individual relays. Makes for a single unit to deal with and pins should match up with the ones pre-defined in the rolloff.ino.standard example. More than needed but quality and reliable. I would recommend getting the 12V supply to power the Uno not try to rely on the USB input. I'll look at the links you provided and check the rolloffi.ino.standard code tomorrow evening. Will check pin assignments and the input pins to use by default.

If you are going to build an Arduino based weather station, think in terms of a different/additional Arduino. Which model can be selected when you select the approach or product. INDI will coordinate with roof. Likely a Mega will be more than needed.

Read More...

Javier,

You do not need to build the driver it can be selected in the Ekos profile editor.
In case you have not seen it: github.com/indilib/indi-3rdparty/blob/ma...no/doc/rolloffino.md

You mention already having a motor. Perhaps you have a roof already working using a garage door or gate opener controller? If so then it is usually just a case of connecting into the existing controller via relay or relays. The rolloffino driver relies on an Arduino to provde that kind of control.
Parts needed when working with an existing garage or gate controller, chosen to work with an existing Arduino code example: An Arduino Uno, and a relay shield for it. Switches that get activated when the roof reaches opened or closed. Let us know what you have & we can get specific. You will need to install the V2 Arduino IDE to download the sketch.

/Tom

Read More...

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

Read More...

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.

Read More...

Stephen,
About distinguishing the Arduinos. Are you using /lib/udev/rules.d/99-observatory.rules?
Example to distinguish between 2 nanos, you can then refer to them like /dev/flpFlat instead of /dev/ttyACM0.
Here 2 Arduino nanos from the same product supplier:

# DeepskyDad FP1 Flat light panel, Arduino Nano
#SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0058", ATTRS{serial}=="D204FE65515146544E4B2020FF0C1723", MODE="0666", SYMLINK+="flipFlat"

# DeepskyDad AF3 Focuser Arduino Nano
#SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0058", ATTRS{serial}=="60E1ECB651514746304B2020FF0C324F", MODE="0666", SYMLINK+="focuser"

For the roof I have an entry like:
# Arduino Uno Rolloffino Roof controller roofCtrl. Arduino SA - Arduino Uno.
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0043", MODE="0666", SYMLINK+="roofCtrl"
and refer to it in INDI as /dev/roofCtrl Did not need the serial ID since it is the only Arduino uno

The rolloffino roof driver doesn't need building anymore since it is now included with the released product.

/Tom

Read More...

wotalota replied to the topic 'Weather station connection to Ekos' in the forum. 2 months ago

www.indilib.org/individuals/devices/weather-stations.html

When it comes to detecting bad weather conditions and parking the mount and closing things down you can consider using more than one of the weather options. 'Weather Safety Proxy' will consider input from up to 4 other named weather stations.

The WeeWX driver is another option, it supports some different weather stations including the Davis Pro.

With some DYI (Arduino wiring and coding glue) you can also supplement with individual local sensors. For example the Davis uses a rain bucket while an RG11 sensor can detect the slightest drops of rain. When adding a local sensor such as a RG11 rain detector using the 'Weather Meta' is handy. Then Weather Meta can be one of the inputs Weather Proxy considers.

Read More...

wotalota replied to the topic 'Rpi GPIO Driver crashes' in the forum. 2 months ago

Just came across this one in case it can be of use in the meantime.
indilib.org/develop/indiforjava/i4jdrive...-pi-gpio-driver.html

Read More...

wotalota replied to the topic 'INDI driver for Rpi GPIO pins?' in the forum. 3 months ago

Under Auxiliary > Other there is the rpigpio driver, it uses the pigpio service.
/Tom

Read More...

wotalota replied to the topic 'Weather safety proxy' in the forum. 5 months ago

Joshua,

Some things to look at to get started. Get the telescope in a safe position.

The watchdog is the key the weather proxy will notify it when notified weather critical. Install & run the watchdog timer. Is the telescope below the roofline safe or able to be parked. At the moment I'm actually not quite sure how to interpret the mount policy mount locks in the watchdog. I use mount ignored finding that the other settings first parks the mount then the roof. I would first experiment with mount locks. To discover how it interacts.



Set the watchdog triggers and the shutdown action checkboxes


In the INDI mount set the Dome Policy, can you unpark the mount when the roof is closed, or does a parked roof block.


Now the other way around in whatever roof control you are using can it close when the mount is unparked or must it wait for the parking to complete. I have a small scope installed so it is showing mount ignored and the roof parks without waiting on the mount to complete its park. You will probably want the setting 'mount locks'.


See if that gets it going.
/Tom

Read More...