Controleur SMHUB Nano MG24

Ok heureusement j’avais télécharger le dossier data avant. Je testerai le reset en usb-c.

Est ce bien ça la procédure pour réinitialiser le Nano ?

Il parle de carte sd mais ça ne doit pas être sur le même modèle

C’est une procédure pour flasher un firmware smhub-os sur l’eMMC d’un smhub via USB.
Applicable semble-t-il pour smhub Pro et Nano.
Il y a une interface microSD sur le Pro.

akenad :slight_smile:

Hello,
Oui, je viens de tester a l’instant car moi aussi après plusieurs manipulation dans le fichier du SMHUB j’ai eu besoin de revenir sur une base propre.
Attention le choix du câble est crucial !! j’ai du en utiliser 3 pour que le SMHUB NANO MG24 soit bien reconnu par Windows. En suite j’ai pu suivre ce tuto très bien réalisé et lancé flash.bat avec succès chez moi. (Cable de souris logitech G502X)

1 « J'aime »

Si on regarde ici: Zigbee network | Zigbee2MQTT
On voit que si l’on place le mot GENERATE cela refait la liste de numéro que Xavax59 avait dans sont fichier d’origine.
image

Apres ma restauration réussite avec Windows en usb C (firmware 0.3.11) les fichiers dans z2m/data sont vide. Il n’y a que le configuration_example.yaml et le configuration.yaml ce dernier est vierge et est a remplir. Chose que j’ai réalisé avec le lien cité en debut de reponse.

Un fois le plugin z2m reboot on obtient les codes.

L’objectif depuis le début était de changer de coordinateur zigbee et d’instance de zigbee2mqtt
sans refaire les appairages des équipements.
Pas sûr que la régénération des paramètres réseaux zigbee atteigne cet objectif.

akenad :slight_smile:

:+1: Effectivement Je pense qu’il faut mieux préparer directement le configuration.yaml avec les bonnes valeurs de « network_key: », « pan_id: » et « ext_pan_id: »

Surtout qu’il est possible d’écrire nous même ces informations car, normalement, on connait l’ancien « network_key: », « pan_id: » et « ext_pan_id: » (Info qui se trouve notamment dans le « coordinator_backup.json »).
Il suffit de simplement convertir ces valeurs Héxadécimal en Décimal en prenant les caractères 2 par 2 (sauf « pan_id » a prendre dans son entier).
…Et ce n’est pas difficile à faire.

c’est en effet évoqué plus haut :

akenad :slight_smile:

2 « J'aime »

Bonjour Akenad,

Oui le but pour moi et aussi d’éviter de réappairer 50 modules.

Je comprends de mieux en mieux (jespere). Je suis donc bien repartie d’un solution propre avec Z2M. J’ai supprimer le dossier data dans /opt/zigbee2mqtt/data. Désinstallé Z2M puis reboot la SMHUB.

Cela m’a bien recréé le dossier data proprement et dument complété par les information rentré depuis l’interface z2m de la SMHUB et non l’édite du fichier config.yaml.

  • Je remis l’IEEE de ma clé sonoff-Dongle-E succés
  • Reboot de nouveau la SMHUB.
  • Tout est revenu proprement encore une fois
    image

Je relis donc le poste

Tu prends donc les infos dans les fichiers z2m de Jeedom
Tu ouvres en parallèles les fichiers dans z2m/data du SMHUB

L’exercice mtn c’est de regarder le fichier cote SMHUB ci dessous…

…et de voir si les valeur correspond a celle de jeedom, et si pas de correspondance alors les remplacer.(en tenant compte des conversion et inversement de certaine séquence)

Une migration n’est donc juste pas un simple changement IEEE mais tout un tas d’autre paramètres.

Ici en vert Jeedom(z2m) // Orange SMHUB(z2m).
On constate bien la conversion (qui c’est faite automatiquement)


Ici en vert Jeedom(z2m) // Orange SMHUB(z2m).

SMHUB

Voyez vous un probleme ou dois je verifié autre chose :slight_smile:
Je suis un peu perdu.

Par avance merci.

1 « J'aime »

Pour ma part, je n’ai pas utilisé l’interface web smhub Apps/zigbee2mqtt pour la configuration de zigbee2mqtt.
Comme expliqué plus haut j’ai copié
(jeedom) /var/www/html/plugins/z2m/data/configuration.yaml => (smhub) /opt/zigbee2mqtt/data/configuration.yaml
et j’ai modifié les paramètres nécessaires pour que ça fonctionne.

Une migration de coordinateur zigbee (transparente pour ses équipements appairés),
c’est conserver le paramètre adresse ieee et les paramétres réseaux zigbee (channel, pan_id, extended_pan_id, network_key)

Une migration d’instance zigbee2mqtt c’est conserver les paramètres précédents,
conserver l’authentification, obligatoire si le plugin MQTT manager est utilisé,
et ajuster le port du coordinateur zigbee et l’IP du serveur mqtt.

akenad :slight_smile:

1 « J'aime »

J’a tout remis à 0, remis l’IEEE et j’ai testé une lampe Ikea et un prise d’une autre marque. En cas de reboot je n’ai plus le problème…

Maintenant je me pose une question ,car dans jeedom la prise qui a changé de Z2M (elle est passée de Z2M jeedom a Z2m du nano) j’arrive a la contrôler mais je n’ai pas de retour d’état…

Si je passe jeezigbee en mode distant, le Z2m local de l’atlas continue de tourner, j’ai bien toutes les commandes qui fonctionnent et retour d’état mais la prise qui est sur le Z2M du nano je peux toujours la piloter mais je n’ai toujours pas de retour d’état.
Je ne comprends pas. Avant de tout basculer vers la nano je voudrais m’assurer de ce qu’il y a a faire dans jeedom. Il faut refaire les commandes ?

Merci

One again :

Une migration s’est passé d’un état initial à un état cible (en une ou plusieurs étapes).
Si tu reviens partiellement en arrière pour faire des expériences tu peux t’attendre à te retrouver dans des états indéterminés.

Pour rappel :

Commandes action et état pour prise OK :

jeezigbee-configuration-smhub-mode-distant-prise-state-on
jeezigbee-configuration-smhub-mode-distant-prise-state-off

Qu’est ce qui te fais penser ça ?

Il faut regarder les process qui tournent réellement.

Sur mon jeedom cible (zigbee2mqtt en distant) :
je n’ai pas de zigbee2mqtt qui tourne en local :

Alors que sur un autre jeedom (avec zigbee2mqtt en local) :
j’ai un zigbee2mqtt qui tourne en local :

Je n’ai pas eu besoin.

akenad :slight_smile:

ok mais si j’ai bien compris moi a la différence de toi je vais migrer différemment, je vais tout reappairer. Et jnai remis l’IEEE d’origine du nano

Je prends mes équipements un par un, ils quitte le réseau Z2M de jeezigbee pour se retrouver sur le Z2M du nano, tout cas sur le meme broker. D’ailleurs dans HA c’est complètement transparents. les périphériquement ne changes pas et j’ai bien le retour d’étatismes. Il faut juste que je veille a remettre le meme nom.

Sur jeedom, j’ai bien ma prise qui était sur le Z2M de jeezigbee, qui est passée au Z2M du nano. que je peux piloter quand meme alors que jeezigbee est en local mais je n’ai pas le retour d’étatismes de la prise. j’ai juste les actions.

Je me suis dit que c’était parce que je suis en local, du coup j’ai passé jeezigbee en Distant pensant avoir l’eau des équipements du nano. mais en fait c’est pareil. Je n’ai que les actions.

J’ai supprimé la prise de jeedom pour tester, j’ai synchronisé jeezgbee, elle est remontée mais je n’ai toujours que les actions.

j’accède toujours a l’interface.

Pour éviter des conflits, pourquoi tu ne désactives pas le zigbee2mqtt local à jeezigbee puisque tu utilises le zigbee2mqtt du smhub ?
Voir plus haut : Controleur SMHUB Nano MG24 - #50 par akenad

Dois je comprendre que tu n’utilises pas du tout MQTT Manager
ou que tu utilises MQTT Manager en mode Broker distant ?
A ma connaissance jeezigbee est censé être abonné à MQTT Manager pour que les échanges jeezigbee ↔ serveur MQTT fonctionnent correctement.
Piste à creuser si tu n’as que les commandes actions qui fonctionnent (sens jeezigbee → (MQTT Manager) → serveur MQTT → zigbee2mqtt) et pas les commandes infos (états) (sens zigbee2mqtt → serveur MQTT → (MQTT Manager) → jeezigbee).
Tu pourrais utiliser MQTT Explorer pour voir ce qui se passe au niveau du broker Mosquitto : [RTEX] plugins basés sur MQTT

Je n’ai pas testé cette méthode.

Ce qui serait à tester c’est :
-partir d’un zigbee2mqtt vierge sur le smhub et y appairer tous les équipements.
-configurer jeezigbee en mode distant (zigbee2mqtt local désactivé).
-faire une synchronisation dans jeezigbee pour faire remonter les équipements du zigbee2mqtt distant.

akenad :slight_smile:

Peut il y avoir conflit ? Quand je réinitialise un équipement comme une prise il quitte le réseau Zigbee et ensuite il rejoint le nouveau Z2m du nano

Oui j’utilise MQTT manager en mode broyer distant relié à proxmox

Oui c’est ce que j’ai fait, j’ai remis à 0 le nano, remis l’IEEE pour ne pas avoir de conflit.
Dans jeedom j’ai testé le mode distant mais pour le coup il ne voit pas le retour d’état des équipements dans le nano. et j’ai bien cliqué sur synchroniser.

Peut être qu’il faut que je transfere tout de l’autre coté pour couper le Z2M de jeezigbee et ensuite me mettre en distant

Si tout ne fonctionne pas correctement ce n’est pas à exclure.
Dans le principe je trouve que ce n’est pas sain d’avoir un jeezigbee avec 2 zigbee2mqtt.

C’est pas un peu ce que je viens de te suggérer …

akenad :slight_smile:

j’a compris je crois le problème . Sur les second Z2m (nano) il faut que je mette un topic différent. Sinon ca met le bazar. Mais du coup je ne peux pas avoir les 2 en meme temps.

Par contre en distant avec le Z2M du nano et un topic different je ne sais pas le piloter depuis jeezigbee

en fait il faudrait que jeezigbee puisse s’abonner à 2 topics différents pour pouvoir migrer tout doucement cet pas tout faire d’un coup … mais je ne pense pas qu’on puisse mettre 2 topics dans cette case

ou alors après tout refaire avec le plugin plugin-mqttdiscovery la ca fonctionne comme dans HA

Ce n’est pas possible. D’ou mes alertes.
HA est hors sujet.

akenad :slight_smile:

a quoi sert la partie remote bridge dans les réglages MQTT ?
Je n’arrive pas a comprendre

Je ferai la migration complète lorsque le nano sera capable de démarrer tout seul Z2M après reboot et que le système sera plus stable