[SOLVED] Ethernet MQTT Gateway Slow to connect
-
I'm not using a wired connection, but had many connection issues also. It took long time before the gateway was up, MQTT connections dropped.
Then I replaced my router (the one delivered by the cable supplier) and I have no issues anymore. So that could be worth a try.
-
Hi guys.
I'm using an Arduino Uno + 5100 based MQTT Gateway.
It's working great with sensors and mqtt but I have a couple if issues that may be related.
-
It is very slow to connect to the ethernet switch
-
won't send registration nor info about local sensors.
Power supply is ok, external regulated 5V + 3v3 reg for nrf. All OK's on the radio front.
Take a look at the startup log:
MCO:BGN:INIT GW,CP=RNNGA---,REL=255,VER=2.3.1 4 TSM:INIT 5 TSF:WUR:MS=0 11 TSM:INIT:TSP OK 13 TSM:INIT:GW MODE 15 TSM:READY:ID=0,PAR=0,DIS=0 17 MCO:REG:NOT NEEDED 580 GWT:TPC:IP=192.168.1.200 1583 MCO:BGN:STP 1585 MCO:BGN:INIT OK,TSP=1 1587 GWT:TPC:IP=192.168.1.200 2590 GWT:RMQ:MQTT RECONNECT 3594 TSM:READY:NWD REQ 3631 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK: 3638 TSF:MSG:READ,11-11-0,s=255,c=3,t=21,pt=1,l=1,sg=0:0 3645 GWT:TPC:IP=192.168.1.200 4647 GWT:RMQ:MQTT RECONNECT 5652 TSF:MSG:READ,0-11-255,s=255,c=3,t=20,pt=0,l=0,sg=0: 5657 TSF:MSG:BC 5659 TSF:MSG:READ,2-2-0,s=255,c=3,t=21,pt=1,l=1,sg=0:0 5664 TSF:MSG:READ,0-2-255,s=255,c=3,t=20,pt=0,l=0,sg=0: 5669 TSF:MSG:BC 5671 GWT:TPC:IP=192.168.1.200 6674 GWT:RMQ:MQTT RECONNECT 7678 GWT:TPC:IP=192.168.1.200 8681 GWT:RMQ:MQTT RECONNECT 9687 GWT:TPC:IP=192.168.1.200 10690 GWT:RMQ:MQTT RECONNECT 11695 GWT:TPC:IP=192.168.1.200 12697 GWT:RMQ:MQTT RECONNECT 13702 GWT:TPC:IP=192.168.1.200 14704 GWT:RMQ:MQTT RECONNECT 15710 GWT:TPC:IP=192.168.1.200 16713 GWT:RMQ:MQTT RECONNECT 17717 GWT:TPC:IP=192.168.1.200 18720 GWT:RMQ:MQTT RECONNECT 19725 GWT:TPC:IP=192.168.1.200 20727 GWT:RMQ:MQTT RECONNECT 21733 GWT:TPC:IP=192.168.1.200 22736 GWT:RMQ:MQTT RECONNECT 23741 GWT:TPC:IP=192.168.1.200 24743 GWT:RMQ:MQTT RECONNECT 25749 GWT:TPC:IP=192.168.1.200 26752 GWT:RMQ:MQTT RECONNECT 27758 GWT:TPC:IP=192.168.1.200 28762 GWT:RMQ:MQTT RECONNECT 29767 GWT:TPC:IP=192.168.1.200 30770 GWT:RMQ:MQTT RECONNECT 30777 GWT:RMQ:MQTT CONNECTEDOnly then, it starts working ok.
When in that MQTT Reconnect, it is not responding any pings. As soon as it gets the ethernet connection running, it connects to the broker at the first attempt.
It is directly connected to a Cisco switch. I tried everything, auto/auto, 10/full, 100/full. Any ethernet combo it's the same.
This is the complete sketch:
// Enable debug prints to serial monitor #define MY_DEBUG // Enables and select radio type (if attached) #define MY_RADIO_RF24 #define MY_RF24_CHANNEL 110 // modulo con amplificador, por ahi recomiendan bajarle la potencia (?) #define MY_RF24_PA_LEVEL RF24_PA_LOW #define MY_GATEWAY_MQTT_CLIENT // Set this node's subscribe and publish topic prefix #define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway1-out" #define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway1-in" // Set MQTT client id #define MY_MQTT_CLIENT_ID "mysensors-1" // W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal) // descomentó guille //#define MY_W5100_SPI_EN 4 // Enable Soft SPI for NRF radio (note different radio wiring is required) // The W5100 ethernet module seems to have a hard time co-operate with // radio on the same spi bus. #if !defined(MY_W5100_SPI_EN) && !defined(ARDUINO_ARCH_SAMD) #define MY_SOFTSPI #define MY_SOFT_SPI_SCK_PIN 14 #define MY_SOFT_SPI_MISO_PIN 16 #define MY_SOFT_SPI_MOSI_PIN 15 #endif // When W5100 is connected we have to move CE/CSN pins for NRF radio #ifndef MY_RF24_CE_PIN #define MY_RF24_CE_PIN 5 #endif #ifndef MY_RF24_CS_PIN #define MY_RF24_CS_PIN 6 #endif // Enable these if your MQTT broker requires username/password //#define MY_MQTT_USER "username" //#define MY_MQTT_PASSWORD "password" // Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP) #define MY_IP_ADDRESS 192,168,1,200 // If using static ip you can define Gateway and Subnet address as well #define MY_IP_GATEWAY_ADDRESS 192,168,1,1 #define MY_IP_SUBNET_ADDRESS 255,255,255,0 // MQTT broker ip address or url. Define one or the other. //#define MY_CONTROLLER_URL_ADDRESS "m20.cloudmqtt.com" #define MY_CONTROLLER_IP_ADDRESS 192, 168, 1,2 // The MQTT broker port to to open #define MY_PORT 8884 /* // Enable inclusion mode #define MY_INCLUSION_MODE_FEATURE // Enable Inclusion mode button on gateway //#define MY_INCLUSION_BUTTON_FEATURE // Set inclusion mode duration (in seconds) #define MY_INCLUSION_MODE_DURATION 60 // Digital pin used for inclusion mode button //#define MY_INCLUSION_MODE_BUTTON_PIN 3 // Set blinking period #define MY_DEFAULT_LED_BLINK_PERIOD 300 // Flash leds on rx/tx/err // Uncomment to override default HW configurations //#define MY_DEFAULT_ERR_LED_PIN 16 // Error led pin //#define MY_DEFAULT_RX_LED_PIN 16 // Receive led pin //#define MY_DEFAULT_TX_LED_PIN 16 // the PCB, on board LED */ #include <Ethernet.h> #include <MySensors.h> // Temperatura #include <SPI.h> #include <DallasTemperature.h> #include <OneWire.h> #define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No #define ONE_WIRE_BUS 2 // Pin where dallase sensor is connected #define MAX_ATTACHED_DS18B20 16 OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs) DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature. float lastTemperature[MAX_ATTACHED_DS18B20]; int numSensors=0; // Initialize temperature message MyMessage msg(0,V_TEMP); // void setup() { // Setup locally attached sensors // temperatura sensors.setWaitForConversion(false); } void presentation() { // Present locally attached sensors here sendSketchInfo("Gateway node with temp", "1.0"); // Fetch the number of attached temperature sensors numSensors = sensors.getDeviceCount(); present(1, S_TEMP); } void loop() { // Send locally attached sensors data here // Fetch temperatures from Dallas sensors sensors.requestTemperatures(); // query conversion time and sleep until conversion completed int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution()); // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater) wait(conversionTime); // Read temperatures and send them to controller for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) { // Fetch and round temperature to one decimal float temperature = static_cast<float>(static_cast<int>((getControllerConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.; Serial.println(temperature); // Only send data if temperature has changed and no error #if COMPARE_TEMP == 1 if (lastTemperature[i] != temperature && temperature != -127.00 && temperature != 85.00) { #else if (temperature != -127.00 && temperature != 85.00) { #endif // Send in the new temperature send(msg.setSensor(i).set(temperature,1)); // Save new temperatures for next compare lastTemperature[i]=temperature; } } // Estudiar un poco esto. Le pongo algo para que no esté midiendo // permanentemente wait(1000); }I'm on 2.3.1
The main issue here is the failure to use local sensors, but a faster startup time would also be great.
Thanks in advance for any tip.
Guillermo
-
-
I'm not using a wired connection, but had many connection issues also. It took long time before the gateway was up, MQTT connections dropped.
Then I replaced my router (the one delivered by the cable supplier) and I have no issues anymore. So that could be worth a try.
@electrik said in Ethernet MQTT Gateway Slow to connect:
I'm not using a wired connection, but had many connection issues also. It took long time before the gateway was up, MQTT connections dropped.
Then I replaced my router (the one delivered by the cable supplier) and I have no issues anymore. So that could be worth a try.
Thanks for the help. I'm on a wired connection. And the network element are of great quality. I think there is a delay in ethernet.connect() but can't find it.
-
@electrik said in Ethernet MQTT Gateway Slow to connect:
I'm not using a wired connection, but had many connection issues also. It took long time before the gateway was up, MQTT connections dropped.
Then I replaced my router (the one delivered by the cable supplier) and I have no issues anymore. So that could be worth a try.
Thanks for the help. I'm on a wired connection. And the network element are of great quality. I think there is a delay in ethernet.connect() but can't find it.
-
@guillermo-schimmel shot in the dark: make sure your Mac ID is unique on your network, or switches will get very confused
@yveaux said in Ethernet MQTT Gateway Slow to connect:
@guillermo-schimmel shot in the dark: make sure your Mac ID is unique on your network, or switches will get very confused
Thank you for the suggestion. This is one of the lines I'm investigating.
192.168.1.200 de-ad-be-ef-fe-ed dynamicAt the moment it seems to be some standard arduino joke, but at least is unique in the network.
-
@guillermo-schimmel wouldn't it be a bit surprising if there is a delay that is only active on your system?
@mfalkvidd said in Ethernet MQTT Gateway Slow to connect:
@guillermo-schimmel wouldn't it be a bit surprising if there is a delay that is only active on your system?
Sure. I'm not meaning that. Sometimes not being an english speaker is tough.
I mean that some combination of settings that I may have done (wrongly?) perhaps generated that delay.
-
@mfalkvidd said in Ethernet MQTT Gateway Slow to connect:
@guillermo-schimmel wouldn't it be a bit surprising if there is a delay that is only active on your system?
Sure. I'm not meaning that. Sometimes not being an english speaker is tough.
I mean that some combination of settings that I may have done (wrongly?) perhaps generated that delay.
@guillermo-schimmel I see. Thanks for explaining.
Which ethernet implementation are you using? (depends on which libraries are installed in your IDE)
To check, turn on "Show verbose output" in Arduino IDE preferences. Then compile the sketch. At the end, something like this will be shown:Using library Ethernet at version 2.0.0 in folder: C:\Program Files (x86)\Arduino\libraries\Ethernet Using library MySensors at version 2.3.2-alpha in folder: R:\Documents\Arduino\libraries\MySensors Using library SPI at version 1.0 in folder: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPIIn my implementation, there is a 560ms delay at init, in src/utility/w5100.cpp. It should only happen once though, so it should not be responsible for a 30 second delay. You could uncomment the Serial.println to verify.
// Many Ethernet shields have a CAT811 or similar reset chip // connected to W5100 or W5200 chips. The W5200 will not work at // all, and may even drive its MISO pin, until given an active low // reset pulse! The CAT811 has a 240 ms typical pulse length, and // a 400 ms worst case maximum pulse length. MAX811 has a worst // case maximum 560 ms pulse length. This delay is meant to wait // until the reset pulse is ended. If your hardware has a shorter // reset time, this can be edited or removed. delay(560); //Serial.println("w5100 init");There are quite a few Serial.println in this file. Activating them all for debugging purposes might be useful.
There are 50ms delays in src/Dhcp.cpp and src/Dns.cpp but since you're using fixed IP and no domain names, they should not be used. You could add Serial.println statements before/after them to verify.
-
@guillermo-schimmel I see. Thanks for explaining.
Which ethernet implementation are you using? (depends on which libraries are installed in your IDE)
To check, turn on "Show verbose output" in Arduino IDE preferences. Then compile the sketch. At the end, something like this will be shown:Using library Ethernet at version 2.0.0 in folder: C:\Program Files (x86)\Arduino\libraries\Ethernet Using library MySensors at version 2.3.2-alpha in folder: R:\Documents\Arduino\libraries\MySensors Using library SPI at version 1.0 in folder: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPIIn my implementation, there is a 560ms delay at init, in src/utility/w5100.cpp. It should only happen once though, so it should not be responsible for a 30 second delay. You could uncomment the Serial.println to verify.
// Many Ethernet shields have a CAT811 or similar reset chip // connected to W5100 or W5200 chips. The W5200 will not work at // all, and may even drive its MISO pin, until given an active low // reset pulse! The CAT811 has a 240 ms typical pulse length, and // a 400 ms worst case maximum pulse length. MAX811 has a worst // case maximum 560 ms pulse length. This delay is meant to wait // until the reset pulse is ended. If your hardware has a shorter // reset time, this can be edited or removed. delay(560); //Serial.println("w5100 init");There are quite a few Serial.println in this file. Activating them all for debugging purposes might be useful.
There are 50ms delays in src/Dhcp.cpp and src/Dns.cpp but since you're using fixed IP and no domain names, they should not be used. You could add Serial.println statements before/after them to verify.
@mfalkvidd Thanks for the tips
I did all that
0 MCO:BGN:INIT GW,CP=RNNGA---,REL=255,VER=2.3.1 4 TSM:INIT 5 TSF:WUR:MS=0 11 TSM:INIT:TSP OK 13 TSM:INIT:GW MODE 15 TSM:READY:ID=0,PAR=0,DIS=0 17 MCO:REG:NOT NEEDED w5100 init w5100.cpp: detect W5200 chip Wiznet soft reset mr=0 w5100.cpp: detect W5500 chip Wiznet soft reset mr=0 w5100.cpp: detect W5100 chip Wiznet soft reset mr=0 chip is W5100 590 GWT:TPC:IP=192.168.1.200 1598 MCO:BGN:STP 1600 MCO:BGN:INIT OK,TSP=1 1603 GWT:TPC:IP=192.168.1.200 2606 GWT:RMQ:MQTT RECONNECT 3610 TSM:READY:NWD REQ 3647 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK: 3656 GWT:TPC:IP=192.168.1.200 4660 GWT:RMQ:MQTT RECONNECT 5664 TSF:MSG:READ,2-2-0,s=255,c=3,t=21,pt=1,l=1,sg=0:0 5669 TSF:MSG:READ,0-2-255,s=255,c=3,t=20,pt=0,l=0,sg=0: 5675 TSF:MSG:BC 5677 TSF:MSG:READ,11-11-0,s=255,c=3,t=21,pt=1,l=1,sg=0:0 New temp: 29.19 5709 GWT:TPC:IP=192.168.1.200 6713 GWT:RMQ:MQTT RECONNECT 7717 TSF:MSG:READ,10-2-0,s=1,c=1,t=13,pt=2,l=2,sg=0:48 7723 GWT:TPC:IP=192.168.1.200 8726 GWT:RMQ:MQTT RECONNECT 9732 GWT:TPC:IP=192.168.1.200 10735 GWT:RMQ:MQTT RECONNECT 11766 GWT:TPC:IP=192.168.1.200 12769 GWT:RMQ:MQTT RECONNECT 13774 GWT:TPC:IP=192.168.1.200 14777 GWT:RMQ:MQTT RECONNECT 15783 GWT:TPC:IP=192.168.1.200 16786 GWT:RMQ:MQTT RECONNECT 17819 GWT:TPC:IP=192.168.1.200 18822 GWT:RMQ:MQTT RECONNECT 19827 TSF:MSG:READ,10-2-0,s=1,c=1,t=13,pt=2,l=2,sg=0:47 19832 TSF:MSG:READ,10-2-0,s=2,c=1,t=0,pt=7,l=5,sg=0:27.62 19837 GWT:TPC:IP=192.168.1.200 20841 GWT:RMQ:MQTT RECONNECT 21849 GWT:TPC:IP=192.168.1.200 22851 GWT:RMQ:MQTT RECONNECT 23882 GWT:TPC:IP=192.168.1.200 24885 GWT:RMQ:MQTT RECONNECT 25890 GWT:TPC:IP=192.168.1.200 26894 GWT:RMQ:MQTT RECONNECT 27901 GWT:TPC:IP=192.168.1.200 28904 GWT:RMQ:MQTT RECONNECT 29910 TSF:MSG:READ,1-1-0,s=1,c=1,t=1,pt=7,l=5,sg=0:62.6 29941 GWT:TPC:IP=192.168.1.200 30945 GWT:RMQ:MQTT RECONNECT 31160 GWT:RMQ:MQTT CONNECTEDIt seems to detect quickly the w5100 and then the delay is elsewhere.
I will try to do the same on some other modules. Perhaps the speed and duplex negotiation.
-
@mfalkvidd Thanks for the tips
I did all that
0 MCO:BGN:INIT GW,CP=RNNGA---,REL=255,VER=2.3.1 4 TSM:INIT 5 TSF:WUR:MS=0 11 TSM:INIT:TSP OK 13 TSM:INIT:GW MODE 15 TSM:READY:ID=0,PAR=0,DIS=0 17 MCO:REG:NOT NEEDED w5100 init w5100.cpp: detect W5200 chip Wiznet soft reset mr=0 w5100.cpp: detect W5500 chip Wiznet soft reset mr=0 w5100.cpp: detect W5100 chip Wiznet soft reset mr=0 chip is W5100 590 GWT:TPC:IP=192.168.1.200 1598 MCO:BGN:STP 1600 MCO:BGN:INIT OK,TSP=1 1603 GWT:TPC:IP=192.168.1.200 2606 GWT:RMQ:MQTT RECONNECT 3610 TSM:READY:NWD REQ 3647 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK: 3656 GWT:TPC:IP=192.168.1.200 4660 GWT:RMQ:MQTT RECONNECT 5664 TSF:MSG:READ,2-2-0,s=255,c=3,t=21,pt=1,l=1,sg=0:0 5669 TSF:MSG:READ,0-2-255,s=255,c=3,t=20,pt=0,l=0,sg=0: 5675 TSF:MSG:BC 5677 TSF:MSG:READ,11-11-0,s=255,c=3,t=21,pt=1,l=1,sg=0:0 New temp: 29.19 5709 GWT:TPC:IP=192.168.1.200 6713 GWT:RMQ:MQTT RECONNECT 7717 TSF:MSG:READ,10-2-0,s=1,c=1,t=13,pt=2,l=2,sg=0:48 7723 GWT:TPC:IP=192.168.1.200 8726 GWT:RMQ:MQTT RECONNECT 9732 GWT:TPC:IP=192.168.1.200 10735 GWT:RMQ:MQTT RECONNECT 11766 GWT:TPC:IP=192.168.1.200 12769 GWT:RMQ:MQTT RECONNECT 13774 GWT:TPC:IP=192.168.1.200 14777 GWT:RMQ:MQTT RECONNECT 15783 GWT:TPC:IP=192.168.1.200 16786 GWT:RMQ:MQTT RECONNECT 17819 GWT:TPC:IP=192.168.1.200 18822 GWT:RMQ:MQTT RECONNECT 19827 TSF:MSG:READ,10-2-0,s=1,c=1,t=13,pt=2,l=2,sg=0:47 19832 TSF:MSG:READ,10-2-0,s=2,c=1,t=0,pt=7,l=5,sg=0:27.62 19837 GWT:TPC:IP=192.168.1.200 20841 GWT:RMQ:MQTT RECONNECT 21849 GWT:TPC:IP=192.168.1.200 22851 GWT:RMQ:MQTT RECONNECT 23882 GWT:TPC:IP=192.168.1.200 24885 GWT:RMQ:MQTT RECONNECT 25890 GWT:TPC:IP=192.168.1.200 26894 GWT:RMQ:MQTT RECONNECT 27901 GWT:TPC:IP=192.168.1.200 28904 GWT:RMQ:MQTT RECONNECT 29910 TSF:MSG:READ,1-1-0,s=1,c=1,t=1,pt=7,l=5,sg=0:62.6 29941 GWT:TPC:IP=192.168.1.200 30945 GWT:RMQ:MQTT RECONNECT 31160 GWT:RMQ:MQTT CONNECTEDIt seems to detect quickly the w5100 and then the delay is elsewhere.
I will try to do the same on some other modules. Perhaps the speed and duplex negotiation.
@guillermo-schimmel Well, solved.
Good brands not means good quality.
Replaced my Cisco switch for a unbranded one:
0 MCO:BGN:INIT GW,CP=RNNGA---,REL=255,VER=2.3.1 4 TSM:INIT 5 TSF:WUR:MS=0 11 TSM:INIT:TSP OK 13 TSM:INIT:GW MODE 15 TSM:READY:ID=0,PAR=0,DIS=0 17 MCO:REG:NOT NEEDED w5100 init w5100.cpp: detect W5200 chip Wiznet soft reset mr=0 w5100.cpp: detect W5500 chip Wiznet soft reset mr=0 w5100.cpp: detect W5100 chip Wiznet soft reset mr=0 chip is W5100 590 GWT:TPC:IP=192.168.1.200 1598 MCO:BGN:STP 1600 MCO:BGN:INIT OK,TSP=1 1603 GWT:TPC:IP=192.168.1.200 2606 GWT:RMQ:MQTT RECONNECT 2615 GWT:RMQ:MQTT CONNECTEDConnected at the first attempt.
Thank you guys a lot for your time.
-
Hi @Guillermo-Schimmel,
I know it's closed but just noticed this issue, you most probably had STP (Spanning Tree Protocol) enabled on that port, which is normal for ent switch, and while it waits for a loop it blocks trafic from that port.
Disabling that feature should solve this problem.
