Logitech Harmony Hub

[Amenophis86]

Ich fürchte, wir reden aneinander vorbei. Ich verstehe auch den Sinn des DOIFs nicht, denn dieser Teil der Bedingung
([HarmonyHub:currentActivity] ne "starting OSMC" or [HarmonyHub:currentActivity] ne "OSMC")
ist doch IMMER wahr.

Das ist richtig, es muss ja auch immer wahr sein. Ich hatte auch nur einen Auszug gepostet, weil dieser Teil immer wieder Aktiv wurde, wenn ich mittels command geschaltet habe. Hier das ganze DOIF:

Code Auswählen Erweitern


(([HarmonyHub:currentActivity] eq "starting OSMC" or [HarmonyHub:currentActivity] eq "OSMC") and [?WZ.IPSteckdose_OSMC] eq "off" and [?HarmonyHub:previousActivity] eq "PowerOff")
(set WZ.IPSteckdose_OSMC on, attr WZ.OSMC disable 0, save) 
(set WZ.OSMC connect)
DOELSEIF (([HarmonyHub:currentActivity] eq "starting OSMC" or [HarmonyHub:currentActivity] eq "OSMC") and [?WZ.IPSteckdose_OSMC] eq "off" and [?HarmonyHub:previousActivity] ne "PowerOff")
(set WZ.IPSteckdose_OSMC on, attr WZ.OSMC disable 0, save) 
(set WZ.OSMC connect)
DOELSEIF (([HarmonyHub:currentActivity] ne "starting OSMC" or [HarmonyHub:currentActivity] ne "OSMC") and [?WZ.IPSteckdose_OSMC] eq "on")
(set WZ.OSMC shutdown)
(attr WZ.OSMC disable 1, save)
(set WZ.IPSteckdose_OSMC off)

Der Sinn dahinter ist, dass OSMC an einer Steckdose hängt. Sobald die Aktivität OSMC startet ("starting OSMC") bzw. läuft ("OSMC") soll die Steckdose geschaltet werden. Bedinung 1+2 unterscheiden sich durch ein wait attr. Bei Nr. 1 wird gewartet, weil der Receiver noch hoch gefahren wird (anderes DOIF). Bei Nr. 2 wird sofort gestartet, weil der Receiver durch eine andere Aktivität schon an war.
Bei Nr.3 soll die Steckdose ausgeschaltet werden. Allerdings wird diese Bedinung auch immer wahr, wenn ich mittels Command etwas schalte. Daher die Frage, ob durch senden des Befehels Command ... kurzzeitig auch das Reading currentActivity betroffen ist?

[justme1968]

nein. das senden eines befehls ändert kein reading.


aber warum tut sich jemand solch ein konstrukt an?

es ist doch viel einfacher z.b. ein dummy gerät mit passend konfigurierter verzögerung in die activity einzubauen und dann dieses in fhem als harmony device anzulegen. auf dieses kann man dann ein ganz einfaches notify los lassen das auf on und off reagiert.

neben bei fällt auch noch die fallunterscheidung war schon an weg weil die harmony das alles intern über die activities schon abbildet.

gruss
  andre

[Amenophis86]

Folgender Aufbau ist bei mir vorhanden:

Steckdose TV: Hier dran stecken der Fernseher, ein Hifi-Receiver und Subwoofer
Steckdose OSMC: Hier dran steckt ein PI, auf welchem Kodi läuft
Steckdose PS4: Hier dran steckt die PS4

Beim Einschalten einer Activity wird zu erst die Steckdose TV eingeschaltet. Währenddessen hat die Harmony ein Dummy Gerät (genannt Pause) welches gestartet wird. Kurz darauf schaltet die Harmony den TV und den Receiver an und auf die richtigen Eingänge. Dies geschieht bei der Activity. Realisiert ist das ganze durch ein DOIF, welches auf das Reading "current Activity" hört

Code Auswählen Erweitern

([HarmonyHub:currentActivity] ne "PowerOff" and [WZ.IPSteckdose_TV] eq "off")
(set WZ.IPSteckdose_TV on)
DOELSEIF ([HarmonyHub:currentActivity] eq "PowerOff" and [WZ.IPSteckdose_TV] eq "on")
(set WZ.IPSteckdose_TV off)

Bei der Activity TV wird noch zusätzlich der Telekom Receiver eingeschaltet, hat immer Strom, daher keine besondere Schaltung.

Wird nun OSMC als Activity geschaltet, muss unterschieden werden, ob der Hifi-Receiver schon an ist oder nicht. Ist er an, wird quasi die Steckdose OSMC eingeschaltet, das Modul XBMC aus dem disable geholt und los gehts.
Ist der Hifi-Receiver noch nicht an und muss auch aus dem Stromlos Modus, wie oben beschrieben, geholt werden, muss dieser erst an und Empfangsbereit sein, bevor OSMC gestartet wird. Aus bisher noch nicht bekannten gründen, bekommt er sonst kein Bild vom Pi angezeigt.
Beim schalten einer anderen Activity, als OSMC, wird der Pi herunter gefahren, das XBMC Modul auf disable gesetzt und kurz darauf die Steckdose ausgeschaltet.

Das ganze wird mit dem zwei Posts vorher aufgeführtem DOIF ausgeführt.

Dann gibt es noch ein DOIF für die PS4, welches allerdings dem TV einschalten ähnelt und keine Probleme macht.


Aus diesem Grund sind die DOIFs, wie sie sind. Bisher hat es auch alles geklappt. Bis ich anfangen wollte und mittels FHEM Befehle an das Hub zu schicken. Das erste Problem hatte ich hier beschrieben:

Mir ist gerade aufgefallen, dass in FHEM die Commandos mit anderen Geräten verknüpft sind, als in der Harmony Software.

Bei der Aktivität OSMC drücke auf die Taste nach oben und es geht nach oben, setze ich den Befehel

Code Auswählen Erweitern

set HarmonyHub command DirectionUp
mit FHEM ab, dann passiert nichts. Grund ist, dass das Modul in FHEM denkt, dass das ganze an meinen Panasonic TV gehen soll, aber in Wirklichkeit soll es an das XBox Gerät (ist die hinterlegte Fernbedienung für OSMC) gehen.

In der Harmony Software ist die Taste nach oben bei kurzem Druck mit dem Gerät XBox verknüpft. Bei FHEM wird mittels get HarmonyHub commands OSMC angezeigt, dass DirektionUp mit dem Panasonic TV verknüpft ist. Wie kann das geändert werden? Habe sowohl sync, als auch set HarmonyHub getConfig versucht.

Und nun habe ich dieses Problem umgehen können, wenn ich mittels

Code Auswählen Erweitern

set HarmonyHub command ID-des-Device Befehl

meine Befehle an die Harmony sende. Allerdings ist mir aufgefallen, dass auch mein OSMC DOIF hier drauf anspringt. Und zwar wird immer die 3. Abfrage wahr. Und ich kann mir nicht erklären warum. Daher die Frage, ob jemand weiß warum.

Für Verbesserungsvorschläge bin ich gerne offen. Allerdings sehe ich noch nicht ganz den Unterschied, ob ich das ganze jetzt mit DOIFs oder mit Notifys baue

[justme1968]

mein hinweis bezog sich weniger auf den unterschied zwischen DOIF und notify sondern darauf das ganze über die logik zu machen die der hub bezüglich des einschalten von devices sowieso schon hat und sich nur an das power reading eines entsprechenden hub devices zu hängen statt die logik noch mal nach zu bilden.

- füge in die activity ein device für die steckdose ein. auch wenn der hub sie nicht wirklich schalten kann.
- füge die passenden verzögerungen ein
- konfiguriere die passende einschaltreihenfolge der devices

das machst du alles auf hub seite

- lege mit set <hub> autocreate xxx ein fhem device für die dummy steckdose an
- sobald das power reading dieser steckdose in fhem auf on geht schaltest du sie über fhem ein
- sobald es auf off geht schaltest du sie über fhem aus

wenn ich deine konfiguration oben richtig verstehe gibt es das dummy gerät in der harmony schon. du musst es nur in fhem als harmony device noch anlegen.

gruss
  andre

[Amenophis86]

Ich werd bekloppt, es könnte so einfach sein Ich danke für die Info. Ich hatte diese Einstellung glaube von meintechblog oder so. Aber das ist ja wirklich noch viel einfacher

[Amenophis86]

Kann es jedoch sein, dass die Dummys erst auf on gehen, wenn die Verzögerung abgelaufen ist? Ich habe es jetzt mal versucht die Steckdose zu schalten, wenn der Dummy auf on geht, aber das klappt nicht. Bzw mir kommt es vor, als ob der Dummy immer erst auf on geht mit allen anderen Dummys auch. Dann müsste ich die Steckdose ja doch wieder auf die Activity schalten lassen und nicht auf den Dummy des Steckdosengeräts?

[justme1968]

die reihenfolgen und verzögerungen (es gibt hier mehrere, im device und zwischen den devices) müssen passen.

gruss
  andre

[Chridd]

Hallo zusammen,

leider komme ich nicht über den "ConnectionState" "Disconnected" hinaus.

Hat jemand eine Idee, was das Problem sein könnte?

[justme1968]

bei verbindungsproblemen waren es bis jetzt zu 95% falsche ip adressen und manchmal auch zeichen im password die probleme machen.

[Chridd]

mmh. Das sieht soweit alles richtig aus.
Muss ich die Connection zum Hub denn irgendwie triggern?
Muss ich ggf. noch etwas auf dem Pi installieren?
Vielen Dank

[Chridd]

Das wäre doch ein richtiger Befehl, oder?
define hub harmony Tester@harmony.de t@XI 10.0.1.4

[rubbertail]

Wenn dein Hub die IP-Adresse 10.0.1.4 hat, dann ja

[rubbertail]

Allerdings - ob das @ ein gutes Zeichen im Password ist?

[Chridd]

Danke für Deine Antwort, rubbertail
Ich habe zwar nicht diese Login Daten, aber ich habe tatsächlich ein @ in meinem Passwort. Kann das das Problem sein? Dann muss ich das mal ändern und versuchen.

[rubbertail]

Bei Sonderzeichen würde ich mich auf Satzzeichen beschränken...