Salut ;

Point de départ :
La problématique de la commande à distance et la sécurité de l'accès à la carte s'est fait jour.

Il y a des moyens pour sécuriser les connexions, un mot de passe sur la carte etc.

L'idée :
Je me suis dit, et si on accédait pas à la carte à distance, que ce soit elle qui accède à l'extérieur ?

Bon, je vous rassure je n'ai pas refait toute la prog de la carte, par contre le principe peut être retenu pour qu'un script Domos accède à un serveur sur le web pour s'y enquérir des changements à appliquer à la carte.

La preuve de concept :
J'ai rédigé une règle pour coller à ce concept.
Elle est disponible sur demande comme d'habitude.

Voici le principe :
- je récupère deux fichiers status distinct (un local, la carte, un distant, le site web) ;
- j'emploie les services de diff pour comparer ces deux status ;
- je récupère un fichier status différentiel ;
- j'agis pour toutes les commandes indiquées par "+<led"

Et tadaa ! Je forge une commande preset multiple (merci Freud pour le bout d'exemple de commande "&") et j'envoi ça vers la carte...

La suite :
Pour les courageux, il n'est pas bien difficile d'avoir un petit script php qui créera ou modifiera un pseudo fichier status sur un site dûment sécurisé. Voir même un ftp...

Voilà une prise d'écran entre le status sur le dépôt, et un status local tout éteint...



Edit : correction des fautes.


   [ Message modifié par  La_Brosse  le  14-10-2011  à  17:55 ] 

• Attachements

Salut La_Brosse,

Intéressant, encore un nouveau mode de comm.
Tu devrais peut-être préciser dès le départ qu'il s'agit d'une application sous Linux, ça ne parle pas à tout le monde.
Peut-être aussi accompagner certains termes de liens ou rapides description. Des gars qui comme moi ont seulement quelques heures de Linux derrière eux, voir pas du tout, peuvent se demander si ce sont des abréviations ou du jargon de développeur.



Je commence à te connaître, je m'en sort à peu près sur les grandes lignes
Utilisation des commandes diff et patch sous Linux

Sympa cette manière d'opérer, fallait y penser.
Ta démo nécessite actuellement 3 entités. La carte, un serveur web php, et un PC avec Linux (ou routeur customisé) pour collecter les infos puis transmettre les opérations à la carte.
Comment comptes-tu t'y prendre pour que ce soit la carte qui fasse le boulot ?

Et si on a toujours besoin du serveur php, en quoi la sécurité s'en trouvera consolidée en opérant de cette manière ?

Un détail, l'url telle qu'elle est écrite avec les & ne passera pas comme lors de mes essais.

++
Fred


   [ Message modifié par Freud  le  14-07-2010  à  12:01 ] 

Salut ;

Mea Culpa. J'emploie donc les services d'un petit outil du monde unix, "diff", qui permet de comparer ligne par ligne le contenu de deux fichiers et en sort une synthèse.

Pour le web php, un hébergement chez son fournisseur d'accès est résolument accessible à bon nombre d'entre nous. Moyennant la mise en place d'un petit portail privé comme le dokuwiki, npds ou encore Artiphp, on a facilement en main un petit espace privé disposant de quelques -bonnes- bases en matière de connexion.
Parmi les pages du portail , une page dédiée peut être mise en place afin de pouvoir écrire le fichier status sur le serveur.
Petit portail discret, page à accès limité, pas de carte du site (sitemap), il y a vraiment peu de chance que quelqu'un s'y intéresse. Contrairement à une carte en accès direct qui sera un jour ou l'autre référencée sur les moteurs de recherches.

Oui, dans mon idée c'est le routeur "modifié" qui, hébergeant un linux, va se charger de récupérer le status distant et de changer l'état des relais.

Sisi cela marche avec les apostrophes habilement placés de part et d'autre de la commande, le shell ne s'intéresse plus aux &...


Après reste à étoffer le tout. Soit on appelle une règle toutes les minutes pour qu'elle fasse la vérification. Soit on crée une règle qui tourne en boucle plus ou moins longue et fait son boulot à intervalles précis.
Mais là, je proposait juste le concept avec une règle bricolée à la va vite ; je n'ai même pas retiré le & inutile à la fin de la commande...

Salut,

Ok. Pour ma part je ne vais pas m'attaquer au routeur pour le moment. Il me reste déjà beaucoup à faire, et aussi la crainte de paralyser ma connexion par de mauvaises manip ou je ne sais quoi, parce que du coup après, plus d'assistance possible
L'idéal serait sans doute de dégoter un modem/routeur d'occasion, faire des essais en local en laissant donc l'existant pour conserver son accès internet, puis une fois que tout semble opérationnel connecter la box expérimentale sur la ligne télécom. Au moins en cas de soucis il sera toujours possible de remettre la box d'origine.
C'est peut-être ce que tu as fait ? Ton Linksys te sert uniquement pour tes essais ?

Quitte à devoir acheter une box spécifique (compatible, donc sous Linux) autant en prendre une qui aura suffisamment de mémoire embarquée et s'épargner ainsi de devoir trifouiller à l'intérieur comme tu l'as fait.
En gros pour nos futurs articles sur le sujet il nous faudrait proposer quelques modèles de box.

++


   [ Message modifié par  Freud  le  11-07-2010  à  10:05 ] 

Re moi,

Visiblement les possesseurs de Neuf Box 4, c'est mon cas, ont tout intérêt à s'acheter le même modèle pour leur application domotique. La NB4 figure dans une autre liste de matériels compatibles (tableau de tous les périphériques pris en charge à compter du 2008/07/21).
Elle à le statut "WiP", soit "Travaux en cours"

Avec ses 8 et 32 MB ça en fait un bon prétendant :



Détails pour la Neuf Box 4

C'est bien beau tout ça mais que faire avec tout ça ? Je ne suis pas très anglophone
En bas de page il y a un lien vers un site consacré à la personnalisation de sa NB4, en français ! J'irais voir ça de plus près.

++

• Attachements

Salut ;

Je suis d'accord avec toi, il est préférable de ne pas employer la passerelle "familiale" pour faire les essais. La NB4 est un bon prétendant avec de la mémoire et deux ports usb pour l'extension de capacité de stockage.

Pour ses caractérisitique, le Broadcom est donc le microcomposant qui fait tout le boulot. Cette société participe activement avec tous les développeurs, ses matériels sont très bien reconnus par les linux minimalistes. Celui ci est cadencé à 300 mhz soit 50% de plus que celui de mon vieux modèle sur le linksys.
La carte NIC sans fil, c'est le wifi. Un bon composant, avec une puissance d'émission pouvant être poussée très haut. Avec une très bonne antenne cela permet d'obtenir une liaison de qualité à grande distance.
Pour mémoire, entre deux linksys et une antenne perso d'un coté j'obtiens 250m de liaison entre 11 et 36 mbit/s.
Le boot wait, c'est une temporisation du matériel au démarrage. Cela permet de récupérer la main après un bidouillage hazardeux.
Le port série, c'est un port série... le Jtag c'est un port spécial utilisable pour remettre en place le système après un bidouillage très hazardeux.
L'usb 2 est sans conteste le meileur point, avec la possibilité de lui brancher n'importe quelle vieille clé usb pour stocker log, images, vidéos etc...



Par ailleurs, concernant le sujet de départ, l'interaction entre le status distant et le status local, voici de nouvelles idées.

J'ai proposé de comparer le contenu du status.xml, car ce fichier est assurément la pierre angulaire de toutes les interactions avec la carte. Mais on peut imaginer d'autres comparaisons de fichiers.

Par exemple : un jardin avec un arrosage automatique dont la commande pourrai être reliée à une carte relai.
Rien d'étonnant, avec les fonctions de programmation journalière disponible à présent dans la carte.

Mais pourquoi arroser si il pleut, ou si la météo a indiqué que le temps serait à la pluie ?

Là un script peux agir.
Le script récupère l'information sur l'internet, sur un site annonçant la météo locale, puis y recherche l'information cruciale "pluie" ou "temps pluvieux".
Si le test est positif alors, le déclenchement de l'arrosage ne doit pas être fait...

Bon, je vais faire une procédure d'exemple en employant les services de météorologic.net.
Ce site est bien fait, avec un portail assez léger qui fonctionne même sans les scrripts activés.

A cette adresse, je peux connaitre les prévisions sur Laval. Moyennant de filtrer le contenu, je peux donc faire en sorte que le script décide d'arroser ou pas si cela est nécessaire.


En raffinant le principe, on peux également coupler l'emploi du gestionnaire de fil pilote à la température extérieure moyenne en hiver.
Ou encore déclencher la fermeture du store-banne de terrasse en été si le temps passe à l'orageux....

A suivre.

Salut,

Ça c'est top !
Arrosage, chauffage, store banne, ... selon la météo. Que d'idées excellentes parties d'une toute autre réflexion. Comme quoi il est bond 'explorer toutes les pistes, une idée en appelant une autre.

Bravo, j'ai hâte de tester ça

Il serait bon de pousser encore la réflexion en cherchant d'autres champs d'applications, et partant pourquoi pas d'autres informations récupérés sur le net que la météo. Si quelqu'un trouve ...

++

Voilà un premier jet.

La règle concept pour le filtrage d'action en fonction de la météo est disponible dans le dépôt /Gawk :
le météo filtre

Description :
Je récupère la page web du flux rss, elle sera meteo_laval.
Je récupère la date du jour de la machine, juste le chiffre, aujourd'hui c'est 14.
Je défini une constante prevision pour, qui peut être un jour de la semaine suivit de la date + 1. Je cherche donc demain...
J'impose le mot clef qui me servira à définir le non besoin d'arrosage : averse.

Puis j'emploie les services d'une fonction crée par un autre de chez freeshell.org.

Je cherche donc la ligne indiquant la prévision pour demain, je note cette ligne index_demain.

Je cherche de la même manière les occurrences du mot clef dans la page meteo_laval.

Si il le trouve, une ou plusieurs fois, je test pour savoir si cette valeur apparait avant demain, c'est à dire aujourd'hui !

Je fais un afficher un message, je pourrai renoncer à l'arrosage, faire d'autres tests etc.


On peux aussi imaginer employer les divers mot clefs disponibles : couvert, pluie, averse
et leur attribuer un coefficient.
Et employer ce coefficient pour définir la durée de fonctionnement du relai de l'arrosage automatique. Nul pour une averse, 5 minutes pour pluie prévue, 20 minutes pour temps couvert, 1 heure sinon.

Il me faut donc à présent référencer tous les mots employés par météorologic pour leur prévisions et décider quoi en faire.




A noter, j'ai enfin fait une procédure sortant de l'entête BEGIN...


   [ Message modifié par La_Brosse  le  14-10-2011  à  18:02 ] 

• Attachements

Salut ;

J'ai récupéré les mots clefs apparaissant sur la page de la météo. Et j'ai concocté une fonction qui filtre selon le mot clef choisit et compte le nombre d'occurrences utiles.

Puis je concatène un petit message indiquant les divers temps répertoriés ce jour, et le nombre de fois.
Il ne faudrait pas grand chose pour que le test décide de lancer une commande d'action ou pas vers un relai en mode fugitif...

Je l'ai intitulée V2, elle est disponible dans le dépôt /Gawk.


Voici ce qu'elle me répond en cette fin de journée :




   [ Message modifié par  La_Brosse  le  14-10-2011  à  18:03 ] 

• Attachements