Concernant la mise à jour de la Zibase de fin février 20126 minute(s) de lecture

Concernant la mise à jour de la Zibase datée de février 2012 voici quelques éléments d’informations qu’il peut être important de connaître afin de bien utiliser votre Zibase afin d’en connaître les impacts et d’en comprendre le fonctionnement.

Gestion de la mémoire

La mise à jour de ce mois de février 2012 permet de redonner un peu d’air à la Zibase au niveau de la mémoire.  Cette mise à jour optimise l’utilisation de la mémoire déjà disponible tout en donnant accès à une  partie de la mémoire embarquée qui n’était pas utilisée auparavant.  On passe ainsi de 50 scénarii à 125!

La gestion de la mémoire est telle que si vous faites un scénario avec peu d’actions ou un scénario rempli au maximum, le taux d’occupation de la mémoire n’augmente pas… Ce qui fait augmenter le taux d’occupation c’est le fait de référencer le scénario pour être utilisé via la ZAPI ou bien si vous faites référence à un ou plusieurs modules déclencheurs.

C’est une bonne nouvelle: vous pouvez avoir un bon nombre de modules la mémoire ne sera que peu affectée.  Vous pouvez utiliser des chaines de caractères longues pour vos actions faisant appel à des requêtes HTTP, la mémoire ne sera que très peu sensible.

Concernant la taille  maximum d’un scénario, cela n’a pas évolué.  Un message d’erreur vous avertira de toutes manières que votre scénario contient trop d’actions lorsque vous voudrez le sauvegarder.  Cette limitation devrait être levée dans une prochaine mise à jour à venir.

Effet de bord intéressant : je trouve que le temps de latence entre le déclenchement manuel d’une action via l’application iPhone par exemple et l’action s’est amélioré.

Gestion de modules Delta Dore

Le protocole permettant de gérer les modules Delta Dore a également été un peu remanié.  La prise en compte du protocole X3D semble être de la partie mais n’ayant pas de modules Delta Dore dernière génération, je n’ai pas pu tester ce dernier point. 

Si vous avez des modules Delta Dore à paramétrer, voici les protocoles à affecter pour que vos modules soient correctement reconnus par la Zibase:

  XDD alarm * SHUTTER A/B * XDD Pilot Wire Boiler/AC
Tyxia 460 X X    
Tyxia 461 X X    
Tyxia 463
X    
Tyxia 4840 X X (X3D !)    
Deltia 1.03

X  
Deltis 1.13

  X
RF640

  X

*Le mode ALARM est à privilégier sur le mode SHUTTER. 

N’oubliez pas que, dans ce mode SHUTTER uniquement, les modules Delta Dore doivent avoir comme identifiant radio les valeurs A1 à A16 ou bien B1 à B16. Si vous les affectez à d’autres identifiants radio, ils ne seront pas pilotés par la Zibase.

Gestion des volets roulants RFY/RTS

Les identifiants C1 à C16 puis D1 à D16 seront à utiliser pour piloter des produits Somfy via le protocole RFY/RTS.  Seuls 32 périphériques sont à ce jour gérés par la Zibase.  Cela vous permet tout de même de gérer 32 volets!

La procédure d’association des volets roulants se fait de la même manière que pour des modules Delta Dore par exemple. Il faut créer le module récepteur dans la Zibase avec le protocole RFY mettre le récepteur en mode association et appuyer sur le bouton “assoc” de la Zibase.  C’est tout. 

N’ayant pas de volets roulants motorisés chez moi je n’ai pas pu tester ce dernier point tant attendu par les propriétaires de volets Somfy.  Ces derniers ont pu faire un retour d’expérience plutôt enthousiaste concernant cette prise en charge.  L’association entre le volet et la box est décrite sur les forums de domotique :

Mettre le store a mi hauteur et appuyer avec un stylo sur le bouton à l’arriere de la télécommande Somfy Telis.
Le store monte et descend.
Dans le configurateur Zibase, créer un actionneur XDD/RFY Shutter dont l’adresse est Cx ou Dx et appuyer sur Assoc. Le store doit alors monter et descendre.
L’association avec la zibase est faite.

Aujourd’hui seules les commandes ON/OFF sont implémentées.  Le reste suivra par la suite.  A ce sujet Zodianet recherche des béta testeur pour en vérifier le bon fonctionnement.

Gestion du Z-Wave

La gestion du Z-Wave a fait également quelques avancées.  Ces améliorations sont disponibles à la fois aux propriétaires de la passerelle externe ZCS201 et aux futurs propriétaires de la Zibase “2” qui gérera le protocole Z-Wave en interne. 

Concernant le module ZCS201 externe Zodianet annonce quelques limitations en même temps que quelques descriptions des mécanismes Z-Wave mis en place :

  • Les inclusions/exclusions comportent des ratés (il faut alors recommencer l’opération), il fait même une fixation sur certains actionneurs ZDP230 lors de ces opérations,
  • Il ne permet pas de générer de graphes de connexions entre noeuds,
  • Il ne gère pas le FLiRS.
  • Il rayonne énormément, éloignez le au maximum de ZiBASE pour ne pas la perturber en 868Mhz.

PS: Sur les techniques de “FLiRS” et de “Wake Up” utilisés en Zwave (périphériques sur piles uniquement):

Le FLiRS est décrit ici. Le périphérique récepteur se réveille quelques dizaines de microsecondes toutes les secondes (à titre indicatif) pour écouter s’il passe une trame de réveil FLiRS (émise forcément sur plus d’une seconde). Pour la longévité des piles le rapport cyclique : Temps activité / Temps inactivité est déterminant.

En pratique, le ZCS201 ne peut piloter une sirène sur piles (genre SE812 utilisant FLiRS) qui doit naturellement s’actionner le plus vite possible. Le FLiRS est peu utilisé mais il est agréable à l’utilisation car le périphérique réagit tout de suite.

La technique alternative au FLiRS est le “Wake Up” (géré par le ZCS201) où le périphérique se réveille périodiquement en le notifiant au contrôleur ZWAVE (il émet une notification “je suis réveillé!” puis écoute quelques secondes). Le Wake Up est très utilisé et consomme peu si l’intervalle entre réveils est grand (On a dit “si”). Le “Wake Up” est désagréable à l’usage car les requêtes vers le périphérique sont stockées,  puis émises à son attention seulement à son réveil. Selon la valeur programmée de périodicité, cela peut être 1/2 ou 1 heure après. Evidemment, tout le monde mettra le minimum possible – souvent vers les 5 mn – malgré les mises en garde du constructeur sur la longévité des piles. Là aussi, le rapport cyclique : Temps activité / Temps inactivité est déterminant pour la longévité des piles.

Vous êtes maintenant prévenus.  Si vous souhaitez une prise en compte globale du protocole Z-Wave et de sa gestion via la Zibase, il est plutôt conseillé de patienter jusqu’à la sortie de cette nouvelle Zibase…

 

3 Comments

  1. Pascal said:

    salut Hervé,

    Juste une petite remarque, la Zibase ne supporte pas le protocole X3D mais les modules X3D en X2D…

    😉

    29 février 2012
    Reply
    • yesman said:

      Bonjour Pascal,
      Cela veut dire que des modules X3D peuvent quand même être pilotés correctement (exemple RF 6600 FP) ??

      6 janvier 2014
      Reply
  2. […] Concernant la mise à jour de la Zibase de fin février 2012 L’objectif ici sera de récupérer la valeur de température d’une sonde Oregon reliée à une Zibase, en interrogeant le fichier XML distant contenant cette information. […]

    17 septembre 2012
    Reply

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Prouvez que vous êtes humain: * Time limit is exhausted. Please reload CAPTCHA.