ESP8266 Community Forum

- Mon Jan 12, 2015 1:56 pm #7110 I was using old code - a week ago the callback didn't work - does now.

Last edited by scargill on Mon Jan 12, 2015 4:25 pm, edited 1 time in total.

Peter Scargill - http://tech.scargill.net

- Mon Jan 12, 2015 2:16 pm #7114 @scargill: callback works fine for me - but it was added several days ago, I hope that you are using the most actual code?
You also have to "register" this callback - I have added

Code: Select all MQTT_OnPublished(&mqttClient, mqttPublishedCb);

in user_init().

@kenn:You may use so-called "retained" messages. See http://mosquitto.org/man/mqtt-7.html for details.
In general, you need one publisher (probably at the same "machine" where the broker runs) that constantly (e.g. every 1s) publishes current time at specific topic, e.g. "/global/timestamp" as retained message (-r option of mosquitto_pub).
This solves 2 issues:
- if a client is staying connected it will receive new update every second
- if a new client (or just waking up from deep sleep client) connects and subscribes, it will get the last value of the timestamp topic.

One thing that I just detected - according to Tuan example, subscription is done in wifiConnectCb(), right after the Mqtt_connect() call. This is wrong - the broker is not yet connected so subscribing doesn't work. I had to move the subscribe call later, in my case in the mqttConnectedCb(). Now I get "MQTT: Subscribe successful" in the log, it was missing before that. Now I get data when somebody publishes at this topic.

What I still don't get is how to "delete" retained message - my goal is that this retained message is used as command to the ESP. When ESP wakes up it connects, subscribes and gets this command (published by remote control application). When the ESP gets the command it processes it and probably deep sleeps again. My problem is that at next wake up I get the same retained message (command) again and I don't want to. I need a way to "delete" this retained message.
This is quite nice mechanism that allows to "post" commands even if the ESP is currently not connected. But I need a way to "acknowledge" this command and to remove it.
This can be solved if I publish a message that notifies the remote application about command execution. So the remote application (the one that had sent the command) knows that processing is over and can "delete" the command message - or send a new command by publishing again the next one.
This will be a way of request-response management over MQTT topics - but I am not sure this is the best one?

- Mon Jan 12, 2015 2:55 pm #7118 Yup - old code!

@scargill: callback works fine for me - but it was added several days ago, I hope that you are using the most actual code?
You also have to "register" this callback - I have added

Code: Select all MQTT_OnPublished(&mqttClient, mqttPublishedCb);

in user_init().

@kenn:You may use so-called "retained" messages. See http://mosquitto.org/man/mqtt-7.html for details.
In general, you need one publisher (probably at the same "machine" where the broker runs) that constantly (e.g. every 1s) publishes current time at specific topic, e.g. "/global/timestamp" as retained message (-r option of mosquitto_pub).
This solves 2 issues:
- if a client is staying connected it will receive new update every second
- if a new client (or just waking up from deep sleep client) connects and subscribes, it will get the last value of the timestamp topic.

One thing that I just detected - according to Tuan example, subscription is done in wifiConnectCb(), right after the Mqtt_connect() call. This is wrong - the broker is not yet connected so subscribing doesn't work. I had to move the subscribe call later, in my case in the mqttConnectedCb(). Now I get "MQTT: Subscribe successful" in the log, it was missing before that. Now I get data when somebody publishes at this topic.

What I still don't get is how to "delete" retained message - my goal is that this retained message is used as command to the ESP. When ESP wakes up it connects, subscribes and gets this command (published by remote control application). When the ESP gets the command it processes it and probably deep sleeps again. My problem is that at next wake up I get the same retained message (command) again and I don't want to. I need a way to "delete" this retained message.
This is quite nice mechanism that allows to "post" commands even if the ESP is currently not connected. But I need a way to "acknowledge" this command and to remove it.
This can be solved if I publish a message that notifies the remote application about command execution. So the remote application (the one that had sent the command) knows that processing is over and can "delete" the command message - or send a new command by publishing again the next one.
This will be a way of request-response management over MQTT topics - but I am not sure this is the best one?

Last edited by scargill on Mon Jan 12, 2015 4:25 pm, edited 1 time in total.

Peter Scargill - http://tech.scargill.net

- Mon Jan 12, 2015 3:40 pm #7121 You've made some assumptions there... the ESP8266s are best used as smart endpoints.. then they'd need to know the time. The ESP8266 does indeed have a clock - but as far as I'm aware no-one has implemented it. Perhaps you're assuming 100% reliability of the sending system. For example - lets say I have an ESP8266 controlling a heater - I've sent it a message to say turn the heater on - and at some point I'll say turn it off - and what happens if it loses the connection. The smarter way and WELL within the capabilty of these devices - is to sent a message to say - turn the heat on - keep it at 20c until midnight - -that is until a better instruction comes along - if that doesn't for any reason - then the unit will operate stand alone. I already have Arduino devices doing this and operating systems across Europe.. I want to do away with the Arduino.

What I'm seeing here is the possibility to use this code as the base for communications - and so an RTC is needed. Anyway I've now implemented that (its on my blog) and have a full RTC running updated from an MQTT timestamp - which is needed only every day or so if that (or on request on powerup of course). I also have temperature sensing and control of a solid state relay. Controlling serial LEDS didn't go so well due to compiler optimisations getting in the way of the tight timing needed for said devices - I'm hoping someone will crack that for me. All that's needed now is for the queue to work - for reasons utterly beyond me the callback set up here in the init function simply isn't working when you publish something.

MQTT_OnPublished(&mqttClient, mqttPublishedCb);

It should be sending an info message to the serial line and it's not. I've implemented a crude queue already but until this callback works I can't use it.

In any real world stand alone application we need to know the time - now, subscribing to the time is no problem but right now we can't run a clock.. again - in my christmas wish list, if the board could subscribe a standard "seconds since 1970" timestamp - and anyone can do that, but then store that value somewhere and have the processor handle the 1 second tick. A simple callback routine in user_main would call every second - passing the timestamp to the user code - that would just be SO good.

Hi Peter, I've seen you raise this issue a few times, and I confess I can't see why it would be that useful for the ESP8266s in a system to 'know' and keep track of real time. At least at this initial stage, where the ESP8266s are best used as smart 'endpoints' in a MQTT network. As I see it, the scheduling comes from a central controlling app, and the endpoints are simply required to provide sensor readings to the central controller at a predetermined interval or on command, and to control loads upon command. I believe the ESP8266 has a basic clock system for accurate intervals of up to a few hours, more than adequate for simple timing tasks.

The MQTT protocol has keep-alive pings and this library has implemented them, currently at intervals of 2 minutes. If real time to the ESP8266 endpoints is critical, I suppose you could rewrite that so that every ping from the ESP8266 is instead a request for time. Or the central system simply keeps farting out timestamps and anything that needs to know the real time can subscribe to it.

Peter Scargill - http://tech.scargill.net