Santé : tous les modules unknown sauf le controleur

Bonjour,

Il m’arrive malheureusement trop souvent d’avoir le plugin z-wave aux fraises sans même avoir le plugin et son daemon plantés. Toute la config Z-wave est vide, cela semble arriver après des coupures de courant, la seule solution que je connaisse est de débrancher le contrôleur z-wave pendant un moment, voire de faire quelques reboots aussi. Des fois, je recharge même un backup de la config xml des modules. Mais, bon, là n’est pas la question, même si pour moi, je considère qu’il n’est plus une bonne idée que d’investir dans de nouveaux modules Z-wave.
La question est : quand cela arrive, la page Santé est vide. Pour la repeupler correctement et avoir le nom des modules remplacés par leur véritable nom, il suffit d’aller sur chacun d’eux et de cliquer sur sauvegarder. Je pense qu’il est possible de scripter juste la partie mettant à jour le nom dans la page Santé, ce qui évitera d’aller sur chaque module pour le sauvegarder. Je n’ai malheureusement pas la compétence pour le faire mais je pense qu’un tel script doit être faisable et pourrait même être intégré au démarrage du démon, ce qui supprimera définitivement ce problème de modules unknown car il me semble avoir lu que je n’étais pas le seul à le connaitre.
Merci de votre intérêt.

Bonjour,
Vraiment étonnant ce problème. Ce n’est clairement pas commun ni normal.
Quel matériel utilisé ? Quelle clé ?
Sinon est ce qu’une synchro ne permet pas de récupérer le lien plutôt que de devoir passer sur chaque équipement ? À priori c’est en partie son rôle.

Salut,

J’ai le même souci depuis une coupure de courant et a part le controleur tout est unknown mais tout fonctionne donc je laisse comme cela sachant que si je regarde le détail d’un module il est bien reconnu

Seul dans santé le souci apparait donc je pense vraiment a un bug du plugin et pas un souci puisque tout roule

Et donc même la synchro n’aide pas ?
C’est sensé refaire le lien entre les infos du contrôleur / démon et les équipements jeedom

Et si tu essayais un bloc code comme ça dans un scénario, ça ping automatiquement tous les noeuds :

C’est l’un des problèmes que j’ai décris dans l’un des posts lié au problème Zwave.

Problème uniquement sur ma V4, pas sur ma V3.

Même constat, pas de problème de fonctionnement et le simple faite de sauver l’équipement zwave remet le nom dans la santé.

Je suis sur Pc avec une Debian. Le contrôleur est un ZW090 Z-Stick Gen5 EU de chez Aeotec. J’avais aussi ce problème quand ma prod était sur Rpi.

Petit complément d’info, pas pour l’histoire des unknown, mais pour le pb du Z-wave aux fraises. J’ai eu une coupure élec ce matin vers 6h30.
Dans Jeedom, j’ai ce code qui tourne toutes les heures dans les scripts

# Etat possible du réseau Z-Wave

# STATE_STOPPED = 0
# STATE_FAILED  = 1
# STATE_RESET   = 3
# STATE_STARTED = 5
# STATE_AWAKED  = 7
# STATE_READY   = 10

try {
  $apizwave = jeedom::getApiKey('openzwave');
  $url = 'http://127.0.0.1:8083/network?type=info&info=getStatus&apikey='.$apizwave;
  $contents = file_get_contents($url);
  $contents = utf8_encode($contents);
  $scenario->setLog('Contents :'.$contents);
  $results = json_decode($contents);
  if ($results->state == "ok") {
    $networkState = $results->result->state;
    $scenario->setData('ZWaveStatus', $networkState);
  }
} catch (Exception $e) {
  $scenario->setData('ZWaveStatus', -1);
}

Et voici ce qu’il a logué ce matin, avant et après la coupure :

[2020-04-18 06:05:01][SCENARIO] Start : Scenario execute automatiquement sur programmation.
[2020-04-18 06:05:01][SCENARIO] Exécution du sous-élément de type [action] : code
[2020-04-18 06:05:01][SCENARIO] Exécution d'un bloc code
[2020-04-18 06:05:01][SCENARIO] Contents :{"state": "ok", "code": 0, "result": {"neighbors": "3;6;11;13;16;20;26;35;36;38;40;41", "isReady": false, "awakedDelay": 243, "OpenZwaveLibraryVersion": "1.4.0", "isPrimaryController": true, "pollInterval": 300000, "state": 7, "controllerStatistics": {"retries": 20, "readCnt": 1256887, "readAborts": 0, "routedbusy": 0, "ACKCnt": 5661, "OOFCnt": 0, "noack": 6, "broadcastWriteCnt": 12, "callbacks": 54, "writeCnt": 1093, "badChecksum": 0, "nondelivery": 99, "CANCnt": 23, "NAKCnt": 0, "netbusy": 0, "SOFCnt": 1256887, "broadcastReadCnt": 0, "badroutes": 0, "ACKWaiting": 9, "dropped": 108}, "isBusy": false, "outgoingSendQueue": 0, "controllerCapabilities": "primaryController", "isStaticUpdateController": false, "PythonOpenZwaveLibraryVersion": "0.3.1", "startTime": 1585680950, "devicePath": "/dev/ttyUSB-ZStick-5G", "controllerNodeCapabilities": "beaming;listening;primaryController", "stateDescription": "Topology loaded", "nodesCount": 25, "isBridgeController": false, "scenesCount": 0, "mode": 0, "sleepingNodesCount": 3}}
[2020-04-18 06:05:01][SCENARIO] Fin correcte du scénario
------------------------------------
[2020-04-18 07:05:01][SCENARIO] Start : Scenario execute automatiquement sur programmation.
[2020-04-18 07:05:01][SCENARIO] Exécution du sous-élément de type [action] : code
[2020-04-18 07:05:01][SCENARIO] Exécution d'un bloc code
[2020-04-18 07:05:01][SCENARIO] Contents :{"state": "ok", "code": 0, "result": {}}
[2020-04-18 07:05:01][SCENARIO] Fin correcte du scénario

On voit qu’il a considéré que tout était ok…sauf que la liste des périphériques Z-wave était complètement vide et qu’aucune donnée ne remontait.

Bonjour,

J’ai le même problème que vous ce matin. Comment vous vous en êtes sorti parce que là moi je galère.

Salut,

Il faut aller dans le plugin Z-wave, éditer chaque périphérique sans rien changer mais le sauvegarder quand même.

Ha bon bin ça a pas marché pour moi…

Bonjour,
J’ai eu ce pbs sur un module, j’ai pu réparé avec une exclusion/inclusion mais depuis ce jour la moitié de mes modules a disparu. Je suis en jeedom V3 smart. Si quelqu’un a une solution avant je m’attaque à la reinclusion d’environ 25 modules ?
merci d’avance
ps : j’ai tout essayé, redemarrage, soigner le zwave, restauration image et restauration xml zwave etc…

voici un log si quelqu’un a les memes choses :

[2020-09-08 20:08:48][ERROR] : Critical error on  send_changes_async threads can only be started once
[2020-09-08 20:09:04][ERROR] : Critical error on  send_changes_async threads can only be started once
[2020-09-08 20:10:42][ERROR] : RequestHandler Unknow node id 44
[2020-09-08 20:12:35][ERROR] : RequestHandler Unknow node id 60
[2020-09-08 20:15:41][ERROR] : RequestHandler Unknow node id 44
[2020-09-08 20:20:39][ERROR] : RequestHandler Unknow node id 44
Unhandled exception in thread started by <bound method _Timer.__bootstrap of <_Timer(Thread-96958, stopped daemon 547407000064)>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
    self.__bootstrap_inner()
  File "/usr/lib/python2.7/threading.py", line 789, in __bootstrap_inner
    del _limbo[self]
KeyError: <_Timer(Thread-96958, stopped daemon 547407000064)>
[2020-09-08 20:25:39][ERROR] : RequestHandler Unknow node id 44
[2020-09-08 20:29:10][ERROR] : RequestHandler Unknow node id 77
[2020-09-08 20:29:22][ERROR] : RequestHandler Unknow node id 77
[2020-09-08 20:29:29][ERROR] : RequestHandler Unknow node id 77
[2020-09-08 20:30:07][ERROR] : RequestHandler Unknow node id 77
Unhandled exception in thread started by <bound method _Timer.__bootstrap of <_Timer(Thread-102308, stopped daemon 547407000064)>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
    self.__bootstrap_inner()
  File "/usr/lib/python2.7/threading.py", line 789, in __bootstrap_inner
    del _limbo[self]
KeyError: <_Timer(Thread-102308, stopped daemon 547407000064)>
[2020-09-08 20:30:48][ERROR] : RequestHandler Unknow node id 44
[2020-09-08 20:35:30][ERROR] : RequestHandler Unknow node id 44
[2020-09-08 20:37:41][ERROR] : RequestHandler Unknow node id 12
[2020-09-08 20:37:47][ERROR] : RequestHandler Unknow node id 12
[2020-09-08 20:37:47][ERROR] : RequestHandler Unknow node id 12
[2020-09-08 20:39:00][ERROR] : RequestHandler Unknow node id 74
[2020-09-08 20:39:13][ERROR] : RequestHandler Unknow node id 74
[2020-09-08 20:39:54][ERROR] : RequestHandler Unknow node id 11
[2020-09-08 20:40:03][ERROR] : RequestHandler Unknow node id 11
[2020-09-08 20:40:10][ERROR] : RequestHandler Unknow node id 11
[2020-09-08 20:40:26][ERROR] : RequestHandler Unknow node id 11
[2020-09-08 20:40:29][ERROR] : RequestHandler Unknow node id 44
[2020-09-08 20:40:32][ERROR] : RequestHandler Unknow node id 11
[2020-09-08 20:40:36][ERROR] : RequestHandler Unknow node id 11
[2020-09-08 20:40:36][ERROR] : RequestHandler Unknow node id 11
[2020-09-08 20:40:57][ERROR] : RequestHandler Unknow node id 11
[2020-09-08 20:45:15][ERROR] : RequestHandler Unknow node id 43
[2020-09-08 20:45:24][ERROR] : RequestHandler Unknow node id 43
[2020-09-08 20:45:34][ERROR] : RequestHandler Unknow node id 44
[2020-09-08 20:45:44][ERROR] : RequestHandler Unknow node id 7

autre constat, lors de la recompilation des dépendances, j’ai pu voir ce message d’erreur (est-ce lié) :

Creating Temporary Shell Launch Script
make[2]: Leaving directory '/opt/python-openzwave/openzwave/cpp/examples/MinOZW'
make[1]: Leaving directory '/opt/python-openzwave/openzwave'
python setup-lib.py build
running build
running build_ext
cythoning src-lib/libopenzwave/libopenzwave.pyx to src-lib/libopenzwave/libopenzwave.cpp
building 'libopenzwave' extension
creating build
creating build/temp.linux-aarch64-2.7
creating build/temp.linux-aarch64-2.7/src-lib
creating build/temp.linux-aarch64-2.7/src-lib/libopenzwave
aarch64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-rSjPv1/python2.7-2.7.13=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DPY_SSIZE_T_CLEAN=1 -Iopenzwave/cpp/src/ -Iopenzwave/cpp/src/value_classes/ -Iopenzwave/cpp/src/platform/ -Iopenzwave/cpp/build/linux/ -I/usr/include/python2.7 -c src-lib/libopenzwave/libopenzwave.cpp -o build/temp.linux-aarch64-2.7/src-lib/libopenzwave/libopenzwave.o
cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++
src-lib/libopenzwave/libopenzwave.cpp:3:0: warning: "PY_SSIZE_T_CLEAN" redefined
#define PY_SSIZE_T_CLEAN
<command-line>:0:0: note: this is the location of the previous definition
In file included from openzwave/cpp/src/aes/aescpp.h:26:0,
from openzwave/cpp/src/Driver.h:42,
from src-lib/libopenzwave/libopenzwave.cpp:459:
openzwave/cpp/src/aes/aes.h:75:0: warning: ignoring #pragma warning  [-Wunknown-pragmas]
#pragma warning( disable : 4324 )
openzwave/cpp/src/aes/aes.h:93:0: warning: ignoring #pragma warning  [-Wunknown-pragmas]
#pragma warning( default : 4324 )
src-lib/libopenzwave/libopenzwave.cpp: In function 'PyObject* __pyx_pf_12libopenzwave_9PyManager_268beginControllerCommand(__pyx_obj_12libopenzwave_PyManager*, PyObject*, PyObject*, PyObject*, PyObject*, PyObject*, PyObject*)':
src-lib/libopenzwave/libopenzwave.cpp:29891:204: warning: 'bool OpenZWave::Manager::BeginControllerCommand(uint32, OpenZWave::Driver::ControllerCommand, OpenZWave::Driver::pfnControllerCallback_t, void*, bool, uint8, uint8)' is deprecated [-Wdeprecated-declarations]
__pyx_t_6 = __Pyx_PyBool_FromLong(__pyx_v_self->manager->BeginControllerCommand(__pyx_t_1, __pyx_t_2, __pyx_f_12libopenzwave_ctrl_callback, ((void *)__pyx_v_pythonfunc), __pyx_t_3, __pyx_t_4, __pyx_t_5)); if (unlikely(!__pyx_t_6)) __PYX_ERR(0, 4120, __pyx_L1_error)
^
src-lib/libopenzwave/libopenzwave.cpp:545:36: note: in definition of macro '__Pyx_PyBool_FromLong'
#define __Pyx_PyBool_FromLong(b) ((b) ? __Pyx_NewRef(Py_True) : __Pyx_NewRef(Py_False))
^
In file included from src-lib/libopenzwave/libopenzwave.cpp:464:0:
openzwave/cpp/src/Manager.h:1731:19: note: declared here
DEPRECATED bool BeginControllerCommand( uint32 const _homeId, Driver::ControllerCommand _command, Driver::pfnControllerCallback_t _callback = NULL, void* _context = NULL, bool _highPower = false, uint8 _nodeId = 0xff, uint8 _arg = 0 );
^~~~~~~~~~~~~~~~~~~~~~

Bonjour,

Il suffisait de cliquer sur synchroniser.

1 « J'aime »