Thanks for the answers guys. I actually got myself an Arduino Uno even before discovering this as I needed to reflash the ATmega to implement the buzzing feature, however unfortunately I can't flash the ESP yet as the USB adapter to flash it arrives tomorrow. I'll keep you updated!
Just a quick heads up: the problem was indeed that a wrong firmware was initially uploaded on either the ESP or the ATmega (or both!). Once I flashed the correct firmwares on both of them they work beautifully together, and changing settings on the ESP web UI now just works. Still waiting on the Nano to proceed on the buzzer side!
You could use the ESP8266 as the alarm master. It already knows what time it is and it serves up the GUI that is used to configure everything, which I assume you would want to change. This has the benefit that you wouldn't need to poll the ATMega from the Nano and you can stick with just one bus master - I'm not sure the ESP8266 can co-exist with another master.
The ESP8266 would just push alarm data to the Nano rather than the ATMega. You could decide whether you want the ESP8266 to monitor the alarm or whether the Nano would do that. If the Nano does it, you would probably want to push the time to it as well as to the ATMega.
You might also look into the Tone library for Arduino.
That's an interesting idea. Right now I made progress using the Nano as another master on the I2C bus, and the basic functionality of the alarm works. The Arduino Nano periodically asks the ATmega if it should ring its alarm (which is just a piezo-electric buzzer connected to one of the analog pins of the Nano, which also allows me to play tones). Code-wise, since I2C does not provide an easy way to discern who's the master that is asking data from the slave (and I don't want the ATmega to send me all the configuration stuff that the ESP needs), the Arduino Nano sends a "I2C_ON_REQUEST_PROVIDE_ALARM" message to the ATmega, which then allows the Nano to receive the expected data when asked. This should not be prone to race conditions as the I2C bus is never released between the message and the data request. The rest is just basic stuff and an extension of what's already there (reading/writing of the alarm from EEPROM etc.)
For now on my todo list there's the following:
- I will try and see how it works using the ESP as the alarm master. It's a bit more of a pain to do because I can't directly debug/program the ESP and connect it to the Nano, as I do not have a level converter which allows them to communicate.
- Once I get the alarm set up and working, I'll also try to make the ESP discoverable using UDP broadcast packets, which should be easier than the current way of "going to your router and finding the ESP's IP address".
It's been a while since I messed with Ian's ESP8266 code, but all my own code uses mDNS to broadcast a hostname. So if you set the hostname to 'myhost', you would access it using 'myhost.local'. This requires that your system is running an mDNS service, but all modern systems do (Windows 10, OSX, iPhone etc.). If you run iTunes, it installs one - Apple call it Rendezvous.
You could also replace how the original AP/STA connection is set up by using
Finally, you could include OTA in the code, which would allow you to update the code in the ESP8266 over-the-air. Though I haven't found this to be terribly reliable.
I've added a suggestion to the Github repo for the first two.