Natywne wsparcie dla MQTT

zalus
Posty: 143
Rejestracja: czw sty 04, 2018 12:29 pm

witam
mam postawionego HA na nim mosquito pracujący z zigbee2mqtt więc podczas intergacji wybieram drugi wariant ale po odpaleniu terminala i próbie edycji pliku bridge.conf jest problem do w katalogu share nie ma katalogu mosquitto a co za tym idzie tez nie ma bridge.conf.
i tu rodzi się pytanie: gdzie popełniłem błąd??:)
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Utwórz go.
zalus
Posty: 143
Rejestracja: czw sty 04, 2018 12:29 pm

dodałem i w logach mam tak:
[15:57:14] INFO: Start Mosquitto daemon
1610290634: Loading config file /share/mosquitto/bridge.conf
1610290634: Error: Invalid bridge configuration.
1610290634: Error found at /share/mosquitto/bridge.conf:1.
1610290634: Error found at /etc/mosquitto.conf:29.
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Co wpisałeś do configa ?
Na screenie było ale w tekście nie było (teraz dopisałem)... w nagłówku powinno być

connection bridge-01
jaku2k
Posty: 830
Rejestracja: ndz maja 24, 2020 8:40 pm
Kontakt:

Dzień dobry,
Kiedy można spodziewać się wydania oficjalnej wersji 2.3.26?
Jakub
Pozdrawiam
Jakub

PS. Czekam na Supla Offline Party 2024
zalus
Posty: 143
Rejestracja: czw sty 04, 2018 12:29 pm

poprawiłem plik bridge.conf
teraz startuje krok dalej ale wywala:
[19:21:12] INFO: No local user available
[19:21:12] INFO: Initialize Hass.io Add-on services
[19:21:12] INFO: Initialize Home Assistant discovery
[19:21:12] INFO: Start Mosquitto daemon
1610302872: Loading config file /share/mosquitto/bridge.conf
1610302872: Error: Unknown configuration variable "remote_user".
1610302872: Error found at /share/mosquitto/bridge.conf:6.
1610302872: Error found at /etc/mosquitto.conf:29.
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Którą wersję masz tego mosquitto ?
Wrzuć screena konfiguracji. Zamaż hasło i email.
zalus
Posty: 143
Rejestracja: czw sty 04, 2018 12:29 pm

coś się w mqqt wywaliło usunąłem i zainstalowałem od nowa i dodałem integrację z suplą jak pierwszą a później zigbee i wszystko odpaliło to znaczy zigbee chodzi a w logach brokera mam takie coś:
[INFO] found homeassistant on local database
1610305875: New client connected from 172.30.33.2 as mqttjs_0f95b566 (p2, c1, k60, u'homeassistant').
1610305875: New connection from 172.30.32.1 on port 1883.
1610305875: New client connected from 172.30.32.1 as 7E5Qc3oAfg3gOkMhrKBriN (p2, c1, k60, u'homeassistant').
1610305883: New connection from 172.30.33.3 on port 1883.
1610305883: New client connected from 172.30.33.3 as ee948fadda224ec8bae3c147735c7bd1 (p2, c1, k15, u'homeassistant').
ale nie widać żeby dodał coś
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Brakuje
"Loading config file /share/mosquitto/bridge.conf"

Dodałeś poniższe ?
customize:
active: true
folder: mosquitto
Awatar użytkownika
pzygmunt
Posty: 18280
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontakt:

Jolka AI-Speaker pisze: sob sty 09, 2021 6:54 pm Zróbmy pierwszą integrację w przez MQTT bridge. Dzięki, że poszliście w tę stronę.
Na beta-cloud.supla.org możecie utworzyć testową aplikację "AI-Speaker" aby przetestować OAuth.
https://beta-cloud.supla.org/integrations/apps/new

W procesie OAuth należy podać scope:
"mqtt_broker"

W środowisk produkcyjnym aplikacja "AI-Speaker" zostanie utworzona przez nas globalnie, czego konsekwencją będzie przekazanie
Wam dedykowanego client_id i secret. Klucz "secret" nie powinien być przekazywany Waszym użytkownikom co wiąże się z tym,
że AI-Speaker powinien wykorzystywać (przez Was zbudowaną) jakąś pośrednią infrastrukturę w procesie autoryzacji w Supli przez OAuth.

W konsekwencji procesu autoryzacji oauth aplikacja kliencka otrzyma token i refresh token. W praktyce będzie wam potrzebny jednorazowo tylko token tak więc nie musicie tych danych na stałe gdzieś zapamiętywać i ich odświeżać. Nasza produkcyjna infrastruktura jest rozproszona przez co nie możecie z góry założyć z którym serwerem będziecie się komunikować. Adres serwera zaszyty jest w tokenie po kropce (base64)

Przykład:
ZjY4OTY0MzM2YzQ5MTVkMjBlOTZlYzdlZGE1N2Q4Y2E0MjNjZjhlODg3MWNmMWUyOWI1MzZkNGY1OGI5ZGU1Yg.aHR0cHM6Ly9iZXRhLWNsb3VkLnN1cGxhLm9yZw==

Po kropce mamy aHR0cHM6Ly9iZXRhLWNsb3VkLnN1cGxhLm9yZw== co w tym przypadku jest jednoznaczne z https://beta-cloud.supla.org/

Jak już znacie token i adres adres serwera to możecie zażądać poświadczeń do brokera mqtt przy pomocy RestAPI.
Oczywiście otrzymane poświadczenia dają dostęp tylko do urządzeń pojedynczego użytkownika, który autoryzował się przez OAuth.

Endpoint:
/api/integrations/mqtt-credentials
Metoda:
POST
W nagłówku http:
Authorization: Bearer ZjY4OTY0MzM2YzQ5MTVkMjBlOTZlYzdlZGE1N2Q4Y2E0MjNjZjhlODg3MWNmMWUyOWI1MzZkNGY1OGI5ZGU1Yg.aHR0cHM6Ly9iZXRhLWNsb3VkLnN1cGxhLm9yZw==

Przykładowa odpowiedź (http ok 200):

{
"host": "beta-mqtt.cloud.supla.org",
"protocol": "mqtt",
"port": 8883,
"tls": true,
"username": "abcd",
"password": "$^&*("
}


Jeśli serwer zwróci 409 to oznacza, że użytkownik ręcznie wyłączył MQTT (lub nie ma skonfigurowanego serwera MQTT w przypadku prywatnej instancji). Przypadek z 409 na cloud.supla.org wystąpi gdybyście zapamiętali token/refresh_token i odpytalibyście ponownie o poświadczenia mqtt po jakimś czasie po tym gdy użytkownik ręcznie wyłączył mqtt. W scenariuszu powyżej 409 (z pominięciem prywatnych instancji) nie wystąpi ponieważ proces autoryzacji OAuth kończy się automatycznie włączeniem u użytkownika brokera mqtt.

Implementacja powyższego endpointa powinna być wrzucona na beta-cloud.supla.org w przyszły wtorek. W między czasie możecie już przygotować implementację po waszej stronie.
ODPOWIEDZ

Wróć do „MQTT”