Skip to content

Conversation

thozza
Copy link
Contributor

@thozza thozza commented Feb 15, 2015

Hi. As discussed on http://forum.mysensors.org/topic/864/controller-ip-auto-discovery-for-ethernetgw I implemented the dynamic controller discovery for Ethernet Gateway.

The basic Idea is that the gateway is just plugged into existing network with DHCP server. Requests IPv6 address from the server and renews it regularly (this can be set). For communication over Ethernet, the GW uses UDP on the transport layer. The GW does not know where is the controller located (which IP address) so it broadcast a special internal message via Ethernet to well known port (5003 from Ethernet GW example) asking for controller to reply with its unicast IPaddress (and possibly also port). The broadcast message is sent to the network subnet broadcast IPv4 address. The controller has to listen on the subnet broadcast address and on the particular unicast address (so there has to be also support in the controller).

The implementation of dynamic controller discovery can be turned on by uncommenting GATEWAY_CONTROLLER_DISCOVERY in the MyConfig.h co it is not compiled in by default. I also extended the Ethernet Gateway example to use DHCP and dynamic discovery if turned on in MyConfig.h.

For testing I used my simple Sensor Net Proxy written in Python3 (https://github.com/thozza/sensor-net-proxy). By running

./sensor-net-proxy.py -v -i <interface_name>

It will bind to all addresses for the particular interface and also to broadcast subnet addresses. It responds to the dynamic controller discovery MySensors message with its IP address and then just prints all messages sent from Gateway using unicast (can be extended to forward them to a specific controller without the dynamic discovery support).

…eway

Signed-off-by: Tomas Hozza <thozza@gmail.com>
Signed-off-by: Tomas Hozza <thozza@gmail.com>
@henrikekblad
Copy link
Member

Cool,

How much does the program size grow?

@thozza
Copy link
Contributor Author

thozza commented Feb 15, 2015

Hi Henrik.

Using Arduino IDE 1.5.8 I get (using the code with changes included):

dynamic discovery ON + DEBUG mode ON

Sketch uses 29,562 bytes (96%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,025 bytes (50%) of dynamic memory, leaving 1,023 bytes for local variables. Maximum is 2,048 bytes.

dynamic discovery ON & DEBUG mode OFF

Sketch uses 28,640 bytes (93%) of program storage space. Maximum is 30,720 bytes.
Global variables use 950 bytes (46%) of dynamic memory, leaving 1,098 bytes for local variables. Maximum is 2,048 bytes.

dynamic discovery OFF & DEBUG mode OFF

Sketch uses 26,534 bytes (86%) of program storage space. Maximum is 30,720 bytes.
Global variables use 837 bytes (40%) of dynamic memory, leaving 1,211 bytes for local variables. Maximum is 2,048 bytes.

Please note that I'm also using SoftSPI and DigitalIO, since I'm using the iboard as Gateway.

@henrikekblad
Copy link
Member

The reason I haven't merged this yet is that @mapnull is doing some refactoring of the gateways in development branch.

And I would much rather get dynamic discovery into development (upcoming 1.5 release). If I take new stuff into master it will become a merge mess.

So... could we wait a few days for development (gateway) structure to settle a bit? And we take it from there.

@thozza
Copy link
Contributor Author

thozza commented Feb 20, 2015

Sure. I can rebase the changes on top of development, since it will not apply based on the changes I saw. I was also thinking about introducing separate gateway sketch, since the ifdefs complicate it (at least visually), but then it will be harder to both versions up-to-date.

@thozza
Copy link
Contributor Author

thozza commented Apr 9, 2015

I didn't have much time lately to hack on Arduino stuff, but looked at the development branch yesterday, since you've sent an email about beta release of 1.5 version coming out. I would like to submit updated pull request for development branch this weekend.

There is one particular thing I would like to ask:

  • What is the reason behind removing MyGateway completely? I see the same code duplicated in all gateways (serial, ethernet, MQTT) in the GatewayUtil.h. Also the header contains implementation of functions.

I can contribute the functionality to the current project structure, and help with de-duplicating the code later...

@henrikekblad
Copy link
Member

The main reason was to remove the remove the PinChangeInt and MsTimer2 dependency from the core MySensors library. This was causing problems for some libraries/sketches.

But I thought about this again a couple of weeks ago again and maybe we could just skip using interrupts for inclusion button (just poll GPIO) and use simple millis() check instead of MsTimer for the led-blinking (handled in process()).

Would be good if tx/rx/er blinking optionally could be included in normal sensors as well as this has been requested by the community a few times.

If you have the time I would appreciate some help.

@thozza
Copy link
Contributor Author

thozza commented Apr 19, 2015

Thanks for the comments @henrikekblad. I think the easiest way to go will be including the bits in MySensor step-by-step. I'll start with the LEDs. After this is merged I'll continue with the dynamic discovery part.

I'm working on the LEDs, so it can be enabled in MyConfig and compiled in also for regular sensors, without the MsTimer2. Although one thing confuses me is that the current code in ledTimersInterrupt() turns on the LED by setting the PIN to LOW. Why it is so? I would expect it to be the other way around.

I'll create separate PR once I have the changes done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants