ChipChop Forum

REPLIES: 18

REPLY TO THIS POST

Gizmo
26 Jan 2024

IoT Push Notifications

This is a new feature that enables you to send IoT Push Notifications form your devices directly to your phone or desktop.

It has been an adventure making this happen and true to the ChipChop modus operandi it is a native ChipChop system not dependant on any third party services. It has required a deployment of a completely new specialised server that has one and only extremely boring job... to handle push notifications for your devices!

As always, I have prioritised making this available to everyone quickly so I am assigning this a Beta status. This is a complex functionality that can only be truly tested through real life use so please make an effort and report if you come across any problems.

Usage Guidelines

1. This feature is mostly intended to be used on a phone and requires the WebApp to be "installed". This is anyway how the app should be run and all you need to do is to use "Add to home screen".
Make sure to access the WebApp through browser first using https:// as it is a security requirement (i.e. https://my.chipchop.io)
tip: Don't bother logging in when you first open it in the browser as when it gets added to the "Add to home screen" it's a completely standalone thing with it's own sandbox and that's when your automatic login can be saved.

2. The functionality requires a permission to be granted on each device you want to accept push notifications (phone, browser, desktop). This is no different than with any native app and follows the same notifications permission protocol.

3. You will find the "enable/disable" toggle button on the WebApp dashboard. The first time you start it you will get the native system permission prompt like with any app. If you don't get the prompt please report it here and specify what device/OS/browser you are using.

4. The notifications work through ChipChop Actions and are very simple to setup. You just have to specify "Notification" as a target and give it a message that you would like to receive.

For example

IF
Trigger Device -> Garage Alarm
Trigger Component -> Motion Sensor
Value is -> DETECTED

THEN
Target -> NOTIFICATION
Send Notification -> "Garage Alarm - Motion Detected" (this is the message you will receive)

WHEN
Any Time / Every Day

IMPORTANT

To avoid getting yourself flooded with your own notifications it is an important practice to "reset" the state of whatever is the trigger for this action.
So, if your motion sensor detects motion you would normally send a triggerEvent straight away with the sensor's status "DETECTED". In the example above that will trigger the Action BUT if you don't reset the status on the next heartbeat to "NOT_DETECTED" the action will keep executing pretty much every 10 seconds and you will quickly use up your available allowance (see usage limits below)

NOTES

1. For iPhone users, this functionality is not available for iOS below 16.4
2. For Mac OS users it is also possible to add the WebApp as a standalone full screen app to the dock directly through Safari.
3. To disable the notifications I would recommend that you use the button in the ChipChop WebApp rather than using the native OS notifications settings as the app will properly inform the OS anyway and also automatically inform your ChipChop API server not to bother sending you notifications for that device anymore.

USAGE LIMITS

As this is a costly processing feature that puts a lot of pressure on the network, I have put some usage restrictions and also to prevent issues caused by general user stupidity (you know who you are and you will do it, this is for your own good!)

1. The current usage allowance per community account is 600 notifications per month shared between your devices. That gives you an average of 20 notifications per day which should suffice handling things like motion sensors, door bells and general alerts.
This is not fixed at 20 notifications per day but rather a monthly total that refreshes itself every month.

2. The speed of sending is set at a maximum of 3 notifications per minute

If you are working on a project that may require a lot more notifications for testing purposes, let me know and I will see if I can allocate you more

Attached images

Son1cb00m
27 Jan 2024

I didn't think you could do that with web apps!???

It works man, kudos for the simplicity of use, I can't believe that I am actually happy to get notifications, can't stop pinging!

This opens up some very cool possibilities.

The Hammerhead
27 Jan 2024

That's it I officially need to get my head checked, I think my IQ has dropped below acceptable levels!!!!!

I've update the ios on my phone two days ago, saw this in the app and honest to God thought how nice of Apple to make this available!

Svetlana Simic
28 Jan 2024

I add notification to my door bell and it work great! So simple, thank you :)

Down Under
28 Jan 2024

Is there a technical reason why we couldn't have a "direct" triggering of a notification straight from a device?

What I mean is could you have something like

        ChipChop.triggerNotification("some string message");

        or event shorter

        ChipChop.notify("some string message");

        or

        ChipChop.iotNotify("some string message");

you see what I mean?

If it would use the same mechanism as "ChipChop.triggerEvent()" it should be super fast, right?

Don't get me wrong, I am not saying there's something wrong with it as it is, just thinking that it may be more intuitive to use if there was a "native" library approach rather than using Actions?

Arduino Geek
28 Jan 2024

my dear @Down Under so let me anal-ise your thinking process:

You can send trigger events in 500ms bursts up to 10 per minute so you will be happy to receive a notification every 500 milliseconds!!!!
I get all jittery if I get 2 notifications PER DAY! Would end up in the loony bin if it was one every half second.

plus, you would also run out of notifications for the entire month in what 10 minutes?

Down Under
28 Jan 2024

my dear @Arduino Geek, I find your comment discriminating and non-inclusive. I am different than you and thrive on notifications. The more the better and the faster they come gives my life a meaning ;0)

Anyway, you are wrong, the "usage limits" above clearly state that it's limited to 3 messages per minute.

So the correct answer is that you will run out of notifications in 600 / 3 = 200 minutes / 60 = 3.3333 hours

It's a small price to pay for the joy it brings me and G will give me more on medical grounds 🖕

Gizmo
28 Jan 2024

@Down Under mate, you are not getting a bigger allowance for those "medical" reasons!

Joking aside, yes, you have a valid question...but...the implementation already works like that :-0
Granted, yes, there is no ChipChop.notifyTrigger() or such in the lib but you actually don't need it and you probably don't want it.

Here's my reasoning behind the way this feature is implemented.

There is no technical barrier for the notifications to use the triggerEvent mechanism allowing a "direct" route from the library as on paper this is the fastest route to signal something from a device to the ChipChop engine.

In reality that is already happening, I don't know what you have used to trigger a notification in the Action but if you have used a triggerEvent from a device you would have noticed that it's as instant as the triggerEvent.
Delivery speed purely depends on latency and whatnot Google/Chrome & Apple/Safari endpoints are doing at their end, which is beyond my control, but at least there are no extra "hops" to some extra third party service on top, it's straight from the new ChipChop notification server all nicely encrypted and signed.

You can test that by hooking up an triggerEvent on some button, setting an Action to send a notification when that button changes state and watching the button in the WebApp.
When you press it on the device you should see instantly the button state to change in the WebApp and a notification will pop straight away.

So, what's happening there. Actions logic is executed regardless if it's triggered by a regular heartbeat or triggerEvent, the route is too complex to detail it now (maybe another time) but in essence heartbeats & triggerEvents must obey the same rules just one is allowed to "jump" the queue and wiggle it's way faster to for example Alexa or the WebApp (or pass a message to another device.)

Basically, apart from maybe few micros needed for the engine to "digest" an Action the notifications will execute instantly if they were caused by a triggerEvent. And, if the notification is the first thing for the Action to do there is practically no slowdown anywhere.

Why didn't I still implement a notifyTrigger() or some shortcut from the library if there is no technical issues but rather made you suffer the burden of hard work of setting up an Action? 🎻 <- that's a little violin playing a sad sad tune

1. Apart from preventing you from flooding yourselves with notifications (which I don't really care if you do), it would add a full extra layer of checks that are already in place with heartbeat/triggerevents ...that's a big no-no...speed maters.

2. If you were triggering Notifications from the device it would be based on some logic. That logic will be hard-baked into the device and if you ever wanted to change it or even simply pause it, you would have to recompile everything. Using Actions allows you to dynamically control the notifications at any time and remotely.
(It's not like you could send a notification without an internet connection so it would be justified to say it works off-line)

Your little gizmos are connected to ChipChop in a constant chatter, use it to your advantage and pass the workload to the IoT donkey...ChipChop doesn't mind. Think of it like a big co-processor for your micro-controller and use it like that.

If you think that Actions are currently not giving you enough logical options, say it and give some suggestions. I have disabled some logical operations on purpose but I am not against a healthy discussion 🧐

Hope this answers some questions and please keep posting your views and suggestion (that excludes the medically challenged mr smarty pants, he said what he had to say)

Hossrod
02 Feb 2024

Hello, I tried this out today and was able to receive notifications. Great feature!

However, did have an issue. On my ESP32 C6 device, I have a component named BlueLED of type Light. I set an action to trigger when it changes to ON. It works, but I get continuous notifications (just 2-5 seconds between) the entire time BlueLED is in the ON state, not just when it switch from OFF to ON as I was expecting.

At least, I assume this is not how its supposed to work, but we all know what assuming does. :)

Gizmo
03 Feb 2024

Hi @Hossrod

Lol....yes...assumption is the mother of all f**ups :-))))

Everything works correctly it's just getting your head around how to control it, I knew this will happen and that's why I've put the limits (for educational purposes :-)))

You are simply not resetting the IF condition so every heartbeat re-fires it. Even if I was to somehow program the logic to fire the notification only once you would still need to tell it somehow to become active again!

Right, here is how to do it and this will give you a more fine grained control

1. Add another component to your device (not physically I mean, just in the Dev Console) and let's call it "notifier" and make it as an ON/OFF

2. Change your action so that the trigger is now when the "notifier" component is ON

3. On the ESP add this logic

    // when your blue led goes ON 

    // this will be instant but you have to be careful on the 6 events per minute restriction
    ChipChop.triggerEvent("notifier","ON");  // NOTE: we are just temporarily changing the notifier status to ON but not really remembering that anywhere else 

    ///somewhere in your loop where you are sending the heartbeat statuses just include the notifier as well
    ChipChop.updateStatus("notifier","OFF"); // always keep it as OFF

alternatively if you expect to have many events per minute you can declare somewhere the notifier as a variable
and alternate the status on the heartbeats so it only happens once every time the led comes on like this:

    String notifier_value = "OFF";

    void setup(){
     ....some stuff here 
    }

    void loop(){
        // somewhere in the code when your blue led goes ON 
        // IMPORTANT: you need to make sure that you are not repeatedly setting this but only when the led state truly changes from off to on

        notifier_value = "ON";


        ///later on when you are sending the heartbeat status

        ChipChop.updateStatus("notifier", notifier_value);  //send whatever the status is 

        // reset it back to off if it's on
        if(notifier_value == "ON"){
            notifier_value = "OFF";
        }
        
    }

That's pretty much all you have to do.

One perk of having the "notifier" as an ON/OFF component is that you can also manually trigger it from the web app by pressing the button, so technically you can manually send notifications and ping messages to you other half, kids etc if they also have the web app on their phone and are logged in on the same account ;-)

If you are not sure about it just ping me the code here and I'll review it

Hossrod
03 Feb 2024

Sounds good thanks! I'll give it try. Sounds like I just need to manage the notifications on the client side.

I dont suppose there are any plans in the future to be able to specify the notification message text at runtime from the client so I can include some live info? I could see where Down Under's request could be useful, both for specifying message text and for not having to create a bunch of components and actions.

Gizmo
03 Feb 2024

Point noted and yeah, I'm not strictly against the notificationEvent() directly from the device, currently more a matter of seeing how it's used (abused) and how it affects the engine performance.

I still think that a more flexible option is to be able to control the flow from Actions rather than the client so if you change your mind you don't have to recompile everything... I'll see if I can make something that covers both options.

Will take me a bit of time, I'm trying to prioritise things and still have a few features I've promised to implement some time ago!

Hossrod
04 Feb 2024

Sounds good! I'll keep playing with it, I've barely poked around so I wouldn't put to much weight on my opinion. :)

I will say that notifications is a big key feature for me and am stoked ChipChop has it even with current implementation. Much of my planned usage is for using my devices to monitor things and let me know when things need human intervention.

Down Under
04 Feb 2024

You see, I was right! People have spoken, we want notifications everywhere!

And in order to forget those earlier hurtful comments about my special needs, the event trigger should bear my name :-p

Gizmo
04 Feb 2024

People!? What people, I've counted two and that's barely plural.

So, let me see if I've got this right....you want me to include in the API the downUnderNotificationEvent()?

@Hoss dude has a valid reason for his need for notifications, he runs an exotic animals sanctuary so it's a safety concern if they get a runaway Boa Constrictor or some abandoned baby pet alligator or whatever crazy stuff they keep.

What's your excuse?a Kangaroo farm?

Hossrod
05 Feb 2024

I dont have such a excellent justification. For me, I'm interested in being able to send runtime generated text in the notification message.

Honestly I haven't played with notifications enough yet to really know pros/cons to have a strong opinion. But I know there will be cases where I have complex logic (using multiple sensor readings, info from external API like weather for example, etc) to determine if a notification is needed.

With my current basic understanding, I believe in current implementation, I would create a Component just for notification and attach an Action with notification to it, then in my devices code, would call that component/action ON, then immediately OFF again. This would fire a notification but with a hardcoded message (that was specified in the Action in the Toolbox UI). So if I have multiple messages, I would need different Components/Actions for each one. Although I still wouldn't be able to include any runtime info like an actual sensor value, an appointment name, etc.

Gizmo
05 Feb 2024

At the moment yes, but if you tap the notification when it pops up it should also immediately open the app where you can see the exact status for all the devices and components. Basically, when the heartbeat/triggerevent engine gets some status it sends it immediately to the app, then in the next breath it checks the actions and sends a request to the notification server.
So, technically, the app gets the status first and knows exactly what’s going on.

Hold on, I can do what you want quite easily! Right, I’ll add the option to either use a pre-set message or simply to pass the component name and status as the message. Doh, could have done that straight away 😵‍💫

You will have to sacrifice a component but you can then change it's status to whatever you want and that will be passed on to your phone.

Will add that later today, easy peasy

I will eventually implement a notificationEvent() directly but need a bit of time, so you can then send whatever message you want without having to resort to actions, it will still require an extra component but I'll include that as a built in thing for every device.

Hossrod
05 Feb 2024

Thanks Gizmo! Look forward to trying it out! Now, back to my Kangaroos.

Gizmo
05 Feb 2024

Done!

I'm starting a new post on this topic as this one is becoming long to scroll :-)