Neues Modul PHTV für Philips Fernseher (inkl. Ambilight)

Begonnen von Loredo, 06 März 2014, 22:09:17

Vorheriges Thema - Nächstes Thema

chphmu

Hi zusammen,

ich beschäftige mich seit kurzem mit FHEM und habe nun auch meinen Philips Fernseher von circa 2010 eingebunden (37PFL7606K/02). Das Modul funktioniert auch soweit sehr gut und zuverlässig, nur das umschalten des Inputs schlägt leider fehl.

Wenn ich manuell ein POST 192.168.178.55:1925/1/sources/current {"id":"hdmi3"} mache funktioniert der Befehl. Mit PHTV klappt es leider nicht. Ich bin mir nicht ganz sicher woran es liegt. Anbei der Log während des Befehls:

2015.05.31 22:01:15 5: PHTV PhilipsTV2: called function PHTV_Set()
2015.05.31 22:01:15 3: PHTV set PhilipsTV2 input HDMI_3
2015.05.31 22:01:15 5: PHTV PhilipsTV2: called function PHTV_SendCommand()
2015.05.31 22:01:15 4: PHTV PhilipsTV2: REQ sources/current/{ "id": hdmi3 }
2015.05.31 22:01:15 5: PHTV PhilipsTV2: GET http://192.168.178.55:1925/1/sources/current ({ "id": hdmi3 })
2015.05.31 22:01:15 5: PHTV PhilipsTV2: called function PHTV_Set()
2015.05.31 22:01:15 5: PHTV PhilipsTV2: called function PHTV_ReceiveCommand()
2015.05.31 22:01:15 4: PHTV PhilipsTV2: RCV sources/current/"id": hdmi3
2015.05.31 22:01:15 5: PHTV PhilipsTV2: RES ERROR sources/current/"id": hdmi3
<html><head><title>Bad Request</title></head><body>Bad Request</body></html>


Was muss ich tun, damit der Befehl erfolgreich an den TV gesendet wird?
Ist es ein Fehler bei mir oder ein Bug im Modul?

Wäre super wenn ihr mir helfen könntet :)

Grüße
Christian

fidel

Hi,

mein Philips TV PFS8159 lässt sich aus dem Standby mit folgendem Ablauf einschalten.
-Senden eines Magic Packets um den Fernseher bzw. die Jointspace Schnittstelle ansprechbar zu machen (vom Cubie mittels Konsole abgesetzt).
-Danach über das fhem Modul sobald das Device als present erkannt wird normal einschalten.

Das Magic Packet sollte folgendes Format haben: wakeonlan -i 192.168.1.255 1c:5a:6b:xx:xx:xx (an die direkte ip des TV funktioniert nicht)

@Loredo: Könntest das einbauen? Ich könnte es auch selbst versuchen, aber mit meinen rudimentären Kenntnissen würde das ewig dauern :)

Gruß
Fhem 5.6 auf Cubietruck,CUL,CUL_TCM97001,FritzBox7390,HMLAN,CUL_HM_HM_OU-16LED,CUL_HM_HM_SEC_SC,CUL_HM_HM_LC_SW4,CUL_HM_HM_RT_DN,HUEBridge,HUEDevice,Panstick,Panstamp (binouts,rgddriver mit dht22),PHTV,Yamaha-AVR,Withings,ELV-IPS, etc...

Loredo


Mein TV hört IIRC nicht auf Magic Packets (hatte das sicherlich während der Modulentwicklung probiert).
Wenn es jetzt solche Modelle gibt, dann baue ich das gerne bei Gelegenheit analog zur gleichen Funktion wie im ENIGMA2 Modul mit ein. Kann aber grad nicht sagen, wann ich dazu kommen werde.




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

fidel

#183
Ich habe mal kurz in die Bedienungsanleitung vom PFL8008 gesehen. Der hat laut Bedienungsanleitung auch WoWLAN Einstellungsmöglichkeit.

Funktioniert denn das Einschalten über die MyRemote App?
Für meinen wird die TVRemote App benötigt.

Ich habe per Wireshark den Traffic mitgelesen und habe dort gesehen, dass die App WOL Magic Packets absendet.

Wenn ich jetzt ein wakeonlan absetze, gehen die readings power und presence auf on bzw. present und der Fernseher bleibt jedoch dunkel. Auch mein Yamaha Receiver wird dabei eingeschalten. Danach lässt sich der TV dann über das Modul einschalten.

Vielleicht können die Philips TV Besitzer, die das interessiert mal nachsehen. WoWLAN im PhilipsTV sollte natürlich eingeschalten sein und man sollte z.B. die Mac-Adressen von LAN und WLAN nicht vertauschen (ist mir selbst passiert ;) ) Das ganze habe ich über LAN gemacht. WLAN habe ich noch nicht getestet. Ich vermute aber auf Grund der Bezeichnung, dass es darüber genauso funktioniert. 



Gruß

Steven
Fhem 5.6 auf Cubietruck,CUL,CUL_TCM97001,FritzBox7390,HMLAN,CUL_HM_HM_OU-16LED,CUL_HM_HM_SEC_SC,CUL_HM_HM_LC_SW4,CUL_HM_HM_RT_DN,HUEBridge,HUEDevice,Panstick,Panstamp (binouts,rgddriver mit dht22),PHTV,Yamaha-AVR,Withings,ELV-IPS, etc...

OsiRis

Hallo,

Ich hab leider immer noch das Problem, dass es nicht mit mehr als 2 HUE Lampen läuft. Gebe ich mehrere an, werden nur die ersten 2 angesteuert.
Hat das jemand am laufen?

Hier ist mein Code, ich kann keinen Fehler finden, könntet ihr da bitte mal drüber sehen.
define PhilipsTV PHTV 192.168.178.30
attr PhilipsTV ambiHueLeft HUEDevice2 HUEDevice3 HUEDevice9
attr PhilipsTV ambiHueRight HUEDevice1 HUEDevice4
attr PhilipsTV devStateIcon on:rc_GREEN:off off:rc_YELLOW:on absent:rc_STOP:on
attr PhilipsTV icon it_television
attr PhilipsTV inputs EXT_1:HDMI_1:HDMI_2:HDMI_3:HDMI_Side:Watch_Satellite:Watch_TV:VGA:Y_Pb_Pr
attr PhilipsTV room Wohnzimmer
attr PhilipsTV webCmd volume:input:rgb


Soweit ich im Log erkennen kann, werden die zusätzlichen gar nicht angesteuert (Genaueres im Post #178). Könnte es sich um einen Bug handeln, oder mache ich was falsch.

Ich hoffe ihr könnt mir weiterhelfen.
Danke!

MFG OsiRis

fidel

#185
Hallo,

anbei eine Version mit wol für Philips TV.
In diesem Modul findet sich zum einen der set Befehl wake, womit ein WOL zum Philips TV abgesetzt wird.
Zum Anderen muss hierfür, das Attribut macaddr (LAN/WLAN) eures Fernsehers gesetzt werden.

Was ich programmiert habe, können die Entwickler bestimmt besser, kürzer und sinnvoller zusammen fassen.
Für meinen TV PFS8159 funktioniert es und mich würde es interessieren ob es bei anderen ebenso funktioniert?

Die WoWLAN Funktion und damit WOL unterstützen soweit ich gelesen habe alle TV's mit einer Modellnummer >= 8 am Ende.

Zum Testen:

Befehl wake absetzen.
Das Reading presence sollte daraufhin auf present wechseln.
Anschließend kann mit set TV on der TV eingeschalten werden.

Der Befehl on und wake könnten dann später bestimmt auch noch zusammen gefasst werden.

@OsiRis

ich habe deine Funktionen nicht in Verwendung.
Laut commandref scheint da, so wie du es angelegt hast,  kein Fehler drin zu sein.

Eventuell könntest du mal die HUEDevices im Attribut untereinander tauschen, um festzustellen ob es PHTV Modul liegt oder eventuell am HUEDevice Modul bzw. deinen unterschiedlichen HUE Typen.
Ich weiß nicht welches HUEDevice welches ist. Aber falls HUEDevice9 z.b. die einzige Aura oder Iris ist, diese einfach mal an erster oder zweiter Stelle im Attribut setzen.

Ich habe bei mir mal testweise attr AmbiHueRight HUEDevice1 HUEDevice2 HUEDevice3 gesetzt und diese auch im Attribut untereinander getauscht.
Bei mir macht jeweils nur das erste HUEDevice im Attribut mit.

Grüße
Fhem 5.6 auf Cubietruck,CUL,CUL_TCM97001,FritzBox7390,HMLAN,CUL_HM_HM_OU-16LED,CUL_HM_HM_SEC_SC,CUL_HM_HM_LC_SW4,CUL_HM_HM_RT_DN,HUEBridge,HUEDevice,Panstick,Panstamp (binouts,rgddriver mit dht22),PHTV,Yamaha-AVR,Withings,ELV-IPS, etc...

Loredo

Ich habe gerade eine neue Version hochgeladen:


- wake-on-lan Support eingebaut
- die wenigen blocking sleep() Aufrufe wurden ersetzt
- verbessertes Logging bei verbose=4 und verbose=5 für ambiHue


das beschriebene ambiHue Problem konnte ich insofern nachvollziehen, als dass bei mir auch nur das erste Gerät die Farbe ändert. Gleichwohl wird (wie man mit dem erweiterten Logging nun auch sehen kann) an alle Geräte entsprechender Befehl über das HUE Modul rausgeschickt. Ich vermute also dort irgend einen Fehler in der Verarbeitung bei mehr als einem Befehl in kurzer Abfolge. Dazu müsste sich dann André einmal äußern.




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DOCa Cola

Vielen Dank, dass du dir Zeit genommen hast dich mit dem Hue Problem zu beschäftigen. Freut mich, dass es da Erkenntnisse gibt. Bin gespannt.

OsiRis

Hallo Loredo,

auch von mir ein großes Dankeschön!

@fidel: Das mit dem Durchtauschen der Devices hatte ich auch schon probiert. Es wird immer nur das erste Device richtig angesteuert. Ich kann allerdings über FHEM grundsätzlich alle ansteuern. Vielleicht liegt es wirklich daran, dass das HUEDevices oder HUEBridge Modul nicht mit der schnellen Abfolge der Befehle klar kommt. Ich dachte es handelt sich eventuell um einen Bug im PHTV Modul, aber das ist laut Loredo ja nicht der Fall.

Liest besagter André hier mit? Oder müsste man ihm das Problem nochmal dediziert schildern?

Danke für eure Mühe! Ich kann es gar nicht erwarten das endlich zum Laufen zu kriegen :)

MFG OsiRis

Loredo

Zitat
Hallo Loredo,

ich habe gerade mal die neue Version getestet und WOL funktioniert damit leider nicht.
Ich weiß nicht ob du dir mal meine Version angesehen und getestet hast?

Zum einen muss das wol an Broadcast gesendet werden. In meiner Version habe ich die Ip-Adresse mit des TV mit:

#format ip address to broadcast address
      $address =~ s/\d*$/255/;

geändert.

Zum Anderen funktioniert es nicht wenn die sub PHTV_wake über set PHTV on Befehl aufgerufen wird. Warum auch immer!?
In meiner Version habe ich eine zusätzliches Argument wake in den Code eingefügt um sub PHTV_wake über set PHTV wake separat aufzurufen.

Gruß

Steven






Deine Variante hatte ich kurz überflogen, aber nicht genauer durchgesehen.


Ich kann die Funktion bei mir grundsätzlich nicht testen, da mein Gerät auf die WoL Pakete nicht reagiert.


Ein Magic Packet wird prinzipiell an die physikalische Broadcast IP-Adresse geschickt (255.255.255.255 -> FF FF FF FF FF FF), nicht an die Netzwerk Broadcast IP-Adresse. Das Paket an die Netzwerk Broadcast IP zu senden kann auch funktionieren (das Paket wird im Netzwerk Stack genauso hochgereicht), entspricht aber nicht dem Standard. Im Falle von 255.255.255.255 muss die Nachricht ankommen, denn ansonsten könnte ein solches Gerät überhaupt gar nicht am Netzwerk teilnehmen (es basieren noch andere Protokolle auf dieser Adressierung, die unter TCP/IP liegen).


Es ergibt sich außerdem die Schwierigkeit, dass bei der Adressierung über die Netzwerk Broadcast IP-Adresse diese nicht zwangsläufig .255 am Ende lauten muss. Dies ist nur bei einem klassischem Class C Netz der Fall. Selbiges haben viele Haushalte so, aber das muss eben nicht so sein. Richtig wäre es also dann, dass man neben der MAC-Adresse auch die Broadcast Adresse per Attribut angeben müsste (oder die Netzmaske, aus der sich die Broadcast Adresse berechnen ließe; aber da dann ohnehin etwas eingegeben werden müsste, könnte es auch gleich die Broadcast Adresse sein).
Die Adressierung über 255.255.255.255 ist universell und wie gesagt im Grunde eine logische Ebene tiefer.


------------------


Ich glaube deshalb zunächst einmal nicht, dass an der WoL Geschichte ansich etwas falsch ist, denn es würde bedeuten, dass sich Philipps hier nicht an Netzwerk-Standards gehalten hätte.


Hast du geprüft, ob ein Paket gesendet wird, wenn du ein set on schickst?


Ich hatte mich gegen ein explizites "set wake" entschieden, da ich keinen Sinn darin gesehen habe, denn man muss ohnehin dann noch ein "on" senden. Also habe ich das "on" versucht zu kombinieren. Es sollte demnach ein WoL Paket geschickt werden, wenn das Gerät abwesend ist und sobald es anwesend ist ein "on" hinterher. Ansonsten kann man auch einfach ein zweites "on" hinterher schicken. Das hat den gleichen Effekt wie dein "set wake" und "set on".
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

Zitat von: OsiRis am 03 August 2015, 19:15:45
Liest besagter André hier mit? Oder müsste man ihm das Problem nochmal dediziert schildern?


Ich weiß nicht, ob er in diesem Thread noch mitliest. Ich habe ihn einmal angeschrieben.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

wie genau sehen denn die kommandos aus die du schickst?

was passiert wenn du das auf der kommando zeile probierst? lässt sich das so reproduzieren? oder mit irgendeinem anderen minimal beispiel?

mir fallen drei dinge ein die man nachsehen (und auch verbessern sollte):
- phillips legt inzwischen relativ viel wert darauf das nicht zu viele kommandos gesendet werden. es sollten nicht mehr als 10 kommando pro sekunde für lampen und 1 kommando pro sekunde für gruppen sein.

- bei den 10 kommandos wird jedes einzelne kommando gezählt. das hue modul sendet zur zeit explizit mit jedem kommando ausser off noch ein on mit. -> das verdoppelt die gesendete anzahl. das will ich schon länger ändern und nur noch das senden was vom aktuell bekannten zustand abweicht.

- eventuell kontrolliert die aktuelle firmware diese grenzen genauer.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

fidel

Hallo Loredo,

ich habe wol  mal mit ner android app auf mac +255.255.255.255 abgesetzt. Auch dabei wird der tv "geweckt".
Anschließend habe ich mir mal im modul die ip-adresse bzw.  $address statt $ mac_addr im log wieder geben lassen. Hierbei bekomme ich die ip des tv s und nicht die Broadcast Adresse zurück...

Wenn ich
if ( !defined $address ) { $address = '255.255.255.255' }
in
if ( defined $address ) { $address = '255.255.255.255' }
ändere
bekomme ich auch die 255.255.255.255 im log zurück,
funktionieren tut es dennoch nicht.

Ich habe die Funktion deshalb unterteilt,  um es vorerst besser unterscheiden zu können.
Irgendwie kommt es mir vor als ob es da noch an einer weiteren  Stelle hakt...

Wenn alles funktioniert spricht natürlich nichts dagegen,  dass wol direkt vor dem eigentlichen on zu senden...

Gruß
Steven
Fhem 5.6 auf Cubietruck,CUL,CUL_TCM97001,FritzBox7390,HMLAN,CUL_HM_HM_OU-16LED,CUL_HM_HM_SEC_SC,CUL_HM_HM_LC_SW4,CUL_HM_HM_RT_DN,HUEBridge,HUEDevice,Panstick,Panstamp (binouts,rgddriver mit dht22),PHTV,Yamaha-AVR,Withings,ELV-IPS, etc...

Loredo

#193
Nachdem ich heute ein Firmware Update auf meinem TV machen konnte, habe ich mir das nochmals genauer angesehen und siehe da, WoWLAN funktioniert nun endlich.
Daher konnte ich es jetzt entsprechend austesten, eine verbesserte Version des Moduls habe ich gerade eingecheckt.




Was ambiHUE betrifft:


Das Modul sendet aktuell nur Kommandos, wenn eine (nennenswert große) Farbänderung stattgefunden hat. Die Standard-Frequenz dazu ist etwa 5x pro Sekunde (alle 200ms).
Dies kann über das Attribut ambiHueLatency verändert werden.
Das Kommando pro Gerät sieht dann so aus:



set $dev transitiontime $transitiontime : noUpdate : hsv $h$s$b



Transitiontime ist dabei 3 oder wird anhand des Attributs ambiHueLatency niedriger oder höher gesetzt.


Wer also Probleme bei der Ansteuerung hat, kann ambiHueLatency entsprechend hochsetzen. Möglicherweise funktioniert es dann beim Einsatz vieler HUE-Geräten besser.
Ich kann es selbst gerade nicht testen, weil nach dem Update bei mir die API auf einige Ambilight Kommandos nicht mehr antwortet (toll, Philips...).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

fidel

Hallo Loredo,

funzt bei mir immer noch nicht. :/
Habe es über Lan sowie WLAN unter Änderung der Mac-Adresse probiert.
Funktioniert es bei dir?

Gruß

Steven
Fhem 5.6 auf Cubietruck,CUL,CUL_TCM97001,FritzBox7390,HMLAN,CUL_HM_HM_OU-16LED,CUL_HM_HM_SEC_SC,CUL_HM_HM_LC_SW4,CUL_HM_HM_RT_DN,HUEBridge,HUEDevice,Panstick,Panstamp (binouts,rgddriver mit dht22),PHTV,Yamaha-AVR,Withings,ELV-IPS, etc...