Not winning a contest sucks. This whole "it's not about winning" thing is a lot of nonsense. However, if participants receive a separate prize after a contest because of special creativity, then they really deserve it.
Today we would like to introduce 3 participants of our Sensor Story Contest, who were not among the original winners, but whose creativity, technical know-how and detailed documentation still have to be appreciated. But because we all love the thrill, only one of the presented ones will win our special prize: a PlayStation 4 Pro. Who that will be? That's for you to decide. Comment on this blog or on Facebook and the participant with the most votes is going to win.
The first entry was submitted by RTV-Noord, a public and regional broadcaster in the Dutch province of Groningen. The second comes from Civica UK, a global IT-based services partner in digital solutions, software applications, outsourcing and managed services. And we received the last entry from Bad-Packets Report, which is dedicated to research regarding cryptojacking, botnets, network abuse, and other security topics.
Let the participants speak for themselves as usual - and let's start with RTV Noord:
»
Let me tell you something cool we monitor with PRTG. I work at a broadcast station where we make radio: 24/7, 365 days a year. Besides all the huge amount off IT stuff we monitor with PRTG, I tried to figure out if it was posible to monitor our broadcast radio line in case off a sudden silence. For the silencedetection on our broadcast radio line we use piece of hardware called a silencedetector. The silencedetector unfortunately only sends out an e-mail in case of a radiosilence (and of course it switches to an alternative playlist on a flashcard). This silencedetector we can monitor within PRTG. In the sensorlist from the silencedetector we see both the stereochannels and the main source of our broadcast radio line. After a lot of testing we noticed that the values of both the stereochannel sensors changes to a certain level when we simulate a silence. So now it was quite easy to made a notification on both the stereochannel sensors. When the values on these channels reaches a certain threshold for amount of time, we get a push notification from PRTG there is a silence on our broadcast radio line. Wonderfull! Quite a puzzle but the result is very very useful.
«
Next, we will give the floor to Civica UK:
»
I use PRTG at work on a daily basis as our central monitoring solution however I also utilise it at home. At work I have created a simple but effective custom sensor that checks for deleted sensors using powershell and the PRTG API. We had instances of whereby important critical infrastructure sensors were being deleted (whether by accident or not) and we want to be alerted to this to ensure we continued to have full coverage of our important business systems. It basically records all sensors to a file in xml, compares them and writes a value of how many deleted and errors if its above 0 and what they are in the message, we then review if these were intended.
One sensor I have created at home captures Nest thermostat statistics from the Nest API as the default Nest app tells you very little, especially over time. I then use a sensor factory to compare ambient, outside and target temperature, heating on/off and humidity which gives you a lovely trend over time on how you property is performing. It also flags inefficiencies with schedules.
I have currently got myself a LaMetric clock and this is great to output PRTG alerts to this display without have to constantly check your phone. A native app for this would be great but the basic notifications of errors at current still makes it great I also have one of my Philips Hues lights as a notification turn red when the baby monitor detects motion, this was very easy to implement. A simple API call to the light bulb packaged as a notification in PRTG. When resolved I just set it back to a nice warm white. I do really like the flexibility of PRTG and there seems no end to how you can go about monitoring and reporting back to you.
«
Last but not least, the use case from Bad-Packets Report:
»
I'm an independent security researcher and has used PRTG for monitoring a new security threat called cryptojacking. Hijacking browsers to mine cryptocurrency is called cryptojacking. Coinhive and other JavaScript cryptocurrency miners are frequently found on compromised websites. PRTG has been very useful for monitoring numerous sites that have been compromised to conduct cryptojacking operations.
This is done via a "HTTP Advanced" sensor.
In the case of Politifact.com, the sensor was configured to look for "coinhive" in a compromised JavaScript file.
Once Coinhive was removed, the sensor would enter a "down" state letting me know the threat has been removed. This was shared on Twitter and received positive feedback from other users.
«
Dear readers, now you've read all the way to the end, do you still have 2 minutes to tell us your opinion? Which of the 3 participants should win our special prize?
