-
-
Notifications
You must be signed in to change notification settings - Fork 896
Dynamic IP assignment using DHCP and dynamic controller discovery for Ethernet Gateway #66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…eway Signed-off-by: Tomas Hozza <thozza@gmail.com>
Signed-off-by: Tomas Hozza <thozza@gmail.com>
Cool, How much does the program size grow? |
Hi Henrik. Using Arduino IDE 1.5.8 I get (using the code with changes included): dynamic discovery ON + DEBUG mode ONSketch uses 29,562 bytes (96%) of program storage space. Maximum is 30,720 bytes. dynamic discovery ON & DEBUG mode OFFSketch uses 28,640 bytes (93%) of program storage space. Maximum is 30,720 bytes. dynamic discovery OFF & DEBUG mode OFFSketch uses 26,534 bytes (86%) of program storage space. Maximum is 30,720 bytes. Please note that I'm also using SoftSPI and DigitalIO, since I'm using the iboard as Gateway. |
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. |
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. |
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:
I can contribute the functionality to the current project structure, and help with de-duplicating the code later... |
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. |
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. |
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
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).