Pixl.js with Wifi (ESP8266 ESP01s) - SOLVED

@robin. the code is the exact same from the example: http://www.espruino.com/Pixl.js+Multicol­our#esp8266-wiring

and doesn't change from working to not working.

NOTICE that the lights SEEM to be on. and I have a feeling that when I get home I'll measure that drop that you DON'T see in the youtube now.

Sun 2019.12.15

Thanks for taking the time to shoot the vids @DamianMontero. That will assist others.

I don't have those boards, but I believe the issue is that there isn't any start up code available once the save() command is issued. That, or as I hinted to in posts #42,#48,#49 that a race condition exists between the Pixl and 8266 initializing at different intervals. Maybe a Pixl data line is in the wrong state or delayed too long, or something of the sort. As it appears editing the code has been successful, in order to 'save()' again, if that state can be gotten into again, I'd try the following:

Here is a snippet I use. Would be interesting to see if after a save and restart, if both boards remain active.

Will have to wrap the var wifi = section with a function and call that function inside the timeout below. The 'var wifi' will need to be defined outside that function, to be global to other assignment.

Place this as the very last section.

example

// Note: save() must be entered at least once before this will take effect

E.on('init',function() {
//  setWatch(kill, BTN, { repeat: true, edge:'falling' });
  setTimeout( function() {
    console.log("Hello World!");
//    st();
//    console.log("Receiving\n");
//    rx();
    
  }, 1500);
});

@DamianMontero, are you sure that the pins of the ESP8266 are held at required state on start up? ...that could explain that it worked while measuring... Check description which pins have to be held high or low so that ESP8266 does get into runtime mode.

@robin.
I understand that code. but can't see what it would do. You are essentially asking me to have it wait for the init. then wait 1.5 seconds and then call the method to connect to the internet. Is this correct?

I've tried something similar in that I put the intial call on a timeout of 5 seconds and it didn't help.

plus I'm just wondering why it'll sometimes work (after a couple of days of not working) but only in debug mode.

again. it's no consitant. It's not a save or a reboot or code that changes it. It's just waiting.

@allObjects I think you're talking about the same thing that robin is talking about. Having the system wait a while and then call the request.

I have the system poll the price ever 5 minutes. I tried that every 2 minutes and waited (the 2 minutes) and the second call failed just line the first on the initial bootup.

'me to have it wait for the init'

The E.on('init' runs after all the code is uploaded.

http://www.espruino.com/Reference#l_E_in­it

'then call the method to connect to the internet. Is this correct'

Effectively yes, but with what ever values would work with the boards you have. Without calls to your code being inside an init function, the demo code you are woking from is attempting to setup the WiFi module at the same time that code is being uploaded through the WebIDE. After save() and no WebIDE, nothing is properly initialized as the init() function fires. That said, the following trio are more likely the culprit:

'plus I'm just wondering why it'll sometimes work (after a couple of days of not working) '

Yes, we are also!!

'but only in debug mode.'

Am I to take this to mean when running within the WebIDE?
Are the devices remaining powered up during this waiting period?

'I have the system poll the price ever 5 minutes'
post #51 'the code is the exact same from the example'

From that reply, I have to make the assumption that the polling process is actually more code that was added to the 'exact code' that was implied in post #51?

Which means as @allObjects suggested a week ago, that something in the http request section is locking up? Looking for that post reference. . . .

EDIT: Damian, see @allObjects #34 post regarding function getPrice() that I pointed to in #33 from the code snippet you posted in #32. Should this function be part of the 'exact code' as you put it; Is the http request being closed? Posting that function with your p/w credentials replaced will help us all here. Q: Does the board pair remain functioning when the getPrice() function is removed? It is starting to look like a combination of factors. . .

Could it be that the WebIDE Chrome Window (browser) is actually assisting in keeping the connection alive. Then after a few days of off time, all http (or WiFi) stuff is effectively re-init'd?


EDIT:
and what about the hardware watchdog? This comment is more for the others, and as I have no experience with the -01, so am not sure how to do this 'feeding' task using Espruino as there is no loop() function as with Arduino.

https://techtutorialsx.com/2017/01/21/es­p8266-watchdog-functions/

@DamianMontero,

no offense, but Espruino is never about waiting... no wait what ever configured will be right. In Espruino things are event driven, and at worst timer-event driven to poll / check (for) something.

Depending your power situation and the given 5 minutes, it could well be that during the inactivity you completely disconnect from WiFi after completing the poll activity (get price), and a bit less than 5 minutes later you start all over with 1st powering the WiFi (module), then connect to the module, then connect to WiFi, and then make the request. To make sure and support retries of poll activity is successful, you start a smart - learning - timeout that triggers a retry before 5 minutes. This timeout is cleared as soon as the poll activity completes. The smartness would try to adjust - in an range of absolute min-max range to the sweet spot or range where you get 90% success rate. You also begin to built a FIFO w/ statistic data to mark the time (1st to 296 (12*24) 5-min-events per day with 0..255 two-second units of completion time... - that costs you only about 600 bytes. You can even show a graph of successes - dot or no dot (or even time (w/ shorter or longer vertical line of one to n dots). Over time you may then notice about the average connect/execute time at times of the day. I'm sure there is variations.

To start from scratch with building up connectivity and tearing it down after completion, you save the code in disconnected, nothing active state, not even with a timeout running. All your activities are in (nested) functions that you call with the top-level function in onInit() with an interval... or better - timeout. The timeout time is calculated from the current time and the next 5 minute time point of the day. You do that to allow dynamics that come with retries,... and are needed for building statistics ( where you know when the last success was and how long it took. In other words there is also as 5 minute interval set to update the statistics. This update is independent of the rhythm of the poll activity. The statistics taking on 5 minute interval just pushes / places the last time of day with completion time into the FIFO / ring buffer since last taking the statistics.

While you develop, you monitor with the IDE connected over BLE. Take a look at @JumJum's testing feature (enable it in Espruino Web IDE settings). It can draw you - in your IDE - multi line graphs and even write logs to file.

Just to add you're fine to use either of the 2 headers. Both have 3.3v and GND, and you can configure the UART on whatever pins you want.

Potentially you don't even have to unsolder the existing Module and could just try another on the other pins as well.

@Gordon I'll try that tonight. just got the headers to solder in.

QUESTION: is the pins in the bottom also repeated anywhere else in the board. I then can bodge some wires to see if it's a hardware issue.

I keep insisting it's hardware because it changes even when the code doesn't.

I've ordered another pixl badge and I'll also try this same code with the EspruinoWifi and the LCD board I made the driver for previously. But it's a different library. but we'll prove I guess that the code isn't an issue.

is the pins in the bottom also repeated anywhere else in the board

Unfortunately not (apart from on the MDBT42 module itself) - however on nRF52 basically any pin can be made to do anything, so part from losing some IO you won't have lost any functionality.

Thank you Gordon; That means I'll put the headers then put another module and pins to do the work to figure out the issue. I'm guessing it's me having killed the pads on the pixl.js bottom pins and for the next one I WILL put in headers so I can put in any module and throw out any bad ones.

This is one of the best IoT products ever and I just LOVE to have this on my neck!