@jim-p There's frequently more to the story. Who made you Grand Inquisitor anyway?
You obviously did not read the entire post and are just making guesses.
@jim-p Go play in the freeway.
I know you don't mean that.
What was the problem and "magic" solution to the failure of programming?
The problem was that although the module was correctly powered at 3.3V and the Rx and Tx lines were connected to the USB to TTL module the code refused to upload
What I had forgotten, but my notes told me, was that GPIO pin 0 needs to be connected to GND for the upload to occur and needs to be removed afterwards. After removing the link the reset button usually needs to be grounded briefly too
Doesn't that need to be connected to ground before you apply power?
It seems to work some of the time without power cycling, but not always, so you are probably correct. I have added the need to power cycle the board to my notes
Playing with the ESP-01 today reminded me of why I didn't persist with it due to the amount of faffing about needed to program it when experimenting
The board itself, being so small, could be useful for some projects so I might use it if the need arises
It became popular way back as a cheap and easy way to add Wifi to you Uno and most people used the AT command feature.
OK, on my own-built devices using ESP-07S and ESP-12 etc I always put two pusbuttons on the board:
- "Reset" connected between GND and RST
- "Prgm" connected between GPIO 0 and GND
Then when I want to use serial f/w programming I push the "Prgm" down and cycle the "Reset" button whereupon the programming software is able to communicate with the ESP for f/w reprogramming.
GPIO-0 is available on a pin on the ESP-01 so it is simple bridging it to get the wanted functionality
Although, if you gave it some thought, you'd see going that way doesn't make much sense given how much more capable the ESP8266 processor is than the Uno when programed directly in C++. It's only downside is limited GPIO. But, even if I needed the extra I/O, I'd go with ESP8266 + SPI I/O Expander over Uno + ESP8266 (limited to AT command set) any day.
Makes a lot of sense because there was no Arduino core for the ESP8266 when the ESP-01 was first introduced
So now I have almost completed the sketch but since C++ is not my language of preference I am struggling with syntaxes...
I almost never use C++ and therefore have a hard time looking up everything when I have to.
This is probably "for dummies" question but:
Since the only purpose of my device is to transfer the fact that the reed switch closed to another application (on Linux) via MQTT I figured I could send a time value so I can check how execution time varies (if it does).
So I want to do this:
unsigned long msgtime;
msgtime = millis(); //Time since reset.
send_mqtt_message(mqtt_topic_rain, msgtime); //What to do here with msgtime?
...
bool send_mqtt_message(const char *topic, char *payload)
{
bool result = mqtt_client.publish(topic, payload, false);
return (result);
}
The problem for me is how to format the millis() value into something compatible with char *payload in the called function?
Do I have to create a char buffer of suitable size (which size?) somewhere and then uses some obscure printing function to get my value into it so the buffer can be sent to the function?
How?
The first argument is declared in an include file as:
const char *mqtt_topic_rain = "aspo/meter/pulse"; // MQTT topic for the gaugue tip
But millis() is an unsigned long and needs to be converted... 
Other functions seem able to use constructs like this:
Serial.println(millis());
Sigh....
If you tweak the function signature slightly, it's easy
String msgtime(millis());
send_mqtt_message(mqtt_topic_rain, msgtime.c_str());
//,,,
bool send_mqtt_message(const char *topic, const char *payload)
mqtt_client.publish takes const char *payload anyway; it doesn't modify it (or the topic either).
Thanks!
I replaced the call to a publishing function with this inside the setup() function:
void setup() {
// put your setup code here, to run once:
Start_WiFi();
mqtt_client.setServer(mqtt_broker, mqtt_port);
mqtt_client.connect(mqtt_broker , "", ""); //No user/password in use
String msgtime(millis()); //New way to get the time value to text
mqtt_client.publish(mqtt_topic_rain, msgtime.c_str()); //Direct call, no function
mqtt_client.disconnect();
End_WiFi();
delay(50); //To let things stabilize
//Finished so go to deep sleep
ESP.deepSleep(0); //Wake up on reed closure via RST
}
It builds without complains so I guess it is sound.
That is because there are several versions of the print functions and the compiler chooses to use the one appropriate for the data type that needs to be printed. This is a feature of C++ known as function overloading
The authors of the PubSubClient chose not to provide multiple functions to publish data but it is easy to convert the unsigned long returned by mills() into a C style string and then use that as the payload
Here is my take on it that avoids using Strings
char buffer[30]; //somewhere to save the string
sprintf(buffer, "%ul", millis()); //convert value from millis() into a string
Use the buffer array in any place that you want a C string version of millis(), like this
mqtt_client.publish(mqtt_topic_rain, buffer);
But they did provide an overload of the publish() function that will work with any (trivially copyable) data type of arbitrary size:
boolean PubSubClient::publish(const char* topic, const uint8_t* payload, unsigned int plength, boolean retained) {
Of course, the code that receives the published data must know how to deal with it.
I have previously noted when dealing with microcontroller firmware (Microchip devices etc) that using sprintf() and printf() means that a lot of extra library code is being added to the binary so as to starve the flash for space holding the "real" code.
Since the ESP-01 has a minimal flash memory chip I like to not use them.
But for the Arduino system I have not really checked the difference between using and not using these functions.
Maybe String as datatype brings along a similar overload of support code?
Now received the ESP-01 and I am trying to figure out which exact type it is...
The IC to the right of the ESP8266 chip is an EEPROM size 1 kBytes by the part number printed on it.
Question regarding EEPROM storage:
Is this chip used for the handling of user EEPROM data using
#include <EEPROM.h>
Or is this system memory not accessible from user code so the simulated EEPROM is actually part of the built-in flash?
And how can I figure out the size of flash for this particular device?
No, it's 1Mbyte of flash where the program is stored.
which exact type it is...
It's an ESP-01