No uzbierało się i póki co nie chce pójść do dobrych ludzi.
Wszystko jest podłączone i DEV3 i DEV1 subskrybują dane urządzeń MQTT na PRO1 do siebie. Obawiam się, że tu powstaje sporo niepotrzebnej komunikacji MQTT co może mieć wpływ na stabilność tego ekosystemu i bramki głównej PRO1.
A dziś miałem totalną wywałkę Zigbee2MQTT 
Wcześniej miałem uruchomione zigbee na DEV3, ale jak podłączyłem PRO1, skopiowałem konfigurację z DEV3 i odpaliłem zigbee na PRO1. Na DEV3 usługa była wyłączona. Na DEV3 nie przywracałem ustawień fabrycznych.
Dzisiaj zachęcony postem o paczkach, odpaliłem skrypt na DEV3, wykonał się, ale bez usługi zigbee bo Conbee jest w PRO1. No to wpadłem na pomysł, żeby do DEV3 włożyć zastąpiony nim CC2531. Odpaliłem usługę a ona bazę z urządzeniami, którą miała jak jeszcze DEV3 był najważniejszą bramką, odpaliłem skrypt, wszystko fajnie się uruchomiło. Stwierdziłem, że na DEV3 do zigbee nie ma podłączonych żadnych urządzeń więc skasowałem bazę i uruchomiłem ponownie zigbee. Pokazało się 0 urządzeń zgodnie z prawdą. Zastopowałem zigbee na DEV3 i skończyłem zabawę.
Wróciłem na PRO1 a tam armagedon Niby zigbee2mqtt śmiga jakby nigdy nic, za to HA zgłupiał do reszty z urządzeniami i encjami zaimportowanymi z zigbee2mqtt…
Teraz jakoś muszę dojść do ładu i składu z tym wszystkim…
Chyba to “skalowanie” sobie odpuszczę i odłączę DEV1 i DEV3 zostawiając tylko PRO1, no chyba, że ktoś utrzymuje więcej niż jedną bramkę i ma to jakoś sensownie i bezkolizyjnie pokonfigurowane., to bardzo proszę o rady…
Topic zigbee2mqtt zmieniaj przy takich zabawach na DEV1 jeśli używasz wspólnego brokera mqtt.
Zatrzymaj usługę zigbee2mqtt na PRO1.
Przez MqttExplorer skasuj cały topic zigbee2mqtt.
Uruchom zigbee2mqtt.
Tak z ciekawości, @Goral64 - ile masz urządzeń, encji po MQTT?
To ten komar ma co u Ciebie robić. Raczej jesteś pionierem w spinaniu trzech bramek razem…
Realnie to po MQTT śmiga tyle urządzeń
Tylko integracja z Suplą powiela mi urządzenia Zigbee.
W sensie, że mam integrację zigbee2mqtt do Supli, a Supla zwraca mi te urządzenia do HA Może to rodzi jakieś konflikty…
To nie jest raczej logiczne, aby mnożyły się encje. Nie mam Supla ale to musi tak wyglądać? Masz dwa brokery w swojej instalacji HA?
Każda bramka ma broker i Supla też ma swój broker.
PRO1 subskrybuje broker Supla i jego komunikaty. DEV1 i DEV3 są “slave” dla PRO1.
Supla musi mieć swój broker, nie może korzystać z tego, który jest na Pro1? Tak jak to robią przykładowo urządzenia z Tasmota?
Tak, z tego co kojarzę Supla ma swój broker i Ty się do niego wpinasz jako klient co samo w sobie nie jest złe. Natomiast duplikowanie encji jest już dziwne. Myślę że trzeba dobrze skonfigurować połączenie z Supla MQTT brokerem tylko do tematów które nas interesują (in/out).
Nie znalazłem formuły, która odfiltrowałaby “powrotne” urządzenia.
Prosiłem developerów Supli o dorobienie opcji wyłączania urządzeń z rozgłaszania przez MQTT, ale to musi jeszcze poczekać.
Możesz pokazać jak to wygląda - jakie tematy pobierasz od Supli i jakie im wysyłasz?
Mapowanie pewnie znasz:
topic # both 2 local/topic/ remote/topic/
PRO1:
# AIS Config file for mosquitto on gate
listener 1883 0.0.0.0
allow_anonymous true
# SUPLA MQTT bridge connection
connection bridge-dom-pro1
address mqtt28.supla.org:8883
topic supla/# in
topic homeassistant/# in
topic supla/+/devices/+/channels/+/execute_action out
topic supla/+/devices/+/channels/+/set/+ out
topic supla/devices/+/channels/+/execute_action out
topic supla/devices/+/channels/+/set/+ out
remote_username *****
remote_password *****
bridge_cafile /data/data/pl.sviete.dom/files/usr/etc/tls/cert.pem
connection bridge-local-pro1
address 172.16.144.2:1883
topic supla/# in
topic homeassistant/# in
topic supla/+/devices/+/channels/+/execute_action out
topic supla/+/devices/+/channels/+/set/+ out
topic supla/devices/+/channels/+/execute_action out
topic supla/devices/+/channels/+/set/+ out
remote_username *****
remote_password *****
#bridge_cafile /data/data/pl.sviete.dom/files/usr/etc/tls/cert.pem
# Most do AIS dom DEV3
connection bridge-to-dom-dev3
address 172.16.144.7:1883
remote_clientid bramka-ais-dom-dev3
topic # both 0
# Most do AIS dom DEV1
connection bridge-to-dom-dev1
address 172.16.144.6:1883
remote_clientid bramka-ais-dom-dev1
topic # both 0
DEV3:
# AIS Config file for mosquitto on gate
listener 1883 0.0.0.0
allow_anonymous true
DEV1:
# AIS Config file for mosquitto on gate
listener 1883 0.0.0.0
allow_anonymous true
No dobra z grubsza rozumiem ten config, chociaż nie widzę która opcja upublicznia urządzenia zigbee do Supla?
Supla nie umie czytać MQTT i dodawać sobie na tej podstawie urządzenia, dlatego napisałem swój bridge, który z zigbee2mqtt, a dokładniej z MQTT tworzy w Supli urządzenia i kanały oraz ubvsługuje komunikację pomiędzy Suplą a urządzeniami zigbee.
Ale skoro mam integrację po MQTT z Suplą, która przesyła swoje urządzenia po MQTT do HA, to przesyła mi także urządzenia zigbee, które już w HA umieściło zigbee2mqtt.