Introduction

Webx est un projet de domotique open source. TLD lui dédie cette section afin de mieux supporter ses utilisateurs?

Modérateur: shen

Re: Introduction

Messagede shen » 16 FĂ©v 2012, 11:01

Salut !
Alors avec le super tuto de poulpy non, c'est faisable ... http://www.poulpy.com/2010/03/le-tellstick-sous-linux-avec-xpl/

En revanche, ça mérite un petit travail supplémentaire poour l'intégrer dans mon projet...
Je suis en train de valider une mise à jour lié aux authentifications des utilisateurs, quand j'aurai fini cette mise à jour pourquoi pas !
Si cela t'intéresse et que tu es prêt à faire quelques tests pour moi (car je n'ai pas de tellstick duo), c'est faisable :-)

Tiens moi au courant en MP si besoin
Cordialement
Webx - Solution domotique open-source
Linux - HTML/AJAX/PHP/PERL
Slim Framework - Jquery mobile
--------------------
Serveur domotique - sheevaplug/raspberrypi
---------------------------
Rfxcom lan (v2/v3)
X10 - X10 security (LM12/AM12/SD18/LM13)
Chacon (télécommande KCT510/interrupteur LWST615)
shen
P'tit Guru de domotique
 
Messages: 90
Inscription: 30 Juin 2010, 09:25

Re: Introduction

Messagede JejeConcept » 02 Avr 2012, 16:11

Bonjour!

Je me lance en domotique, et je penses partir sur une installation basée sur du z-wave.
Or je cherche une solution open-source pour commencer à bosser sur mon serveur perso, et ton projet a l'air particulièrement proche de mon objectif.
Sachant que pour l'instant tu t'es concentré plutôt sur la techno X10, je te propose mon aide pour commencer à y implémenter la techno z-wave ou même tout autre projet ou tu aurais besoin d'un coup de pouce.

Cdlt
JejeConcept
Membre un peu timide !
 
Messages: 1
Inscription: 02 Avr 2012, 15:45

Re: Introduction

Messagede shen » 02 Avr 2012, 17:20

Salut JejeConcept !
Merci pour cette gentille proposition !
Pourrais t'on en discuter en MP ? je suis très intéressé par l'intégration du Z wave dans mon projet ?!

Pour info, cette version du projet est un peu en standby pour le moment.
Je suis en train de bosser sur une nouvelle version en sencha (desktop ajax, c'est le top ! ) et surtout sur un nouveau concept de gestion des évènements.
Dans l'état actuel, rajouter des technologies à cette version est un peu ... long. Mais faisable cela dit ! 1 classe à créer, quelques pages html/php à créer et surtout un script shell à modifier pour piloter tes ordres z wave...

Si ça te dit, on pourra en discuter en mp...
En attendant, bonne après midi !
Webx - Solution domotique open-source
Linux - HTML/AJAX/PHP/PERL
Slim Framework - Jquery mobile
--------------------
Serveur domotique - sheevaplug/raspberrypi
---------------------------
Rfxcom lan (v2/v3)
X10 - X10 security (LM12/AM12/SD18/LM13)
Chacon (télécommande KCT510/interrupteur LWST615)
shen
P'tit Guru de domotique
 
Messages: 90
Inscription: 30 Juin 2010, 09:25

Re: Introduction

Messagede Stephane44 » 04 Avr 2012, 09:08

Bonjour, et tout d'abord bravo pour cette solution.
Je débute dans la domotique et je me pose des questions sur la stratégie côté serveur.
Je suis un peu comme toi, allergique aux usines Ă  gaz.
Plus simple c'est mieux c'est. DĂ©veloppeur (surtout Android), je souhaite pouvoir interagir depuis cette plateforme.
1ere question
La solution web est solution rapide et Multi-plateforme et Jquery Mobile est très pratique pour ça.
Le côté WebApp (SENCHA que je ne connaît pas) a l'avantage d'alléger les flux qui peuvent poser problème en 3G.
Tout ça (ouf) pour poser ma question : Dans le cas d'une Webapp tu envisages donc une une couche intermédiaire (de type REST/SOAP ou autre) ?
2eme question.
Si j'ai bien compris, les scenaris que tu as monté correspondent à des actions précises dans le temps.
Ne connaissant rien à XPL mais ayant compris que c'est LA solution incontournable pour utiliser des émetteurs/récepteurs de protocoles différents, ne peut-on pas sur réception d'un évènement, regarder touts les scénarios et réaliser l'action associée si cette action est concernée par l'information de l'émetteur ? Dans l'idée, l'action(ou une succession d'action) pourrait-être un lien HTML, d'ou l'intérêt de la couche intermédiaire pour une interaction entre modules, et la possibilité de créer des scripts PHP ou autres indépendants de ta solution (PUSH, MAIL, SMS)

Voila j'espère n'avoir pas été trop brouillon dans mon message,
Padawan en domotique
*RFXtrx433
*3 MS18
*OREGON THR128
*Arduino+TC35+ethernet = module sms
Avatar de l’utilisateur
Stephane44
Membre Actif
 
Messages: 12
Inscription: 07 Mar 2012, 22:11

Re: Introduction

Messagede shen » 04 Avr 2012, 10:33

Salut et merci pour tes encouragements !
La webapp que je construis en sencha utilise une couche intermédiaire de type REST.
Je débute un peu en sencha, mais ce qui m'importe plus c'est la structure et l'organisation de mon programme à travers un standard (MVC, flux de données, optimisation de la webapp, meilleure gestion des mises à jour, etc)

Je ne comprends pas ta question ? Quelle est le but, le sens, le bout de ta pensée ?

De plus, je comprends mieux la couche xpl qu'au début de mon projet dans cette version beta. J'ai rajouté une surcouche indispensable dans cette version béta pour le fonctionnement de mes scénarios, qui à terme n'aura plus lieu d'être...
Mais concernant les scénarios, c'est exactement ce que je fais ! Sur réception d'un évènement, je regarde tous les scénarios et je réalise l'action associée si cette action est concernée par l'information de l'émetteur. l'action, ou les successions d'actions sont des définitions renseignées par l'utilisateur en base de données.
Et concernant l'utilisation de scripts PHP ou autre indépendamment de ma solution (PUSH, MAIL, SMS) c'est déjà le cas : xpl-sms-send, etc... Il te suffit de créer ton script perso

Moi je l'ai géré comme ça :
Code: Tout sélectionner
/usr/local/domos/bin/atjob_env


# --------------------------------------------------
#       Pilotage des technologies x10/ipx800/chacon
# ---------------------------------------------------

function x10_on () {
        echo "pl $1 on" | nc -q 0 localhost 1099 1>/dev/null 2>&1
        echo " * `date +%T` atjob_env::x10_on() $1"
}

function x10_off () {
        echo "pl $1 off" | nc -q 0 localhost 1099 1>/dev/null 2>&1
        echo " * `date +%T` atjob_env::x10_off() $1"
}

function x10_dim () {
        echo "pl $1 dim $level" | nc -q 0 localhost 1099 1>/dev/null 2>&1
        echo " * `date +%T` atjob_env::x10_dim() $1"
}

function x10_bright () {
        echo "pl $1 bright $level" | nc -q 0 localhost 1099 1>/dev/null 2>&1
        echo " * `date +%T` atjob_env::x10_bright $1()"
}

function ipx800_relay () {
        curl -o /var/log/domos/ipx800.log "http://$IPX800_LOGIN:$IPX800_PASS@$IPX800_IP:$IPX800_PORT/leds.cgi?led=$1"
        echo " * `date +%T` atjob_env::ipx800_relay() led=$1"
}

function ipx800_button () {
        curl -o /var/log/domos/ipx800.log "http://$IPX800_LOGIN:$IPX800_PASS@$IPX800_IP:$IPX800_PORT/rlyfs.cgi?rlyf=$1"
        echo " * `date +%T` atjob_env::ipx800_button() rlyf=$1"
}

function chacon_on () {
        xpl-sender -m xpl-cmnd -c ac.basic address=$1 unit=$2 command=on -i lo -define broadcast=255.255.255.255 1>/dev/null 2>&1
        echo " * `date +%T` atjob_env::chacon_on() address=$1 unit=$2"
}

function chacon_off () {
        xpl-sender -m xpl-cmnd -c ac.basic address=$1 unit=$2 command=off -i lo -define broadcast=255.255.255.255 1>/dev/null 2>&1
        echo " * `date +%T` atjob_env::chacon_off() address=$1 unit=$2"
}
.........


En fait, mes scripts xpl-perl perso (xpl-trig-ac.basic, xpl-trig-ac.basic, etc) écoutent les évènements provenant du bus-xpl et exécute un script bash (/usr/local/domos/bin/atjob_scenario.sh). Si le module est actif, connu en base mysql et associé à un domaine on exécute atjob_scenario.sh qui se chargera de dérouler les actions associées à ce scénario...

Mais la modif est lourde ! Il faut modifier la classe associée à ta techno (si elle existe, ie: X10/IPX800/CHACON), créer une nouveau "case" dans la page de gestion des scénarios, rajouter ta fonction dans le fichier atjob_env ... pffu ! C'est pas encore modulaire !!! Et je peux t'assurer que cette prochaine version en sencha fera sauter tous les verrous que j'avais voulu mettre, à tord...

Voilà ! Donc cette prochaine version apporte les nouveautés suivantes :
- Meilleure gestion du changement
- Intégration plus facile des technologies (zwave,zigbee) grâce au standard xPL
- Une interface plus aboutie via le framework javascript Sencha, bien plus complet que jQuery (il faut bien commencer quelque part :-)
- Une gestion des scénarios bcp plus souple puisque totalement débridée (plus de notion de "domaine" ie:alarme, luminaire, chauffage) et une gestion de "groupe de module par activité"

Ca va être de la tuerie ! Mais comme évidemment l'opensource c'est pendant le temps libre, forcément...
Webx - Solution domotique open-source
Linux - HTML/AJAX/PHP/PERL
Slim Framework - Jquery mobile
--------------------
Serveur domotique - sheevaplug/raspberrypi
---------------------------
Rfxcom lan (v2/v3)
X10 - X10 security (LM12/AM12/SD18/LM13)
Chacon (télécommande KCT510/interrupteur LWST615)
shen
P'tit Guru de domotique
 
Messages: 90
Inscription: 30 Juin 2010, 09:25

Re: Introduction

Messagede Stephane44 » 04 Avr 2012, 18:19

En fait je tatonne un peu sur ma propre expression de besoins :roll:
1/ Ce que je sais c'est que j'ai besoin d'une couche d'uniformisation matérielle >>> XPL
2/ Que j'ai besoin d’exécuter des scénarios soit sur un élément de temps (CRON) soit en interaction sur la réception d’évènements.
3/ Qu'il me faut une interface admin et tablette(home) sympa
4/ Qu'il me faut une interface Android dédiée,(push) donc une couche de médiation(REST/SOAP/Autres ?)
5/ Que du côté serveur cela ne soit pas une usine à gaz
99/ Que je développe sur pas mal de techno et que je n'ai pas envie de me mettre en plus au PERL, et que je préférerais écrire mes scenarios en PHP et les affecter aux events via l'interface admin

Pour les points 1,3 et 5, je m'y retrouve dans ton projet :D
Pour le 4 j'en fait mon affaire. :wink: pour le 2 je suis Ă  la pĂŞche. :?:

Pour le 99 tu comprendras donc que mes connaissances d'XPL se limite Ă  la page about du site XPL :mrgreen: .
Je dois déjà regarder comment s'interface le RFXCOM RFXtrx433(transmetteur USB) avec XPL et là j'ai déjà peur. :(

Voila, encore merci pour ta réponse rapide.

Cordialement,
Padawan en domotique
*RFXtrx433
*3 MS18
*OREGON THR128
*Arduino+TC35+ethernet = module sms
Avatar de l’utilisateur
Stephane44
Membre Actif
 
Messages: 12
Inscription: 07 Mar 2012, 22:11

Re: Introduction

Messagede shen » 24 Avr 2012, 15:09

Salut,
je n'avais pas été notifié de ton message désolé du retard :-)
As tu trouvé ton bonheur ?
En tout cas chez moi pour faire tourner mon xpl RFXCOM LAN V3 je procède comme celà :

/usr/local/bin/xpl-rfxcom -i eth0 --rfxcom-rx-tty 192.168.1.x:10001 --rfxcom-tx-tty 192.168.1.x:10002

Regarde l'aide c'est pas dur :
Code: Tout sélectionner
domosbdf1:/usr/local/domos/bin# xpl-rfxcom
The --rfxcom-rx-tty parameter is required
or the value can be given as a command line argument
Usage:
      xpl-rfxcom [flags] [options] --rfxcom-rx <device> --rfxcom-tx <device>
      where valid flags are:
        --help              - show this help text
        --verbose           - verbose mode (for the xPL layer)
        --rfxcom-rx-verbose - verbose mode (for the RFXCOM receiver layer)
        --rfxcom-tx-verbose - verbose mode (for the RFXCOM transmitter layer)
      and valid options are (default shown in brackets):
        --interface if0          - the interface for xPL messages (first
                                   non-loopback or loopback)
        --rfxcom-rx-tty /dev/tty - the serial device for the receiver
        --rfxcom-rx-baud nnnn    - the baud rate for the receiver (4800)
        --rfxcom-tx-tty /dev/tty - the serial device for the transmitter
        --rfxcom-tx-baud nnnn    - the baud rate for the transmitter (4800)

      # start the rfxcom-rx application on first ethernet interface in verbose mode
      xpl-rfxcom --interface eth0 --verbose \
                 --rfxcom-rx-verbose --rfxcom-tx-verbose \
                 --rfxcom-rx <device> --rfxcom-tx <device>



OU alors tu as 1 autre méthode qui consiste à lancer 2 process : 1 pour la réception et au autre pour l'émission (xpl-rfxcom-rx / xpl-rfxcom-tx)


Et sinon pour ton expression des besoins :

1/ Ce que je sais c'est que j'ai besoin d'une couche d'uniformisation matérielle >>> XPL <<= OK pareil
2/ Que j'ai besoin d’exécuter des scénarios soit sur un élément de temps (CRON) soit en interaction sur la réception d’évènements. <<= OK mon projet est basé sur CRON et sur la réception d'évènements
3/ Qu'il me faut une interface admin et tablette(home) sympa <<= OK pareil, cela dit je suis en train de tout refaire en sencha LOL vice la geekerie
4/ Qu'il me faut une interface Android dédiée,(push) donc une couche de médiation(REST/SOAP/Autres ?) Il faut voir l'interaction que peut avoir ton interface REST avec mon projet :-) quand j'aurais assez avancé, je te montrerais
5/ Que du côté serveur cela ne soit pas une usine à gaz <<= OK pareil, Webx fait de la domotique et rien que de la domotique
99/ Que je développe sur pas mal de techno et que je n'ai pas envie de me mettre en plus au PERL, et que je préférerais écrire mes scenarios en PHP et les affecter aux events via l'interface admin <<= OK le perl j'en fait mon affaire

Qu'est-ce que tu en dis ?
Webx - Solution domotique open-source
Linux - HTML/AJAX/PHP/PERL
Slim Framework - Jquery mobile
--------------------
Serveur domotique - sheevaplug/raspberrypi
---------------------------
Rfxcom lan (v2/v3)
X10 - X10 security (LM12/AM12/SD18/LM13)
Chacon (télécommande KCT510/interrupteur LWST615)
shen
P'tit Guru de domotique
 
Messages: 90
Inscription: 30 Juin 2010, 09:25

Précédente

Retourner vers Webx

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité

Copyright © 2011 - Touteladomotique.com - Tous droits rĂ©servĂ©s
Les blogs partenaires : Abavala, Domo-Blog, Domotique34, Maison et Domotique


cron