[pKNyX] ajout d'exemples

[fma38]

Bonjour,

Je n'ai pas touché à mon framework depuis un moment, et il est temps de m'y remettre.

Notez que la version actuelle fonctionne très bien : j'ai un bout de device virtuel qui tourne pour gérer mon chauffage (changement de consigne en fonction de l'heure).

Ce que j'aimerais faire, c'est ajouter des exemples pertinents, histoire de montrer ce qu'on peut faire avec.

Je suis donc preneur d'idées, vagues ou précises, ou de choses déjà réalisées (avec des règles linknx, par exemple) à implémenter en pKNyX.

Merci d'avance.

[mil3d]

ha ça des idées, j'en ai !

Par exemple : je souhaite gérer mon "alarme" avec mes modules KNX. J'ai 3 types de détecteurs :
- détecteur d'ouverture de porte de type contact reed (NC)
- détecteurs de choc sur les portes (NO)
- détecteurs incendie (NO) : 8 en tout
L'ensemble est branché sur des ABB US/U ou sur un ABB UK/S 32.2 (en réalité, je n'en ai que quelque uns qui le sont pour l'instant)

J'ai aussi une LED au dessus de chaque porte/fenêtre qui devra s'allumer quand l'alarme est armée "à cet endroit là" et qui devra clignoter si c'est cette fenêtre qui a déclenché l'alarme.
Pourquoi "à cet endroit là"? Parce que je souhaite pouvoir définir plusieurs zones à protéger de manière différentes selon les moments (uniquement la zone garage/étage le soir mais pas la zone salon par exemple).

Je dois y adjoindre un ou plusieurs boîtiers à code et/ou avec badge RFID pour activer/désactiver l'alarme, mais je ne sais pas encore lequel ni comment récupérer ça en KNX... ni comment définir quelle zone à activer selon le code ou selon le badge... Aucune idée pour l'instant.
Le "truc" doit aussi bien entendu pouvoir activer une alarme 12v, envoi de mail/sms/etc.

Il faut avoir assez d'intelligence pour éviter les faux positifs, timer avant déclenchement, timer pour la mise en route,... et tout ce que je n'ai pas encore pensé.

bref : un truc bien complexe, certainement pas du tout aux normes, mais c'est ça que je souhaite faire.
Aucune idée de savoir si c'est réalisable avec pKNyX.. mais c'est une idée :-)

[RemyB]

Hello,

- Gestion de capteurs 1-wire, soit en natif ou via OWFS. Envoi à intervalle régulière des valeurs t° vers adresses de groupe. Sauvergarde dans DB SQL pour historique/graphiques. Possibilité d'envoi d'alarmes par mail si une t° dépasse un seuil haut ou bas.
- intégrer une visu :-) (j'ai vu que tu as commencé à bosser dessus dans un autre sujet)
- Gestion de sonnette d'entrée avec possibilité d'envoi de photo vers smartphone, par mail, en cas d'abscence. Interaction avec Zoneminder ?

[fma38]

@mil3d, euh, ouais, c'est pas trivial, ton truc ! Tout est faisable, hein, mais c'est clair que ça va demander du boulot.

En fait, la philosophie KNX, que j'ai essayé de suivre avec mon framework, c'est de décomposer un Device en Functional Blocs ; ces blocs doivent être vus comme des boîtes noires, possédants des entrées, des sorties, et éventuellement des paramètres. Plus, bien sûr, un état et un comportement (ce modèle se traite très bien avec une approche objet). Les entres/sorties/paramètres sont ce qu'on appelle les Datapoint ; il sont généralement accessibles à travers des Group Object associés (y'a d'autres types d'accès, mais pas utiles en usage courant). Ces Group Object sont liés entre eux via les Group Address.

Un Device est donc généralement composé des plusieurs Functional Bloc, dont certains Datapoint sont reliés en interne (et également dispos via un Group Object) ; c'est par exemple le cas d'un détecteur de présence, qui intègre aussi une mesure de lumière, le tout permettant de piloter un actionneur pour maintenir un niveau de luminosité constant. On peut utiliser chaque composant de manière indépendante, ou de manière globale.

Tout ça pour dire que dans ton cas, il faut déjà arriver à faire cette décomposition en plusieurs Functional Bloc, voir en plusieurs Device si ça devient trop lourd. C'est par exemple ce que j'ai fait pour un début de gestion de VMC ; faudrait que je poste le code quelque part pour te donner une idée...

@RemyB, l'accès 1-wire est intéressant ; ce n'est pas trop compliqué, et illustre bien le but de pKNyX : créer un pseudo-device KNX permettant d'étendre les fonctionalités d'une installation. Si tu as un peu de temps, je serais preneur de quelques liens sur le 1-wire en python (owfs ou autre)... Le but est de s'appuyer sur des choses existantes, et les mapper dans le monde KNX. Tout en permettant de faire des choses plus complexes, comme le log en base de données, l'envoi de courriels, etc...

Tiens, d'ailleurs, l'envoi de courriels en cas d'alerte peut tout à fait faire l'objet d'un exemple à part entière ; un truc un peu générique, ou très facile à adapter en fonction des besoins.

Hop, je vais commencer pas là

[fma38]

Voili :

http://www.pknyx.org/browser/pknyx/examp...lert/alert

Je vais mettre la routine d'envoi de courriels dans un module à part, pour que ce soit plus facile à utiliser...

[RemyB]

Super, une option qui sera bien utile :-) Je vais tester dès que possible..

[RemyB]

Salut Frédéric,

Est ce que ca serait compliqué d'ajouter un driver websocket permettant d'interagir avec les objets d'un device à partir de Smartvisu ?
Pour rendre fonctionnel rapidement une visu je pense que c'est une option à creuser, à mon humble avis. Smartvisu est compatible avec Linknx,smarthome et d'autres superviseurs logiciels..
Ce qui permet de rendre plus attrayant le projet par l'aspect visuel rapidement déployé avec le framework de Smartvisu. Car j'imagine que développer une visu sympa demande un travail colossal..

Qu'en penses-tu ?

En fait pour faire quelques tests de gestion de chauffage j'ai besoin d'une visu (partiellement) opérationelle, je suis donc en train de mettre cela en place avec smarthome/smartvisu. Ce framework est déjà bien abouti dans certains domaines, mais je pense que pKNyX offre d'autres avantages qu'il serait intéressant d'utiliser en meme temps, sur un autre driver websocket par exemple.
Les sources des autres drivers sont disponibles içi: http://smartvisu.googlecode.com/svn/trunk/driver/

Rémy

[fma38]

Faut que je creuse ça

[fma38]

Je viens de regarder un peu smartVisu, et je vois qu'il y a un driver 'json'. J'ai l'impression que c'est un truc plus générique, mais je n'arrive pas à trouver la doc pour savoir comment servir ce mode de communication...

As-tu plus d'infos ? Perso, je ne parle pas allemand, donc le forum knx-de ne m'aide pas beaucoup

[RemyB]

Salut Frédéric,

Selon les infos glanées sur le forum allemand, le driver json est à usage générique et en effet il est très peu documenté.
Maintenant suite à l'autre sujet est-ce finalement nécéssaire, je pense que ce n'est pas le urgent, surtout qu'on sait interagir entre smarthome/pKNyX via les gad. :-)

[fma38]

Yep !

[fma38]

J'ai uploadé 2 nouveaux exemples dans le dépôt : l'un pour montrer comment faire une moyenne sur des températures, l'autre (pas encore testé) qui rejoue les dernières xx minutes de l'activité du bus (enfin, des GAD paramétrées dans le script)...

http://www.pknyx.org/browser/pknyx/examples

Moyenne :

http://www.pknyx.org/browser/pknyx/examp...erageFB.py

Replay :

http://www.pknyx.org/browser/pknyx/examp...eplayFB.py

Au passage, si on vire les logs et les commentaires, on voit qu'il ne reste pas grand chose :

Code :

# -*- coding: utf-8 -*-

import time
import Queue

from pknyx.api import FunctionalBlock
from pknyx.api import logger, schedule, notify


class ReplayFB(FunctionalBlock):
    DP_01 = dict(name="replay", access="input", dptId="1.011", default="Inactive")
    DP_02 = dict(name="replay_period", access="input", dptId="7.006", default=1440)  # min (= 24h)
    DP_03 = dict(name="light_1", access="output", dptId="1.001", default="Off")
    DP_04 = dict(name="light_2", access="output", dptId="1.001", default="Off")
    DP_05 = dict(name="light_3", access="output", dptId="1.001", default="Off")
    DP_06 = dict(name="light_4", access="output", dptId="1.001", default="Off")
    DP_07 = dict(name="light_5", access="output", dptId="1.001", default="Off")

    GO_01 = dict(dp="replay", flags="CRWU", priority="low")
    GO_02 = dict(dp="replay_period", flags="CRWU", priority="low")
    GO_03 = dict(dp="light_1", flags="CWTU", priority="low")
    GO_04 = dict(dp="light_2", flags="CWTU", priority="low")
    GO_05 = dict(dp="light_3", flags="CWTU", priority="low")
    GO_06 = dict(dp="light_4", flags="CWTU", priority="low")
    GO_07 = dict(dp="light_5", flags="CWTU", priority="low")

    DESC = "Replay FB"

    def init(self):
        self._sequence = Queue.Queue(100)

    @notify.datapoint(dp="light_1", condition="change")
    @notify.datapoint(dp="light_2", condition="change")
    @notify.datapoint(dp="light_3", condition="change")
    @notify.datapoint(dp="light_4", condition="change")
    @notify.datapoint(dp="light_5", condition="change")
    def lightStateChanged(self, event):
        dpName = event['dp']
        newValue = event['newValue']
        time_ = time.time()
        try:
            self._sequence.put_nowait({'dp': dpName, 'value': newValue, 'time': time_})
        except Queue.Full:
            logger.exception("%s: storage sequence is full; skipping..." % self.name, debug=True)

    @schedule.every(seconds=1)
    def processQueue(self):
        try:
            item = self._sequence.get_nowait()
        except Queue.Empty:
            logger.exception("%s: storage sequence is empty; skipping..." % self.name, debug=True)

        delta = (time.time() - item['time']) / 60.
        if self.dp['replay'].value == "Active"  and delta > self.dp['replay_period'].value:
            self.dp[item['dp']].value = item['value']

[RemyB]

Super ca pourra servir. :-)
Je vais regarder à la carte i/o peut etre ce soir..