search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 499 forks source link

Philips Ambilight+Hue won´t recognize Conbee II as Hue Bridge anymore #3088

Closed Gizmo-Ger closed 4 years ago

Gizmo-Ger commented 4 years ago

I was using ConbeeII as a Hue Bridge replacement with some IKEA light bulbs. Everything connected nicely with Ambilight+Hue function of my Philips TV. Since the last update of Phoscon v2.05.79 in combination with a recent firmware update of the TV it doesn´t work anymore. Searching for Hue bridge on the TV it only shows two dots where it used to show Phoscon-GW twice. I´ve tried to reset the gateway but that didn´t help.

Mimiix commented 4 years ago

Hi! When did this break? After the .79 update? If you can try: Install a older version and check if it works again. That would help in determining where the issue is.

Gizmo-Ger commented 4 years ago

Yes, it broke after the .79 update. Will revert back to .78 later tonight.

Mimiix commented 4 years ago

Let me know after :)

ebaauw commented 4 years ago

Hue recently updated their v2 bridge firmware, now API v1.38.0. I would suspect the updated TV firmware to require (look for) this version of the Hue bridge. Do the release notes of the TV firmware mention anything on this?

Gizmo-Ger commented 4 years ago

In fact they did mention it: Changelog TPM171E_107.001.132.000 – Date: 2020/06/29

Android Oreo 8.0.0 based software Improvements for Ambilight Hue Improvements for WiFi connection issue Improvements for system stability Improvements for TV shop mode Improvements for Bluetooth RC firmware upgrade Improvements for EPG performance Fix for ARD massive stuttering Fix for deformed image content during KODI/VLC playback Fix for stretched picture content during USB/DLNA playback

In this case the improvement means trouble.

Fun fact: It recognizes something (at least the two dots in the menu) but the space where it used to say "Phoscon-GW" is empty.

ebaauw commented 4 years ago

The Hue bridge firmware was around June 8th, see https://www.philips-hue.com/en-us/support/release-notes/bridge, so that could be it. I fear they might actually have moved from the regular Hue API to the Hue Entertainment API. In that case, it’ll work only with the genuine Hue bridge, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2582#issuecomment-599130593.

Gizmo-Ger commented 4 years ago

I finally had the time to test. Downgrade back to .78 wasn´t successfull. Still won´t be recognized by TV. So they really switched to the Entertainment API. Esp. since I also bought a HUE bridge just to test and with that it works. Bummers. Anyhow, I can also report the my Hue GO and some random Müller tint work nicely with Ambilight+Hue.

Mimiix commented 4 years ago

In that case, we can't do anything to fix it :( Can we close this issue?

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] commented 4 years ago

As there hasn't been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it isn't solved, request to get this opened again.

labaland commented 4 years ago

I just tested this with conbee2 and latest deconz and it works for me on first try! now i can unplug my hue hub!! i can see all my hue/ikea lights but i have only connected my hue ledstrip to amblight

Z-Rick84 commented 3 years ago

@Gizmo-Ger and @labaland

Would you like to share your hardware-configuration in this thread with me? Thanks! https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3461

labaland commented 3 years ago

@Gizmo-Ger and @labaland

Would you like to share your hardware-configuration in this thread with me? Thanks!

3461

Synology nas ds916+

me1337me commented 3 years ago

@lalamber

I just tested this with conbee2 and latest deconz and it works for me on first try! now i can unplug my hue hub!! i can see all my hue/ikea lights but i have only connected my hue ledstrip to amblight

May I kindly ask whether you are using home assistant? And what is your port configuration for deconz? I'm not able to find a bridge with my philips TV 65OLED803 FW 107.001.132.000 (also tried older ones) deconz 2.5.88

Thanks a lot!

labaland commented 3 years ago

I use latest deconz with standard port settings ports:

labaland commented 3 years ago

Now after i had to reinstall deconz tv no longer finds conbee2 :(

unstressable commented 1 year ago

same here. Can't finde Conbee2 over Phoscon with my Ambilight TV :(

The following Philips TV Specs-Site writes:

Ambilight AL 3 + Hue (mit Entertainment API)

So that means, that I will never be able to connect with phoscon actually? Doesn't matter what firmware I use?

https://toengel.net/philipsblog/2019/07/19/philips-2019-die-oled754-tvs-mit-saphi-und-hdr10-dolby-vision-dolby-atmos-und-alexa/

ebaauw commented 1 year ago

Probably need to update the API and/or software version with the values reported by the latest Hue bridge firmware. Could also be that they moved to Hue APIv2, to HTTPS, and/or ditched UPnP discovery in favour of mDNS. Would help if someone with a ambilight TV could sniff the IP network and check how it’s trying to find and connect to the Hue bridge.

ottelo9 commented 1 year ago

I can help. What I have to do? Do I have to use Wireshark for this ?

ebaauw commented 1 year ago

Yes. Ideally, you'd be able to sniff the traffic at the TV.

Nastras commented 1 year ago

@ottelo9 Are there any new findings here yet? I am currently facing the same problem.

ottelo9 commented 1 year ago

@Nastras Currently no. I haven't had time for that yet.

Nastras commented 1 year ago

I am not familiar with Wireshark so I am not sure if it is the right data @ebaauw . I started the search for the Hue Bridge on the TV and searched in Wireshark for the iP of the TV and found these two MDNS requests:

1 0.000000 192.168.178.45 224.0.0.251 MDNS 587 Standard query response 0x0000 TXT, cache flush PTR _androidtvremote2._tcp.local PTR Fernseher im Wohnzimmer._androidtvremote2._tcp.local SRV, cache flush 0 0 6466 Android.local PTR, cache flush Android.local PTR, cache flush Android.local A, cache flush 192.168.178.45 AAAA, cache flush fe80::72af:24ff:fe11:e8ab TXT, cache flush PTR _philipstv_s_rpc._tcp.local PTR 6_Fernseher im Wohnzimmer._philipstv_s_rpc._tcp.local SRV, cache flush 0 0 1926 Android.local NSEC, cache flush Fernseher im Wohnzimmer._androidtvremote2._tcp.local NSEC, cache flush 45.178.168.192.in-addr.arpa NSEC, cache flush B.A.8.E.1.1.E.F.F.F.4.2.F.A.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa NSEC, cache flush Android.local NSEC, cache flush 6_Fernseher im Wohnzimmer._philipstv_s_rpc._tcp.local

2 0.000002 fe80::72af:24ff:fe11:e8ab ff02::fb MDNS 607 Standard query response 0x0000 TXT, cache flush PTR _androidtvremote2._tcp.local PTR Fernseher im Wohnzimmer._androidtvremote2._tcp.local SRV, cache flush 0 0 6466 Android.local PTR, cache flush Android.local PTR, cache flush Android.local A, cache flush 192.168.178.45 AAAA, cache flush fe80::72af:24ff:fe11:e8ab TXT, cache flush PTR _philipstv_s_rpc._tcp.local PTR 6_Fernseher im Wohnzimmer._philipstv_s_rpc._tcp.local SRV, cache flush 0 0 1926 Android.local NSEC, cache flush Fernseher im Wohnzimmer._androidtvremote2._tcp.local NSEC, cache flush 45.178.168.192.in-addr.arpa NSEC, cache flush B.A.8.E.1.1.E.F.F.F.4.2.F.A.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa NSEC, cache flush Android.local NSEC, cache flush 6_Fernseher im Wohnzimmer._philipstv_s_rpc._tcp.local

ebaauw commented 1 year ago

These look like the IPv4 and IPv6 mDNS responses by the TV to an mDNS query by some other devices. We want to see the request that the TV sends to find the “Hue bridge”. Historically, the Hue bridge uses UPnP for (local) discovery, but they are changing that to mDNS. deCONZ only uses UPnP.

unstressable commented 1 year ago

These look like the IPv4 and IPv6 mDNS responses by the TV to an mDNS query by some other devices. We want to see the request that the TV sends to find the “Hue bridge”. Historically, the Hue bridge uses UPnP for (local) discovery, but they are changing that to mDNS. deCONZ only uses UPnP.

This seem to be a good information. So all we need is an upgrade from phoscon to use mDNS?

ebaauw commented 1 year ago

So all we need is an upgrade from phoscon to use mDNS?

Please, NO! If it ain’t broke, don’t fix it. Phoscon and other API client are perfectly able to discover the deCONZ gateway.

Maybe the gateway needs to advertise its presence over MDNS, in addition to over UPnP. But before doing so, I want confirmation that the Ambilight TV actually tries to discover the “Hue bridge” over mDNS. In the past, Ambilight support broke because the TV expected a certain firmware and/or API version by the “Hue bridge”, and we were able to restore deCONZ support by changing these to those of the latest Hue bridge firmware.

So, before doing anything, we need to know how the Ambilight TV now finds the “Hue bridge”, and what it considers to be a valid “Hue bridge”, as requested above,

Nastras commented 1 year ago

I'm trying it out again right now. I have now started the search several times on the TV and looked via Wireshark. This query appears again and again after starting the search: I could not see a UPnP query so far or other mdns query.

189 16.795813 192.168.178.45 224.0.0.250 UDP 85 10101 → 10101 Len=43 Frame 189: 85 bytes on wire (680 bits), 85 bytes captured (680 bits) on interface en0, id 0 Section number: 1 Interface id: 0 (en0) Encapsulation type: Ethernet (1) Arrival Time: Apr 5, 2023 13:19:46.019074000 CEST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1680693586.019074000 seconds [Time delta from previous captured frame: 0.923325000 seconds] [Time delta from previous displayed frame: 0.923325000 seconds] [Time since reference or first frame: 16.795813000 seconds] Frame Number: 189 Frame Length: 85 bytes (680 bits) Capture Length: 85 bytes (680 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:udp:data] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: TPVision_11:e8:ab (70:af:24:11:e8:ab), Dst: IPv4mcast_fa (01:00:5e:00:00:fa) Destination: IPv4mcast_fa (01:00:5e:00:00:fa) Address: IPv4mcast_fa (01:00:5e:00:00:fa) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: TPVision_11:e8:ab (70:af:24:11:e8:ab) Address: TPVision_11:e8:ab (70:af:24:11:e8:ab) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.178.45, Dst: 224.0.0.250 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 71 Identification: 0x1d4f (7503)

  1. .... = Flags: 0x2, Don't fragment ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 1 Protocol: UDP (17) Header Checksum: 0x0887 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.178.45 Destination Address: 224.0.0.250 User Datagram Protocol, Src Port: 10101, Dst Port: 10101 Source Port: 10101 Destination Port: 10101 Length: 51 Checksum: 0x2dd8 [unverified] [Checksum Status: Unverified] [Stream index: 32] [Timestamps] UDP payload (43 bytes) Data (43 bytes) Data: 0a2031344539414333303234423538444335363932353030344144393244353939341001… [Length: 43]
ebaauw commented 1 year ago

Nether the multicast address nor the port number matches a mDNS query.

You’d expect an outgoing request to 255.0.0.251:5353 for mDNS or to 239.255.255.250:1900 for UPnP.

Nastras commented 1 year ago

Next Try 😅

77 7.681611 192.168.178.45 224.0.0.251 MDNS 587 Standard query response 0x0000 TXT, cache flush PTR _androidtvremote2._tcp.local PTR Fernseher im Wohnzimmer._androidtvremote2._tcp.local SRV, cache flush 0 0 6466 Android.local PTR, cache flush Android.local PTR, cache flush Android.local A, cache flush 192.168.178.45 AAAA, cache flush fe80::72af:24ff:fe11:e8ab TXT, cache flush PTR _philipstv_s_rpc._tcp.local PTR 6_Fernseher im Wohnzimmer._philipstv_s_rpc._tcp.local SRV, cache flush 0 0 1926 Android.local NSEC, cache flush Fernseher im Wohnzimmer._androidtvremote2._tcp.local NSEC, cache flush 45.178.168.192.in-addr.arpa NSEC, cache flush B.A.8.E.1.1.E.F.F.F.4.2.F.A.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa NSEC, cache flush Android.local NSEC, cache flush 6_Fernseher im Wohnzimmer._philipstv_s_rpc._tcp.local

Frame 77: 587 bytes on wire (4696 bits), 587 bytes captured (4696 bits) on interface en0, id 0 Section number: 1 Interface id: 0 (en0) Interface name: en0 Interface description: Wi-Fi Encapsulation type: Ethernet (1) Arrival Time: Apr 5, 2023 13:57:48.938792000 CEST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1680695868.938792000 seconds [Time delta from previous captured frame: 0.512053000 seconds] [Time delta from previous displayed frame: 0.512053000 seconds] [Time since reference or first frame: 7.681611000 seconds] Frame Number: 77 Frame Length: 587 bytes (4696 bits) Capture Length: 587 bytes (4696 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:udp:mdns] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: TPVision_11:e8:ab (70:af:24:11:e8:ab), Dst: IPv4mcast_fb (01:00:5e:00:00:fb) Destination: IPv4mcast_fb (01:00:5e:00:00:fb) Address: IPv4mcast_fb (01:00:5e:00:00:fb) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: TPVision_11:e8:ab (70:af:24:11:e8:ab) Address: TPVision_11:e8:ab (70:af:24:11:e8:ab) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.178.45, Dst: 224.0.0.251 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 573 Identification: 0x7777 (30583)

  1. .... = Flags: 0x2, Don't fragment 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 255 Protocol: UDP (17) Header Checksum: 0xae66 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.178.45 Destination Address: 224.0.0.251 User Datagram Protocol, Src Port: 5353, Dst Port: 5353 Source Port: 5353 Destination Port: 5353 Length: 553 Checksum: 0xf8cf [unverified] [Checksum Status: Unverified] [Stream index: 21] [Timestamps] UDP payload (545 bytes) Multicast Domain Name System (response) Transaction ID: 0x0000 Flags: 0x8400 Standard query response, No error Questions: 0 Answer RRs: 12 Authority RRs: 0 Additional RRs: 5 Answers Additional records [Retransmitted response. Original response in: 53] [Retransmission: True]
ebaauw commented 1 year ago

That again is the mDNS response of the TV to some other device discovering the TV.

The TV would look for _hue.tcp.local on mDNS.

Nastras commented 1 year ago

Erik if this is still not the right thing to do, do I have the ability to send you the Wireshark log in a secure way?

For me, this is all a huge mess 😕

ebaauw commented 1 year ago

You can PM me on Discord, attaching the output file. Are you capturing on your router, or on your PC? If you PC, it needs to be on the same subnet as the TV and the Hue bridge/deCONZ gateway.

Nastras commented 1 year ago

do it

me1337me commented 1 year ago

@Nastras and @ebaauw Thanks for your effort finding a solution!

ebaauw commented 1 year ago

From what we can tell from @Nastras logs, the TV only seems to find the Hue bridge through the meethue portal. Nothing we can do about that. It sends out a UPnP query, but doesn’t seem to get a response from deCONZ.