You are reading a single comment by @asez73 and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@asez73
Yes, the lines you gave fixed it.
I pushed those changes and some minor cleanup around there.
Since that, I think, you merged these in 1.72.
Yes but those defines just swallow some init code of the serial inf structure if there are no RX and TX macros predefined in the board. However, this is now a closed issue.
Well, I hope to get a reasonable result with voltage regulator simply because I intend to shutdown the ESP8266 as soon as possible and power it up only when required. All of that being done by a GPIO, potentially some current limiting resistance on the CH_PD, at that point specs say 0.5 nA which is admissible. This is a web connected sensor approach, not a web controlled system. The later would require a permanent connection which is just a terrible thing to do if you expect batteries to last for months or may a year...
It is still unreliable/unstable as this post explains. I faced some issues of this kind after 1 or 2 weeks with Xively+Wifly and even faster with CC3000. The CC3000 just never ever reconnected to my modem/router. The Wifly did required a full reset and software update, but keeped unstable on long term. Actually, those modules do have some problems with the unreliable aspects of Wifi and Internet: they all can fail without warning or error messages and apparently this mess up the wifi/IP stacks in their inner memory.
Aside of Wifi, Xively faced unreliablity due to the internet connection itself. Some data was never received at Xively even from a Debian PC connected through ethernet.