B4R Question ESP-controllers and Push notification receiving

[peacemaker]

Hi, All

Am i right thinking that to get Push-notification there should be a HTTP-service that periodically pulls some server ?
I mean if we write code for MCU - is it the same: pulling a server by HTTP-requests directly, and no any use to have a Push-notification service on MCU ?

 

[janderkan]

https://www.b4x.com/android/forum/t...ons-to-ios-and-android-devices.71507/#content

 

[peacemaker]

I'm about receiving notifications on MCU

 

[Erel]

I guess that you are not asking about Android or iOS push notifications. You will not be able to receive such notifications.

If you want to send an incoming message to an ESP then you can quite easily do it with MQTT or WebSockets.

 

[peacemaker]

Yes, Erel, about receiving.
I meant the principle - any background service on a device should pull th server all the time to be able to get incoming request ?
It's for such situation: ESP MCU is used for making a sensor that works on battery, with periodical sleep. And how to pass to MCU some setting\parameters from a server ?
Now i add a command to a table of server, and MCU has to pull the server each 15 seconds: better to sleep longer, but ... how to make it responsible... not to wait for hour for each command.

 

[hatzisn]

1) Create a B4J Application which has MQTT Server that exposes port {#port} and it also has an MQTT client impemented and that has access to DB
2) Connect the B4J client to 127.0.0.1:{#port} and subscribe to channel "CHANNELNAME"
3) Connect ESP8266 to this server with rMQTT library and subscribe to channel "CHANNELNAME"
4) When someone posts to this MQTT server to channel "CHANNELNAME" a JSON for example like {"cmd":"send", "value": 1} it will parse the json and according to cmd it will save to the DB
5) The ESP8266 wakes up and publishes to this MQTT server to channel "CHANNELNAME" a JSON for example like {"cmd":"pull"}, the MQTT server gets the message and according to the cmd it will pull the last value that was saved and post it through the MQTT client to channel "CHANNELNAME" with a JSON for example {"cmd":"resp_pull", "last_cmd_id": 1, "value": 1}. The ESP8266 waits some milliseconds to get the answer, saves it to the EEPROM and goes to sleep again until the reboot.
6) Next time the ESP8266 wakes up it reads the json saved in the EEPROM and creates a new json like {"cmd":"pull", "last_cmd_id": 1, "value": 1} and publishes it to the B4J app and if the last_cmd_id is lower than the last cmd id that was saved in the DB the same thing happens again as before (B4J app reads last saved value -> B4J MQTT client posts -> ESP8266 receives -> ESP8266 writes to the EEPROM the response and goes to sleep).
7) Goto 6 again and again. This command is for the MCU but you can continue to the next line
8) Have fun programming it


P.S. There is a catch though in this solution but there is no other solution - at least that I can think of. You will be able to write to EEPROM only around 100000 times and then it will not work but you can extend EEPROM's working time by not saving anything to EEPROM if the response of "last_cmd_id" is the same as the one that has been saved in the EEPROM.

 

[janderkan]

4) When someone posts to this MQTT server to channel "CHANNELNAME" a JSON for example like {"cmd":"send", "value": 1} it will parse the json and according to cmd it will save to the DB

When saving, give it a running number.

When Esp wakes up, it requests all new messages.
If server doesn´t know the client, all messages is sent and the server saves the client id and the last sent message number.
Next time the client connects, the server knows the last sent message number and will send all newer messages and save the last sent message number on the client id.

Now you dont kill your eeprom.

 

[hatzisn]

When saving, give it a running number.

When Esp wakes up, it requests all new messages.
If server doesn´t know the client, all messages is sent and the server saves the client id and the last sent message number.
Next time the client connects, the server knows the last sent message number and will send all newer messages and save the last sent message number on the client id.

Now you dont kill your eeprom.

Thanks for the correction. Even though I am mentioning it later as "last_cmd_id" indeed I hadn't written it in number 4. This could be an identity integer field so that it does not have to insert the value himself. Great additions also that I didn't think of in a glimpse of an eye. Why save to EEPROM while you can save last sent ID in DB with client ID? Maybe if I had spent more time analyzing I would have thought it but I really wanted to end writting to create something else I was about to design at that time.