Hallöchen,
ich habe mit
define Sonos SONOS localhost:8089 30
Sonos angelegt und sehe dieses aber nur im Status disconnected - nachdem der Subprozess angelegt wurde.
mit Verbose = 3 sehe ich im fhem log aber nicht mehr als
tail -f /opt/fhem/log/fhem-2019-03.log | grep SONOS
2019.03.24 17:04:14 1: SONOS0: Kein UPnP-Server gefunden... Starte selber einen und warte 8 Sekunde(n) darauf...
2019.03.24 17:04:14 1: SONOS0: ./FHEM/00_SONOS.pm is started by fhem...
2019.03.24 17:04:14 1: SONOS0: ./FHEM/00_SONOS.pm is listening to Port 8089
Invalid value for shared scalar at ./FHEM/00_SONOS.pm line 9895.
Ein list zeigt:
Internals:
CFGFN
DEF localhost:8089 30
DELAYTIME 0
DeviceName localhost:8089
FUUID 5c97aa7d-f33f-9562-b545-f77a44677d995996
INTERVAL 30
NAME Sonos
NEXT_OPEN 1553445744.3372
NOTIFYDEV global
NR 311
NTFY_ORDER 50-Sonos
PARTIAL
STATE disconnected
TYPE SONOS
WAITTIME 8
READINGS:
2019-03-24 17:41:24 state disconnected
Attributes:
verbose 3
Keine Ahnung was man noch wo kucken kann. Im Netzwerk selbst ist nichts besonderes eingestellt. Bisher steht eine Sonos Play 3 da die gut funktioniert. Da diese diese Woche aber Kinder bekommt, wollte ich in fhem das Sonos mal zum Laufen kriegen.
kann man da noch irgendetwas machen, kucken?
Hi,
und Port 8089 ist bei Dir wirklich frei?
Anderen Port probiert? localhost:4711
Gruß Otto
Hallo Otto!
ja, auch mit 4711 ist laut netstat listening
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:4711 0.0.0.0:* LISTEN
Aber keine connection (established).
Irgendwie passiert da nichts - ist auch nichts in den logs die ich bislang kenne.
Grüße,
Frood
Das ist wirklich etwas für den Anfängerfragen Bereich.
loclhost und 127.0.0.1 gehen nicht, aber mit der richtigen IP 192.168.a.b geht es (ruck zuck auf opened).
Ist so auf einem recht frischen Debian und /etc/hosts sieht normal aus...
Was sagt ping localhost ?
Was sagt cat /etc/hosts ?
die hatte ich gescheckt..
ping localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.046 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.036 ms
und
cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 froodhost.lan froodhost
ist irgendwas anderes dubioses...
In der hosts fehlen Einträge für ipv6 - bei ping löst er aber nur ipv6 auf ???
Ich müsste es schon besser wissen. Aber ich hatte es weggelassen, da ich dachte es wäre nicht soooo wichtig
cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 froodhost.lan froodhost
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Das die Namensauflösung nicht für localhost geht, aber das auch 127.0.0.1 gar nicht geht?
Gibt es den loopback überhaupt? Kannst Du z.B. mit ip addr schauen.
An anderen Stellen z.b. der phpmyadmin geht localhost. In manchen configs ist localhost auch drin. Also localhost auf der Kiste ist an sich kein Problem. FHEM selbst kann man auch per localhost:port aufrufen im Browser.
Das ganze ist nur local also mit DNS und AdBlock auf dem Router kann es keine Probleme geben.
Naja localhost geht scheinbar /wird aufgelöst mit ipv6. Dein FHEM / Sonos UPnP läuft aber scheinbar mit ipv4 und Du hast gesagt 127.0.0.1 geht nicht. Das war ja die letzte Frage: nicht localhost sondern 127.0.0.1 ist ev. das Problem?
Nachdem neue Devices mit "unnamed room" angelegt wurden, da das Modul Sonos aktiviert war beim Einrichten, habe ich Deinen Rat in einem anderen Thread befolgt und
delete Sonos*
gemacht und das ganze nochmal neu angelegt mit
127.0.0.1
und das hat prima geklappt.
Das heißt am Ende des Tages, dass localhost nicht IPv4 aufgelöst wurde, oder?
Ich hatte schonmal so ein Problem, dass ich libio-socket-inet6-perl installieren musste weil api.telegram.org nur auf eine IPv6 aufgelöst wurde.
Das wäre dann mal was für die OpenWRT Kollegen, im Grunde auch für mich. Aber IPv6 ist eh mit steiler Lernkurve f(x)=x²
Zitat von: Frood42 am 26 März 2019, 20:50:00
Das wäre dann mal was für die OpenWRT Kollegen, im Grunde auch für mich. Aber IPv6 ist eh mit steiler Lernkurve f(x)=x²
wie meinst Du das? Dein FHEM läuft auf OpenWrt?
nee. Debian.
Der router läuft mit OpenWRT. Manche Sachen wie SIP (nee, es war Telegram API) gibts auch nur auf IPv6. Keine Ahnung warum.
naja aber localhost muss lokal aufgelöst werden. Da spielt der Router keine Rolle.
Aber den loopback 127.0.0.1 hast Du - war ja noch meine Vermutung. Also bleibt letztlich ein Problem mit der Namensauflösung...
Das ist nicht schön und wird immer wieder zu Problemen führen.
Also ganz schlüssig ist das nicht;
Ich habe mal ein bisschen ausprobiert.
ein ping localhost geht
Ein wget localhost_8082
Dann bin ich voll deep in perl development rein und habe das ausprobiert
use LWP::Simple qw(get);
my $url = 'http://localhost:8082';
my $html = get $url;
print ${html};
Geht auch.
Auf fhem ist es aber immer noch so, dass localhost für Sonos nicht funktioniert.
Ich bin da jetzt noch mal dran, weil meine Sonos Devices auch Player disappeared sind nach einiger Zeit.
Zitat von: Frood42 am 28 März 2019, 19:50:49
ein ping localhost geht
Ping geht - war nicht die Frage!
Ping ging auf IPv6 .
Sonos fragt aber auf IPv4.
Gruß Otto
Da stimme ich nicht ganz zu.
Es gibt ping mit -4 und -6
(auch ping4 und ping6, nicht sicher ob das gleich ist - ping -4/-6 ist so wie nmap -6, was ich krass finde wenn man einen range mitgeben will)
ping -4 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.042 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.041 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.059 ms
als auch
ping -6 localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.069 ms
naja in #5 hast Du einfach Ping gemacht und es wurde IPv6 aufgelöst - gut ich verstehe es nicht.
stimmt, das ist mir gar nicht aufgefallen.
ping localhost
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.069 ms
Dann könnte es ja immer noch daran liegen...