Hallo, ich bin gerade dabei meine Wetterdaten von Proplanta auf OpenWeaterMap umzustellen. Habe schon eine kleine ewigkeit damit verbracht die fehlenden libs in meinen Container einzubauen um überhaupt das Weather-Modul laden zu können. Das klappt nun endlich.
Doch beim Erstellen des Device für die Wetterdaten wird im state
API Maintainer: Marko Oldenburg ErrorMsg: DNS: short DNS answerausgegeben.
Laut KI liegt das Problem darin, das der Container die DNS der OpenWeatherMap-Adresse nicht richtig auflösen kann. Mit den bisherigen KI-Antworten komme ich nicht mehr weiter und wollte nun mal fragen ob mir jemand mit "echter" Erfahrung hier weiterhelfen kann. Ich habe die url von OpenWeatherMap bereits im Container getestet, da läuft es noch. Also liegt das Problem offenbar zwischen Conatiner und Fhem-Anwendung im Container.
PS.: Es handelt sich um ein TS-431x2 QNAP NAS. Der Container nutzt ein fhem-arm32v7_linux-2 Image.
Kann mir jemand was dazu sagen?
Attribut dnsServer im device global gesetzt? Wobei ich mir nicht sicher bin, ob das hier so viel bringt.
Sonst fällt mir jetzt grade nicht so viel ein, außer in der FHEM-Befehlszeile mal mit"nslookup ..."o.ä. zu testen und – wohl wichtiger – tcpdump + Wireshark laufen zu lassen, damit du siehst, wo die von OpenWeaterMap initiierten DNS-Pakete hingehen bzw. (fehlerhafte) Antworten herkommen bzw. was drin steht.
also attribut DnsServer ist auf 127.0.0.11 gesetzt. Ob das richtig ist weiß ich ehrlich nicht.
Das Ganze konstrukt läuft ja in einem QNAP NAS über einen virtuellen Switch in die Container-Station mit einer eigenen IPv4 über die Bridge-Funktion.
– tcpdump + Wireshark muss ich mir ansehen, bisher noch nie genutzt also weder installiert noch sonst was bisher. Muss ich mal schauen wenn ich mehr Zeit habe.
Ehrlich gesagt, weiß ich ja nicht mal ob API Maintainer: Marko Oldenburg ErrorMsg: DNS: short DNS answerwirklich was mit der DNS-Auflösung zu tun hat. Kenne das Modul so bisher nicht und da ich mit keiner anderen Kommunikation nach außen aktuell Probleme habe könnte der Fehler ja auch innerhalb des Device liegen und der state auf eine falsche Spur locken. Darum poste ich sicherheitshalber mal das list des Device mit:
Internals:
API DarkSkyAPI
APIKEY **********
APIOPTIONS cachemaxage:600
CFGFN
DEF apikey=*********** location=51.15629,8.03564 interval=3600 lang=de
FUUID 69dceaf5-f33f-7706-8c94-9d872d6072ccf3ae
FVERSION 59_Weather.pm:v2.3.3-s30437/2025-10-23
INTERVAL 3600
LANG de
MODEL DarkSkyAPI
NAME Wetter_Elspe
NOTIFYDEV global
NR 2452
NTFY_ORDER 50-Wetter_Elspe
STATE API Maintainer: Marko Oldenburg <fhemdevelopment@cooltux.net> ErrorMsg: DNS: Cant find host
TYPE Weather
VERSION v2.3.3
eventCount 347
READINGS:
2026-04-13 20:52:42 apiMaintainer Marko Oldenburg <fhemdevelopment@cooltux.net>
2026-04-13 20:52:42 apiVersion v1.2.12-stable
2026-04-13 20:52:42 current_date_time Do, 1 Jan 1970 01:00
2026-04-13 20:52:42 lastError DNS: Cant find host
2026-04-13 20:52:42 lat 51.15629
2026-04-13 20:52:42 long 8.03564
2026-04-13 20:52:42 state API Maintainer: Marko Oldenburg <fhemdevelopment@cooltux.net> ErrorMsg: DNS: Cant find host
2026-04-13 20:52:42 status DNS: Cant find host
2026-04-13 20:52:42 validity stale
fhem:
LOCATION 51.15629,8.03564
allowCache 1
interfaces temperature;humidity;wind
Attributes:
group OpenWeatherMap
room OpenWeatherMap,Information->WetterImmerhin funktionieren ja alle HTTPSMOD-Abfragen und ein Ping aus der Konsole des Containers auch.
nslookup api.openweathermap.orgin in der Konsole des Containers gibt folgendes zurück:
Server: 127.0.0.11
Address: 127.0.0.11#53
Non-authoritative answer:
api.openweathermap.org canonical name = eu-api.openweathermap.org.
Name: eu-api.openweathermap.org
Address: 141.95.47.139Es wird also offensichtlich schon eine IP ermittelt. Nur kommt diese nicht im Device an.
Wie vermutet war der Eintrag im state eine Finte und es lag gar nicht an der DNS-Auflösung sondern an einem fehlenden Teil im Def, der in diversesten Quellenangaben nicht aufgeführt wurde.
Es ist halt nicht immer ratsam der KI oder deren Angaben blind zu vertrauen.