fhem mit sonos im docker container Problem

Begonnen von lewej, 27 April 2017, 22:01:53

Vorheriges Thema - Nächstes Thema

Erdmännchen

#15
Bevor ich mit der HA-Bridge anfange, habe ich mal meinen aktuellen Stand hoch geladen.

https://github.com/3rdmaennchen/docker_test

Sorry hab mich noch nicht mit supervisord beschäftigt, kann ich nichts zu sagen.

mfg

Erdmännchen

Lieber dev0,

könntest du bitte auf deine Antwort https://forum.fhem.de/index.php/topic,71191.msg627802.html#msg627802
näher eingehen.
Zitat von: dev0 am 29 April 2017, 08:08:04
Ihr werdet nicht drum herumkommen Euch mit Multicast auseinander zu setzen. Sonos benutzt 239.255.255.250/1900.
Out of the box funktioniert es nicht, aber je nachdem wie Du das Netz segmentiert hast, kannst Du IGMP oder einen Multicast/Bonjour-Proxy einsetzen.

Was genau muss ich in Docker machen, damit Multicast für Sonos funktioniert?

Mein Traumszenario ist ein FHEM Container mit integriertem "Sonos-Server" ohne host mode.
Ist das überhaupt möglich, wenn man in docker das Netzwerk richtig einrichtet?
In etwa so, wie im Abschnitt "Custom Networks":
https://runnable.com/docker/docker-compose-networking

Momentan habe ich einen Fhem Container im network mode bridge und einen Sonos Container als host.
Damit FHEM den Sonos Container sieht, muss ich den Sonos Server als hart verdrahtete IP definieren.

Es ist keine schöne Lösung, da sich die Container intern nicht sehen.
Vielleicht mit einem Overlay Network https://www.youtube.com/watch?v=nGSNULpHHZc
oder "verlinken" des Containers, wie ich es mit dem mysql Server gemacht habe. https://docs.docker.com/compose/compose-file/#links

Wie schon gesagt, am liebsten hätte ich nur einen Container mit FHEM und Sonos. Aber ich weiss nicht genau, was ich machen muss.
Ich habe versucht deine Aussage mit der Multicast Adresse von Sonos zu verstehen.
Wenn ich das richtig verstanden habe kann man mit einer Multicast Adresse bestimmte Geräte im Netzwerk ansprechen.
Die Multicast Adresse setzt sich aus der IP Adresse und dem MAC-Adress-Bereich der Geräte zusammen.
Da ich kein Netzwerk Profi bin, ist das alles nur gefährliches Halbwissen.

Hier meine aktuelle Docker Umgebung https://github.com/3rdmaennchen/docker_test

Über eine Antwort würde ich mich freuen.
Ich verlange keine Komplettlösung, nur ein paar Denkanstöße oder nähere Informationen mit welchem Thema ich mich beschäftigen muss.

Für Nähere Informationen stehe ich dir gerne zur Verfügung.

MfG Erdmännchen

dev0

Zitat von: Erdmännchen am 03 September 2017, 11:41:27
Was genau muss ich in Docker machen, damit Multicast für Sonos funktioniert?
Da Du mich direkt ansprochen hast (sonst hätte ich mir die Antwort verkniffen): Die bisherigen Antworten aus diesem Thread weiter verfolgen und Dich in Docker einarbeiten. Konkrete Fragen werden hier vmtl. beantwortet, auch wenn es mMn im FHEM Forum offtopic ist.

Erdmännchen

Zitat von: dev0 am 03 September 2017, 11:57:19
Da Du mich direkt ansprochen hast (sonst hätte ich mir die Antwort verkniffen)
Danke das du dir Zeit für eine Antwort genommen hast, hat mich echt weiter gebracht.  :-\

Tut mir echt Leid, daß ich mich als Neuling hier im Forum nicht so auskenne.
Ich werde mich mal durch das Offtopic Forum klicken.

Schönen Sonntag noch.

dev0

ZitatIch werde mich mal durch das Offtopic Forum klicken
Statt sich "irgendwo" durchzuklicken, könnte man sich auch direkt die Grundlagen der verwendeten Software/Technologie aneignen...

Erdmännchen

Alles klar mach ich.
Danke für deine Zeit.

FunkOdyssey

Hallo Erdmännchen, lass dich bitte nicht entmutigen. :-) Ich hatte auch ein wenig die Hoffnung, dass dev0 vielleicht eine schnelle Antwort zur Hand hat. Hätte ja sein können. Dann müssen wir uns wohl in den Docker-Foren umschauen. Die Fragen sind für ein FHEM-Forum wirklich sehr speziell. Wobei ich - ehrlich gesagt - hier noch nie an Grenzen gestoßen bin. Bisher habe ich selbst immer Hilfe zu auch offtopic-Fragen erhalten können. Nur sind die Docker-Threads hier wirklich Mangelware. :-)

Ich persönlich habe mir auch schon den Wolf gesucht und befürchte, dass MultiCast in einem bridged-Docker-Container nicht laufen wird. dev0 erwähnte ja auch bereits, dass es "out-of-the-box" nicht klappen wird. Ich finde zwar Ansätze in verschiedenen Threads dazu, mir wird eine solche Umsetzung zu komplex. Dann bleibe ich lieber im Host-Modus.




Was mich noch interessieren würde:
Ich sehe in deinem fhem_sonos-Container die relative geschickte Möglichkeit, das FHEM zu aktualisieren.
Aber wird dies nicht eigentlich nur beim Erstellen des Containers durchgeführt?
Muss ich also die Container regelmäßig löschen, wenn ich die FHEM-Instanz updaten möchte?

Erdmännchen

Hallo FunkOdyssey,

die dockerfile erstellt ein image und daraus wird beim ersten starten des "Containers" ein container erstellt.
d.h. der erstellte Container ist direkt lauffähig für meine fhem.cfg ohne das ich Sachen aus der Config löschen oder aus kommentieren muss.

Ich benutze z.b. das ABFALL Modul, wenn ich FHEM (ohne update) das erste mal mit meiner eigenen Config laden möchte, stürtz FHEM ab, weil das Modul ABFALL nicht gefunden wurde.

FHEM hat bei der Installation nicht alle Module die ich brauche an Bord.
Bei einem update von FHEM werden diese erst geladen (Quellen stehen in der controls.txt).

Somit ist mein Container, der aus dem Image erstellt worden ist, direkt lauffähig.
Ohne das man blöd rum tricksen muss: definierte Module in der fhem.cfg aus kommentieren usw.

Du kannst ganz normal in deinem Container "update all" machen, du brauchst den Container nicht zu löschen.
Dein container ist dann auf dem aktuellsten stand, aber dein image hat dann noch den Softwarestand vom Tag des Erstellens.

Ich hoffe du konntest folgen. Kann das irgendwie schlecht beschreiben, ist auf jeden Fall komfortabel   ;D


Habe mich ein wenig mit docker networking auseinander gesetzt.
Wenn ich das richtig verstanden habe, werden beim erstellen von Container auto. die Container an das docker bridge Netzwerk (docker0) eingebunden.
d.h. eine interne IP Adresse wird vergeben (172.17.0.x) und es wird ein Eintrag in die iptables generiert, der auf diese IP Adresse verweist, wenn eine Anfrage über das Netzwerk kommt.

Nur eine Vermutung:
Wenn du die richtigen Ports aus einem Container nach aussen mapst, kann Sonos zwar Daten senden, aber das Empfangen funktioniert nicht, weil das docker0 Netzwerk nicht weiss wohin mit den Daten.
d.h. man muss in der iptables die multicast Adresse von Sonos auf den Container verweisen.

Diese Informationen sind ohne Gewähr und verzeiht mir, wenn ich etwas falsches geschrieben habe. Dann korrigiert mich bitte, ich bin kein Profi.
Das sind alles nur Vermutungen!!!

Ich schmeisse einfach mal ein paar links in die Runde:
http://www.dasblinkenlichten.com/docker-networking-101/
http://www.dasblinkenlichten.com/docker-networking-101-host-mode/
http://www.dasblinkenlichten.com/docker-networking-101-mapped-container/
https://blog.docker.com/2016/12/understanding-docker-networking-drivers-use-cases/
https://runnable.com/docker/basic-docker-networking
https://runnable.com/docker/docker-compose-networking

Vielleicht kann man sich auch Informationen aus einem airsonos dockerfile holen:
https://github.com/justintime/docker-airsonos

Ich bleibe auch erstmal im host mode, wenn ich nochmal viel Zeit und Lust habe, werde ich mich nochmal damit beschäftigen.

Wünsche noch viel Erfolg.

FunkOdyssey

Zitat von: Erdmännchen am 07 September 2017, 18:31:20
Hallo FunkOdyssey,

die dockerfile erstellt ein image und daraus wird beim ersten starten des "Containers" ein container erstellt.
d.h. der erstellte Container ist direkt lauffähig für meine fhem.cfg ohne das ich Sachen aus der Config löschen oder aus kommentieren muss.

Ich benutze z.b. das ABFALL Modul, wenn ich FHEM (ohne update) das erste mal mit meiner eigenen Config laden möchte, stürtz FHEM ab, weil das Modul ABFALL nicht gefunden wurde.

FHEM hat bei der Installation nicht alle Module die ich brauche an Bord.
Bei einem update von FHEM werden diese erst geladen (Quellen stehen in der controls.txt).

Somit ist mein Container, der aus dem Image erstellt worden ist, direkt lauffähig.
Ohne das man blöd rum tricksen muss: definierte Module in der fhem.cfg aus kommentieren usw.

Du kannst ganz normal in deinem Container "update all" machen, du brauchst den Container nicht zu löschen.
Dein container ist dann auf dem aktuellsten stand, aber dein image hat dann noch den Softwarestand vom Tag des Erstellens.

Ich hoffe du konntest folgen. Kann das irgendwie schlecht beschreiben, ist auf jeden Fall komfortabel   ;D

Danke, Erdmännchen, für die ausführliche Antwort. Das hättest du dir aber sparen können. Wie der Docker-Fhem-Container funktioniert, habe ich schon verstanden. Bei mir ist es genauso. Wobei ich komplett /opt/fhem als Volume angelegt habe. Einschränken kann ich das später.

Meine Frage bezog sich eher auf die eigene FHEM-Instanz für Sonos. Hier führst du ja nur bei der Erstellung des Containers ein Update durch. Danach wird die update.cfg ja umbenannt.




Am Rande: AirSonos läuft bei mir übrigens im Host-Modus. :-)

Erdmännchen

Hallo FunkOdyssey,

Im FHEM Sonos Container ist noch die update.cfg aktiv d.h. du musst nur Fhem einmal im Container starten.

perl fhem.pl fhem.cfg

Dann wird sich FHEM updaten und beenden.
(Hoffe ich, bis jetzt hab ich den Container & Image immer gelöscht und neu gebaut.)

Falls es zu Problemen kommt musst du den org. FHEM Container so lange beenden.

Mfg Erdmännchen

Otto

Hallo zusamen,

habt Ihr Sonos schon im Fhem Container laufen?
Gruss Otto

.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.

docker - homematic

FunkOdyssey

Zitat von: Reinerlein am 29 April 2017, 23:38:36
Hallo,

alternativ kannst du auch den Sonos-SubProzess selber auf einer Maschine innerhalb des Netzes laufen lassen, wo deine Sonos-Player laufen.
Dein Docker-Fhem kann sich dann mit diesem Prozess verbinden.

Das bedeutet aber immer noch, dass du eine laufende Maschine innerhalb deines "normalen" Netzes brauchst, auf der Perl läuft...

Wenn du das versuchen möchtest, so kannst du den SubProzess selber starten:

perl 00_SONOS.pm <PORT> <INITIAL_VERBOSELEVEL> <MSECLOG>

also z.B.

perl 00_SONOS.pm 4711 1 1


Grüße
Reinerlein


Ich habe folgende Ausgangssituation:

In einem Docker-Container, welchen ich im Host-Modus laufen lasse, starte ich die Sonos-Prozesse wie folgt:

perl 00_SONOS.pm 4711 120 10 10

Im produktiven FHEM-Container (eigene Bridge) habe ich Sonos folgendermaßen eingebunden:

define Sonos SONOS dockerhostname:4711 120 10 10

Das funktioniert generell ganz gut.

Aber sobald ich das Produktiv-FHEM kurz offline nehme, neu starte oder sonst pausiere, steigt die CPU-Last im Sonos-Container (auf der Host) auf 100%.
Wenn ich das richtig verstehe, so liegt das doch wahrscheinlich daran, dass das FHEM dem Prozess nicht mitteilen kann, dass die Sub-Prozesse beendet werden müssen, oder? Quasi Zombie-Prozesse?
Ich muss jedenfalls stets beide Container neu starten. Vergesse ich den Sonos-Container, so gehen CPU-Lust und Stromverbrauch steil nach oben.

Besteht irgendwie die Möglichkeit, dass man (auch den nicht eigens gestarteten) Sub-Prozess stoppen kann (SONOS_StopSubProcess / fremdes DevIo)?




Falls mal jemand fragen sollte, warum ich das so mache?
Der Sonos-Prozess muss scheinbar im Host-Modus laufen (siehe Diskussion zuvor) und ich will FHEM nicht in dieser Ebene laufen lassen.

Reinerlein

Hi FunkOddyssey,

die Parameter für den Sonos-Prozess solltest du noch anpassen:

perl 00_SONOS.pm 4711 3 1
Die drei ist der Verbose-Level. Dort hattest du 120 stehen, was wirklich hoch ist :)
Danach folgt die Angabe, ob in der Logausgabe Millisekunden enthalten sein sollen (also 0 oder 1).
Das sind nicht die gleichen Parameter wie bei deinem Fhem-Device!

Aber zu deiner Frage:
Prinzipiell arbeitet das System nach dem Prinzip: Wer einen Prozess startet, beendet ihn auch wieder.
Deswegen gibt es auch keine Möglichkeit von Fhem aus den SubProzess zu beenden.

Allerdings sollte er auch nicht auf 100% CPU-Last gehen, da bei einem regulären Fhem-Shutdown ein Signal an den SubProzess gesendet wird, dass Fhem jetzt weg ist, und dementsprechend die Threads des SubProzesses beendet werden sollen.
Passiert das beim regulären Beenden? Oder wird Fhem irgendwie abgeschossen o.ä.?

Sonst mal den SubProzess mit Verbose auf 5 starten (anstatt der drei in meinem Beispiel), und nach dem Beenden des Fhem-Containers im Log schauen, was er so tut, bzw. gerade noch getan hat...

Grüße
Reinerlein

FunkOdyssey

Zitat von: Reinerlein am 09 Februar 2018, 19:45:01
Hi FunkOddyssey,

die Parameter für den Sonos-Prozess solltest du noch anpassen:

perl 00_SONOS.pm 4711 3 1
Die drei ist der Verbose-Level. Dort hattest du 120 stehen, was wirklich hoch ist :)
Danach folgt die Angabe, ob in der Logausgabe Millisekunden enthalten sein sollen (also 0 oder 1).
Das sind nicht die gleichen Parameter wie bei deinem Fhem-Device!

Ehrlich gesagt hatte ich das sogar immer auf
perl 00_SONOS.pm 4711 1 1
stehen und habe das erst beim Schreiben meines Postings bemerkt. Ich dachte, dass das ein Fehler wäre und habe das zeitgleich mit dem Posting auf 120 geändert. Dank deiner Erläuterung habe ich den Wert unverzüglich wieder abgeändert.

Zitat von: Reinerlein am 09 Februar 2018, 19:45:01
Prinzipiell arbeitet das System nach dem Prinzip: Wer einen Prozess startet, beendet ihn auch wieder.
Deswegen gibt es auch keine Möglichkeit von Fhem aus den SubProzess zu beenden.

Ist logisch. Leider habe ich vom Produktiv-FHEM keine Möglichkeit, den Prozess im Host-Container zu stoppen. Nun ja, das ist wohl mein individuelles Problem. :-)

Zitat von: Reinerlein am 09 Februar 2018, 19:45:01
Allerdings sollte er auch nicht auf 100% CPU-Last gehen, da bei einem regulären Fhem-Shutdown ein Signal an den SubProzess gesendet wird, dass Fhem jetzt weg ist, und dementsprechend die Threads des SubProzesses beendet werden sollen.
Passiert das beim regulären Beenden? Oder wird Fhem irgendwie abgeschossen o.ä.?

Ich habe mal ein wenig darauf geachtet. In der Tat passiert wohl nichts, wenn ich FHEM (z.B. durch ein Update) neu starte. Ich versuche den Fehler mal einzugrenzen. Noch weiß ich nicht mehr.

Zitat von: Reinerlein am 09 Februar 2018, 19:45:01
Sonst mal den SubProzess mit Verbose auf 5 starten (anstatt der drei in meinem Beispiel), und nach dem Beenden des Fhem-Containers im Log schauen, was er so tut, bzw. gerade noch getan hat...

Das habe ich jetzt gerade mal gemacht. Ich frage mich gerade nur, ob ich wohl im richtigen Log schauen. Das FHEM-Log ist diesbezüglich leer. Und das sonos.log in FHEM ist merkwürdig ruhig. Da sehe ich nur ein paar der folgenden Zeilen:

2018-02-13_11:26:26 Sonos LastProcessAnswer: 1518517586.28313
2018-02-13_11:26:26 Sonos ZoneGroupState: <ZoneGroups><ZoneGroup Coordinator="xxx" ID="xxx:37"><ZoneGroupMember UUID="xxx" Location="http://xxx:1400/xml/device_description.xml" ZoneName="Küche" Icon="x-rincon-roomicon:kitchen" Configuration="1" SoftwareVersion="40.5-49090" MinCompatibleVersion="39.0-00000" LegacyCompatibleVersion="25.0-00000" BootSeq="265" TVConfigurationError="0" WirelessMode="1" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="2437" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="3" SecureRegState="3" VoiceState="0"/><ZoneGroupMember UUID="xxx" Location="http://xxxx:1400/xml/device_description.xml" ZoneName="Wohnzimmer" Icon="x-rincon-roomicon:living" Configuration="1" SoftwareVersion="40.5-49090" MinCompatibleVersion="39.0-00000" LegacyCompatibleVersion="25.0-00000" BootSeq="180" TVConfigurationError="0" WirelessMode="1" WirelessLeafOnly="0" HasConfiguredSSID="1" ChannelFreq="2437" BehindWifiExtender="0" WifiEnabled="1" Orientation="0" RoomCalibrationState="1" SecureRegState="3" VoiceState="0"/></ZoneGroup></ZoneGroups>
2018-02-13_11:26:27 Sonos LastProcessAnswer: 1518517587.84417


Ich werde das mal beobachten.

Danke dir für deinen (off-topic)-Support.

Reinerlein

Hi FunkOdyssey,

du musst natürlich in der Konsole des anderen Docker-Containers (dem des Sonos-Prozesses) schauen.
Je nachdem, wie du deinen Container erzeugt hast, landen die Sonos-Prozess-STDOUT-Ausgaben in der STDOUT-Ausgabe des Docker-Containers selbst, sodass du dir nur dieses anschauen brauchst...

Grüße
Reinerlein