SONOS - SubProzess mit set Befehl neustarten anstatt disable (1/0)

[webdandy]

Hallo Reinerlein,

leider kommt es bei meiner FHEM Installation auch ab und zu vor, dass der SubProzess unerwartet beendet wird.
Sehr selten, aber es kommt vor...

Code: [Auswählen]

2019.08.23 02:34:58 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
Wäre es möglich, dass Du ein "set Befehl" integrierst, der einen restart des Prozesses durchführt?
Dann könnte man mit einem notify oder DOIF monitoren, ob der Prozess läuft und dann mit einem "set..." notfalls wieder restarten.
Dies wäre wesentlich komfortabler als ein attr Sonos disable 1 und deleteattr Sonos disable.

Oder gibt es schon was ähnliches, was ich übersehen habe?

Grüße Fabian

[webdandy]

Gibt es niemanden, bei dem der Prozess auch ständig beendet wird?

Code: [Auswählen]

2019.08.28 12:53:54 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...


[DeeSPe]

Ich wäre auch dafür einen entsprechenden Setter im SONOS Device zu integrieren.
Bei mir steigt der Prozess auch (un)regelmäßig aus.
Dazu habe ich ein stündliches at definiert, welches prüft ob SONOS disabled ist, falls ja wird dass attr disable gesetzt und nach 30 Sekunden wieder gelöscht. Nachteil ist aber eben die Änderung der cfg.

Gruß
Dan

[webdandy]

Ich wäre auch dafür einen entsprechenden Setter im SONOS Device zu integrieren.
Bei mir steigt der Prozess auch (un)regelmäßig aus.
Dazu habe ich ein stündliches at definiert, welches prüft ob SONOS disabled ist, falls ja wird dass attr disable gesetzt und nach 30 Sekunden wieder gelöscht. Nachteil ist aber eben die Änderung der cfg.

Gruß
Dan

Hallo Dan,
könntest Du mir mal bitte schicken, wie Du es realisiert hast?
Bei mir hatte das irgendwie nicht geklappt.
Bekomme nur eine Telegram Nachricht, sobald der Subprozess stoppt und muss dann händisch setzen. Blöd...

Gruß Fabian

[DeeSPe]

Das ist kein Hexenwerk Fabian!

Mein at sieht so aus:

Code: (RAW DEF) [Auswählen]

defmod at_SONOS at +*01:00 {fhem "attr Sonos disable 1;; sleep 30;; deleteattr Sonos disable" if (Value("Sonos") eq "disabled")}
Gruß
Dan

P.S. Man könnte es auch mit einem entsprechenden notify umsetzen.

Code: (RAW DEF) [Auswählen]

defmod n_SONOS notify Sonos:.disabled {fhem "attr Sonos disable 1;; sleep 30;; deleteattr Sonos disable"}

[webdandy]

Ah, okay danke! Damit hatte ich auch schon mal experimentiert und festgestellt, dass man ein"save" mittlerweile nicht mehr mit einem notify ausführen kann.
Deshalb sagtest du auch die Änderung in der cfg.... Werde es aber auch erstmal so konfigurieren, bis es vielleicht in Zukunft ein set Befehlt für einen Neustart gibt.
Kann es durch das "sleep 30" Freezes geben?
Gruß Fabian

[DeeSPe]

Kann es durch das "sleep 30" Freezes geben?

Nein, denn es ist ein FHEM sleep und kein Perl sleep.

Gruß
Dan

[Otto123]

Hi,

ich habe das so gemacht.

Code: [Auswählen]

defmod di_SonosCheck DOIF ([05:00] and [?Sonos] ne "opened" )(attr Sonos disable 1)(attr Sonos disable 0)
attr di_SonosCheck room Bad,Status
attr di_SonosCheck wait 0,10
Damit früh das automatische Radio sichergestellt ist
Ich glaub ich hatte bei Sonos im Fehlerfall schon den Status der nicht "disabled" war - bin aber nicht ganz sicher. 

BTW: Das mit den automatischen save ist nicht ganz ohne, da hat sich manch einer die Konfig "gelöscht". Es gibt Zustände, da werden bei Neustart in der aktiven Konfig (also der im Speicher) Geräte wieder entfernt weil sie nicht definierbar sind. Das würde dann bei einem save "ohne hinschauen" festgeschrieben.

Gruß Otto

[webdandy]

Hi Otto,
verstehe, der Ansatz mit dem automatischen save, kann gefährlich sein 
Ich habe nur mal kurz gesucht, aber gibt es die Möglichkeit eines “Diffs“ zwischen der running und der cfg Datei?
Gruß Fabian

[webdandy]

Hallo Reinerlein,

hast Du vielleicht schon geplant, den SONOS SubProzess mit einem "set Befehl" neustarten zu können?

Gruß Fabian

[Mitch]

Alt, aber immer noch aktuell.

Gibt es mittlerweile Überlegungen in diese Richtung?

Bei mir stirbt der Subprozess immer wieder, wird aber in fhem als open angezeigt, somit geht notify/DOIF und Co. nicht wirklich.

[Kurt77]

Hallo,
bei mir genauso: Subprocess wird auch nach dem Sterben als "opened" angezeigt.
Gibt es eine andere Möglichkeit, festzustellen, dass sich der Subprocess verabschiedet hat?

Danke und Gruß,
Kurt

[Kurt77]

Hallo,
dann will ich mir mal selbst antworten. Vielleicht hilft es ja jemandem.
Ich ermittle stündlich die Differenz zwischen der aktuellen Zeit und der Zeit, die im reading   LastProcessAnswer abgelegt wird. Bei einer Differenz > 60 Sekunden starte ich den Prozess neu.

Gruß Kurt