Lazer

héhé

Attention, cette valeur maxi de réveil est différente d'un module àl'autre. Pour le FGSS-001, c'était 86399 s

@Pepite oui ça fait 10 jours chez Domadoo aussi, on en a parlé y'a pas longtemps Ce qui est fou, c'est qu'il n'y a eu aucune communication officielle de Fibaro sur ce passage Z-Wave+, même les revendeurs l'ont découvert par hasard !!!

Bon, j'ai cherché un peu.... et j'ai fini par trouver une doc avec les paramètres du module. Mais pourquoi ce n'est pas dans la doc de base fournie avec le module, ni sur Domadoo ? Bref, sur le site de domotique-store : Spéc. tech. ZW096 Smart Switch 6 (PDF) J'ai pas trop eu le temps de regarder en détail, mais il a l'air d'y avoir pas mal de choses, il y a peut être moyen de tirer quelque chose de cette prise.

Non, justement, mes tests ont montré qu'il n'y a pas de remonté de conso instantanée. Ce n'est que du polling, donc la box qui va chercher les infos a intervalle régulier. Comme sur les tous premiers modules Z-Wave quoi, et ce que je dis c'est qu'on n'a plus l'habitude depuis que Fibaro nous fait des modules tip-top tels que WP et FGMS ( Benjy ) Bref difficilement exploitable dans des scénarios. Il faut que je confirme tout cela avec quelques tests sur Jeedom

Non mais Jeedom c'est ouvert, mais à des protocoles fermés (Z-Wave, et ses petits concurrents). En plus c'est un truc de geek, complexe. Ce n'est pas la cible du grand public. Là on parle de clairement autre chose, des protocoles de haut niveau, qui sont là pour unifier tout le monde. Comme l'IP pour le réseau. Jeedom n'est qu'une passerelle, comme l'est notre HC2, entre un monde et un autre. Thread, ou un autre, viendra fédérer Jeedom, HC2, Zibase et les autres pour communiquer avec la voiture, le frigo, le téléphone, etc.... Thread ou un autre, sera implémenté dans tous les objets, et sera doté d'une interface intuitive. Là dessus, seul des Samsung, Google, Apple (si ils le veulent bien), Legrand, etc auront les moyens de réfléchir à l'intégration dans leurs propres produits, qui sont des référence en matières d'interface homme-machine, en plus d'avoir une base de client conséquente.

Oui làje suis d'accord, mais encore une fois sur ce Zw096 en particulier, il n'y a rien àredire. Il fonctionne comme attendu, c'est juste qu'on est trop exigeant avec notre habitude des modules Fibaro, surtout le Wall Plug, truffés de paramètres et d'options.

65535 s pour la valeur maxi, c'est pour cela qu'il te jette grillé

sur ce module Aeotec en particulier, je ne pense pas qu'on puisse le reprocher à la Z-Wave Alliance (même si je suis d'accord sur le fond du débat). Ce module ne fait rien, et comme on dit, y'a que ceux qui ne font rien qui ne se trompe pas.... dans la doc du module, il n'y a aucun paramètre permettant de configurer la remonté de consommation. Donc j'ai envie de dire "work as designed"

C'était le risque, mais pour moi ils ont loupé leur coup. Homekit n'a jamais décollé, quasiment aucun périphériques ne sont compatibles, et je ne serais pas surpris que Apple ai fait des beaux chèques à Philips & co pour qu'ils ajoutent la compatibilité à leur produits. A coté de ça, Apple ne fabrique aucun objet connecté, donc ils ne peuvent même pas se créer leur propre écosystème. A contrario Samsung en est parfaitement capable. C'est simple, les seuls à avoir encensé Homekit, c'est la presse généraliste, que l'on sait depuis longtemps acquis à la cause Apple. A coté de ça, dès que tu creuses un peu dans la presse spécialisée et sur les salons internationaux (bâtiment, domotique, informatique), ça ne parle plus que de Thread, AllJoyn, etc.... pour moi la tendance est claire.

je n'ai pas ce module, donc pas d'expérience particulière, mais c'est une mauvaise idée de fermer la fenêtre d'inclusion. Tu devrais essayer de réveiller le module lorsque la fenêtre d'inclusion est encore ouverte, afin que la HC2 finisse l'inclusion propre du module.

Euh.... oui et non. Si des marques comme Apple ou Fibaro (à son échelle) continuent de se prendre pour les rois du monde, et à dédaigner tout le monde, alors oui ils auront une solution qui fonctionne, mais de façon totalement fermée, donc ils seront juste compatible avec un nombre très limité de périphériques. Si t'as un iPhone et un électroménager Samsung, bah tu l'as dans l'os. Donc a un moment, ils seront bien obligé de s'adapter et d'accepter de communiquer avec le reste du monde. Samsung ils sont moins idiots, ils ont racheté Smartthings qui cause en Z-Wave, Zigbee (et donc bientôt le futur Zigbee 3 avec une vraie normalisation de la couche applicative, et des technos EnOcean sans-pile dedans). Ils sera facile d'y ajouter le futur protocole universel qui unifiera tout le monde. Même Apple s'y mettront, aujourd'hui un MacOS sais discuter couramment sur un réseau Windows (SMB/CIFS), et pour avoir pratiqué les versions de MaxOS avant X, c'était pas gagné d'avance avec leur AppleTalk fermé. Microsoft a dominé le monde pendant les années 1990/2000, mais leurs protocoles sont devenus des standards acceptés de tous maintenant. Là où Google est intelligent avec Thread, c'est que les spécifications sont totalement ouvertes, donc le protocole a plus de chance d'être accepté par tous. Autre lecture pour ceux qui l'auraient raté hier : #MWC2016 : Rencontre avec l’Open Connectivity Foundation Ca n'a pas finit de bouger pour notre plus grand bonheur

Bon je suis chaud là. Pour étayer ce que je dis, et prouver le polling forcé par Fibaro HC2 pour la multiprise Greewave (sur ma box de test pour ne pas être pollué par les milliers de messages sur ma box de prod) : root@fghc2:/tmp# grep 'Performing poll action for device 22' Zwave.log 3 23:02:04:7 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:06:14:8 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:10:24:8 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:14:34:9 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:18:44:9 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:22:55:0 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:27:05:1 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:31:15:1 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:35:24:2 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:39:34:2 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:43:44:3 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:47:54:3 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:52:04:4 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 23:56:14:5 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 00:00:24:5 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 00:04:34:6 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 3 00:08:44:6 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 22 Toutes les 4 minutes environ. C'est le mieux qu'on aura sur ce genre de module au firmware développé àl'arrache.

Je confirme, je viens de refaire un polling, les informations passent dans les logs du moteur Z-Wave, et si on attends suffisamment que le poling aie le temps de se terminer, les valeurs se mettent à jour sur l'interface de la HC2. Donc comportement totalement identique à la multiprise Greenwave. Quand Fibaro implémentera le support de ce module, avec le template, ils vont forcer un polling régulier, je ne vois pas d'autres possibilité. Donc on n'aura jamais de retour d'information en temps réel. Ca me saoule, j'ai pas acheté un module qui coute le même prix qu'un Wall Plug pour avoir une information décalée dans le temps..... c'est décidé, je vais le renvoyer

Réponse pour i-magin : Aeotec fait de la merde Le module n'a pas envoyé un seul relevé de conso depuis mes tests de polling tout à l'heure : root@fghc2:/tmp# grep "EVENT: updateProperty: power devId: 458 value" Zwave.log.0 5 22:22:59:0 [Notice] EVENT: updateProperty: power devId: 458 value: 0.0000000000000000 5 22:22:59:6 [Notice] EVENT: updateProperty: power devId: 458 value: 0.0000000000000000 5 22:32:07:2 [Notice] EVENT: updateProperty: power devId: 458 value: 2088.2800000000002 5 22:52:29:5 [Notice] EVENT: updateProperty: power devId: 458 value: 2104.1799999999998 5 22:54:01:4 [Notice] EVENT: updateProperty: power devId: 458 value: 2138.4969999999998 5 22:54:56:9 [Notice] EVENT: updateProperty: power devId: 458 value: 2107.6619999999998 Pourtant je peux te garantir que la conso est repassée à 0, tout comme l'anneau est repassé à la couleur verte. Donc si pas de polling, le module ne répond rien. Comportement identique à la Greenwave. Ca me saoule ces fabricants, Aeotec, Greenwave, Qubino, qui ont des supers idées de modules, mais implémentent les fonctions basiques Z-Wave n'importe comment. Pour ma part, je crois qu'à la lumière de ce résultat, le ZW096 va repartir d'où il vient. Ca fait 2 fois en 15 jours que je me fait avoir par des nouveaux modules au firmware pas fini.... ça va me calmer pour un moment de tester des nouveaux modules ça :angry:

@Did : faudrait que je teste sur Jeedom. @i-magin : je n'ai pas vérifié si le module remonte l'info régulièrement, j'ai seulement vu les logs après avoir forcé le polling. Donc on ne sait pas encore si Aeotec fait bien son job ou pas. Déjà pour Fibaro, on sait @chris6783 : bonne idée, ça mérite un test.... bon j'ai pas trop envie de casser mon réseau de prod, je peux faire l'essai sur ma box de test, mais faut que je réinclue quelques modules pour ça....

Ah bah ça alors, voilà que j'ai une remonté dans l'interface maintenant !!!! Surement mes pollings répétés qui l'ont excité un peu ! Le gag c'est que la machine est maintenant terminée, et le module est resté bloqué à 2.11 kW : . Bref, pas du tout utilisable en l'état.....

Bon, j'ai fait tourner le lave-vaisselle, et la puissance W, l'énergie kWh, et l'ampérage A ne sont jamais remonté sur l'interface de la HC2 en 4.080. Quand on clique sur le bouton "Interroger cet appareil", pas plus de résultat Donc je suis allé voir les logs du moteur Z-Wave dans les sombres recoins de la HC2 : 3 22:54:45:4 [Notice] ROUTER: [JSONRPCServer] callAction callAction name: "poll" paramSize: 0 json: [] 3 22:54:45:4 [Notice] ROUTER: [JSONRPCServer] [JSONRPCServer::pollDevice] Performing poll action for device 457 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_SWITCH_BINARY >> Command serialization: cmdSwitchBinaryGet 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_SWITCH_MULTILEVEL >> SWITCH_MULTILEVEL_GET 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_METER >> Command serialization: METER_GET_V3: [unit=kWh][scale=0] 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_METER >> Command serialization: METER_GET_V3: [unit=W][scale=2] 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_METER >> Command serialization: METER_GET_V3: [unit=V][scale=4] 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_METER >> Command serialization: METER_GET_V3: [unit=A][scale=5] 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_COLOR_CONTROL >> Command serialization: cmdColorControlStateGet [capabilityId=2] 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_COLOR_CONTROL >> Command serialization: cmdColorControlStateGet [capabilityId=3] 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_COLOR_CONTROL >> Command serialization: cmdColorControlStateGet [capabilityId=4] 3 22:54:45:4 [Information] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_COLOR_CONTROL >> Command serialization: cmdColorControlStateGet [capabilityId=0] 1 22:54:45:4 [Notice] DRIVER: devId: 0 nId: 102 eId: 0 jobId: 5651570 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: true callback: 134 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x3 finish send; jobs in JobHandler: 9 1 22:54:45:5 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> handler cmd class: COMMAND_CLASS_COLOR_CONTROL 1 22:54:45:5 [Notice] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_COLOR_CONTROL >> Received command: STATE_REPORT[colorId=3][value=20] 1 22:54:45:5 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> Comfirm for sendJob: 102 cmdClass: COMMAND_CLASS_COLOR_CONTROL cmd: 4 1 22:54:45:6 [Notice] DRIVER: devId: 0 nId: 102 eId: 0 jobId: 5651571 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: true callback: 135 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x4 finish send; jobs in JobHandler: 8 1 22:54:45:6 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> handler cmd class: COMMAND_CLASS_COLOR_CONTROL 1 22:54:45:6 [Notice] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_COLOR_CONTROL >> Received command: STATE_REPORT[colorId=4][value=27] 1 22:54:45:6 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> Comfirm for sendJob: 102 cmdClass: COMMAND_CLASS_COLOR_CONTROL cmd: 4 1 22:54:45:8 [Notice] DRIVER: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: true callback: 136 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 finish send; jobs in JobHandler: 7 1 22:54:46:3 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> waiting ... 528ms txCount: 1 timeCommunication: 0 1 22:54:46:3 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: false txCount: 1 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 1 22:54:47:8 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> waiting ... 2037ms txCount: 1 timeCommunication: 0 1 22:54:47:8 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: false txCount: 1 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 1 22:54:49:3 [Error] DRIVER: timeout for wait for Report job: cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: false txCount: 1 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 1 22:54:49:3 [Notice] DRIVER: Resend frame txCount: 1 max retry send: 3 1 22:54:49:3 [Notice] DRIVER: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: true callback: 137 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 2 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 finish send; jobs in JobHandler: 7 1 22:54:49:8 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> waiting ... 525ms txCount: 2 timeCommunication: 0 1 22:54:49:8 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: false txCount: 2 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 1 22:54:51:4 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> waiting ... 2034ms txCount: 2 timeCommunication: 0 1 22:54:51:4 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: false txCount: 2 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 1 22:54:52:9 [Error] DRIVER: timeout for wait for Report job: cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: false txCount: 2 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 1 22:54:52:9 [Notice] DRIVER: Resend frame txCount: 2 max retry send: 3 1 22:54:52:9 [Notice] DRIVER: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: true callback: 138 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 3 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 finish send; jobs in JobHandler: 7 1 22:54:53:4 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> waiting ... 527ms txCount: 3 timeCommunication: 0 1 22:54:53:4 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: false txCount: 3 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 1 22:54:54:9 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> waiting ... 2041ms txCount: 3 timeCommunication: 0 1 22:54:54:9 [Warning] JOB: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: false txCount: 3 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 1 22:54:56:4 [Error] DRIVER: timeout for wait for Report job: cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: false txCount: 3 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 1 22:54:56:4 [Notice] DRIVER: Resend frame txCount: 3 max retry send: 3 1 22:54:56:4 [Warning] DRIVER: devId: 0 nId: 102 eId: 0 jobId: 5651572 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: false callback: 0 waitFunction: 0x0 isNeedResend: true txCount: 3 prio: 10 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x0 : transmission succeeded, but expected response from the device was not received. 1 22:54:56:4 [Notice] DRIVER: devId: 458 nId: 102 eId: 0 jobId: 5651562 >> cc: Command Class Switch Binary cmd: Switch Binary Get ccWaitFor: Command Class Switch Binary cmdWaitFor: Switch Binary Report ack: true callback: 139 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 15 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x25 0x2 finish send; jobs in JobHandler: 6 1 22:54:56:5 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> handler cmd class: COMMAND_CLASS_SWITCH_BINARY 1 22:54:56:5 [Notice] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_SWITCH_BINARY >> Received command: SWITCH_BINARY_REPORT: [value=255] 1 22:54:56:5 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> Comfirm for sendJob: 102 cmdClass: COMMAND_CLASS_SWITCH_BINARY cmd: 3 1 22:54:56:6 [Notice] DRIVER: devId: 458 nId: 102 eId: 0 jobId: 5651563 >> cc: Command Class Switch Multilevel cmd: Switch Multilevel Get ccWaitFor: Command Class Switch Multilevel cmdWaitFor: Switch Multilevel Report ack: true callback: 140 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 15 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x26 0x2 finish send; jobs in JobHandler: 5 1 22:54:56:6 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> handler cmd class: COMMAND_CLASS_SWITCH_MULTILEVEL 1 22:54:56:6 [Notice] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_SWITCH_MULTILEVEL >> Received command: SWITCH_MULTILEVEL_REPORT [value=99] 1 22:54:56:6 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> Comfirm for sendJob: 102 cmdClass: COMMAND_CLASS_SWITCH_MULTILEVEL cmd: 3 1 22:54:56:7 [Notice] DRIVER: devId: 458 nId: 102 eId: 0 jobId: 5651565 >> cc: Command Class Meter cmd: Meter Get ccWaitFor: Command Class Meter cmdWaitFor: Meter Report ack: true callback: 141 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 15 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x32 0x1 0x0 finish send; jobs in JobHandler: 4 1 22:54:56:7 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> handler cmd class: COMMAND_CLASS_METER 1 22:54:56:7 [Notice] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_METER >> Received command: METER_REPORT_V3: Rate type: IMPORT Meter type: METER_REPORT_ELECTRIC_METER Value: 0.767 Delta: 56 Previous: 0.732 5 22:54:56:7 [Notice] EVENT: updateProperty: energy devId: 458 value: 0.76700000000000002 1 22:54:56:7 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> Comfirm for sendJob: 102 cmdClass: COMMAND_CLASS_METER cmd: 2 5 22:54:56:7 [Notice] EVENT: updateProperty: unit devId: 458 value: "kWh" 5 22:54:56:7 [Notice] EVENT: updateProperty: unit devId: 458 value: "kWh" 1 22:54:56:8 [Notice] DRIVER: devId: 458 nId: 102 eId: 0 jobId: 5651566 >> cc: Command Class Meter cmd: Meter Get ccWaitFor: Command Class Meter cmdWaitFor: Meter Report ack: true callback: 142 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 15 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x32 0x1 0x10 finish send; jobs in JobHandler: 3 1 22:54:56:9 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> handler cmd class: COMMAND_CLASS_METER 1 22:54:56:9 [Notice] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_METER >> Received command: METER_REPORT_V3: Rate type: IMPORT Meter type: METER_REPORT_ELECTRIC_METER Value: 2107.66 Delta: 0 Previous: 0 5 22:54:56:9 [Notice] EVENT: updateProperty: power devId: 458 value: 2107.6619999999998 1 22:54:56:9 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> Comfirm for sendJob: 102 cmdClass: COMMAND_CLASS_METER cmd: 2 5 22:54:56:9 [Notice] EVENT: updateProperty: unit devId: 458 value: "W" 5 22:54:56:9 [Notice] EVENT: updateProperty: unit devId: 458 value: "W" 1 22:54:57:0 [Notice] DRIVER: devId: 459 nId: 102 eId: 0 jobId: 5651567 >> cc: Command Class Meter cmd: Meter Get ccWaitFor: Command Class Meter cmdWaitFor: Meter Report ack: true callback: 143 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 15 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x32 0x1 0x20 finish send; jobs in JobHandler: 2 1 22:54:57:0 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> handler cmd class: COMMAND_CLASS_METER 1 22:54:57:0 [Notice] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_METER >> Received command: METER_REPORT_V3: Rate type: IMPORT Meter type: METER_REPORT_ELECTRIC_METER Value: 226.585 Delta: 0 Previous: 0 5 22:54:57:0 [Notice] EVENT: updateProperty: value devId: 459 value: 226.58500000000001 1 22:54:57:0 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> Comfirm for sendJob: 102 cmdClass: COMMAND_CLASS_METER cmd: 2 5 22:54:57:0 [Notice] EVENT: updateProperty: unit devId: 459 value: "V" 5 22:54:57:0 [Notice] EVENT: updateProperty: unit devId: 459 value: "V" 1 22:54:57:1 [Notice] DRIVER: devId: 460 nId: 102 eId: 0 jobId: 5651568 >> cc: Command Class Meter cmd: Meter Get ccWaitFor: Command Class Meter cmdWaitFor: Meter Report ack: true callback: 144 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 15 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x32 0x1 0x28 finish send; jobs in JobHandler: 1 1 22:54:57:2 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> handler cmd class: COMMAND_CLASS_METER 1 22:54:57:2 [Notice] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_METER >> Received command: METER_REPORT_V3: Rate type: IMPORT Meter type: METER_REPORT_ELECTRIC_METER Value: 9.315 Delta: 0 Previous: 0 5 22:54:57:2 [Notice] EVENT: updateProperty: value devId: 460 value: 9.3149999999999995 1 22:54:57:2 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> Comfirm for sendJob: 102 cmdClass: COMMAND_CLASS_METER cmd: 2 5 22:54:57:2 [Notice] EVENT: updateProperty: unit devId: 460 value: "A" 5 22:54:57:2 [Notice] EVENT: updateProperty: unit devId: 460 value: "A" 1 22:54:57:3 [Notice] DRIVER: devId: 458 nId: 102 eId: 0 jobId: 5651569 >> cc: Command Class Switch Color cmd: Color Switch Get ccWaitFor: Command Class Switch Color cmdWaitFor: Color Switch Report ack: true callback: 145 waitFunction: FUNC_ID_ZW_SEND_DATA isNeedResend: false txCount: 1 prio: 15 Security: false CRC: false MultiCmd: false bufferCmd: H: 0x33 0x3 0x2 finish send; jobs in JobHandler: 0 1 22:54:57:3 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> handler cmd class: COMMAND_CLASS_COLOR_CONTROL 1 22:54:57:3 [Notice] CMD: devID: 458 nID: 102 eID: 0 CC: COMMAND_CLASS_COLOR_CONTROL >> Received command: STATE_REPORT[colorId=2][value=27] 1 22:54:57:3 [Information] CMD_FACTORY: devId: 458 nID: 102 eID: 0 >> Comfirm for sendJob: 102 cmdClass: COMMAND_CLASS_COLOR_CONTROL cmd: 4 Mon device a le Node ID 102, et le Device ID 457. Les enfants ont les Devices ID 457, 458, et 459 Et qu'est ce qu'on voit : que les valeurs remontent bien depuis le module : 0.76700000000000002 kWh 2107.6619999999998 Watts 226.58500000000001 Volts 9.3149999999999995 Ampères Donc c'est (encore) un bug de la HC2 qui ne remonte pas les données dans la DB et l'interface. Le moteur Z-Wave reçoit bien les infos. Messieurs Fibaro, au boulot !!!!

oui exact simple techno, doubles faisceau PIR, comme mes DIagral. Mais c'est fiable quand même grâce au double faisceau, la contrainte c'est de l'installer absolument vers 90cm de hauteur. Impossible de le placer en hauteur comme celui que tu as acheté. Après je me demande quelle est la qualité des capteurs... àce prix làça doit être du premier prix, pas certain de la fiabilité en plein soleil.

@Jojo tu nous feras un retour sur la fiabilité de ces Selectronic, ça ne me semble anormalement pas assez cher par rapport à tous les autres capteurs qui fonctionnent sur le même principe de double faisceau. SInon sur le principe, cette technologie est d'une fiabilité à toute épreuve, j'en ai 3 de mon alarme Diagral tout autour de la maison..... même ébloui en plein soleil, ça fonctionne. D'ailleurs, j'ai démonté l'un des miens, en plus du boitier étanche, la carte électronique a été plongée dans un bain pour l'étanchéifier, de la grande qualité. Les Diagral sont cher mais au moins on sait pourquoi.

Non mais Apple ils ont perdu d'avance, la dessus y'a même pas débat. Ils font un système fermé et propriétaire, par définition, alors que l'objectif est de créer un système ouvert, auquel les perdants devront se rallier quoi qu'il arrive. Exemples célèbres : VHS/Betamax, Blu-ray/HD-DVD, TCPIP/Novel-IPX, MS-Office/Lotus, etc... La liste est sans fin, et rappelle un article d'Abavala sur la différence entre une norme et un standard de facto. Il n'y aura très certainement jamais de norme en domotique, mais uniquement un standard de facto. Ce qui est certain c'est que ça tournera autour de TCP/IP, donc Google Thread a toutes ses chances. En ce qui concerne Fibaro, ils seront bien obligé de se raccrocher àce futur standard, quand la Z-Wave Alliance sortira des spécifications pour interconnecter nos modules avec ce futur protocole universel.

Source : batirama => Domotique (3) : Google repart à l’attaque avec Thread C'est intéressant, mais il est encore trop tôt pour savoir si ce protocole sera réellement le protocole ultime qui réussira à unifier tout le monde. Comme souvent en hitech/informatique/électronique, ce n'est pas toujours le meilleur protocole qui l'emporte (souvenir du VHS vs Betamax), mais celui qui est le mieux poussé par son concepteur. Google a une force de frappe technique conséquente, mais ils sont plutôt mauvais en communication/marketing. A suivre avec attention...

C'est clair que de ne pas pouvoir paramétrer l'intervalle ou le seuil de remonté d'info vers le contrôleur Z-Wave est pénalisant sur cette prise. C'est là qu'on se dit que les modules Fibaro avec leur nombreux paramètres sont quand même géniaux. Cette prise Aeotec me rappelle un peu la multiprise Greenwave, dont la remonté d'info a quelques secondes de retard....

@Nico ; Start pour passer en enregistrement continu pendant les vacances, afin de ne rien louper, car le risque de visite est beaucoup plus élevé qu'en temps normal, et la détection Syno n'est pas fiable à 100%... il y a des faux positifs, mais aussi des faux négatifs. Pour les faux positifs, je confirme qu'un chat devant la fenêtre peut déclencher l'enregistrement ! Et le grand classique, c'est la Foscam qui passe en mode IR le nuit, et inversement le matin, ça déclenche l'enregistrement à tous les coups. L'idéal ce sont les détecteurs bi-technologie.

@Jojo Ah oui très important le pré-roll pour l'enregistrement C'est un point fort de la détection par le Syno. Oui tu peux faire cela pour la variable camera, c'est simple et efficace. @Nico : - Enable au quotidien - Enable + Start pendant les vacances