Another webCoRE piston bites the dust.
True, I am now using it and have it testing Google and Cloudflare and resetting the modem if they are both down for 2 minutes, exactly what was required
So the flow now looks like this…
Hey … I was thinking … geesh … did i forget to mention this? Um … nope.
Guys … ABCD! SMH.
I always insisted I wouldn’t say it. And I haven’t. All in good fun.
Certainly loving this @april.brandt
Just put my ‘Ring’ gear in the ‘flow’ and I now have notifications to see if my Cameras etc. go offline.
That’s awesome. I suppose now you @CliveS can also help me advocate why i encouraged the additional checks in the flow. There’s always something to monitor!
I used the April’s node to practice. I simplified the flow (my usage Is Just to test phone presence based on ip ping) for my purpose.
It Is still unclear to me the purpose of the http(200) node
Yes with the one node I could filter Google and Cloudflare just by testing for ID, anything else will get a different ID, so simple.
Well 11 external cameras will be monitored,I will try to add the iPhones for presence but using it live for Google ping and DNS (they are different IP’s) and Cloudfare DNS to reboot my modem they both go down, yes I expect I will think of other things as well in the coming days but very impressed so far.
Still would like to know why the NR ping nodes screw up in Core, that completely takes NR3 off the Dashboard so even with a safe mode option you could not implement it. Not that I now need it but I expect others will try and use it.
From what Markus tells me, it’s trying to have access that he’s not willing to open up due to security concerns. Some don’t think security when opening ports, etc. So, Markus referred to it as “saving them from themselves”. That’s what i know. Maybe he’ll explain better, but i probably won’t understand it fully anyway.
Every webhook has two parts. The message and the response. Peas and carrots. There are different responses based on what you’re sending. This one sends a confirmation back when it’s received. Google would explain it better.
Ohhh. It Is the secret Key. I would expected It was embedded in the node and not exposed. But that Is an implementation detail as far as I understand.
Just a bit a info on something I’ve spotted regarding the monitorID.
When you have defined ypur monitor, if you go to the Kuma dashboard and hover your mouse over the monitor you have just defined, a url appears at the bottom left (on chrome anyway) and it shows the monitorID.
The 6 being the monitor ID designation.
You’ve probably all spotted this but just thought I’d mention it as it saves going through the debug node.