ESP8266 Community Forum

It's great to hear how far (thousands of miles) Livetv has taken Esp_Basic out into the real world... http://www.esp8266.com/viewtopic.php?f=40&t=12258

And it's obvious from comments that reliability and fault tolerance are becoming more important, if problematic.
So I thought I'd mention a ghost of a hardware idea that might offer a potentially useful alternative direction which may be of interest to someone.

I keep 'feeling' that there could be some value in stacking a couple of ESP-12F's above each another - using roughly half-inch straight-through connecting wires for power and some common control pins, but criss-crossing TX & RX, and connecting a gpio from each to the others reset.
A sort of 'double-decker ESP brick'.

It would offer a more powerful dual processor node with extra IO if needed.

But it could also offer independent Quality-Of-Service monitoring - of each other and/or the network - with one hopefully always surviving to take corrective action for the other when needed.

They would both have the same common default.bas script plus the same primary.bas and secondary.bas scripts.

The common 'Default' script could check at bootup for something like a serial response (or even a gpio pin state) to decide at startup whether to load the 'Primary' or 'Secondary' script depending on the order they start up in... possibly influenced by the presence or absence of a serial response. A reset hardware timing delay (capacitor) could be added to one of the chips to cause one ESP to always start before the other, but I don't think it would be necessary unless wanting to check for pin states rather than serial response. A software time difference could be implemented according to the unique last IP address byte, ie: DELAY LastByte * 200 would ensure a minimum difference of 200ms even for consecutive DHCP addresses.

The Primary script would 'do the main business', and the Secondary might just keep checking status of the primary while remaining on standby to load it's own 'Primary' script and take control if the existing primary or it's network connection failed, then the failed primary could be rebooted again as a secondary. The primary could send all relevent variables via serial for the secondary to save to flash, so whenever there was a role reversal it could be fairly seamless.

The secondary might do other tasks besides just monitoring the primary's health - it could offer availability of a 2nd TIMER facility, or another pin INTERRUPT, or a myriad of other possibilities, including additional independent functionality if required.
It should be possible for the 2 ESPs to share hardware resources, because only the primary would be configured to actively drive shared output pins, and inputs could simply share a common pullup/pulldown resistor.

Slight tangent... they don't have to be double-deckers, ie: a couple of ESP-01's stacked end to end might be used as a physical wifi(1) to wifi(2) bridge with integrated monitoring and signalling.

Just offering some food for thought for anyone who might be interested.

An interesting idea worthy of further thought!

I use a similar principle on my solar heating system in Spain. There is a board which monitors 18 temperature sensors in various places which feeds data to a controller (in this case, a small PC) which then controls pumps, valves etc.

If the PC fails or hangs, there is the danger that the primary circulation could stop and cause the solar tubes to overheat. Similarly, if the sensor board stops working, the same problem would arise.

So there is constant checking by each component that the other is working correctly. If the sensor board fails to get a response from the PC it cuts the power to the PC for 30 seconds and then reapplies it, allowing it to boot up afresh. If the PC fails to get a response from the sensor board, it cuts the power to that and resets the serial port before re-applying power.

So far this system has worked effectively!

Phil

Fault tolerance is important! Right now my ESP8266 nodes have worked well except for the one with (what appears to be) a low signal problem with the router. What got me a few days ago was the need to reset the router and DSL modem. Had to call a cousin to go and do it. Since I don't have temperature sensors upstairs (and should) I'm planning to build a new node into a small power strip. This node will monitor two temperature sensors but it will also supply the power to the router and modem through a normally closed relay. This node will look for connectivity problems and reset the router & modem (via the relay) if it senses that the internet is not reachable. I plan to build and program the whole thing and mail it to my cousin for a simple plug-in install.

I want to have nodes able to reset each other. The problem is that I don't want to use long lengths of wire for this. I'm contemplating using these cheap 415mhz transmitter/receiver combos to trip RST pins but I need to insure that these won't have interference problems with other devices using that frequency range.

Another option is a fairly simple "deadman's switch" that will pull down a RST pin if the node doesn't send out regular heartbeat pulses.

Lastly, I keep wanting to put together some sort of mesh network with the intent that nodes will self-correct connection problems and automatically relay data so that distant nodes can still reach a router. Basic will probably prove too slow for anything requiring high speed or volume of data but rudimentary data collection might tolerate it just fine.

It sounds like you are tantalisingly close to your mesh network, I'll be quietly hoping for news on that in due course.

For the cost of an extra couple of quid/dollars whatever, if you could have a primary ESP doing it's primary function, and an intimately attached secondary ESP sharing resources as a standby mirror ready to take over as primary in the event of primary failure, wouldn't that give you sufficient resilience?

The secondary could keep monitoring for online server pages, temperatures, primary heartbeat, and whatever else was appropriate, and at any sign of problem could grab the primarys variables etc, promote itself to primary, and reboot the sicko to secondary, where it would hopefully be evailable as a standby mirror again. Having a secondary acting as primary mirror gives you an independent standby machine to connect to and even SAVE an updated script to if wished, and all without affecting the primary or it's roll.


The main question I need to answer is about future reflashing. If only one chip is started up in flashing mode (by the other), will it still be flashable with it's TX and RX tied to the other - and if not, might it be possible using a couple of diodes to prevent one dragging the other.
Or would it be better to use OTA.

I'm hoping to be able to answer that question this weekend by using a couple of single-inline ESP-12-based modules that will both fit a breadboard... I don't want to be welding anything up and burning bridges until it's been ckecked out.

I've actually had quite a few more thoughts about the subject, in fact the 'ghost' of an original idea is starting to haunt me and cause sleepless nights.

As mentione previously, two linked similar ESP's would be great for rolling out a program change or update, and with minimal disturbance of primary function - just connect to the secondary and upload (SAVE) the new script, then role-reverse between old primary and updated secondary when convenient... with the insurance of automatic fallback to previous if necessary.

There's no reason why operations such as role-reversal can't be triggered by either the secondary or primary if necessary - it would just be a matter of having appropriate serial commands that could be sent and/or received by either, in the same way that either could be instructed to reboot the other. Another useful command might be to instruct the target to un-asign all outputs (or re-asign as inputs) to prevent any shared resource conficts during the role-reversal handover.

The 'double-header' serial vocabulary could be kept simple and minimal... but there's no reason why it shouldn't include commands to request transfer of flash variables from one to the other prior to role-reversal handover, or instigate any required interaction between primary and secondary at any time, including sharing resources (eg: signalling TIMER events or INTERRUPTS) between them both. I can see that some thought is going to be needed to draw up a list of viable serial double-header commands for optimal control and interaction of 2 ESP's:
RemoteReboot (delay)
RemoteEnd
ReadLocalVars 'needs to maintain a Vars list, perhaps as a Flash Var.
WriteLocalVars
ReadRemoteVars
WriteRemoteVars
UnAsignRemoteOuputs
UnAsignLocalOutputs

...enough already - getting too haunting!

But at the risk of causing confusion, it might be worth pausing a moment to see where it might actually end up... cos with a list of possible 'double-header' serial commands, many of them might be just as useful for interfacing an ESP to an Arduino and sharing its resources.
Obviously the arduino cannot act as an ESP standy primary mirror, but it could still intimately monitor and control the primary, as well as having potential to bring all of it's own resources to the ESP_Basic party - such as extra timers and gpios and possibility of wired network etc - which could be a worthwhile target just in itself.
Anyway, I going to bed and need to try to think of something else or it's going to be another sleepless night.