Controller IP auto-discovery for EthernetGW
-
@daulagari
I am all for a standard way of doing this, but as present Ethernet Library implementation we have to alter our libraries to support multicast broadcasts, and therefore it is not possible to do a standardized implementation, since it wont be compatible with the current Ethernet Libraray.We have to wait for the library to include this functionality, or come up with a way to do this without multicast and still keep it small.
-
@daulagari
I am all for a standard way of doing this, but as present Ethernet Library implementation we have to alter our libraries to support multicast broadcasts, and therefore it is not possible to do a standardized implementation, since it wont be compatible with the current Ethernet Libraray.We have to wait for the library to include this functionality, or come up with a way to do this without multicast and still keep it small.
@Zen
Multicast and broadcast are two different things. You can broadcast a packet by sending it to a broadcast IP address of the network you are on.So if you are on network 192.168.1.0/24, the broadcast address will be 192.168.1.255. Then the controller listening on a socket with IP address from that network should get it.
I think it can be achieved by simply sending a special (new) internal message from GW to the broadcast IP address using UDP (we should use some specific port all the time). The Controller will get it and respond to with the same type of internal message that can contain its IP address (or GW can extract the IP from response).
The first step from my point of view is adding a new internal message type. I will try out my ideas during the weekend and if working create a pull request on Github. I wanted to get some feedback, since I think it might be an interesting Feature, rather than hard-coding everything into GW.
-
@Zen
Multicast and broadcast are two different things. You can broadcast a packet by sending it to a broadcast IP address of the network you are on.So if you are on network 192.168.1.0/24, the broadcast address will be 192.168.1.255. Then the controller listening on a socket with IP address from that network should get it.
I think it can be achieved by simply sending a special (new) internal message from GW to the broadcast IP address using UDP (we should use some specific port all the time). The Controller will get it and respond to with the same type of internal message that can contain its IP address (or GW can extract the IP from response).
The first step from my point of view is adding a new internal message type. I will try out my ideas during the weekend and if working create a pull request on Github. I wanted to get some feedback, since I think it might be an interesting Feature, rather than hard-coding everything into GW.
-
@nneeoo
I am well aware of this, but it requires you to actually know the broadcast address of your segment.In multicast you choose the multicast address you want to use, and this is regardless of your segment, which actually makes it abit easier.
@Zen
Use the mask to determine the broadcast ip.Instead of multicast use anycast, this way you do not have to keep track of interested parties.
UPNP is also a possibility, it does not automatically implies router configuration options. Only implementing presence would suffice. All though space on the chips should then be looked at.
[JUSTATHOUGHT]
UPNP could also cover a bigger range of possible options where not only specific mysensor controllers can jump in to, but also other applications. UPNP enabled devices could see a MySensors gateway (it is even possible you will see it in your windows network discovery). I'm not saying to implement an UPNP subset, but broaden the gateway visibility.I for example are going to implement UPNP for media discovery, or even other possible devices support so adding components/devices can be easier, having MySensors doing UPNP would let it appear on the list.
[/JUSTATHOUGHT] -
@Zen
Use the mask to determine the broadcast ip.Instead of multicast use anycast, this way you do not have to keep track of interested parties.
UPNP is also a possibility, it does not automatically implies router configuration options. Only implementing presence would suffice. All though space on the chips should then be looked at.
[JUSTATHOUGHT]
UPNP could also cover a bigger range of possible options where not only specific mysensor controllers can jump in to, but also other applications. UPNP enabled devices could see a MySensors gateway (it is even possible you will see it in your windows network discovery). I'm not saying to implement an UPNP subset, but broaden the gateway visibility.I for example are going to implement UPNP for media discovery, or even other possible devices support so adding components/devices can be easier, having MySensors doing UPNP would let it appear on the list.
[/JUSTATHOUGHT] -
@John
But in anycase, I have only 1190 bytes left, and this is with debugging disabled.I was hoping I could get a simplified serial library going to show the ip on a lcd aswell, but I am guessing this is more or less a no go.
-
@Zen
Oh.. Dealbreaker, A bigger reason to do anycast (if going for the *cast route), It ain't possible to squeeze a broadcast calculator in it if the multicast code would be removed? -
@John
well I am not all that familiar with anycast, is that the same as the segment's broadcast address ?@Zen
anycast is almost like broadcast, but with some restrictions. The most important one is broadcast (old convention method) does not care who where anycast does. More info here (too much to post): http://en.wikipedia.org/wiki/Anycast -
If anyone is interested in trying out the implementation using UDP packets sent to the subnet broadcast address, check out my pull request https://github.com/mysensors/Arduino/pull/66
