Allow setting inverter IP via config because link-local addresses like `169.254.12.3` do not work on Linux

[wimleers]

Thanks for the PR!

But … I very much tried to make this plug-and-play. This should not be necessary.

Is your inverter not accessible via 169.254.12.3?

[sweh]

Unfortunately not:

$ ping 69.254.12.3
PING 69.254.12.3 (69.254.12.3): 56 data bytes
^C--- 69.254.12.3 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

Its accessible via 10.0.1.122:

$ ping SMA3009870204.local
PING sma3009870204.local (10.0.1.122): 56 data bytes
64 bytes from 10.0.1.122: icmp_seq=0 ttl=64 time=1,959 ms
64 bytes from 10.0.1.122: icmp_seq=1 ttl=64 time=0,545 ms
^C--- sma3009870204.local ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0,545/1,252/1,959/0,707 ms

[wimleers]

You did:

$ ping 69.254.12.3

You forgot the leading 1 😅

[wimleers]

Quoting https://github.com/wimleers/homebridge-sma-home-manager/issues/2#issuecomment-1452697140:

I really want to avoid address configuration.

Can you install https://apps.apple.com/be/app/discovery-dns-sd-browser/id305441017?l=nl, tap on _http._tcp and see if there’s SMA stuff there?

→ I may be able to add mDNS ("Bonjour") powered discovery to automatically find the IP if it's not 169.254.12.3. Your ping SMA3009870204.local proves that that should work. But I'd like to get a screenshot from you that shows the details of the advertised service, so I can discover it automatically!

[sweh]

You did:

$ ping 69.254.12.3

You forgot the leading 1 😅

Oh you are right, but the leading 1 doesn't make it besser: :-)

ping 69.254.12.31
PING 69.254.12.31 (69.254.12.31): 56 data bytes
^C--- 69.254.12.31 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

[Scream4Life]

Now the leading 1 is a closing 1 in your ping call🤪

[sweh]

I found two set

Quoting #2 (comment):

I really want to avoid address configuration. Can you install apps.apple.com/be/app/discovery-dns-sd-browser/id305441017?l=nl, tap on _http._tcp and see if there’s SMA stuff there?

→ I may be able to add mDNS ("Bonjour") powered discovery to automatically find the IP if it's not 169.254.12.3. Your ping SMA3009870204.local proves that that should work. But I'd like to get a screenshot from you that shows the details of the advertised service, so I can discover it automatically!

I found two services:

[Scream4Life]

But in the end I would vote for a optional variable too. My solution (changing the index.js) is not very robust against plugin-updates 😕

[sweh]

Now the leading 1 is a closing 1 in your ping call🤪

Oh man, luckily it's Friday. I wasn't expecting this, but I can ping that IP:

$ ping 169.254.12.3
PING 169.254.12.3 (169.254.12.3): 56 data bytes
64 bytes from 169.254.12.3: icmp_seq=0 ttl=64 time=2,962 ms
64 bytes from 169.254.12.3: icmp_seq=1 ttl=64 time=2,099 ms

[sweh]

Now the leading 1 is a closing 1 in your ping call🤪

Oh man, luckily it's Friday. I wasn't expecting this, but I can ping that IP:

$ ping 169.254.12.3
PING 169.254.12.3 (169.254.12.3): 56 data bytes
64 bytes from 169.254.12.3: icmp_seq=0 ttl=64 time=2,962 ms
64 bytes from 169.254.12.3: icmp_seq=1 ttl=64 time=2,099 ms

But only from my MacBook, not from my ubuntu machine, that's in the same network and hosting Homebridge:

$ ping 169.254.12.3
PING 169.254.12.3 (169.254.12.3) 56(84) bytes of data.
^C
--- 169.254.12.3 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5125ms

while the SMA-hostname works:

$ ping SMA3009870204.local
PING SMA3009870204.local (10.0.1.122) 56(84) bytes of data.
64 bytes from SMA-1285097092.wehrmann.local (10.0.1.122): icmp_seq=1 ttl=64 time=0.442 ms
64 bytes from SMA-1285097092.wehrmann.local (10.0.1.122): icmp_seq=2 ttl=64 time=0.451 ms
64 bytes from SMA-1285097092.wehrmann.local (10.0.1.122): icmp_seq=3 ttl=64 time=0.450 ms

[wimleers]

Wow! There must be some Linux-specific thing about link-local addresses then! https://en.wikipedia.org/wiki/Link-local_address 🤯

[wimleers]

You don't have VLANs set up by any chance?

[wimleers]

Also, what are the IP addresses of your Ubuntu machine and your MacBook?

[sweh]

Also, what are the IP addresses of your Ubuntu machine and your MacBook?

They are all in the 10.0.1.0 range:

Ubuntu Server: 10.0.1.2 MacBook: 10.0.1.158 (wifi) and 10.0.1.4 (LAN)

[sweh]

But in the end I would vote for a optional variable too. My solution (changing the index.js) is not very robust against plugin-updates 😕

I would vote for it, too. As the default for the ip address is the one that should work for most users, it should be save to add a hint that one should only change the ip if its not working.

[wimleers]

I'd rather write more code to discover this automatically than making this configurable 😅

You both are comfortable with IP addresses, and know how to find them. Buy many people don't!

I want this to be usable even for them 😊

[wimleers]

I'd rather write more code to discover this automatically than making this configurable 😅

You both are comfortable with IP addresses, and know how to find them. Buy many people don't!

I want this to be usable even for them 😊

Did some research.

Linux

Per https://networkengineering.stackexchange.com/a/35965, it seems that https://www.rfc-editor.org/rfc/rfc3927 is not implemented on Linux 🤯 https://www.kernel.org/doc/rfc-linux.html seems to confirm this?

OTOH, AFAICT RFC3927 is more about .local addresses resolving, not about 169.* IP addresses…

https://en.wikiversity.org/wiki/Link-local_address/Linux suggests that avahi must be installed for this to work. That page links to https://manpages.debian.org/bullseye/avahi-autoipd/avahi-autoipd.8.en.html, which seems to have the clearest docs I could find:

avahi-autoipd implements IPv4LL, "Dynamic Configuration of IPv4 Link-Local Addresses" (IETF RFC3927), a protocol for automatic IP address configuration from the link-local 169.254.0.0/16 range without the need for a central server. It is primarily intended to be used in ad-hoc networks which lack a DHCP server.

IPv4LL is part of the Zeroconf stack.

[…]

To allow communication between hosts that have only an IPv4LL address assigned and hosts that only have a routable IP address assigned you may add the following routes to both network configurations:

route add -net 169.254.0.0 netmask 255.255.0.0 dev eth0 metric 99

route add default dev eth0 metric 99

See http://developer.apple.com/qa/qa2004/qa1357.html for more information.

That's right — a Linux package's docs referring to Apple docs 🤪

mDNS discovery

• https://www.npmjs.com/package/multicast-dns → massive adoption, well maintained?
• https://www.npmjs.com/package/bonjour → last release 7 years ago 👎
• https://www.npmjs.com/package/mdns → little use, barely maintained?

Question

Could you please try the following on Linux (both on Ubuntu and on Raspberry PI):

route add -net 169.254.0.0 netmask 255.255.0.0 dev eth0 metric 99 route add default dev eth0 metric 99

and then:

ping 169.254.12.3

? 🙏

[sweh]

After adding the route, I can ping the inverter:

$ ping 169.254.12.3
PING 169.254.12.3 (169.254.12.3) 56(84) bytes of data.
64 bytes from 169.254.12.3: icmp_seq=1 ttl=64 time=4.36 ms
64 bytes from 169.254.12.3: icmp_seq=2 ttl=64 time=3.64 ms

But unfortunately homebridge can not connect:

[3/7/2023, 8:27:51 AM] [homebridge-sma-home-manager] Loaded homebridge-sma-home-manager v1.0.1 child bridge successfully
[3/7/2023, 8:27:51 AM] Loaded 0 cached accessories from cachedAccessories.0E9CB6B1BD4C.
Error: connect ECONNREFUSED 169.254.12.3:502
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1487:16)

If I try to telnet to that port I indeed get an error:

telnet 169.254.12.3 502
Trying 169.254.12.3...
telnet: Unable to connect to remote host: Connection refused

When I opened the IP in the browser, I found out that the IP is assigned to the SMA EV Charger 22, not the Sunny Tripower. So it looks like the 169.254.12.3 is not guaranteed to point to the Inverter, right?

[wimleers]

Woah, that is one massive f-up by SMA! Quoting the README:

Removed inverter IP address configuration in favor of zero config thanks to a link-local address instead.

👇 "Establishing a Connection via Ethernet in the local network" page in:

• SMA solar inverter manual: https://manuals.sma.de/SBSxx-10/en-US/1685190283.html
• SMA EV charger manual's page: https://manuals.sma.de/EVCxx10/en-US/1687859467.html

Alright, I think it's at this point safe to conclude that 169.254.12.3 should not be used as a zero configuration method to connect with the SMA inverter, for at least 2 reasons:

1. Linux does not support link-local addresses natively 🤯
2. SMA may have its EV charger use the same link-local address ⇒ any installation with >1 SMA product besides the Home Manager (so: solar inverter, EV charger and presumably battery inverter too?!) will all use the same address 🤯

⇒ It seems SMA intends 169.254.12.3 to be used only when connected directly to the device via an ethernet cable, not when it's connected to a LAN; SMA seems to intend SMA[serial number].local is the canonical connection mechanism when on a LAN.

That means the next question becomes: how can we discover this reliably, and correctly distinguish between:

1. solar inverter
2. battery inverter
3. EV charger

Based on the mDNS discovery you shared 4 days ago at https://github.com/wimleers/homebridge-sma-home-manager/pull/3#issuecomment-1453555009:

1. the Website for SMA-Inverter: SMA[serial number] advertisement is for the solar inverter → identifiable based on the string SMA-Inverter → your screenshot matches the pattern I see locally 👍
2. the Website on SMA[serial number] advertisement with the path=/legal_notices.txt is for the Home Manager → identifiable based on the presence of that path (try to visit that URL and you'll see the open source legal notices!) → your screenshot matches the pattern I see locally 👍
3. battery inverter: 🤔 → was there really no other service discovered? 😞
4. EV charger: 🤔 → was there really no other service discovered? 😞

What do you see if you open the EV charger's IP address in a browser?

[sweh]

Hi there,

Based on the mDNS discovery you shared 4 days ago at #3 (comment):

1. the Website for SMA-Inverter: SMA[serial number] advertisement is for the solar inverter → identifiable based on the string SMA-Inverter → your screenshot matches the pattern I see locally 👍
2. the Website on SMA[serial number] advertisement with the path=/legal_notices.txt is for the Home Manager → identifiable based on the presence of that path (try to visit that URL and you'll see the open source legal notices!) → your screenshot matches the pattern I see locally 👍
3. battery inverter: 🤔 → was there really no other service discovered? 😞

No, unfortunately not

4. EV charger: 🤔 → was there really no other service discovered? 😞

No, that one was not advertised as well, though all 4 are on the same network and reachable.

What do you see if you open the EV charger's IP address in a browser?

I can see the WebUI like for the inverters.

[wimleers]

I've got this working locally!

Will test this another day or so with a bunch of reboots to make sure it works well before I release it.

[wimleers]

🚢 Fix shipped in https://github.com/wimleers/homebridge-sma-home-manager/releases/tag/1.1.0

[Scream4Life]

sudo npm install -g homebridge-sma-home-manager@latest still pushes 1.0.2 and config UI doesn't show an update either.

[wimleers]

sudo npm install -g homebridge-sma-home-manager@latest still pushes 1.0.2 and config UI doesn't show an update either.

npm’s infrastructure was lagging. It’s caught up now.

[sweh]

Hi @wimleers ,

this is fantastic, great work!

Found inverter SMA3006930808 at SMA3006930808.local with IPv4 address 10.0.1.124.

Next up support for battery inverters? ;-) If I can assist with this, feel free to contact me.

Cheers, Sebastian