Gestion knx de l'alarme varuna 3

Bonjour,
ma centrale d’alarme expose une MIB, mais aussi permet de lire ou recevoir l’état sur le bus knx.
Ex : 7/0/000 = état des 8 groupes de surveillance en 5.xxx
==>EA, soit en numérique 232, et en binaire 11101010.
C’est cette valeur qui m’intéresse : position 1 = état du groupe 1, ici active.
ca me fait un boulot monstre deja de tout implémenter afin de créer les différents groupes pour Interrogation d’état, Emission d état et retours d’état d’EIB !
Passé cette étape, il faut exploiter tout ca.
Je pensais donc passer par un virtuel pour isoler chaque donnée :
la encore un boulot monstre :frowning:
Mais je ne vois pas comment transcoder de l’ascii vers le binaire en utilisant le champ calcul.

Donc mes questions :
-comment peut on importer toute la définition sur base d’un csv par ex dans jeedom afin de simplifier la tâche ?
-Est ce que passer par un virtuel est la bonne/meilleur stratégie? Ou bien il faut passer par des scénarios de calcul intermédiaires ?
-Enfin, Comment transformer l’ascii en binaire et exploiter individuellement les résultats ?

Merci par avance pour vos aides.
(take care)

Le dtp de ton gad est 5.xxx? Peux tu donner un screenshot de la commande dans ets pour partir sur de bonnes bases.

Le but est de n’avoir que les états, il est question aussi d’envoyer des commandes a partir de jeedom ?
En général, les entreprises demande un dtp spécial pour eux.

Je n’ai pas tout compris mais ce que tu veux faire c’est le décodage de la data brute
Le mieux est certainement que je l’intègre au plugin mais pas sur que se soit tres pertinent.

Autre solution pour toi c’est de codé un script sur #plugin-script, je peux t’aider

Peux tu expliquer un peut plus ce que fait ton module et le décodage de la donnée
On choisira ou l’intégration est le plus facile et le plus pertinent
Au pire je te donnerai un base de décodage

oula, merci pour votre réactivité !
Alors la centrale n’est pas un module knx, (c’est la varuna 3 d hestia). Elle n’apparait donc pas dans ETS. elle est cependant connectée et dialogue avec le bus knx.
Pour tout dire, j’ai aussi une lifedomus qui l’intégrait avant le rachat delta dore. depuis, ils ont désactivé le connecteur ! Pas très sympa, surtout que le choix de lifedomus était aussi en partie pour ce service. Bref.

Le but est double, mais surtout d’avoir les états mais aussi idéalement les transmettre à la centrale. Ceci dit, on peut le faire, via scenario. Mais je suis tenté par une intégration complète.
Donc mes participants knx remontent dans la centrale, et vice versa, les detecteurs d’alarme servent de présence lorsqu elle est désactivée.

je résume :

  • Interrogation d’état (la supervision interroge la centrale)
    Il est possible de lire la plupart des « variables domotiques » de la centrale Varuna3 à tout moment via le bus EIB en effectuant la lecture d’adresse groupe prédéfinie.
    7/0/000 : état des 8 groupes de surveillance, groupe 1 sur bit 0, groupe 2 sur bit 1, etc. Bit à 1 pour groupe surveillé
    7/0/001 : état des sorties universelles 1 à 8 = Eclairage Cellier/Eclairage Dressing/…
    etc
  • Emission d état (de la centrale vers le knx sur changement)
    Il est possible de faire émettre automatiquement sur le Bus EIB certaines « variables domotiques » ainsi que l’état de certaines
    entrées de la centrale Varuna3 à chaque changement d’états de ces dernières vers des adresses ‹ groupe › prédéfinies.
    7/1/000 : état de la boucle de surveillance 1 (envoi d’un 0 pour boucle fermée et d’un 1 pour boucle ouverte) = detecteur cellier
    7/1/001 : état de la boucle de surveillance 2 =detect dressing
    7/1/009 : état des sorties cumulus 1 à 4 et du mode d’énergie (hiver (bit 5), été (bit 6), hors-gel (bit 7))
    etc
    -retours d’état d’EIB
    ==>Cette partie est automatique, donc pas nécessaire de le gérer
    Il est possible de gérer les retours d’état d’EIB afin d’actualiser les 48 sorties logiques ‹ Universelles › de la centrale lors de commandes directes (pas par la centrale)
    effectuées des modules EIB.
    7/2/000 : sortie universelle 1=Eclairage Cellier
    7/2/001 : sortie universelle 2=Eclairage Dressing

voila, j’espère que ca explique plus en détail la problématique.
Merci

Ok, on parle que de lecture de données se trouvant côté alarme.

Cela est tout a fait faisable dans un scénario avec des modulos et x commandes virtuelles. Un petit peu de boulot. Mais pas impossible. Une fois que le premier est fait, il suffit de dupliquer

@mika-nt28, tu pourrais l’intégrer comme tu as fait pour des commandes avec des dtp propriétaires mais tu serais hors standard knx.pas très joli. Il faudra de toute façon, des commandes virtuelles pour recevoir les valeurs

Pour moi, la solution idéale serait un plugin qui gère chaque entré et les converti en binaire. A ma connaissance, cela n’existe pas encore.

1 « J'aime »

Oui je peux l’integrer, au plugin
Je me pose la question est-ce plus pertinent directement dans le plugin ou de faire un plugin/script qui gère cette alarme particulière.

J’ai peur de la finalité car ça fonctionnera comme le télé info qui est hyper complexe.

@acognard qu’en pense tu, toi qui connaît cette alarme
Je peux m’y coller avec ton aide
J’ai édité le titre pour que ce soit plus parlant
Dit moi si j’ai bien compris ta problématique

je vois bien un plugin ou l’on indique la commande source KNX et qui crée pour chaque commande 8 commandes virtuelles binaires avec les infos dedans. cela revient au meme que un scénario/script avec 8 virtuels.

la question est de savoir si c’est pertinent, pas du travail et de la maintenance pour que quelques personnes. a toi de voir

Et oui toute la question est la.
Je ne connais pas du tout ce produit je ne sais pas s’il est rependu ou pas.
Après, pour un utilisateur un plugin est ce qu’il a de plus souple et simple à utiliser

De mémoire, c’est un module Hager qui coûte autour de 1000€. Pour moi, pas très répandu

1000€ pour un alarme c’est pas non plus deconnant
Je vais regarder si je trouve de la doc et ce qui est le plus simple pour tous le monde

Alors je pense qu’il y a qqes knxiens qui ont cette alarme et qui seraient ravis de la voir intégrée à jeedom.
Elle est plutôt destinée industrie, mais son atout est le knx. Je l’ai depuis 2010, et 0 panne, hyper fiable. Je l’ai intégrée sommairement avec linknx/knxweb et repris dans lifedomus via des scénarios. Mais c 'est pas très poussé.
Elle est encore en place sur la marché de l’industrie, mais dans une V4. Devenue inexistante sur la marché du particulier depuis que lifedomus a cassé ce lien. Et bien évidement, ils ne sont pas ouvert à refiler le code…

je donne la doc précise. Car ce n’est pas simple que vous l imaginez …
A savoir que je suis assez newbie avec jeedom. Mais la j y vois un intéret d y mettre les mains pour l’apprentissage. Cependant, il faut partir de la bonne manière.

Interrogation d’état
Il est possible de lire la plupart des « variables domotiques » de la centrale Varuna3 à tout moment via le bus EIB en effectuant la lecture d’adresse groupe prédéfinie.
Le groupe principal (1er chiffre de 0 à 15 de l’adresse groupe) et le groupe médian (2ème chiffre de 0 à 7 de l’adresse groupe) sont renseignés dans cet encadré.
Le groupe secondaire (3ème chiffre de 0 à 255 de l’adresse groupe) défini la variable domotique à lire dans la centrale.
La réponse sera envoyée à cette adresse en retour.

LISTE DES ADRESSES SECONDAIRES (implicites) dont la data utile est sur 1 octet :
7/0/000 : état des 8 groupes de surveillance, groupe 1 sur bit 0, groupe 2 sur bit 1, etc. Bit à 1 pour groupe surveillé
7/0/001 : état des sorties universelles 1 à 8
002 : état des sorties universelles 9 à 16
003 : état des sorties universelles 17 à 24
004 : état des sorties universelles 25 à 32
005 : état des sorties universelles 33 à 40
006 : état des sorties universelles 41 à 48
007 : état des sorties chauffages des zones 1 à 8
008 : état des sorties climatisations des zones 1 à 8
009 : état des sorties cumulus 1 à 4 et du mode d’énergie (hiver (bit 5), été (bit 6), hors-gel (bit 7))
010 : état des sorties gâche des groupes 1 à 8
011 : état des entrées d’automatisme / surveillance technique 1 à 8
012 : état des entrées d’automatisme / surveillance technique 9 à 16
013 : état des entrées d’automatisme / surveillance technique 17 à 24
014 : état des entrées d’automatisme / surveillance technique 25 à 32
015 : état des boucles de surveillance (détecteur) 1 à 8
016 : état des boucles de surveillance (détecteur) 9 à 16
017 : état des boucles de surveillance (détecteur) 17 à 24
018 : état des boucles de surveillance (détecteur) 25 à 32
019 : état des boucles d’auto protection 1 à 8
020 : état des boucles d’auto protection 9 à 16
021 : état des boucles d’auto protection 17 à 24
022 : état des boucles d’auto protection 25 à 32
023 : état de la boucle d’auto protection de la centrale (sur bit 0)
024 : état des boucles d’auto protection des Unités Déportées 1 à 8
025 : état des 2 seuils de la cellule crépusculaire (seuil 1 sur bit 1, seuil 2 sur bit 0)
026 : al. secteur (bit 7), al. SOS (bit 6), al. seuils températures (bit 5), al. technique 25 à 32 (bit 3), al. tech. 17 à 24 (bit 2), al. tech. 9 à 16 (bit 1), al. tech. 1 à 8 (bit 0)
027 : présence alarme groupe 1 à 8
028 : Etat mode d’énergie (01 : mode hiver, 10 : mode été, 11 : mode hors-gel)
029 : présence tarif EDF (bits 7 et 6), au moins une al. (bit 3), présence du secteur (bit 0)
030 : état anti-gaspi des 8 zones de chauffage / climatisation (bits à 1 : en anti-gaspi)
031 : état délesté des 8 zones de chauffage / climatisation (bits à 1 : délestée)

LISTE DES ADRESSES SECONDAIRES (implicites) dont la data utile est sur 3 octets :
032 : index du compteur N°1 (PF sur 1er octet utile de data, pf sur 3ème octet utile de data)
033 : index du compteur N°2 (PF sur 1er octet utile de data, pf sur 3ème octet utile de data)
034 : index du compteur N°3 (PF sur 1er octet utile de data, pf sur 3ème octet utile de data)
035 : index du compteur N°4 (PF sur 1er octet utile de data, pf sur 3ème octet utile de data)
036 : index du compteur N°5 (PF sur 1er octet utile de data, pf sur 3ème octet utile de data)
037 : index du compteur N°6 (PF sur 1er octet utile de data, pf sur 3ème octet utile de data)
038 : index du compteur N°7 (PF sur 1er octet utile de data, pf sur 3ème octet utile de data)
039 : index du compteur N°8 (PF sur 1er octet utile de data, pf sur 3ème octet utile de data)

Nota : Pour la lecture à partir du Bus EIB des variables domotiques au format ‹ 1 bit › voir l’encadré ci-contre nommé ‹ Emissions états domo. ›
Cela concerne la lecture de l’état des 32 boucles de surveillance, de l’état des 8 groupes de surveillance et de l’état de régulation des 8 zones de chauffage / climatisation.

Emission d état
Il est possible de faire émettre automatiquement sur le Bus EIB certaines « variables domotiques » ainsi que l’état de certaines
entrées de la centrale Varuna3 à chaque changement d’états de ces dernières vers des adresses ‹ groupe › prédéfinies.
Le groupe principal (1er chiffre de 0 à 15 de l’adresse groupe) et le groupe médian (2ème chiffre de 0 à 7 de l’adresse groupe)
sont renseignés dans cet encadré.
Les groupes secondaires (3ème chiffre de 0 à 255 de l’adresse groupe) définissent implicitement les variables domotiques concernées.

LISTE DES ADRESSES SECONDAIRES (implicites) :
000 : état de la boucle de surveillance 1 (envoi d’un 0 pour boucle fermée et d’un 1 pour boucle ouverte)
001 : état de la boucle de surveillance 2
|
031 : état de la boucle de surveillance 32

032 : état du délai de sortie du groupe de surveillance 1 (envoi d’un 1 au début du délai de sortie et d’un 0 à la fin)
033 : état du délai de sortie du groupe de surveillance 2
|
039 : état du délai de sortie du groupe de surveillance 8

040 : état de surveillance du groupe 1 (envoi d’un 1 à la mise En surveillance et d’un 0 à la mise Hors surveillance)
041 : état de surveillance du groupe 2
|
047 : état de surveillance du groupe 8

048 : état de régulation ‹ Absence › de la zone de chauffage/climatisation 1 (envoi d’un 1 en ‹ Absence › et d’un 0 si pas en ‹ Absence ›)
049 : état de régulation ‹ Absence › de la zone de chauffage/climatisation 2
|
055 : état de régulation ‹ Absence › de la zone de chauffage/climatisation 8

056 : état de régulation ‹ Présence › de la zone de chauffage/climatisation 1 (envoi d’un 1 en ‹ Présence › et d’un 0 si pas en ‹ Présence ›)
057 : état de régulation ‹ Présence › de la zone de chauffage/climatisation 2
|
063 : état de régulation ‹ Présence › de la zone de chauffage/climatisation 8

064 : état de régulation ‹ Confort › de la zone de chauffage/climatisation 1 (envoi d’un 1 en ‹ Confort › et d’un 0 si pas en ‹ Confort ›)
065 : état de régulation ‹ Confort › de la zone de chauffage/climatisation 2
|
071 : état de régulation ‹ Confort › de la zone de chauffage/climatisation 8

Toutes ces variables sont interrogeables du Bus EIB en effectuant une lecture sur les adresses correspondantes décrites ci-dessus.

retours d’état d’EIB
Il est possible de gérer les retours d’état d’EIB afin d’actualiser les 48 sorties logiques ‹ Universelles › de la centrale lors de commandes directes (pas par la centrale)
effectuées des modules EIB.
Le groupe principal (1er chiffre de 0 à 15 de l’adresse groupe) et le groupe médian (2ème chiffre de 0 à 7 de l’adresse groupe) sont renseignés dans cet encadré.
Ils sont communs à toutes les variables de retour d’état.
Les groupes secondaires (3ème chiffre de 0 à 255 de l’adresse groupe) définissent les sorties universelles de la centrales concernées.

LISTE DES ADRESSES SECONDAIRES (implicites) correspondantes aux sorties universelles de la centrale :
000 : sortie universelle 1
001 : sortie universelle 2
002 : sortie universelle 3
|
047 : sortie universelle 48

Attention, ces commandes de retour d’état n’agissent pas sur les sorties universelles de la centrale dans les cas suivants :

  • Forçage des sorties universelles cencernées par ripostes d’alarme de la centrale.
  • Forçage ON ou OFF par les écrans de supervision de la centrale.
  • Forçage ON ou OFF en ‹ maintenu › par les scénarios domotiques de la centrale.
  • Forçage OFF par les fonctions ‹ ET › de la tarification EDF et des seuils de la cellule crépusculaire de la centrale.

Les retours d’état ‹ ON › ne temporisent pas les sorties universelles concernées (action en ‹ ON › non temporisée), mais ils n’annulent pas
les éventuelles ‹ temporisations › déjà enclenchées par la centrale.

Note importante : Ces adresses de ‹ retour d’état › ne doivent pas être utilisées en même temps dans les 96 ‹ variables universelles d’entrée EIB ›.
Dans ce cas, seul la ‹ variables universelles d’entrée EIB › sera traitée. Le retour d’état ne le sera pas.

non non, du tout, ils sont indépendants, petite société familiale dans le pas de calais.

Cette alarme n’est pas reconnue en tant qu’alarme knx, Donc rien à faire selon moi dans le plugin knx.

Au vue de la complexité, je pense que la création d’un plugin est pas de trop.
Si je comprends bien c’est un module qui fait beaucoup de chose et que pour une bonne intégration sur jeedom faut créé plusieurs widget
Est-ce que tu aurais une idée du découpage à faire.

Je vais crée une structure de plugin que l’on complétera ensemble si ça te dit

1 « J'aime »

Les adresses de groupe (gad) sont fixe ou c’est configuré dans la varuna comme tu veux?

A part la passerelle knx, il y a une interface web pour l’interroger? Si oui, cela vaudrait pas la peine de regarder de ce côté avant de devoir passer par le knx. P-e plus simple

J’allais le demandé, car si c’est fixe je peux cree de boucle au lieu de saisir toute les commande
J’ai pas bien compris le decoupage des groupe principal et médian

il y a une mib dispo, pas de webservices, ni api.
pour ma part, je pense qu’il faut rester via knx

Merci pour votre intérêt !

La varuna est assez figée, mais son architecture permet pas mal de fantaisies.
La complexité si on réfléchit a qqe chose de générique dans l intégration de chaque habitat est lié au knx : Chez moi, c’est x/x/x pour mon éclairage bureau, chez Paul ca sera y/y/y…

Le mieux est peut être de se faire un zoom/skype/hangout ou autre pour vous montrer le bouzin ?

Ca va etre complique pour moi, meme si c’es super interressant.

En gros faut le plugin doit cree l’architecture (KNX et lui meme)
Vue le nombre de commande je vois mal devoir les cree a la main sous le plugin eibd puis les liée au plugin
Il est donc important de comprendre ce qui est personnalisable et fixe

J’ai commencé un plugin qui je l’espère pourra faire toute ca

  • Créer un équipement sous le plugin knx => OK
  • Créer les commandes avec les gad => Ok mais quel gad si non générique qu’est personnalisable par rapport a le description précédent
  • Créer les commandes decodé => En partie, reste a cree les boucles de creation
  • Ecoute des commande knx => Ok
  • Decodage et mise a jours => En cours

Donc en gros ce qui vas etre bloquant est de bien comprendre quel gad crée
Peux tu donc essayé d’eclaircire ce point avec peut etre quelques screenshot

@acognard, demain c’est fini. :wink:

@mika-nt28, joli boulot.