Problem mit Z-Wave und Google Home

Konfiguration
1

Hallo!
Es ist schon eine Weile her, dass ich ein Problem mit einigen Z-Wave-Geräten hatte.

Wenn ich Google mit der Stimme bitte, etwas auszuschalten, antwortet sie „OK, ich schalte aus“, aber nichts passiert. Wenn ich es aber über die App (Google oder Gladys) mache, funktioniert es.

Manchmal geht das Licht aus, schaltet sich aber sofort wieder ein und geht dann wieder aus, kurz gesagt, ein Durcheinander ^^'.

Beim Überprüfen habe ich dies in meinen Logs gefunden, aber ich habe nie direkt nach einem „Zwischenfall“ danach geschaut.

2022-02-24T19:18:17+0100 <warn> gateway.forwardDeviceStateToGoogleHome.js:41 (sendCurrentState) Gladys Gateway: Unable to forward google home reportState
2022-02-24T19:18:17+0100 <warn> gateway.forwardDeviceStateToGoogleHome.js:42 (sendCurrentState) Error: getaddrinfo EAI_AGAIN api.gladysgateway.com
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:71:26) {
  errno: -3001,
  code: 'EAI_AGAIN',
  syscall: 'getaddrinfo',
  hostname: 'api.gladysgateway.com',
  config: {
    url: 'https://api.gladysgateway.com/google/report_state',
    method: 'post',
    data: '{"devices":{"states":{"mqtt-zwave-chambre-enfant-plafonnier":{"online":true,"on":false}}}}',
    headers: {
      Accept: 'application/json, text/plain, */*',
      'Content-Type': 'application/json;charset=utf-8',
      authorization: 'iYi05OTFkLTM3OTczMmZkYjdlZSIsImlhdCI6MTY0NTcyNTk5MCwiZXhwIjoxNjQ1NzI5NTkwLCJhdWQiOiJp.hddKDhIiF4znPRHKBU8-E84bhHyGBKy142ScP_vJjm0',
      'User-Agent': 'axios/0.21.1',
      'Content-Length': 90
    },

Auf der DNS-Seite gibt es keine blockierte Anfrage, trotzdem :thinking:

Screenshot_20220224-195309_Chrome
Screenshot_20220224-195309_Chrome1439×1134 156 KB

2

Dieser Fehler ist eher klar, es handelt sich um ein DNS-Problem.

Interessant ist, dass man etwas bemerkt: Es gibt Dutzende von DNS-Auflösungsanfragen hintereinander, ohne die TTL zu respektieren, die ich angeben, denn manchmal gibt es 2 Anfragen in derselben Sekunde!

Daraus schließe ich, dass Gladys die Adresse des Gateway-Servers bei jeder Anfrage erneut anfordert. Nicht verrückt!

Bei der Untersuchung scheint es sich um ein bekanntes Problem im Internet zu handeln:

Während der Arbeit an einem großen Node eCOM-Backend mit viel Verkehr fanden wir von Zeit zu Zeit den Fehler getaddrinfo EAI_AGAIN in unseren Logs, eine schnelle Google-Suche erklärt, dass dies bedeutet, dass unser DNS-Server unsere Anfrage derzeit nicht bedienen kann.

(Siehe diesen Artikel: https://medium.com/@amirilovic/how-to-fix-node-dns-issues-5d4ec2e12e95)

Und bei weiterer Untersuchung bin ich auf Folgendes gestoßen:

https://stackoverflow.com/questions/48262528/docker-node-js-alpine-does-not-cache-dns-results

EDIT: Dieses Verhalten ist absichtlich so gestaltet: Problème zwave et google home - #6 par pierre-gilles

Im Großen und Ganzen scheint das Docker-Image Node.js Alpine, das wir als Basis für Gladys verwenden (siehe Dockerfile), kein Paket zu haben, das den DNS-Cache verwaltet, und somit führt jede Anfrage ihre eigene DNS-Auflösung durch: ein bisschen schwer ^^

Ich untersuche weiter das Problem, um das richtige Paket für die Docker-Seite hinzuzufügen.

cc @VonOx das wird dich interessieren :slight_smile:

@spenceur Danke für das Feedback! Wir werden das beheben!

3

Kommt das DNS-Problem, das ich habe, von der Anonymisierung auf dem Node-Bild oder von AdGuard, das zu einem bestimmten Zeitpunkt blockiert?

Danke für deine Antwort

4

Schwer zu sagen, das kann mehrere Ursachen haben:

  • Lokal könnte der DNS-Resolver ins Stocken geraten, weil er mit zu vielen Anfragen in kurzer Zeit überfordert ist
  • AdGuard könnte mit der Last nicht klarkommen, da es, wie man sieht, für jede Anfrage kontaktiert wird

Nur um sicherzugehen, dass das Problem bei uns und nicht bei deiner Installation liegt, was hast du genau für eine DNS-Konfiguration auf deinem Pi gemacht?

5

Wenn ich mich nicht irre, habe ich einfach diese Variable in die resolve.conf eingefügt

static domain_name_servers
Das war vor einer Weile ^^’

6

Ich bin auf solche Kommentare gestoßen:

Screenshot 2022-02-25 at 10.01.50
Screenshot 2022-02-25 at 10.01.501532×952 180 KB

Jetzt verstehe ich besser, warum das TTL nicht eingehalten wird (sowohl im Docker-Alpine-Image als auch im Debian von Raspberry Pi OS). Es ist kein Bug, sondern „by design“ bei den meisten Linux-Systemen.

@spenceur Könntest du in Gladys vorübergehend die Verwendung deines Adguard deaktivieren (und durch einen beliebten DNS wie Cloudflare DNS (1.1.1.1) ersetzen) und prüfen, ob die Fehler weiterhin auftreten?

→ Wenn die Fehler weiterhin auftreten, bedeutet das, dass dein Adguard nicht schuld ist. Vielleicht sind wir bei Gladys zu aggressiv in der Häufigkeit der Aufrufe des Gladys Gateway für den Google Home reportState.

→ Wenn keine Fehler mehr auftreten, liegt das Problem bei deinem Adguard, der manchmal nicht reagiert.

PS: Wenn du den DNS änderst, vergiss nicht, zu überprüfen, ob der neue DNS auch tatsächlich verwendet wird.

7

Ich kümmere mich darum, sobald es geht und halte dich auf dem Laufenden

PS: Ich habe immer noch keine Zeit dafür gefunden :smiley:

8

Ich habe die Manipulation so durchgeführt, wie ich es hier beschrieben habe:

Und ich habe auch überprüft, dass ich über Quad9 gehe:

image
image1118×474 59.7 KB

Jetzt bleibt nur noch abzuwarten, ob ich auf mittlere Sicht die gleichen Probleme habe.

9

Super! Halt uns auf dem Laufenden, ich hoffe, das wird das Problem lösen :slight_smile:

10

bon finalement je peu répondre même sous quad9, j’ai une erreur qui pop :

2022-03-22T20:58:10+0100 <warn> gateway.forwardDeviceStateToGoogleHome.js:41 (sendCurrentState) Gladys Gateway: Unable to forward google home reportState
2022-03-22T20:58:10+0100 <warn> gateway.forwardDeviceStateToGoogleHome.js:42 (sendCurrentState) Error: getaddrinfo EAI_AGAIN api.gladysgateway.com
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:71:26) {
  errno: -3001,
  code: 'EAI_AGAIN',
  syscall: 'getaddrinfo',
  hostname: 'api.gladysgateway.com',
  config: {
    url: 'https://api.gladysgateway.com/google/report_state',
    method: 'post',
    data: '{"devices":{"states":{"fgd212-dimmer-2-2":{"online":true,"brightness":99}}}}',
11

Führe ein docker inspect gladys aus, ich bin mir fast sicher, dass der Container eine andere DNS-Adresse hat.

12

Hier ist das, was ich mit einem grep auf dns habe

docker inspect gladys | grep -iF dns
            "Dns": [],
            "DnsOptions": [],
            "DnsSearch": [],
13

Wieder Probleme heute Morgen:

2022-03-23T10:22:24+0100 <warn> gateway.forwardDeviceStateToGoogleHome.js:41 (sendCurrentState) Gladys Gateway: Unable to forward google home reportState
2022-03-23T10:22:24+0100 <warn> gateway.forwardDeviceStateToGoogleHome.js:42 (sendCurrentState) Error: getaddrinfo EAI_AGAIN api.gladysgateway.com
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:71:26) {
  errno: -3001,
  code: 'EAI_AGAIN',
  syscall: 'getaddrinfo',
  hostname: 'api.gladysgateway.com',
  config: {
    url: 'https://api.gladysgateway.com/google/report_state',
    method: 'post',
    data: '{"devices":{"states":{"fgd212-dimmer-2-2":{"online":true,"brightness":99}}}}',

Keine Änderung trotz DNS-Änderung

14

Das ist seltsam, ich habe auch standardmäßig quad9.

Kannst du dich interaktiv mit dem Container verbinden? Die Idee wäre, den Inhalt von /etc/resolv.conf zu holen

Edit:

Der Befehl => docker exec -it gladys /bin/ash -c "cat /etc/resolv.conf"

Beispielausgabe:

vonox@odin in  ~  1 ❯ docker exec -it gladys /bin/ash -c "cat /etc/resolv.conf"
search lan
nameserver 192.168.1.1
nameserver 9.9.9.9
15

Ja, ich kümmere mich heute Nachmittag darum

Bitte lasst meine Nachrichten so wie sie sind :smiley:

16

Hier ist das Ergebnis (danke)

docker exec -it gladys /bin/ash -c "cat /etc/resolv.conf"
# Generated by resolvconf
nameserver 9.9.9.9
17

Ich habe gerade deinen ‹ dig › überprüft

Du hast keine DNS-Antwort :confused:

Bei Quad9 ist die Domain in Ordnung

image
image1446×758 180 KB

Bei mir:

vonox@odin in  ~ ❯ dig api.gladysgateway.com

; <<>> DiG 9.16.1-Ubuntu <<>> api.gladysgateway.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59709
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;api.gladysgateway.com.         IN      A

;; ANSWER SECTION:
api.gladysgateway.com.  300     IN      A       142.93.160.146

;; Query time: 15 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Mar 23 14:00:46 CET 2022
;; MSG SIZE  rcvd: 66

Dein Problem ist wirklich seltsam (ich bin in einer ähnlichen Konfiguration Quad9/Pihole).

18

Beim Testen deiner Route

pi@raspberrypi:~ $ dig api.gladysgateway.com

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> api.gladysgateway.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55078
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;api.gladysgateway.com.         IN      A

;; ANSWER SECTION:
api.gladysgateway.com.  119     IN      A       142.93.160.146

;; Query time: 50 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Mar 23 14:04:12 CET 2022
;; MSG SIZE  rcvd: 66

Kein Problem auch ^^

19

Ich bin nicht 100 % überzeugt, dass wir von der richtigen Annahme ausgehen.

20

Mist, ich war auf der API

dig plus.gladysassistant.com

; <<>> DiG 9.16.1-Ubuntu <<>> plus.gladysassistant.com
;; globale Optionen: +cmd
;; Antwort erhalten:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;plus.gladysassistant.com.      IN      A

;; ANSWER SECTION:
plus.gladysassistant.com. 300   IN      A       188.114.97.3
plus.gladysassistant.com. 300   IN      A       188.114.96.3

;; Query time: 27 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Mar 23 14:06:50 CET 2022
;; MSG SIZE  rcvd: 85