Tap on Push notification to connect automaticly

Sato

Thank you

Regards

kl3m3n

The notification channel is not tied to any specific device, but is determined by the application uuid. Therefore it is not possible to know which device you want to connect when tapping on the notification.

It is possible for me to add a new option to connect a default device automatically when application is started:
Right now, when you select "Autoconnect" feature and you have multiple devices, a list is shown and a device needs to be selected. I can add a new feature that automatically connects to a default device (if chosen) when starting the application. In this case, no list will be shown.

What do you think?

Regards.
Klemen

Sato

Hi @kl3m3n, wich you a happy new year

I appreciate the effort, but I think your suggestion to connect to a pre-selected device isn't quite what I thought.

The sugested function would be a TOP feature in Gui-O.

With 50 devices in Gui-O it's not easy to find in the list the one that you need to connect, now imagine 500 or more....

It would be great, but if you don't have a way of implementing it, there's nothing you can do.

Thank you
Best regards

Sato

Hi @kl3m3n,

I again

Can you think of any extra unique information that we could program into the device and send it as part of the text of the Push message that would help you solve this function?
Only a idea!

Regards

Sato

Hello @kl3m3n,

As I think it's desirable for everyone, I'm still thinking about it.
Can that work? Every time a new device is added to Gui-O, it could generate a unique small token like it already creates for "out" and "in", but much shorter, which we could program into the device to be sent with the push notification.
With this information, you might be able to automatically position the respective connection in the list???

Thank you
Regards

kl3m3n

@Sato Hi.

I am currently in the process of implementing standard way of push notifications handling (throught FCM). This should also show notifications when the app is not running.

I got it working, but I still need to implement the logic in the app. When I do this, I will again think about this feature. I think it should be doable.

Best regards,
Klemen

Sato

Hi @kl3m3n,

That's great, thanks

Regards

Sato

Hello @kl3m3n,

I've updated to 1.0.61.1
I don't know if there have been any improvements in push notifications, at least I haven't noticed much differences.

One situation that I wanted to report a few months ago is the following.
I receive notification "A", it displays "A"
I receive notification "B", it displays "A", "B"
In the notification I confirm "Clear All"
I receive a new notification, it shows "A", "B", "C"
Shouldn't only "C" appear?

Regards

kl3m3n

@Sato said in Tap on Push notification to connect automaticly:

Hello @kl3m3n,

I've updated to 1.0.61.1
I don't know if there have been any improvements in push notifications, at least I haven't noticed much differences.

One situation that I wanted to report a few months ago is the following.
I receive notification "A", it displays "A"
I receive notification "B", it displays "A", "B"
In the notification I confirm "Clear All"
I receive a new notification, it shows "A", "B", "C"
Shouldn't only "C" appear?

Regards

Hi!

IoT push notifications are a non-standard way of passing messages, while the new push notification feature offers a standard push messages mechanism:

based on Google messaging service (FCM)
if Android device is offline, the message should arrive when back online
you don't need IoT connection, you can send push messages in any communication mode (Bluetooth, USB, etc...)
notification is shown when it arrives and does not persist on the Android screen
Each notification gets a new message, messages are grouped

For new projects it is recommended to use this instead of IoT push notifications, which is a custom mechanism and does not handle some cases efficiently.

P.S.: I did not forget about your suggestion for auto connection when tapping the push notification.

Best regards,
kl3m3n

Sato

Hello Kl3m3n,
Ok, thanks for the info

Do I now have to change anything on my device?

I'm asking because I forced Gui-O to stop
in the smartphone settings. After that, my device sent a notification, it didn't arrive, I opened Gui-O and it still didn't receive it, since I only send the notification once, I'm sure it will never arrive.
If I understand correctly, isn't this the Broker's "persistence mechanism"?

Do I have to implement periodic resending on the device as long as I don't confirm receipt via Gui-O?

Initially I had it working this way, but to save data because it works with a GPRS modem and I have very little data available, I removed the periodic sending procedure.

"I haven't forgotten your suggestion....."
Thank you!

Regards

kl3m3n

@Sato Hi.

You now have two options for push notifications:

Standard push notifications (preferred / recommended)

This works without the foreground service running and ensures delivery, even if your device is offline (it will be delivered when back online). This uses Google Cloud Messaging and is the standard way of handling push notifications. You can use this in any GUI-O connection mode.

IoT push notifications

This is (my) custom delivery mechanism as it relies on MQTT.

I will explain why you don't in this case receive notifications if you are offline:
GUI-O MQTT broker uses persistence, but only in RAM.

Note that I did not implement reliable persistence (storing messages locally and recalling them if server has a power outage for example) as this would take additional resources.

That is why in normal GUI-O mode (when the app is opened), the client connects without persistence ("clean session flag" is always set to true). When using IoT push notifications, the cllient requests persistence ("clean session flag" is set to false), but as a new client id is generated on each connection, this persistence does not matter (persistence is based on known client id).

I will try to link the client id (which can be set in the app) to the IoT push notifications and test the persistence - this is currently low priority to me. Note that the IoT push notifications are currently not encrypted and can be potentially read by a third party. I will patch this ASAP.

To sum it up: I suggest for new projects you use push notifications as described here: https://www.gui-o.com/examples/gui-o-push-notifications.

Best regards,
Kl3m3n

Sato

Hello @kl3m3n,

Thanks, I understand
But both types are still supported, push notifications as well as the new ones via FCM, right?

My last suggestion of automatically positioning the Menu in the connection of the device that sent the notification, do you have any idea if it will be possible?

As always you make a good work, congrats

Regards

kl3m3n

@Sato I have added persistence to GUI-O MQTT broker (7 days), but only for IoT push notifications, not for normal connection (in this case, there is no persistence as it makes no sense). But, the only catch is that the MQTT messages need to be published with QOS (quality of service) at least QOS 1. Otherwise, the broker will discard the message. If published with QOS 1 or QOS 2, the broker will deliver the messages when the IoT push notification service is back online... Sadly, the PubSubClient used in the Android examples only supports publishing messages with QOS 0...

Of course, the push notifications that use FCM are persistent by default!

Still, I will deliver the persistence functionality with the new release.

After this release, I will see what I can do about your suggestion...

Regards,
Kl3m3n

Sato

Hello @kl3m3n,

Great, thank you

Best regards

Sato

Hello Kl3m3n,

The latest version .62 doesn't work well with push notifications.
Most of the time they don't arrive, and everytime the device sends the notification, it freezes for a while, often even stops communicating and after a while resumes the MQTT connection.

I haven't tested FCM notifications yet, but I'd like to know if Gui-O can support both?
At the moment, as it is, it is unusable.

How can i get back to .61 version?

Thank you
Regards

kl3m3n

@Sato Hi.

Can you try again now? I have made some changes to the broker.

I don't see how the app can be the problem, since no major changes were made to IoT push notifications.

Do you have Mqtt clientId set or is it empty?

Yes, both types of push notifications can work (even simultaneously).

Regards,
Kl3m3n

kl3m3n

@Sato said in Tap on Push notification to connect automaticly:

Most of the time they don't arrive, and everytime the device sends the notification, it freezes for a while, often even stops communicating and after a while resumes the MQTT connection.

You mean when the microcontroller device sends a notification?

Sato

Hi @kl3m3n,

It's still not working properly. What I can see is that whenever Esp sends a notification, it freezes for about 5...10 seconds then it continues to communicate. I can see it on the led on the pcb board, which is always flashing as long as I have an internet connection.
With version 6.0 this didn't happen, it didn't freeze when sending a push notification.
Another issue is that the app now freezes so often that I have to force it to stop.
I haven't changed the App settings, the Mqtt clientid is still Not set

Regards

Sato

@kl3m3n

Yes, right allways the Esp send the Push notification

kl3m3n

@Sato What freezes? GUI-O app or ESP? Both?

Can you try setting the clientId to something unique and reconnect (disable and enable IoT notifications)? And see if the problem persists?