|There's more than one way to do things|
ping $deviceIP or report it as not responding and exit
Just a little, slightly off-topic bean counting. Some devices prefer not to respond to pings, yet they readily serve telnet, ssh, http or other services. Yes, this is stupid behaviour, nevertheless it happens, mostly because some clueless people dictated stupid "firewall" rules.
I would omit the ping test, because it is generally useless. If you get a ping reply, you still don't know what services are supported, you only know that the device was reachable shortly after you sent the ping package. If you don't get a ping response, you know nothing. The device may be shut down, offline, firewalled, or misconfigured. In both cases, you still have to try ssh and telnet. Omitting ping reduces the amount of code needed and wastes slightly less network resources.
Another different thing: Because ssh is encrypted and telnet is not, I would prefer to connect via ssh first, and only if that fails fall back to telnet.
I would only try telnet first if I had to work with a known set of machines where telnet is much more likely enabled than ssh. But then again, if I know the machines, and know that they always respond to pings when they are up and running, a ping test may be faster then failing to establish an ssh connection.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)