Retour d'état Z-Wave

[TFx]

Bonjour à tous,
J'ai choisi un interrupteur Z-Wave pour avoir un retour d'état et ainsi être certain qu'une commande a bien été exécutée.
En effet je souhaite déclencher un script lors d'un changement d'état effectif. Exemple de contexte : envoi d'une commande par sms et confirmation par sms retour que la commande a bien été exécutée.

Or je constate que Domoticz notifie 2 fois le changement d'état, et je ne trouve aucun moyen de savoir si l'une des 2 notifications est liée au retour d'état du module Z-Wave. De plus j'ai pu constater que si le module Z-Wave est débranché (ou si OpenZWave est planté comme cela arrive souvent malheureusement), j'ai quand même 1 notification par Domoticz. Donc se fier à la présence d'une notification n'est pas suffisant pour savoir si la commande a bien été exécutée.

Savoir que le module a réellement changé d'état est pour moi indispensable, mais comment faire ?
Merci pour votre aide.

[lost]

De plus j'ai pu constater que si le module Z-Wave est débranché (ou si OpenZWave est planté comme cela arrive souvent malheureusement), j'ai quand même 1 notification par Domoticz. Donc se fier à la présence d'une notification n'est pas suffisant pour savoir si la commande a bien été exécutée.

Savoir que le module a réellement changé d'état est pour moi indispensable, mais comment faire ?

Si un module est débranché, chez moi les switch/capteurs... qui y sont attachés passent visuellement en rouge dès la première manipulation, avec des logs de timeout sur le nodeID débranché... et l'info "vu pour la dernière fois" rester inchangée.

Je verrais donc au moins 3 façons de faire:
-Check des timeout niveau log et envoyer un sms ou autre d'un script externe à Domoticz (à voir si fail2ban, assez souple dans le check des logs, saurait faire avec des règles adaptées) juste quand il y a un souci...
-D'un script device Lua ou autre, une action directe sur un switch va déclencher un changement d'état... et sur ce changement d'état, les scripts device vont déclencher immédiatement après et il est facile d'en avoir un qui envoie l'état courant par mail/sms du switch à controler. Si on ne recoit rien, c'est que pas d'action. En prime on contrôle l'état réel.
-Un script device qui stocke l'heure de dernière action dans une user variable pour le switch + un script time qui toutes les minutes vérifie le lastupdate du switch et si > 1mn et user var non nulle, notification que la commande n'est pas passée + mise à zéro de la user var pour ne plus déclencher la minute suivante.

Exemples dans le wiki:
https://www.domoticz.com/wiki/Event_script_examples

Sinon, il doit y avoir d'autres problèmes chez toi: Z-Wave, passé les soucis éventuels d'inclusion parfois capricieuse, est globalement très stable. Ou alors il y a un pb de portée avec un réseau ayant peu de périphériques (donc peu maillé): Vérifier la topologie réseau z-wave et les chemins menant de cet interrupteur au contrôleur serait la première chose à faire.

Eviter les marques de périphériques peu connues et ceux n'ayant pas passé le processus de certification (cf site de la z-wave alliance pour les listes) aide également à éviter ceux à emmerdes avant l'achat.

Attention aussi aux SMS: Il arrive sur des envois proches d'en louper ou qu'ils soient inversés (et même que certains arrivent avec bcp de retard). Ajouter l'affichage de l'heure système dans le script d'envoi et idéalement un numéro (maintenu là aussi dans une user variable et incrémenté par le script à chaque envoi) d'ordre peut aider à démêler les ennuis de gestion SMS des ennuis réels de matériel/script!

[TFx]

Merci lost pour ta réponse.
Lorsque je débranche un Device zwave pour simuler une perte de connexion (chez moi uniquement lié au plugin openzwave qui par à 100% de CPU et ne transmet/reçoit plus rien), effectivement je vois bien des messages de timeout dans les logs, par contre le Device ne passe pas en rouge. Mais cela peut se gérer dans domoticz au niveau matériel avec un timeout sur la non-réception de messages zwave.

Par contre, j'ai quelques soucis à mettre en oeuvre tes 2 autres propositions :
Tout d'abord, le changement d'état de mon module zwave est commandé par sms, donc par un script (en python dans domoticz). Les scripts liés au changement d'état sont appelés 2 fois (changement du device domoticz puis retour d'état du module zwave). Pour envoyer un sms seulement sur le retour d'état zwave, l'idée d'utiliser des variables est bonne mais pour le moment il m'est impossible de modifier une variable dans un plugin domoticz python : la commande json relative fait toujours planter l'IHM, alors que cette même commande entrée dans un navigateur fonctionne parfaitement.

Cette impossibilité à modifier une variable depuis un script python sur événement (Device ou time) est le principal frein à ce jour.

[lost]

Cette impossibilité à modifier une variable depuis un script python sur événement (Device ou time) est le principal frein à ce jour.

Je pourrais toujours poster un extrait de script python...

Mes fonctions de lecture/ecriture usr var en python (et aussi modif switch):

Avec url de la forme (récupéré d'un fichier de config externe au script en YML pour ma part, avec tous les IDX/noms des devices utilisés):
http://127.0.0.1:8080/json.htm?

Il faudra ajouter au début du fichier les imports suivants:

Code : Tout sélectionner

import logging
import json
import requests

Et en variables globales le format de base ci-dessous, patché par les requêtes:

Code : Tout sélectionner

dmtJsonSwitch = {"type":"command", "param":"switchlight", "idx":999, "switchcmd":"Off"}
dmtJsonGetVar = {"type":"command", "param":"getuservariable", "idx":999}
dmtJsonUpdVar = {"type":"command", "param":"updateuservariable",
                 "vname":"DOMOTICZ_USR_VAR", "vtype":0, "vvalue":0}

Pour reprendre ces fonctions proprement dit:

Code : Tout sélectionner

# Get domoticz user value, returns sys.maxint if error
def dmtGetUsrVar(url, idx, name, logger):
    """
    Get Domoticz integer user variable, returns -1 if idx/name mismatch, -2 if connection fails...
    """
    ret = -1
    
    dmtJsonGetVar['idx'] = idx
    
    try:
        # Connect to Domoticz via JSON API and send data
        dmtRget = requests.get(url, params=dmtJsonGetVar)
    except requests.exceptions.RequestException as dmtErr:
        logger.log(logging.ERROR, "Unable to connect with URL=%s \nGet requests error %s" % (url, dmtErr))
        ret = -2
        return ret
        
    #logger.log(logging.DEBUG, "Sent data: [%s]" % (dmtRget.url))
    #logger.log(logging.DEBUG, "dmtGetUsrVar(idx=%d <=> %s) server response :\n%s" % (idx, name, dmtRget.text))
    
    # Check var/idx coherence to validate domotics response
    jsonRget = json.loads(dmtRget.text)
    if jsonRget["result"][0]["Name"] != name:
        logger.log(logging.INFO, "dmtGetUsrVar(idx=%d <=> %s != %s) MISMATCH" % (idx, name, jsonRget["result"][0]["Name"]))
        return sys.maxint

    ret = int(jsonRget["result"][0]["Value"])
    #logger.log(logging.DEBUG, "dmtGetUsrVar(%s) = %d" % (name, ret))
    
    # Looks OK, return domoticz user variable value...
    return ret
    
# Used to update a user variable ; If variable is linked to a user switch,
# can also be done using switch action on & off from domoticz interface...
def dmtUpdateUserVar(url, name, value, logger):
    """
    Update Domoticz user variable "name" with integer value
    """
        
    dmtJsonUpdVar['vname'] = name
    dmtJsonUpdVar['vvalue'] = value
        
    try:
        # Connect to Domoticz via JSON API and send data
        dmtRget = requests.get(url, params=dmtJsonUpdVar)
    except requests.exceptions.RequestException as dmtErr:
        logger.log(logging.ERROR, "Unable to connect with URL=%s \nGet requests error %s" % (url, dmtErr))

    #logger.log(logging.DEBUG, "Sent data: [%s]" % (dmtRget.url))        

def dmtNotifySwitch(url, idx, switchcmd, logger):
    """
    Notify Domoticz switch idx with cmd=On/Off
    """
    
    dmtJsonSwitch['idx'] = idx
    dmtJsonSwitch['switchcmd'] = switchcmd
        
    try:
        # Connect to Domoticz via JSON API and send data
        dmtRget = requests.get(url, params=dmtJsonSwitch)
    except requests.exceptions.RequestException as dmtErr:
        logger.log(logging.ERROR, "Unable to connect with URL=%s \nGet requests error %s" % (url, dmtErr))
        return
        
    #logger.log(logging.DEBUG, "Sent data: [%s]" % (dmtRget.url))

Dans le main, avant 1er appel il faudra au besoin configurer le logger (ou supprimer les appels ci-dessus):

Code : Tout sélectionner

def main(argv):
    """
    Main
    """
    logger = logging.getLogger()
    handler = logging.StreamHandler(sys.stdout)
    
    # Configure the logger
    handler.setFormatter(
        logging.Formatter('%(asctime)s - %(levelname)s - %(message)s')
    )
    logger.setLevel(INFO) # Or DEBUG
    logger.addHandler(handler)
    
    # La suite ici : ...

Avec comme précisé une utilisation hors cadre plugin, mais ce serait quand même étonnant que cela ne fonctionne pas tout de même....

[TFx]

Merci Lost.
J'ai fait un test d'une requête http en python dans un script Domoticz événement minimaliste (dans l'IHM Domoticz) et cela rend l'IHM inaccessible :

Code : Tout sélectionner

import urllib.request
request = urllib.request.Request('http://localhost/json.htm?type=command&param=updateuservariable&vname=PreviousState&vtype=2&vvalue=On', None, {})

Je vais regarder avec attention tes scripts et voir si cela fonctionne mieux...

[TFx]

Même résultat avec tes scripts python : si ces scripts sont appelés par Domoticz (sur événement type time ou Device), la requête http fait planter le serveur web de Domoticz et l'IHM ne répond plus...

A noter que si le script est appelé hors de Domoticz (en ligne de commande par exemple), ça marche très bien. Ce serait donc un problème de contexte d'exécution

Précision : testé sur Domoticz v4.10717 stable et v4.11352 (beta) sur Raspberry Pi 2 sous Raspbian Buster