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

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

Vorheriges Thema - Nächstes Thema

DOCa Cola

#120
die ambilight+hue geschichte sieht bei mir ganz ähnlich aus wie bei dennis87 (ähnliche logausgabe). Bisher habe ich dafür Hambisync verwendet, was problemlos läuft.
Ich habe mal ein bischen im 70_PHTV script herumgespielt und mir ein paar logausgaben hier und da gesetzt. Die Hue lampen kann ich problemlos via FHEM setzen.

Das erste was mir aufgefallen ist, dass er den check des HUEDevices garnie erfolgreich durchlaufen hat. Das lag scheinbar an zeile 2389
                                    || $defs{$dev}{READINGS}{reachable}{VAL} ne
                                    "true"

Den check des 'reachable' hab ich einfach auskommentiert. Warum das fehlzuschalgen scheint weis ich nicht. In Fhem steht reachable 1 in meinem HUEDevice

-----

zeile 2582 - Auch wenn er diesen code, erreicht, diese logzeile wird nie ausgegeben (wohl weil einer der werte dort ungültig ist?) ganz habe ich nicht durchschaut wieso. das entsprechende loglevel ist gesetzt. Eine von mir hinzugefügte log eine zeile zuvor kommt problemlos im log an:
                                    Log3 $name, 4,
"PHTV $name: color changed hDiff=$hDiff sDiff=$sDiff bDiff=$bDiff"
                                      if ( $hDiff && $sDiff && $bDiff );


---

hat das ganze irgendwas mit den zeilen beginnend mit 2537 zu tun? dort scheint er niemals hineinzuspringen. das scheint ja auch wichtig für die nachfolgenden (zuvor angesprochene) funktionen zu sein

                                if (
                                    defined(
                                        $hash->{helper}{ambiHueColor}{$side}


DOCa Cola

Also... wer hat denn Ambilight+Hue am laufen? Was muss man denn noch beachten? Wer hat das am laufen? Ich hatte inzwischen immer noch keinen Erfolg. Beim aktivieren scheinen sich die Lampen zwar manchmal einzuschalten, aber sonst geschieht nichts.
Ich kann gern jede art von debug output posten, man muss mir nur sagen was benötigt wird.

Loredo

Ist gefixt und ab morgen per Update abrufbar.


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

habs mir mal aus dem SVN geholt. Funktioniert :)

Mir ist aufgefallen, dass die Farben bei den Hue Lampen jedoch mit dem Modul etwas überzogen ankommen. Es gibt einen Algorithmus den Philips in der Offiziellen Ambilight+Hue app verwendet. Dieser ist auch spezifisch für verschiedene Lampentypen (Das ist einfach die modelid bei den Hue Lampen in FHEM). Der Entwickler von hambisy hat diesen aus der offiziellen App extrahiert. Mit diesem stimmen die Farben der Hue lampen ziemlich genau mit denen des Ambilights überein:
Link (java code): http://pastebin.com/HQkpCrN5
Der Code muss natürlich in Perl nachprogrammiert werden. Meine Perl Erfahrung ist eher unterirdisch
Die zentrale Funktion hier ist convertRGBtoXY_final.
Die Parameter der Funktion lauten
1. float red (0.0 bis 1.0)
2. float green (0.0 bis 1.0)
3. float blue (0.0 bis 1.0)
4. ? - int 0
5. ? - int 0
6. ? - int 0
7. ausgabefeld, dass die brightness als float zurückliefert
8. immersion (saturation) - float
9. brightness - float
10. der modelid string. zB LLC011, LCT001 etc

Rückgabewert ist ein float array für ein X und Y wert. Dann kann dieser dieser via set HUEDevice1 xy an die Lampe geschickt werden. Die Rückgegebene brightness auch.

aufruf in hambisync sieht also so aus findet so statt
Algorithm.convertRGBtoXY_final(
            color.r / 255F,
            color.g / 255F, color.b / 255F, 0, 0, 0,
            outBrightness,
            lamp.getImmersion(), lamp.getBrightness(), model);

justme1968

die aktuelle rgb -> xy routine im hue modul verwendet die offizielen Parameter die phillips für die hie bulbs veröffentlicht hat. die farben sollten für hue bulbs also stimmen. das modul verwendet zur zeit die gleichen parameter auch für living colors lampen da phillips damals noch keine eckdaten für diese veröffentlicht hatte.

ich bin gerade dabei das modul etwas zu überarbeiten und werde auch die living colors lampen einbauen.

welche lampen hast du ?

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

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

DOCa Cola

#125
achso :) irgendwie hab ich das im code nicht gesehen. aber wie ich sagte, mein Perl ist nicht so dolle. Man sagt sich, dass die offiziellen angaben (aus dem sdk) nicht korrekt sein sollen, aber ich schätze, dass sie nicht soweit daneben liegen werden.
Bei mir sind die farben aus irgendeinem Grund völlig anders als die des Ambilights vom TV. Bei einem Schwarz-Weiss bild (doku) strahlen die lampen z.B in  Rot oder Gelb. Bei einem dunklen blauen bild strahlen die lampen in hellem blau. Ich hab livingcolors (LLC001) eine bulb (LCT001) zwei Blooms (LLC011). Das Problem besteht aber auf allen Lampen gleichermaßen.
Via PHTV modul hab ich die Lampen ohne weitere Parameter eingebunden. Ich habe dann auch ein bischen mit der Saturation gespielt, aber das brachte auch nicht das gewünschte ergebnis.
Via hambisync oder offizieller (ios) app stimmen die farben*
Ist es eigentlich möglich, mehrere lampen auf einen bereich festzulegen? z.B dass bei ambiHueLeft zwei lampen einbinden kann?


*Bei den Blooms stimmen die Farben dort allerdings nicht mit dunkelblauen bildern, die werden dann gelb. Das ist aber ein anderes Thema...

justme1968

das mit der abweichung der offiziellen dokumentation scheint zu stimmen :). das aktuelle modul im cvs verwendet noch eine berechnung aus der zeit vor der offiziellen dokumentation. ich hatte vor einiger zeit schon mal versucht diese 1:1 durch die offizielle zu ersetzen und das ergebnis was sehr bescheiden. ich hoffe ich habe inzwischen etwas besseres. aber ich muss die unterscheidung der lampen typen noch einbauen.

wichtig ist es zu wissen das die unterschiedlichen lampen typen nicht die gleichen farben darstellen können. ich glaube leds hinter dem fernseher sind 'echte' rgb leds. so wie die living colors auch. d.h. die können z.b. ein richtiges kräftiges grün darstellen. die hue bulbs haben rot/pastell grün/pastell blau statt rgb und können so ein grün nicht darstellen. egal wie man rechnet. für blau gilt ähnliches.

sind bei dir die farbabweichungen bei dir bei allen lampen identisch?

zum ambihue modul kann ich dir nichts sagen. von mir sind nur die hue module :)

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

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

DOCa Cola

#127
ich hab es jetzt nochmal mit allen Lampen(typen) getestet. Ich habe ein Schwarz-Weiss bild angezeigt und die Lampen leuchten alle in Gelb (mit standard einstellungen). Das Amblight des TV gibt währenddessen weiss aus.
Hier auch nochmal die ausgabe von /1/ambilight/processed

{
"layer1": {
"left": {
"0": {
"r": 21,
"g": 19,
"b": 17
},
"1": {
"r": 31,
"g": 30,
"b": 28
},
"2": {
"r": 76,
"g": 72,
"b": 70
},
"3": {
"r": 91,
"g": 88,
"b": 82
},
"4": {
"r": 74,
"g": 70,
"b": 66
}
},
"top": {
"0": {
"r": 70,
"g": 66,
"b": 62
},
"1": {
"r": 70,
"g": 66,
"b": 62
},
"2": {
"r": 117,
"g": 113,
"b": 106
},
"3": {
"r": 59,
"g": 55,
"b": 53
},
"4": {
"r": 18,
"g": 16,
"b": 16
},
"5": {
"r": 21,
"g": 19,
"b": 19
},
"6": {
"r": 40,
"g": 38,
"b": 37
},
"7": {
"r": 66,
"g": 63,
"b": 60
},
"8": {
"r": 81,
"g": 77,
"b": 73
},
"9": {
"r": 83,
"g": 79,
"b": 75
}
},
"right": {
"0": {
"r": 87,
"g": 83,
"b": 79
},
"1": {
"r": 84,
"g": 81,
"b": 77
},
"2": {
"r": 78,
"g": 74,
"b": 70
},
"3": {
"r": 63,
"g": 60,
"b": 53
},
"4": {
"r": 73,
"g": 68,
"b": 61
}
},
"bottom": {

}
}
}


edit:
hier das ganze auch nochmal mit einem komplett weissem bild getestet:
https://hostr.co/file/XkDZOhDLisCu/IMG_1577.JPG

dirk.msc

Ganz großes Dankeschön! Seit heute funktioniert auch bei mir endlich wieder Ambilight mit Hue über Fhem. Ich hatte es bis zum Sommer einwandfrei laufen, dann habe ich es eine Weile nicht genutzt und dann im Oktober festgestellt, dass es nicht mehr funktioniert. Die neue Version von heute löst das Problem.

Ich kann allerdings bestätigen, dass der Farbabgleich nicht stimmt. Ich habe zwei Blooms und dort ist das Licht z.B. auch genau wie hier beschrieben gelb statt weiß.

Ich habe außerdem noch einen Wunsch: Ich möchte gern Ambilight+Hue automatisch aktivieren, sobald TV und Lampen eingeschaltet sind. Wie lässt sich das denn realisieren?

Viele Grüße
Dirk

Loredo

Das PHTV Modul nimmt lediglich die RGB Werte auf, rechnet diese 1zu1 in den HSB Farbraum um und bildet ggf. einen Mittelwert aus mehreren LEDs bei den Werten Hue, Sättigung und Helligkeit. Sofern definiert werden Sättigung und Helligkeit noch prozentual verringert/erhöht. Anschließend wird der daraus resultierende HSB Wert an das HUE Modul übergeben:




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



Aus PHTV Sicht macht es keinen Sinn hier irgend welche Farbwerte umzurechnen. Ich nehme an so wie André es beschreibt wird das bald im HUE Modul entsprechend abgehandelt.
Was mich dabei aktuell etwas wundert ist, dass die Blooms eigentlich keine Probleme haben sollten den Farbwert 1zu1 zu übernehmen, da sie die gleiche Technologie verwenden wie der TV. Vielleicht liegt es an unserer leicht unterschiedlichen Auffassung zwischen HSB und HSV Farbräumen, André? Siehe PHTV_rgb2hsb().
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

Ich möchte nochmal unterstreichen, dass das Problem nicht nur auf den Blooms, sondern auch auf meiner "normalen" älteren Living Colors sowie meiner Bulb auftritt.
Wie der genaue Ablauf im Hintergrund aussieht, weiss ich nicht. Offensichtlich ist aber, dass an einer Stelle etwas schiefläuft.

Bei denjenigen, den das ganze mit der neusten FHEM+PHTV Modul revision problemlos läuft: Verwendet ihr spezielle Saturation werte für die Lampen?

av3nger

Ich nutze seit heute ebenfalls die AmbiHue-Funktion von PHTV. Tolle Arbeit! Deutlich schneller als via Android APP - und schont meinen Akku.

Bei mir kommen zwei Light Strips zum Einsatz und beobachte ebenfalls das Verhalten, dass die Light Strip-LEDs gelblich sind, wenn das Ambilight eigentlich weiß ausgibt.

AHA1805

Hallo zusammen,

ich hab das Modul zwar noch nicht getestet,
werde es aber bei Gelegenheit demnächst ausprobieren.
Die passende Hardware wurde kürzlich geliefert
AHA 1805 RIP 29.08.2016 --> RUHE IN FRIEDEN
In Gedanken Bei dir HANNES
Dein Bruder Gerd (Inputsammler) Vermisst dich Hannes (AHA1805)

dirk.msc

Seit dem letzten Update klappt es schon wieder nicht mehr :-(

AmbiHue bleibt immer auf off stehen und lässt sich nicht mehr einschalten und im Log stehen viele Fehlermeldungen:

2014.12.09 20:50:32 1: PERL WARNING: Use of uninitialized value $channel_name in substitution (s///) at ./FHEM/70_PHTV.pm line 1784.
2014.12.09 20:50:32 1: PERL WARNING: Use of uninitialized value $channel_name in substitution (s///) at ./FHEM/70_PHTV.pm line 1785.
2014.12.09 20:50:33 3: PHTV PhilipsTV: API command 'sources/current' not supported by device.
2014.12.09 20:50:42 3: PHTV PhilipsTV: API command 'channels/current' not supported by device.
2014.12.09 20:50:42 1: PERL WARNING: Argument "" isn't numeric in numeric ne (!=) at ./FHEM/70_PHTV.pm line 318.
2014.12.09 20:50:42 1: PERL WARNING: Argument "Das_Erste_HD" isn't numeric in numeric ne (!=) at ./FHEM/70_PHTV.pm line 318.
...
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/sat_tv' not supported by device.
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/tv_radio' not supported by device.
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/sat_all' not supported by device.
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/tv_all' not supported by device.
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/tv_favourite' not supported by device.
2014.12.09 20:50:51 3: PHTV PhilipsTV: API command 'channellists/sat_favourite' not supported by device.
2014.12.09 20:50:51 3: PHTV PhilipsTV: API command 'channellists/tv_tv' not supported by device.
2014.12.09 20:50:51 3: PHTV PhilipsTV: API command 'channellists/sat_radio' not supported by device.
2014.12.09 20:50:55 2: PHTV set PhilipsTV ambiHue on
2014.12.09 20:50:57 3: PHTV PhilipsTV: API command 'ambilight/processed' not supported by device.

Loredo

Zitat von: dirk.msc am 09 Dezember 2014, 22:33:11
2014.12.09 20:50:33 3: PHTV PhilipsTV: API command 'sources/current' not supported by device.
2014.12.09 20:50:42 3: PHTV PhilipsTV: API command 'channels/current' not supported by device.
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/sat_tv' not supported by device.
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/tv_radio' not supported by device.
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/sat_all' not supported by device.
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/tv_all' not supported by device.
2014.12.09 20:50:50 3: PHTV PhilipsTV: API command 'channellists/tv_favourite' not supported by device.
2014.12.09 20:50:51 3: PHTV PhilipsTV: API command 'channellists/sat_favourite' not supported by device.
2014.12.09 20:50:51 3: PHTV PhilipsTV: API command 'channellists/tv_tv' not supported by device.
2014.12.09 20:50:51 3: PHTV PhilipsTV: API command 'channellists/sat_radio' not supported by device.
2014.12.09 20:50:57 3: PHTV PhilipsTV: API command 'ambilight/processed' not supported by device.


Diese Meldungen sagen, dass dein Fernseher nicht die erwartete bzw. keine Rückmeldung auf diese Kommandos schickt. Um zu vermeiden, dass nicht funktionierende Kommandos unnützerweise an den TV geschickt werden und dessen Performance noch stärker belasten, werden die als fehlerhaft arbeitenden Kommandos zwischengespeichert und nicht mehr zugelassen bzw. automatisch verwendet.
Generell wird dabei so vorgegangen, dass eine Antwort auf das Kommando audio/volume dazu genutzt wird zu erkennen, ob der TV betriebsbereit ist. Alle weiteren Kommandos wie das Abfragen der Kanalliste etc werden erst dann geschickt. Dies scheint bei dir auch der Fall zu sein. Es wird aber eben erwartet, dass der TV, weil er ja online ist, dann auch eine Antwort darauf schickt. Tut er das nicht, verhält er sich eben falsch oder hat sonst irgend einen Fehler und das Modul verhindert dann, dass der TV noch mehr mit Anfragen überschüttet wird, die er dann ja offenbar nicht verarbeiten kann (oder aus welchem Grund auch immer er dann keine Antwort mehr liefert).


Bei gesetzten Attribut verbose=5 siehst du im Logfile, was genau der TV liefert (oder eben nicht).
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