c’est l’inverse, dans la configuration du nouveau Z2M tu lui donnes l’IP du serveur MQTT de HA.
Tout apparaitra dans l’intégration MQTT, comme pour le reste
alors ça c’est génial.
Du coup j’ai deux lave-vaisselle à vendre
je tente dès que j’ai un peu de temps et je vous tiens informés
là je suis dans le menu Z2M de mon HA, j’ai installé Z2M sur le serveur HA.
Est-ce que les nouveaux modules détectés par mon second pi arriveront dans cette liste?
Non, là c’est le Z2M installé sur le HA, tu auras la même interface sur l’IP de l’autre Raspberry mais tu auras les sensors au niveau de MQTT dans les intégrations
Faudrait peut-être reprendre depuis le début quelques concepts, parce que j’ai l’impression qu’il y a un peu de flou !
En fait, il y a plusieurs abstractions qu’il faut décortiquer pour comprendre pourquoi (nonobstant le matériel acheté), le plus simple est sans doute de coller un z2m « à part » sur le(s) site(s) éloigné(s).
On a donc, « dans l’ordre »:
- la gestion de « l’intelligence » domotique, confiée à HA, qui est centralisée
- la gestion « agnostique », sans présupposé technologique, des échanges de messages avec les objets connectés (ou tout autre truc qiu souhaite échanger des infos, en réalité). C’est l’objet du bus de messagerie MQTT (en l’occurrence, mosquitto), qui se fiche de la nature des objets et se contente de relayer des messages d’un point à tous les autres points
- la gestion des objets Zigbee, via un contrôleur matériel. C’est ce que fait z2m, qui « parle » ce protocole et retranscrit donc vers le bus les messages (ou dans l’autre sens, le cas échéant)
- les objets eux-mêmes, qui captent des infos sur leur environnement ou agissent sur celui-ci.
Dans la plupart des installations, on a:
HA ↔ MQTT ↔ z2m ↔ objets zigbee
À chaque étape, on n’est absolument pas obligé d’avoir une relation de 1 pour 1 (bon, ce n’est pas tout à fait vrai, je crois, HA ne sachant pas (encore ?) parler à plus d’1 bus MQTT, mais ce n’est pas important ici).
L’idée dans ton cas est donc d’avoir 1 z2m qui tourne dans chaque bâtiment, pour piloter les objets qui sont à sa portée. Mais tous les z2m « parlent » avec le même bus MQTT, et du point de vue de HA, tous les objets zigbee devraient être vus de la même façon.
La seule chose qu’il te faudra (éventuellement) faire, c’est de faire les mises à jour des z2m qui tournent sur leurs rpi dédiés, puisque ceux-là ne seront pas mis à jour par HA (mais l’OS dessus non plus, et il faudra bien lui aussi le tenir à jour).
En espérant que ça te clarifie un peu les choses.
En effet, cela clarifie, je te remercie. Le plus dur quand on est newbie d’un sujet c’est d’en avoir une vision générale, et la réponse m’éclaire, et je pense avoir bien pigé.
Donc si je reprends ce screenshot, est-ce que le module Z2M de la barre latérale me montrera seulement les objets appairés avec mon Z2M local connecté à mon MQTT (local aussi), ou bien pourrai-je y voir tous les objets, incluant ceux injectés dans ce même MQTT par mes Z2M distants ?
Sinon, aurai-je plusieurs lignes dans la barre latérale?
L’option d’utiliser les ZB-GW03 est elle abandonnée ?
Si oui, ce serait bien de le savoir pour ne pas passer du temps à comprendre comment cela fonctionne pour rien !
@jfrousval , non pas abandonnée mais semble compliquée par rapport à ce que j’avais imaginé en commandant ces appareils: je pensais en fait que c’était des passerelles pour faire passer les infos Zigbee par ethernet. Il s’avère que c’est plus compliqué visiblement.
Si je peux, j’aimerais éviter d’ajouter un nouveau protocole (?) , j’aimerais me limiter à HA+MQTT+Z2M+Zigbee (si je ne dis pas de bêtise) avant d’aller compliquer mon système et ma compréhension.
Pour moi les ZB-GW03 flashés Tosmato-MQTT sont une clé Zigbee + un équivalent de Z2M.
Donc pas besoin de Z2M, ils transmettent directement les données dans le broker MQTT par ethernet filaire (ou peut être Wifi).
intéressant alors car si cela fonctionne c’est ce que je cherche (et ce pour quoi je les ai achetés); mais je ne vois pas comment setup ça
Tu ne verras effectivement que ceux de ton z2m local. Tu pourras ajouter un tableau de bord avec pour seule vue un panneau contenant une carte web, qui pointera sur la page d’administration du second z2m, ce qui te donnera le même résultat à l’affichage (mais bien 2 lignes séparées). Chaque z2m ne connait pas les objets de l’autre, donc c’est inévitable. Attention également: il faudra que chaque z2m utilise un « topic » de base différent de l’autre, sans quoi tu vas rencontrer des blocages (cf. cette entrée dans le bugtracker de z2m).
cela signifie-t-il que je ne pourrai pas faire des scenarios mettant en œuvre des objets de batiments différents?
il me semblait avoir compris que le Z2M distant allait injecter les infos des objets dans le MQTT central, et que j’y aurais accès comme devices et entités dans mes scripts, automatisations etc. J’ai raté un truc ?
Par l’interface web.
L’ensemble de tes devices seront centralisés dans mqtt et tu pourras évidemment faire des scripts/automatisation avec l’ensemble de ceux-ci
Comme je l’ai dit, 2 z2m, mais un seul HA dans lequel toutes tes entités seront centralisées, avec donc la possibilité de les combiner comme il te plaira dans HA (au sein de groupes, d’automatisation, de sondes « template », etc.). Ce n’est pas z2m qui gère les automatisations (une partie de l’intelligence dont je parlais plus haut), donc pas de problème.
D’accord c’est très clair merci !
Bonjour, j’ai enfin trouvé un peu de temps pour creuser ce sujet, en effet si les gateways que j’ai achetées pouvaient tenir le rôle de gateway, ça serait top avec une solution hard+soft embarquée, et avec moins de maintenance qu’un Pi+coordinateur USB.
J’ai bien l’interface TASMOTA, la gateway se connecte en ethernet ou en wifi sans problème; je l’ai paramétrée pour injecter ses infos dans le MQTT « central », j’ai bien créé un topic de base différent. La connexion entre la gateway et le MQTT est OK selon les logs de la gateway, mais je ne vois rien apparaitre dans les logs de MQTT.
LOGS depuis la console TASMOTA:
17:02:42.344 ZIG: Subscribe to group 0 ‹ ZbListen0 0 ›
17:02:42.448 MQT: tele/tasmota_chai/RESULT = {« ZbState »:{« Status »:0,« Message »:« Started »}}
nb : Ici on voit le base topic tasmota_chai
17:02:42.452 ZIG: Zigbee started
17:02:42.508 ZIG: Zigbee device information found in File System (1 devices - 36 bytes)
17:02:42.516 ZIG: Zigbee device data in EEPROM (29 bytes)
17:02:42.528 ZIG: ZbLoad ‹ <internal_plugin> › loaded successfully
17:02:45.161 ZIG: {« ZbEZSPReceived »:« 2300000115CF2EA3CDFEFF20BA8404 »}
17:02:45.211 ZIG: {« ZbEZSPReceived »:« 240015CF2EA3CDFEFF20BA8400030000 »}
17:02:45.219 MQT: tele/tasmota_chai/RESULT = {« ZbState »:{« Status »:34,« IEEEAddr »:« 0x84BA20FFFECDA32E »,« ShortAddr »:« 0xCF15 »,« ParentNetwork »:« 0x0000 »,« JoinStatus »:0,« Decision »:3}}
nb: ici j’ai bien mon device 0xCF15 qui a été appairé à la gateway (c’est une sonde temp+hygro)
17:02:45.410 ZIG: {« ZbEZSPReceived »:« 62002EA3CDFEFF20BA84 »}
17:02:45.472 MQT: tele/tasmota_chai/RESULT = {« ZbState »:{« Status »:30,« IEEEAddr »:« 0x84BA20FFFECDA32E »,« ShortAddr »:« 0xCF15 »,« PowerSource »:false,« ReceiveWhenIdle »:false,« Security »:false}}
17:02:57.620 MQT: tele/tasmota_chai/RESULT = {« ZbParent »:{« Device »:« 0x0000 »,« Children »:1,« ChildInfo »:[« 0x84BA20FFFECDA32E »]}}
17:03:09.470 ZIG: {« ZbEZSPReceived »:« 9B002EA3CDFEFF20BA8406 »}
17:07:28.938 MQT: tele/tasmota_chai/STATE = {« Time »:« 2023-07-06T17:07:28 »,« Uptime »:« 0T00:05:06 »,« UptimeSec »:306,« Heap »:131,« SleepMode »:« Dynamic »,« Sleep »:50,« LoadAvg »:19,« MqttCount »:1,« Berry »:{« HeapUsed »:3,« Objects »:40},« Wifi »:{« AP »:1,« SSId »:« GASTILAN »,« BSSId »:« 50:C7:BF:65:C9:62 »,« Channel »:1,« Mode »:« 11n »,« RSSI »:34,« Signal »:-83,« LinkCount »:1,« Downtime »:« 0T00:00:02 »}}
17:12:20.961 APP: Serial logging disabled
17:12:28.972 MQT: tele/tasmota_chai/STATE = {« Time »:« 2023-07-06T17:12:28 »,« Uptime »:« 0T00:10:06 »,« UptimeSec »:606,« Heap »:132,« SleepMode »:« Dynamic »,« Sleep »:50,« LoadAvg »:19,« MqttCount »:1,« Berry »:{« HeapUsed »:3,« Objects »:40},« Wifi »:{« AP »:1,« SSId »:« GASTILAN »,« BSSId »:« 50:C7:BF:65:C9:62 »,« Channel »:1,« Mode »:« 11n »,« RSSI »:34,« Signal »:-83,« LinkCount »:1,« Downtime »:« 0T00:00:02 »}}
j’ai pas mal avancé donc, mais il me reste encore un peu de soucis qui me séparent de la satisfaction d’avoir résolu la collecte de devices zigbee dans des batiments distants.
Quelqu’un a une idée d’axe de recherche? Merci d’avance !
config MQTT de la gateway
Device 0xCF15 fonctionnel et appairé à la gateway
Peut être serait il utile d’installer MQTT-Explorer pour voir se qui arrive sur le broker MQTT.
je viens de l’installer, que dois-je regarder en particulier?
concernant mon tasmota_chai (la gateway distante), j’ai ça
tele
▼tasmota_chai
LWT = Online
▼tasmota
▼discovery
▼A0B7655792A8
config = {« ip »:« 192.168.1.23 »,« dn »:« Tasmota_chai »,« fn »:[« Tasmota_chai »,null,null,null,null,null,null,null],« hn »:« tasmota-chai-eth »,« mac »:« A0B7655792A8 »,« md »:« ZB-GW03-V1.2 »,« ty »:0,« if »:0,« ofln »:« Offline »,« onln »:« Online »,« state »:[« OFF »,« ON »,« TOGGLE »,« HOLD »],« sw »:« 12.3.1 »,« t »:« tasmota_chai »,« ft »:« %prefix%/%topic%/ »,« tp »:[« cmnd »,« stat »,« tele »],« rl »:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"swc…
sensors = {« sn »:{« Time »:« 2023-07-06T17:46:30 »},« ver »:1}
▼tasmota_chai
▼bridge
info = {« commit »:« unknown »,« config »:{« advanced »:{« adapter_concurrent »:null,« adapter_delay »:null,« availability_blacklist »:[],« availability_blocklist »:[],« availability_passlist »:[],« availability_whitelist »:[],« cache_state »:true,« cache_state_persistent »:true,« cache_state_send_on_startup »:true,« channel »:11,« elapsed »:false,« ext_pan_id »:[221,221,221,221,221,221,221,221],« homeassistant_legacy_entity_attributes »…
je ne sais pas si ça aide?