Est-ce que cela intéresse qqun,un driver indi et code arduino pour l'ouverture d'un toit à distance ?

[olivier1986]

il y a 22 minutes, Fred_76 a dit :

J'ai corrigé ton pb de double envoi de CON:0:0

En effet, le problème est corrigé!

je n'avais pas vu ce double emploi du parsecommand!! a force d'avoir les yeux dessus on fini par plus rien voir

 

merci Fred.

 

Pour info, j'ai fini le modèle 3D de la boite dédiée au module du toit avec:

l'Arduino, les différentes fiches (mêmes celles non utilisées pour d'autres personnes ou pour une futur évolution facile à mettre en place) et le module 8 relais.

reste plus qu'à imprimer tout ca.

 

Je peux fournir les plans de constructeurs boite + PCB.

Le joins le code modifié ici.

 

Merci Fred.

 

Olivier

RollOff_codefinal (4).ino

[ch_porchet]

Hello les gars !

Cool le travail que vous faite !

Malheureusement , comme dis au debut, je suis vraiment pas bon en code,je suis juste arriver à faire le système d ouverture manuel et le reste c est Tom qui a tous fais.

Du coup tu pense bien que le python c est pas pour demain ......

 

Je pense que on devra sûrement  mettre la version définitive du code à quelle que part, peut-être sur indi.

 

Pour la macro ,il faudrait juste faire une tempo entre la commande de l'alimentation et le reste. 

Mais du coup je pense que c'est plus simple de faire la tempo entre le rolloff et le reste. 

 

A+

[Fred_76]

Attention à ne pas trop mélanger les interruptions par timer et les delay... sinon ça risque de faire des trucs bizarres difficiles à débugger.

 

Le mieux est de tout gérer avec des interruptions par timer et ne placer des delays que lorsqu'il n'y a pas de timer en fonctionnement.

 

Un peu de lecture : https://www.forward.com.au/pfod/ArduinoProgramming/TimingDelaysInArduino.html

 

Une interruption par timer appelle une certaine fonction dès qu'un lapse de temps s'est écoulé. Ca peut se produire n'importe quand. On doit donc gérer le cas (généralement peu probable, sauf si cette fonction fait une pause avec un delay) où une fonction est appelée alors qu'elle n'est pas achevée. Une fois que la fonction appelée est achevée, le programme reprend son cours là où il s'était arrêté.

 

Un delay va juste suspendre l'exécution du programme pendant un certain temps, et rien d'autre ne se passe pendant ce temps, sauf les appels d'interruptions.

 

Si on mélange les deux, on peut alors se retrouver avec une fonction appelée pendant une pause, ce qui n'est pas trop grave en général, mais pire, une pause appelée pendant qu'une fonction est appelée. Là ça peut provoquer des choses étranges et globalement aléatoires.

 

[olivier1986]

tout à fait d'accord avec toi Fred.

[ch_porchet]

Ok, mais moi je pensait à une action dans kstars et pas dans le code arduino.

 

[olivier1986]

Le 18/06/2021 à 21:59, ch_porchet a dit :

Ok, mais moi je pensait à une action dans kstars et pas dans le code arduino.

 

Salut Christophe,

 

je suis pas sur d'avoir tout suivi!

Ce que tu souhaites, c'est que lorsque tu lances Kstars / EKOS, c'est que l'alim se déclenche, que le toit se connecte mais que tout le reste se connecte genre 5s, c'est bien ça?

Le 14/06/2021 à 19:07, ch_porchet a dit :

Comme tant que le toit et pas ouvert ,les caméra,roue à filtre,etc ne se connecte pas.

 

Avoir obligatoirement le toit ouvert pour connecter les accessoires est pas top à mon avis 😕

[ch_porchet]

Il y a 3 heures, olivier1986 a dit :

Ce que tu souhaites, c'est que lorsque tu lances Kstars / EKOS, c'est que l'alim se déclenche, que le toit se connecte mais que tout le reste se connecte genre 5s, c'est bien ça?

Hello Olivier 

Exactement, car la, si tu veux, c'est un peut aléatoire du faite que tous se connecte en même temps.

Y compris l'alimentation des caméras commandé par le relais alimentation. 

 

Il y a 3 heures, olivier1986 a dit :

Avoir obligatoirement le toit ouvert pour connecter les accessoires est pas top à mon avis 😕

Après réflexion, en effet tu as raison, c'est pas le top.

A+

[olivier1986]

il y a 25 minutes, ch_porchet a dit :

Hello Olivier 

Exactement, car la, si tu veux, c'est un peut aléatoire du faite que tous se connecte en même temps.

Y compris l'alimentation des caméras commandé par le relais alimentation. 

 

Après réflexion, en effet tu as raison, c'est pas le top.

A+

Ok.

Donc si je comprends bien ce qui serait vraiment cool c'est d'avoir un séquençage du lancement des différents drivers!!

et ca j'avoue que ça me plairai aussi.

par exemple je vois bien un truc du genre:

1- meteo

2- toit

3-focuser

4- cam guidage

5- cam

6- monture

 

Alors pour ce genre de chose je pense qu'il faudrait voir si cela existe sur les fofo INDI (à Jasem ^^)

Si c'est pas le cas il faudrait leur demander si c'est possible. (je pense que oui).

Et si c'est pas possible alors il faudrait passer par une boite de relais pilotable depuis l'interface. Il y a les driver indiduino qui permettent de faire ça facilement.

Mais ca rajoute des relais sur des relais et ça complique l'installation et rend l'automatisation bcp plus coriace.

 

Le top serait que cette fonctionnalité soit, soi existante, soit développée dans les futurs MAJ

 

Olivier

 

edit:

 

j'ai lancé une dicussion sur INDI ici:

https://indilib.org/forum/general/9886-order-start-driver.html

 

a+

Olivier

Modifié 24 juin 2021 par olivier1986

[olivier1986]

Bon et bien Jasem a répondu.

Le démarrage des drivers est un processus stochastique, donc on ne peut prévoir quel driver va démarrer en premier.

Il ne reste donc que la possibilité des les démarrer manuellement un par un ce qui pour un automatisme complet est pas possible.

Je vais réfléchir à une solution pas trop compliqué.

 

Dans un premier temps je pense que séparer l'alimentation des accessoires de l'alimentation du toit est une bonne chose.

Je m'explique: Si tu veux lancer une session de dark en pleine journée tu n'as pas forcément envie d'ouvrir le toit pour faire ca.

Donc en image ce que j'imagine pour la partie elec de l'observatoire (de tête sans trop réfléchir car pas encore défini, mais à la grosse  ).

Alors cette je ne profite pas de la tempo pour l'alimentation des accessoires mais je compte utiliser un switch sur le 220V via un petit nano et une utilisation via HTTP.

Donc j'allume tout via internet et je peux tout éteindre via internet le matin. On peut aussi automatiser cette tâche avec un petit script dans EKOS.

 

A voir...

 

Olivier

[ch_porchet]

Alors j ai hélas vu la réponse de Jasem!

Par contre je comprends pas le mot "processus stochastique" ,cela veut dire que c est aléatoire ?

Alors chez moi (et je me souviens plus si je te l'ai déjà dit) , mais mon relais alimentation fais deux chose, la première il me coupe tous le 230v dans mon observatoir ,sauf l'ardino qui gère le toi,mon mini pc ( kstars) et une ardino pour la météo. 

Alors que vas t'il alimenter , le transformateur 12v pour le moteur du toit et des prises 220v pour les caméras ,la monture ,etc.....

 

Mais quand même dommage que l'on peut pas faire que kstars lance les drivers en "cascade" avec ou non la possibilité de mettre des tempos.

 

A+

Christophe 

 

 

[olivier1986]

Il y a 11 heures, ch_porchet a dit :

Par contre je comprends pas le mot "processus stochastique" ,cela veut dire que c est aléatoire ?

 

Oui c'est tout à fait ça.

Cela se traduit par le fait qu'un système n'a pas de choix prédéterminé.

En effet c'est dommage et j'aurais penser possible cette action, en forçant le type de driver à démarrer dans l'ordre, quelque soit le driver.

Maintenant, si cela n'est pas possible, le seul moyen est de démarrer à la main et un par un les drivers.... méthode pas orthodoxe si bcp de driver!!

 

je réfléchi à une solution.

 

Je comprends que dans ton cas l'ensemble du 220V observatoire est géré par le bouton ou par la commande kstars.

cette solution est séduisante. Cela implique, si tu veux travailler la journée dans ton abris, d'appuyer sur le bouton pour forcer l'alim.

mais au bout de 5 min d'inactivité le courant se coupe non?

 

 

 

[ch_porchet]

Il y a 12 heures, olivier1986 a dit :

mais au bout de 5 min d'inactivité le courant se coupe non?

Alors non cela ne se coupe en mode manuelle .

Mais je vais vérifier, car chaque fois que je le fais , j'ai kstars qui tourne derrière. 

Je te redis. 

A+

[Fred_76]

Une alternative au démarrage manuel des drivers serait de lancer un premier driver, et de surveiller son installation. Une fois qu’il est installé, le programme lancerait le second et ainsi de suite. C’est faisable car normalement Linux - commande lsmod a priori - (et Windows) ont une commande qui permet de connaître la liste des drivers chargés en mémoire.
 

C’est un module à programmer et qui serait alors lancé par Indi à la place des drivers, vu que c’est lui qui chargerait les drivers.
 

Par contre l’exécution sera bien plus lente car les drivers ne se lanceraient que les uns après les autres au lieu de tous ensemble.

[ch_porchet]

Le 07/06/2021 à 14:00, olivier1986 a dit :

Manip à suivre:

- tu vas dans le répertoire indi où sont stocker les "3rd party"  (de base c'est dans le dossier Projects)

- tu ouvres un terminal depuis de dossier et tu tapes :

git pull

-> cela va mettre à jour le répertoire "3rd party"

- tu fermes le terminal

- tu vas dans le dossier indi-duino et tu ouvres un terminal

- dans le terminal tu lances les commandes suivantes:

mkdir build

cd build

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug ../

make -j4

sudo make install

 

Après l'installation tu lances kstars et dans la version tu devrais lire 1.14

hello

alors j'arrive pas a faire ces manip, j'ai des erreurs durant l'installation 

a+

[ch_porchet]

Hello Olivier ,

Deplus je n'arrive plus a relancer  weatherradio

NAFABox:~$ sudo service indi-weatherradio start
[sudo] Mot de passe de nafa : 
nafa@NAFABox:~$ sudo service indi-weatherradio status
● indi-weatherradio.service - INDI server for weather radio
   Loaded: loaded (/etc/systemd/system/indi-weatherradio.service; enabled; vendo
   Active: failed (Result: exit-code) since Sat 2021-07-10 15:30:16 CEST; 4s ago
  Process: 4199 ExecStart=/usr/bin/indiserver -vv indi_weatherradio >> /tmp/weat
 Main PID: 4199 (code=exited, status=1/FAILURE)

juil. 10 15:30:16 NAFABox indiserver[4199]: Child process 4240 died
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_wea
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_wea
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_wea
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_wea
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_wea
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: good bye
juil. 10 15:30:16 NAFABox indiserver[4199]: Child process 4241 died
juil. 10 15:30:16 NAFABox systemd[1]: indi-weatherradio.service: Main process ex
juil. 10 15:30:16 NAFABox systemd[1]: indi-weatherradio.service: Failed with res
lines 1-16/16 (END)...skipping...
● indi-weatherradio.service - INDI server for weather radio
   Loaded: loaded (/etc/systemd/system/indi-weatherradio.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2021-07-10 15:30:16 CEST; 4s ago
  Process: 4199 ExecStart=/usr/bin/indiserver -vv indi_weatherradio >> /tmp/weatherradio_output.txt (code=exited, status=1/FAILURE)
 Main PID: 4199 (code=exited, status=1/FAILURE)

juil. 10 15:30:16 NAFABox indiserver[4199]: Child process 4240 died
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_weatherradio: pid=4241 rfd=0 wfd=5 efd=6
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_weatherradio: sending <getProperties version='1.7'/>
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_weatherradio: indi_weatherradio: symbol lookup error: indi_weatherradio: undefined symbol: _ZN4INDI10BaseDev
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_weatherradio: stderr EOF
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: Driver indi_weatherradio: Terminated after #10 restarts.
juil. 10 15:30:16 NAFABox indiserver[4199]: 2021-07-10T13:30:16: good bye
juil. 10 15:30:16 NAFABox indiserver[4199]: Child process 4241 died
juil. 10 15:30:16 NAFABox systemd[1]: indi-weatherradio.service: Main process exited, code=exited, status=1/FAILURE
juil. 10 15:30:16 NAFABox systemd[1]: indi-weatherradio.service: Failed with result 'exit-code'.
~

 

[olivier1986]

@ch_porchet

salut, as tu mis a jour les scripts via le raccourci sur le bureau?

et es tu sur de faire l’installation depuis le bon répertoire ?

 

en MP donne moi un acces via vnc ou TV voir si je peux regarder 

[ch_porchet]

Hello Olivier 

Tu as réussi à te connecter?

C est juste pour savoir 

 

Modifié 10 juillet 2021 par ch_porchet

[ch_porchet]

hello Olivier

Alors visiblement j'ai de nouveau weatherradio qui se stop après un moment .

je vais voir cela se soir et je te redis

 

a bientot

 

[ch_porchet]

Alors précision, visiblement c est que la page Web qui déconne. 

Car depuis kstars c est bon.

[olivier1986]

Salut Christophe,

 

as tu essayé de lancer la page web depuis un autre navigateur? depuis un autre terminal? genre depuis ton téléphone, tablette un autre pc?

[ch_porchet]

hello

alors c'est tous bon ,j'ai effacer le cache du navigateur.

Par contre il faudra que tu me remontre deux choses

la première c'est comment faire pour ouvrir l'accès depuis n'importe ou, et la deuxième c'est comment on force a garder cette ip.

 

A bientot

[ch_porchet]

Hello Olivier 

Je reviens vers toi car j'ai un soucis avec wetherradio, ma page et bloqué sur un jour et j'arrive pas a la relancer, as tu une idée de quoi cela peut venir. 

Et de plus j'arrive toujours pas a avoir l'acces de puis un autre pc qui est pas sur le réseau. 

Merci A+