Shelly Binding & DNS

Add-ons Bindings
,
1

Hi,

I am running a 2.5.12 and 4.1.1 (migrating very slowly…). On both of them I see the same “problem”. Almost all my devices on the local network get their ip-address from DHCP, and the devices are all resolveble via DNS. The Shelly devices are no different from this. Therefore I use the FQDN in the configuration of the thing.

I have noticed that the shelly binding (in 2.5.12 as well in 4.1.1) replaces the FQDN with the ip-address of the device. Why is this ? Until now, there was never a big issue, but I am waiting until the day that a shelly device gets a new ip-address, and the binding tries to connect to the old ip-addres.

Or does the binding update itself upon the macaddres ?

2

no, you have to make sure that the IPs of your Shellys remain unchanged with a setting in your dhcp-server.

3

it’s just the whole point not to do that, using DNS. So, why does the binding removes the FQDN and replaces it with it ip-address ?

4

There is no question why it does, this is by design. If you check the Shelly Binding documentation, the config parameter clearly says IP address of the device.

5

I just tried and seems to work with the hostname too.

6

yes, it works, but the binding replaces the hostname with the ip address after some time.

7

And this is correct behavior. The config says IP address !

8

If it is by design, then the why question is even more relevant. The shelly devices handle DHCP and DNS by the (rfc-)book.

Someone who took part in the design of the binding decided that the FQDN was not good enough, and jugded that the ip address should be used. Probably for good reason. Sharing that reason might result in an improvment of the binding.

So, the question remains : why does this piece of code exists ?

if (!config.deviceIp.isEmpty()) {
            try {
                InetAddress addr = InetAddress.getByName(config.deviceIp);
                String saddr = addr.getHostAddress();
                if (!config.deviceIp.equals(saddr)) {
                    logger.debug("{}: hostname {} resolved to IP address {}", thingName, config.deviceIp, saddr);
                    config.deviceIp = saddr;
                }
            } catch (UnknownHostException e) {
                logger.debug("{}: Unable to resolve hostname {}", thingName, config.deviceIp);
            }
        }
1 Like
9

@markus7017 Can you comment please.

10

There is a simple reason: Because there are callbacks to the binding with CoAP (Gen1) or WebSock (Gen2+3). The binding uses the remote ip address to match the thing. Otherwise I need to perform a reverse lookup.

Where is you problem? Why should it work in a different way?
Many of us are using 50+ Shellys since 3+ years.

Just change your router setup to assign always the same address to the device. All good.
(or use static IP addresses)

2 Likes
11

hi @markus7017,

There is no problem. As an infrastructure guy, I don’t like reservations and/or static IP addresses. If a device (on IP level) acts as it should, it looked strange that the binding replaces the FQDN with the IP address. Therefore I was almost sure that there would be an explation, which is given at this point.

An option could be, in a possible future version of the binding, that if a (resolveble) FQDN is used, then the rDNS is performed. If an IP, keep the current procedure.

the Why ? : I understand this will make the binding (a bit) more complex, but it will make the infrastructere (a little bit more) less complex (for sure when you have 50+ Shellys).

Nevertheless, thanks for the (alomst) perfect binding. I am replacing most of my zwave devices with Shellys.

If only one could change the hostname of the shelly devices, then we would be close to an ideal world…

2 Likes