Broadlink platform problem

Hi,

I’ve Home assistant on a arch linux, and i’m having troubles to add a Broadlink mini 3 to it.

I’d followed this guide: https://www.home-assistant.io/integrations/broadlink.

This is my configuration.yaml:

remote:
  - platform: broadlink
    host: !secret miniSalon_ip
    mac: !secret miniSalon_mac
    name: miniSalon

I’ve triple check the ip and mac in my dsnmasq leasses, and ip is responding to ping.

When I reboot home assistant this is the log warning:

2020-01-20 12:31:04 WARNING (MainThread) [homeassistant.components.remote] Platform broadlink not ready yet. Retrying in 180 seconds.
2020-01-20 12:34:05 WARNING (MainThread) [homeassistant.components.remote] Platform broadlink not ready yet. Retrying in 180 seconds.
2020-01-20 12:37:06 WARNING (MainThread) [homeassistant.components.remote] Platform broadlink not ready yet. Retrying in 180 seconds.
2020-01-20 12:40:07 WARNING (MainThread) [homeassistant.components.remote] Platform broadlink not ready yet. Retrying in 180 seconds.
2020-01-20 12:43:08 WARNING (MainThread) [homeassistant.components.remote] Platform broadlink not ready yet. Retrying in 180 seconds.

I tried

switch:
  - platform: broadlink
    host: !secret miniSalon_ip
    mac: !secret miniSalon_mac

and warning log message disapear, but i can’t see the switch in home assistant.

Any help?

Thx to all.

Have you tried the configuration without the !secret to see if it works?

Hi code, thx for your answer. Yes i did, same problem.

Odd. According to the docs, is your MAC address in ‘AA:BB:CC:DD:EE:FF’ format (along with the quotes)?

With out !secret I tried:

remote:
  - platform: broadlink
    host: 192.168.1.53
    mac: 24:df:a7:7a:5d:5f
    name: miniSalon
remote:
  - platform: broadlink
    host: '192.168.1.53'
    mac: '24:df:a7:7a:5d:5f'
    name: miniSalon

and

remote:
  - platform: broadlink
    host: "192.168.1.53"
    mac: "24:df:a7:7a:5d:5f"
    name: miniSalon
cat /var/lib/misc/dnsmasq.leases
[REMOVED]
1579556059 24:df:a7:7a:5d:5f 192.168.1.53 * *
[REMOVED]
ping 192.168.1.53
PING 192.168.1.53 (192.168.1.53) 56(84) bytes of data.
64 bytes from 192.168.1.53: icmp_seq=1 ttl=255 time=2.93 ms
64 bytes from 192.168.1.53: icmp_seq=2 ttl=255 time=11.9 ms
64 bytes from 192.168.1.53: icmp_seq=3 ttl=255 time=2.53 ms
64 bytes from 192.168.1.53: icmp_seq=4 ttl=255 time=16.7 ms
64 bytes from 192.168.1.53: icmp_seq=5 ttl=255 time=15.2 ms
^C
--- 192.168.1.53 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 2.534/9.859/16.687/6.023 ms

But always the same warning

Thx

That’s really weird. Can you access the device in the Broadlink e-Control app? Is your HA instance on a separate VLAN? Are you pinging it from the HA instance?

I’m wondering if there’s something network-wise that’s preventing HA from seeing it. I have this issue from time to time when crossing VLANs, but it almost always clears itself up after restarting HA.

Ok, i think i figure it out what is happening. I’ve A transparent proxy who redirects port 80 requests to 8080. May broadlink use port 80?

Yup. Broadlink (AFAIK) uses port 80. So, if your proxy is translating port 80 to port 8080, that would explain the issue.

Source: https://blog.ipsumdomus.com/broadlink-smart-home-devices-complete-protocol-hack-bc0b4b397af1

Ok, it’s resolve, I just had to reboot squid (transparent proxy) and now i have got the broadlink remote device available. Thx code and VolkerS.

2 Likes

Sundenly it stops to work and platform is not aviable again, and I did nothing. I’ve stop squid and erase firewall rules, so port 80 is not longer translated to 8080, but the same warnig remains in my HA logs.

Broadlink remote is working on broadlink app and I’ve not separated on difererents instances my HA network and the rest, this is some thing in my todo list (So no vlans).

Can any one with nmap installed post the output of this command?

nmap -p80 broadlink_ip

This’s my output

[REMOVED]$ nmap -p80 192.168.1.53
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-21 17:01 CET
Nmap scan report for 192.168.1.53
Host is up (0.0043s latency).

PORT   STATE  SERVICE
80/tcp closed http

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

EDIT:

$ tshark -f "host 192.168.1.53"
Capturing on 'enp6s0'
    1 0.000000000 Giga-Byt_24:16:7f → Hangzhou_7a:5d:5f ARP 42 Who has 192.168.1.53? Tell 192.168.1.1
    2 0.003200212 Hangzhou_7a:5d:5f → Giga-Byt_24:16:7f ARP 60 192.168.1.53 is at 24:df:a7:7a:5d:5f
    3 19.273188117 192.168.1.53 → 52.53.122.173 UDP 198 16385 → 1812 Len=156
    4 19.445009080 52.53.122.173 → 192.168.1.53 UDP 182 1812 → 16385 Len=140
    5 43.729543756 192.168.1.53 → 52.53.122.173 UDP 198 16385 → 1812 Len=156
    6 43.901590306 52.53.122.173 → 192.168.1.53 UDP 182 1812 → 16385 Len=140
    7 46.667222770  192.168.1.1 → 192.168.1.53 UDP 194 35594 → 80 Len=152
    8 46.707500293 192.168.1.53 → 192.168.1.1  UDP 98 80 → 35594 Len=56

Wireshark show packets between 192.168.1.1 (Hass) and 192.168.1.53(mini 3) but broadlink platform is still not ready.

Do you know any zwave infra red remote device? Because I give up

There is a problem with the new broadlink protocol, if python.broadlink discovers your device as 0x5f36:

./broadlink_discovery
Discovering ...
###########################################
Unknown
# broadlink_cli --type 0x5f36 --host 192.168.1.53 --mac 5f5d7aa7df24
Device file data (for use with --device @filename in broadlink_cli):
0x5f36 192.168.1.53 5f5d7aa7df24

This device won’t learn new commands. There is a gritub issue (#537) that explains the problem.

On the other hand, if you connect your mini 3 with the new broadlink app, it will never connect to HA (That was my problem). You must to reset it and configure it with the old e-Connect or IHC app.

if you connect your mini 3 with the new broadlink app, it will never connect to HA

That’s a really bad news. I tried to reset it and to connect to e-Connect without success.
Is this something on which someone is working or it will be impossible to use with HA?

Try IHC app, e-Connect doesn’t work to me, but IHC does. Anyway if broadlink_discovery discover it as type 0x5f36 there is nothing to do right now, it doesn’t work with HA.