Ce sujet a 7 réponses, 2 participants et a été mis à jour par 
-
Messages
-
Bonjour,
Je reprends sur ce fil .
J’ai un WES v2 avec une carte d’extension 8 relais.
Je suis avec un linky et pour le moment en historique pour la TIC malgré une demande pour passer en standard!!!mais Enedis et EDF c’est pas gagné! Abonnement TEMPO 12kva triphasé.
Mon Wes pilote des contacteurs de puissance pour faire du délestage des gros consommateur pour:
1 lisser la consommation
2 éviter de passer au dessus de la puissance d’abonnement car le linky il est délicat sur ce point (même si il y a une surcharge autorisée voir la documentation officielle) et peut même couper l’installation….!!!!
J’ai des retours d’état pour l’instant au travers des entrées analogique faites par des relais pour assurer l’isolement et sur les entrées capteurs pour surveiller les alimentations des frigos-congels avec envoi d’un message si ca tombe…
Une bonne vingtaine de regles au totale.
pas de soucis majeur coté programmation, accès etc.
Seul soucis mineur la page d’accueil au travers du WIDGET.INI « merdouille » franchement. Dès que je bouge un wif=dget et hop je pert ma page d’acceuil, elle fait n’inporte quoi , seul quelques widgets reste aléatoirement…..!!!
bon j’ai détourné le problème je prend le fichier widget.ini à la mano avec un éditeur de texte et j’organise mes widgets à la mano avec les champs x,y…
Nicolas si une idée je suis à l’écoute
Sinon je prévois des capteur de températures puis j’aimerai bien avoir des entrées sur le 1W.
Pascal
Bonjour,
Je fais juste une petite parenthèse sur votre fil concernant votre souhait : « j’aimerai bien avoir des entrées sur le 1W. »
J’avais déjà demandé à Nicola, il y a déjà un moment par échange de mail, la possibilité d’utiliser pleinement les gestions I/O du circuit Dallas DS2408 géré par le WES. Le WES reconnaît ce petit circuit uniquement dans son mode Output (Cartes 8 relais) mais ce circuit peut aussi être utilisé en mode Input à 8 entrée et le WES ne le gère pas pour le moment !.
Ayant comme vous, le besoin d’avoir des entrées 1Wire pour faire des tests de changement d’état Input côté programmation dans le WES, j’ai détourné ce manque de gestion 1Wire côté WES, par un artifice très facile à implémenter. Peut être le savez vous, il existe une librairie (compatible Arduino, esp8266, esp32 etc) qui permet de faire des échanges 1Wire en émulation de circuits Dallas par soft. Vous trouverez cette librairie ici : https://github.com/orgua/OneWireHub
Rapidement je vous décrits comment j’utilise cette libraire en relation avec le WES.
Cette libraires permet de créer et de simuler 32 circuits Dallas 1Wire Virtuel via un Arduino, ESP8266 ou ESP32 par exemple, donc de créer et de gérer les deux circuits 1Wire reconnus par le WES, à savoir le DS2408 (cartes à Relais) et le DS18B20 (sonde de temppérature).
On peut donc créer des Cartes à 8 Relais aussi bien que des Sondes de température de façon Virtuelles. Le micro contrôleur utilisé peut donc manager ces entrées et sorties avec le WES, Ex: Envoyer des valeurs de températures Virtuelles relatives aux Sondes crées ou intercepter les changements des Relais Virtuels soumis par le WES.
Donc l’idée est de détourner la gestion des relais 1Wire, accessible côté WES, en mode Input ? Relais. Comme j’utilise un ESP8266, je peux envoyer des requêtes Http (Wifi) afin d’activer les relais du WES à la demande. Donc dès que je détecte dans le ESP8266 un changement d’état d’un GPIO défini en mode input digital, j’envoie une requête Http au WES pour faire activer le relais Virtuel en relation. Dès lors le WES opère le changement sur ce Relais Virtuel et côté programmation dans le WES, je peux tester l’état de ce relais Virtuel et m’en servir comme élément Source.
Oui ! c’est un peu tordu, mais cela fonctionne parfaitement bien. La seule contrainte de ce dispositif est d’avoir dans le WES une carte à Relais Virtuelle en visuel au lieu d’une Entrée type Input.
Mais c’est juste une vue de l’esprit car dès que l’on sait qu’elle est la Carte à Relais mise en Oeuvre, on peut aussi utiliser cet état de fait pour faire par exemple des Interrupteurs type Va et Vien, par exemple : Le Input Gpio coté ESP8266 peut être connecté à un interrupteur mécanique et un changement d’état de cet interrupteur (relais virtuel) peut aussi être effectué via les pages Relais du WES. Les ESP peut lire et gérer ces changements d’état dans les deux sens. La lecture du bus 1Wire depuis la libraire OneWireHub permet au ESP8266 de connaître l’état des relais Virtuel pratiquement en temps réel.
Comme le ESP8266 n’a pas assez de GPIO pour créer les 8 inputs, je passe par un multiplexeur à 8 entrée vers une sortie, lecture des 8 inputs de façon cyclique par adressage avec 3 Gpio et un Gpio en sortie permet de lire les valeurs associées pour les envoies des requêtes RL vers le WES.
Je me sert de cette mécanique pour commander 15 Prises sans fil de chez PlugWise. Une librairie (GitHub) permet de gérer ces Prises PlugWise en dehors du Logiciel propriétaire fourni par la Marque. Le ESP8266 implémente aussi cette librairie et crée dans le WES via la librairie OneWireHub les deux cartes à Relais Virtuel (soit 16 relais ) associé à chaque prise PlugWise. Donc c’est le WES qui traite maintenant ces Prises PlugWise issue d’un autre système ! Je peux donc commander ces prises avec des interrupteur mécanique ou via le WES en système Va et Vient.
Les sondes de température Virtuelle pourraient aussi servir comme Input analogique, on peut envoyer les valeurs des sondes 1wire Virtuelle depuis le micro contrôleur et lire les valeurs de la sonde Virtuelle côté WES et s’en servir comme source côté programmation. Mais comme la lecture des sondes est seulement faites toutes les 30s depuis le changement de version, il est impossible d’avoir une réactivité suffisante lors d’un changement de valeur de la sonde virtuelle (input analogique !)
J’avais envoyé une maquette de démo à Nicolas.
Cdt
Re:
Pour ceux que cela intéresse j’ai modifié et adapté la librairie OneWieHub afin qu’elle puisse tourner dans un ESP8266 en Mode IRQ (interruption). Cela permet de ne plus lancer la scrutation du bus 1Wire par le Hub de la libraires en mode Spooling comme prévu de base, mais de lancer le Hub de la libraire depuis une CallBack Irq activé dans le ESP8266 dès le passage du front descendant du signal du bus 1Wire, lors de la Pulse RESET de démarrage de cycles 1Wire initiée par le Maître 1Wire ( le WES dans mon cas ).
Une interface I2c en mode Slave est aussi implémenté dans le ESP8266 (initialement le ESP8266 ne gère pas le I2c en mode Slave).
Une CallBack I2c Slave est activé par IRQ (interruption) dans le ESP8266 dès le front descendant de la Pin SDA du bus I2c lors de l’appel du Maitre I2c. Cela permet des échanges en I2c, avec un Micro contrôleur externe relié en I2c avec le ESP8266, afin de lire et écrire les datas des circuits Dsxxx Virtuel qui ont été crées dans la Librairie OneWireHub.Pour terminer J’ai également modifié la librairie OneWireHub afin de supporter 64 Objets DSxxx au lieu de 32 Objets Initialement.
Le ESP8266 est boosté pour fonctionner en 160mhz.J’ai aussi implémenté un Pont 1Wire qui me permet de gérer le bus 1Wire du domicile depuis le ESP8266 et d’envoyer en écho au WES les échanges
du bus 1Wire via la librairie OneWire. Cela me permet de laisser le WES gérer le bus 1Wire du Domcile à sa guise et d’avoir un autre process qui gère le même Bus 1Wire en parallèle. Toutes Les Info 1Wire du ESP8266 peuvent être traitées par un module I2c Maitre distant connecté à la liaison I2c du ESP8266. J’utilise un Raspberry pi me concernant ( Le WES et le bus 1Wire du domicile est géré par un plugin dédié dans un serveur Gateway).Cela me permet de ne plus faire de requêtes CGX pour récupérer les valeurs des Sondes de Température et les états des Relais 1Wire connectées sur le Bus 1Wire du domicile et aussi de connecter d’autre circuits DSxxx non gérés par le WES. Cela me permet aussi de faire des scrutations plus rapidement des Sondes de Temp (2.5s au lieu de 30s), Relais (200ms) et autres circuits DSxxx connecté au Bus 1Wire.
Donc j’ai une utilisation du bus 1Wire du domicile en Y. Le WES fait son travail de son côté et de l’autre côté je peux traiter, lire/écrire dans tous les DSxxx du Bus 1Wire Via des Cde I2c. Le WES par contre est prioritaire sur l’accès du bus 1Wire. Comme c’est géré par IRQ, il n’y a pas de conflis possible dans les échanges croisés sur le Bus 1Wire du domicile.
Pour terminer le Esp8266 fonctionne avec son WIFI désactivé, sinon il y aurait des conflics dans la gestion des Irq et plantage côté WatchDog.
Par contre j’utilise un ESP8266 au lieu d’un Arduino ou autre Micro contrôleur pour son faible coût (3€ environs), sa fréquence d’utilisation (boosté à 160mhz) et la capacité mémoire interne plus que nécessaire.J’ai une gestion plus personnalisé qui me permet de gérer en 1Wire via des DS28E17 (Bridge 1wire to I2c) de petits modules distants par des échanges de protocoles I2c depuis le bus 1Wire. Cela me permet d’avoir des modules de type Cpt à impulsions, Pinces Amp, système Alarme, etc connectés et gérés depuis le bus 1Wire. (Les Modules sont gérés par des Arduino Pro-Mini alimenté en 3.3v, en gestion mode I2c Slave).
Un circuit DS28E17 peut gérer jusqu’à 5 modules Arduino (5 adresses I2c). J’ai limité Le nombre de DS28E17 (Constante) à 10 dans mon appli. cela me permet de gérer 50 petits modules Arduino divers selon leur conception Pcb. plus que nécessaire pour mon usage.Je peux fournir, à ceux qui le demande, un squelette de base du fichier Ino du ESP8266 ( sans mes procédures perso DS28E7 ) avec le minimun de requête I2C qui vous permet déjà de gérer des DS18b20 ou DS2408, seul composants 1Wire gérés par le WES avec le DS2438.
J’avais déjà envoyé à Nicola la maquette de base de ce montage. Comme il n’a pas donné suite, je le met à Dispo. Cela ne rentre pas en Conflic avec les spécificités et gestion du WES. Par contre cela permet de mieux interfacer les modules externes comme Eedomu, Domoticz etc via une liaison I2C, concernant les accès aux infos 1Wire.
Ci-joint le schéma de câblage du ESP8266 pour info.
RE: l’image n’est pas passée
Bonjour,
Pour info je suis moi même de formation informatique industrielle.
C’est intéressant certe, mais cela complexifie grandement et ca à un petit coté malin de créer des RL virtuels pour les lires dans les règles de programmation!
Personnellement je n’ai pas un caractère d’urgence, je vais donc attendre de voir ce que Nicolas propose à terme comme input.
Si cela ne vient pas ou est insuffisant alors je verrais pour me créer un second contrôleur qui pourra piloter des I/O que je connecterais au WES pas forcément par le bus 1W mais plus au travers d’interface(s) (HTTP/UDP/TCP/….) à l’image d’une interconnexion avec un serveur domotique (jeedom, eedomus…..). Je regarde du coté M2M , on pourrait la aussi piloter des inputs virtuels (switchs) et les « piloter » depuis l’automate de gestion des I/O pour transmettre au WES les infos…
Une remarque Nicolas serait-possible de mettre plus d’inputs virtuels dans le WES ca serait le top pour envoyer des infos depuis l’extérieur!
A+
Bonjour,
Il y a une autre astuce pour travailler sur des inputs Virtuel de façon plus général. L’idée est d’utiliser les VARS du WES comme valeur de Input.
De bien attendu ces Vars ne peuvent pas interagir directement en tant que Input physique, mais peuvent représenter une valeur reçue indirectement d’un capteur analogique ou digital lamda et d’envoyer la valeur au WES.
On peut modifier les valeurs de chaque VAR par envoie de requête Http ex var1=12345.25 :
http://login:password@192.168.xx.xx/?varv1=12345.25 // 2 chiffres après la point (le signe virgule pas reconnue)
Les valeurs peuvent être envoyées sous forme HEXA ex:
http://login:password@192.168.xx.xx/?varv1=12345.00 // Val en analogique
http://login:password@192.168.xx.xx/?varv1=0x3039 // Val en Hexa
http://login:password@192.168.xx.xx/?varv1=0x0011000000111001 // Val en Binaire Bit à BitOn peut lire les valeurs des VAR par requêtes CGX :
# Format Fichier.Cgx >> Réponse WES sous format XML
#
t <?xml version= »1.0″ encoding= »utf-8″ ?>
t <data>
t <variables>
c Vv1 <VARIABLE1>%.02f</VARIABLE1>
c Vv2 <VARIABLE2>%.02f</VARIABLE2>
c Vv3 <VARIABLE3>%.02f</VARIABLE3>
c Vv4 <VARIABLE4>%.02f</VARIABLE4>
c Vv5 <VARIABLE5>%.02f</VARIABLE5>
c Vv6 <VARIABLE6>%.02f</VARIABLE6>
c Vv7 <VARIABLE7>%.02f</VARIABLE7>
c Vv8 <VARIABLE8>%.02f</VARIABLE8>
t </variables>
t </data># Format fichier.Cgx >> Réponse WES sous format CSV ( ne pas oublier le point final )
#
t <form>
c VV <array><var>VAR</var><value>0,%.02f,%.02f,%.02f,%.02f,%.02f,%.02f,%.02f,%.02f</value></array>
t </form>
.Comme on peut envoyer à une VAR une valeur HEXA et convertir la valeur reçue en HEXA par lecture en retour req.Cgx on peut très facilement définir des inputs DIGITAUX en utilisant chaque Octs comme des états I/O
ex : http://login:password@192.168.xx.xx/?varv1=0x0110001001 >> 1er=OFF, 2éme=ON, 3éme=ON, 4éme=OFF etc
La valeur MAX accepté par le WES en valeur HEXA pour une VARx :
http://login:password@192.168.xx.xx/?varv1=0xfffffffffffffffffffffffffffffff // Float = 21267647932558654000000000000000000000.00De bien entendu les VARS peuvent être utilisées comme référence d’une Source dans les lignes de Programmation du WES
Pour parfaire les discris Bit à Bit sur des valeurs côté Programme du WES, il faudrait que Nicolas ajoute des tests sur valeur type Logique ET / OU .Mais déjà on peut faire un semblant de Do Case pour une ou des valeurs données sur une VAR x. Les valeurs sont reconnu en valeur Float analogique dans le WES.
Cdt
RE: Désolé, Oublier mon délire précédent concernant l’Usage des Vars comme Input !!!
J’ai été un peu trop présomptueux dans mon Idée d’utiliser les VARS en tant que Source dans des lignes de Programme du WES.
Je m’aperçois seulement maintenant que les VARs ne sont pas des référents utilisables comme Sources dans la gestion Programme du WES mais seulement utilisées en tant que Valeurs de comparaison d’un Source.
Il serait intéressant que Nicolas rajoute la faculté d’utiliser les VAR comme référents Source dans la gestion Programme ainsi qu’un complément de Switch Virtuel très pratique pour faire des discris.
Hello
Oui il faudrait que Nicolas rajoute des variables de dialogues avec « l’extérieur » en nombre important et qu’elle soit utilisables non pas enn condition d’action ou pas mais comme sources (prémisse) des régles. (Ca pourrait être les actuelles ).
Idem pour les variables actuelles trop peu nombreuses pour faire une programmation structurée et avancée avec un nombre non négligeable de règles d’interactions!!!
Vous devez être connecté pour répondre à ce sujet.