At the beginning of the year we had an IoT hackathon at PwC. All we had to do was to invent a great use case for IoT and once we got through the selection process we got the IoT devices (the same you can buy for Trailhead). Then the real fun begin, my first time when I can really put my hands on this thing and not just watch the presentation.
What did I learn and how it went?
I chose a pretty simple scenario, which I extended with Sigfox device, to have more fun. I used the “Trailhead” device to monitor temperature and speed and use the clicker from Sigfox to notify me about clicks (and it can send GPS location as well, when you buy the right version!)
The Trailhead device was easy to setup, I was surprised that the programming is done by flashing light from your mobile phone on the device. Pretty cool to watch. The hardest part was to link it to our corporate network, but that’s totally different story.
I struggled a bit to find a code to track movement, but with the help of my colleagues I got that as well.
Bigger fun was with the Sigfox device. That’s pretty cool thing, which can survive months on one battery, has limited amount of information it send and due to this fact it compress them in some way.
The first problem was how to authenticate it against Salesforce, as it just support basic authentication, which Salesforce consider not safe enough and doesn’t support. Luckily, there is something called Node-RED, which you install on your own server, connect the device to it and it can process all incoming messages, can do a great thing with them and then send them to another system. Or you don’t even need the another system, which is quite sad for Salesforce.
With first problem solved, I had to solve the second problem – I needed to decode the info I got from the device. Again, I had two ways how to do it – create an APEX trigger in Salesforce, or use Node-RED to do the decoding and send only the final data to Salesforce. Obviously, that was the solution for me. If I have to have this middleman in place, it probably makes sense to use it to do some heavy lifting so I don’t have to do it in Salesforce.
And with that came the final part – how to work with all that info in Salesforce. What we usually see is the “player”, which shows how nicely the devices send info and how it change statuses. The interface for defining these things is not that cool, but after a while you will get used to it. It looks like some Excel with columns, where you write if this then that and set this, but you need to get used to it.
The temperature was easy to handle – it sends info every few seconds, so IoT cloud just take the event and process it. The tricky part was with the button, which sends info only when you press it. However, it would be cool to reset its status after a while but I never figured out how to do it without the event. Probably need to write a trigger which will create another event after a while to reset it, but that just does not sound as the way to go.
It was great to put my hands on IoT for the first time and not just see the presentations. I was surprised how many different devices there are and how many different brands. I can monitor probably anything nowadays; you just need to find the right device. I have been surprised how limited the capabilities in Salesforce are unless you decide to custom code everything – which is at the end quite obvious.
Now I need to find some real world use case, where I can play with it more and deliver some really cool thing. The maintenance planner for lifts sounds like one great example and you can probably invent many more.