claudeheintz / LXDMXWiFi_Library

Library for ESP8266 implements Art-Net and sACN with example DMX input/output to/from network
BSD 3-Clause "New" or "Revised" License
74 stars 17 forks source link

Wifi configuartion tool not working #17

Closed gagarcr closed 5 years ago

gagarcr commented 5 years ago

Hello, I am trying to use the WiFi configuration tool with no luck. I am running the java application in both Windows 10 and MacOs, however it is not working (no devices found). This is on an ESP8266, not an ESP32. If however, I try to use the python tool, I am getting an "exception reading packet" on the console log. I have tried both in AP and Station mode. The wireless connection is working and the DMX changing (I am using "Art-net Controller" on Android) Thank you for your time.

claudeheintz commented 5 years ago

You do not say if you are using a specific example. In the ESP-DMX example, there is a commented out #define that enables remote configuration. See the comments in ESP-DMX.ino above the #define which is is on line 83.

Assuming that you have USE_REMOTE_CONFIG defined (the value is irrelevant), there is another possible reason it is not working for you. The wifi configuration is an alternate packet sent to the same port as Art-Net or sACN. ( It should be ignored by anything listening for these protocols because it has the wrong header.) If you have an application open on your computer that is occupying the Art-Net or sACN port, the configuration utility will not be able to use it. I would make sure that the configuration tool is the only thing running on your computer that uses Art-Net or sACN. Depending on the system it can take a moment to free the port. So, make sure other apps are closed and off before starting the configuration tool.

gagarcr commented 5 years ago

I am using the ESP_DMX example, I uncommented that line with the same results. I have downloaded the lastest commit, not the lastest release (in case its relevant). Its hardly improvable that the port is occupated by other program, because when I try in macOs I got the same result.

claudeheintz commented 5 years ago

Are you connecting to the ESP8266 as an access point or station? What are the IPAddresses of your computer and the ESP8266? Does your computer have more than one network interface? If so, are you sure that you are using the one matching the connection to the ESP8266?

gagarcr commented 5 years ago

I am using the ESP_DMX example, I uncommented that line with the same results. I have downloaded the lastest commit, not the lastest release (in case its relevant). Its hardly improvable that the port is occupated by other program, because when I try in macOs I got the same result. I have tried with ESP8266 as an access point and station (right now it is as station). My computer is 192.168.1.10 and ESP8266 is 192.168.1.13 on WLAN1. The connection is working fine with QLigthControllerPlus + artnet.

claudeheintz commented 5 years ago

I believe that this has to do with initializing the EEPROM area of the flash.

Try this:

1) in ESP-DMX.ino line 83 should read: #define USE_REMOTE_CONFIG 0

2) in LXDMXWiFiConfig.cpp uncomment line 35: #define RESET_PERSISTENT_CONFIG_ON_DEFAULT 1

Flash the ESP8266 and reboot it.

3) in LXDMXWiFiConfig.cpp comment out line 35: //#define RESET_PERSISTENT_CONFIG_ON_DEFAULT 1

Flash the ESP8266 and reboot it.

Try the remote configuration utility, either the java based app or the python one.

I have been checking the version of the example on github using an ESP8266 board that already had the EEPROM area initialized and it was working fine. However, I tried a fresh brand new ESP8266 board and ran into the problem. Using the steps above, I was able to get it to respond to the configuration utility.

Please let me know if this works for you. If so, I'll write the procedure up and put it into the source file.

gagarcr commented 5 years ago

I can confirm that the problem is solved! However, this procedure must be followed each time a new module is program. Thank you for your time.

claudeheintz commented 5 years ago

The examples have been updated with comments reflecting this procedure. It should be only necessary to initialize the EEPROM once for an ESP8266 board. After that, the data stored there should survive re-flashing a sketch. This is unlike a MKR1000 which wipes the EEPROM area each time you upload a sketch.