No WiFi connection after upgrade via web interface

[spmp]

After initial flashing with v1.2.1 via platformio and configuration via wifimanager the web interface is available and looking great! I checked for update and updated to 1.2.2 after which time the device never re-connected to the network. Re-flashing with 1.2.1 or 1.2.1 (via build and git tags in platformio) has not made the device visible on the network again.

Obviously fixing the issues is the goal, but did beg some questions: How can I reset the WiFi manager if the device has not connected to the network Is there a serial connection available, and if so what commands etc. are available. What settings/command would be used to initiate this connection.

[sidoh]

The auto-update functions use SSL, which takes something like 16-18 KBs of SRAM. I think a bare setup is taking 19-20 KBs of SRAM. If you dip down into the range where SSL will run the ESP out of memory, you'll start seeing crashes. I need to find more places to save SRAM, and probably add some safeguards that don't attempt to do SSL things when there isn't enough free memory.

Re-flashing the firmware should fix it. If it's not connecting to your network, I'd recommend looking at Serial output.

[spmp]

How can I get to the serial output? I have tried screen /dev/ttyUSB0 9600 but get an empty screen which responds to no commands. What commands etc are available? I see reference to a settings JSON in the config, how can I access and modify that?

Re flashing does not fix it 8( I do not see WiFi hotspot ESPblah.

To reflash I am issuing the commands as in the readme:

export ESP_BOARD=nodemcuv2
platformio run -e $ESP_BOARD --target upload
platformio run -e $ESP_BOARD --target uploadfs

On 1 May 2017 at 04:15, Chris Mullins notifications@github.com wrote:

The auto-update functions use SSL, which takes something like 16-18 KBs of SRAM. I think a bare setup is taking 19-20 KBs of SRAM. If you dip down into the range where SSL will run the ESP out of memory, you'll start seeing crashes. I need to find more places to save SRAM, and probably add some safeguards that don't attempt to do SSL things when there isn't enough free memory.

Re-flashing the firmware should fix it. If it's not connecting to your network, I'd recommend looking at Serial output.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sidoh/esp8266_milight_hub/issues/74#issuecomment-298241322, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEriahZoyGiuvprAXqWIXH8tqS4fzn5ks5r1LOFgaJpZM4NMdFH .

[sidoh]

Are you sure it's not just connecting to your network? I think WiFi settings are stored in a separate part of flash that isn't affected by re-flashing the firmware or SPIFFS image.

I use platformio to attach to serial output.

platformio device monitor

[spmp]

yes I am sure it is not connecting to the network. The AP does not list it as a client and nmap cannot find it in a ping scan - it did the first time. How can I remove the WiFi managers settings please - or at least reflash that portion.

On 1 May 2017 at 06:12, Chris Mullins notifications@github.com wrote:

Are you sure it's not just connecting to your network? I think WiFi settings are stored in a separate part of flash that isn't affected by re-flashing the firmware or SPIFFS image.

I use platformio to attach to serial output.

platformio device monitor

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sidoh/esp8266_milight_hub/issues/74#issuecomment-298247568, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEriVFUAU3Y5lcdtFojAJ2YJy5b8CkFks5r1M70gaJpZM4NMdFH .

[sidoh]

I'd start with looking at serial output. It's going to be hard to tell what's going on without that.

You can erase the entire flash memory. I use esptool.py for that.

$ python /opt/esptool/esptool.py --port /dev/cu.SLAB_USBtoUART erase_flash

[spmp]

erasing flash helped. Finally serial output... very sparse tho

*WM: Sent config page
*WM: WiFi save
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Connection result:
*WM: 3

reset button pressed

␒�␄��5s��*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.1.135

Unfortunately browser , nmap etc. show nothing at this IP 8( AP logs do not show anything 8( This did work the first time I flashed and configured (yesterday) until reboot.

On 1 May 2017 at 06:20, Chris Mullins notifications@github.com wrote:

I'd start with looking at serial output. It's going to be hard to tell what's going on without that.

You can erase the entire flash memory. I use esptool.py for that.

$ python /opt/esptool/esptool.py --port /dev/cu.SLAB_USBtoUART erase_flash

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sidoh/esp8266_milight_hub/issues/74#issuecomment-298248027, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEriXSibOGHDyLf62Hk7EIMp9_zEiM9ks5r1NDQgaJpZM4NMdFH .

[sidoh]

So it's still not working, despite connecting? Does it respond to pings?

What radio are you using? What happens if you disconnect Vin?

[spmp]

It is stil not working. I am using what looks like it must be a knockoff nodemcu V2 with an 'esp8266mod' chip and NRF24L01+ radio. I have tried with/without radio connected. Strange that it worked once then not again, but works as AP... I wonder if its the WiFi manager... Using last saved values, should be faster may be the issue?

No ping response as it does nto appear to have an IP on the network. Can I increase the logging to see where it gets to? Sorry I have not familiarised myself with your code enough to know where to do this.

What does it mean to disconnect Vin?

On 2 May 2017 at 04:38, Chris Mullins notifications@github.com wrote:

So it's still not working, despite connecting? Does it respond to pings?

What radio are you using? What happens if you disconnect Vin?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sidoh/esp8266_milight_hub/issues/74#issuecomment-298369582, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEriUDOq1z890Gs38KoM46pfNeENrAOks5r1gqCgaJpZM4NMdFH .

[sidoh]

The IP it's printing out (192.168.1.135) isn't an IP on your network? Is it possible it's connecting to the wrong AP? "Using last saved values, should be faster" just means it's connecting with the WiFi credentials stored in flash. This is normal.

If it is connecting to your network, it's probably blocked setting something up. My best guess is the NRF radio. By "disconnect Vin," i meant the positive voltage line for the NRF.

Not much more debugging info, but you can add some here:

https://github.com/sidoh/esp8266_milight_hub/blob/master/src/main.cpp#L101

[spmp]

It is working now. I cannot attribute it to the debug messages added. Possibly the WiFi router reset? Confirmed WiFi manager working correctly by ensuring htat DHCP was giving it a different fixed address. Now to start training on the bulbs that I have that are not supported (RGBWW/CW, and RGBW s saturation). Can I get to show all traffic to help reverse engineer the two unsupported protocols I have?

Awesome effort BTW and thank you for supporting my esp8266 n00bishness

On 2 May 2017 at 08:15, Chris Mullins notifications@github.com wrote:

The IP it's printing out (192.168.1.135) isn't an IP on your network? Is it possible it's connecting to the wrong AP? "Using last saved values, should be faster" just means it's connecting with the WiFi credentials stored in flash. This is normal.

If it is connecting to your network, it's probably blocked setting something up. My best guess is the NRF radio. By "disconnect Vin," i meant the positive voltage line for the NRF.

Not much more debugging info, but you can add some here:

https://github.com/sidoh/esp8266_milight_hub/blob/master/src/main.cpp#L101

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sidoh/esp8266_milight_hub/issues/74#issuecomment-298420819, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEriZZD2QQ0JZhuoZCr3D2Lx04RULfXks5r1j13gaJpZM4NMdFH .

[sidoh]

Glad it's working. I've had instability like this before when my NRF didn't have a stable connection to my ESP. When I switched to soldered connections I saw this kind of thing less often.

What is the remote's model number (here's a product list)?

[spmp]

I cannot see the RGBW w/ saturation remote is not on the linked site, nor on the one I bought it from... but the controller is: http://www.limitlessled.com/shop/rgbw-led-strip-mr16-gu10-controllers/ See the bottom option in the drop down. Allows white as well as colour - my final goal . Cannot be bothered with straight colour - want bright w/ww strips and be able to tint them, if all goes to plan in the same way the redshift et al. does to correspond to time of day. Twilight can talk to a phillips controller to do this... The remote looks like this: http://futlight.com/productdetails.aspx?id=173&typeid=143 But the bottom buttons are not zones, they do white, R, G, B brightness resp.. The remote is setup stupidly, so hoping i can hack a http://futlight.com/productdetails.aspx?id=174&typeid=143 to give me what I want

The other remote (RGBww/cw) is: http://futlight.com/productdetails.aspx?id=161&typeid=143

http://futlight.com/productdetails.aspx?id=161&typeid=143 is quite over the top. may be good for controlling other things as well like blinds and fans or whatever 8)

The first remote is my real priority.

8)

On 3 May 2017 at 17:15, Chris Mullins notifications@github.com wrote:

Glad it's working. I've had instability like this before when my NRF didn't have a stable connection to my ESP. When I switched to soldered connections I saw this kind of thing less often.

What is the remote's model number (here's http://futlight.com/productlist.aspx?typeid=143 a product list)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sidoh/esp8266_milight_hub/issues/74#issuecomment-298824687, or mute the thread https://github.com/notifications/unsubscribe-auth/ADEriRaDEpUsjtC3hhYzZ7-Tl6OuWfhBks5r2A1VgaJpZM4NMdFH .

[sidoh]

This remote:

is "RGB+CCT." Have you tried using that one?

I think the other one you linked should be "RGBW" in the ESP.

[spmp]

Yup, you are right, the RGBWW/CW is indeed "RGB+CCT" colour temperature was not working properly last night, but all good now 8) The other remote is one sold to me as somewhat experimental. Would be great if the RGB+CCT could be spoofed to have the white on as well as the colour. Any way from your project to sniff all to get started with the weird remote? From http://www.milight.ca/wrgb-remote.html

[sidoh]

Are you not able to keep WW/CC LEDs on at the same time as the RGB LEDs? I have bulbs compatible with the RGB+CCT remote, and they definitely support having both on at the same time. The "saturation" control just adjusts the brightness of the WW/CC LEDs relative to the brightness of the RGB LEDs.

Re: your other remote --

Could you post a picture of it?

There are a couple of parameters that feed into the RF libraries for listening:

• A list of three 2.4 GHz channels
• Two syncwords used by the RF module.

I would start by compiling and flashing with the DEBUG_PRINTF flag, sniffing on existing channels and looking at the serial output.

If you don't see anything, it's going to be trickier.

The parameters for all of the other RF configs were borrowed from other projects. They're generally discovered by people disassembling remotes and attaching logic analyzer probes to sniff SPI packets.