It occurred to me that a simple (Arduino, for example) device that could subscribe to hints and get presence information from the server could be really handy. Has anyone ever looked at what it would take (or know of project) to not “BE” a phone, but still watch some of these SIP things?
I actually have several ideas for this, including things like controlling lights from the phone system, marking rooms in a waiting/holding area with the current status of the person in the room/cell, message waiting LEDs, etc. I want to make it as simple as possible, but don’t necessarily want to start working from bare metal.
In my first iteration, the box would be “read only” and would be “cleared” by the underlying action (no messages, presence set to “none”, etc.). The second iteration might have a “clear” button that would clear the hint/presence, but that’s down the line.
Well if you’re talking about being able to SUBSCRIBE to Asterisk generated HINTs then you just need to either write something that will use AMI/ARI to check the states of those HINTs or write an AMI Listener that can “listen” for AMI Events that happen including STATE changes for devices.
You can push this all to a screen that can be monitored. Basically, you can install FOP2 and just setup a big monitor/tv screen that is attached to a RasPI using Chrome or something. Because that’s basically what I was describing.
But yeah, AMI/ARI is basically what you want to watch/monitor Asterisk for states/calls.
Otherwise, if you’re talking about something that will be the Presence server that things will send updates and subscribe to. Look at Kamailio or OpenSIP.
Good idea. That would be perfect. Now I just need to write an AMI listener for Arduino.
I’d like to stick with the Arduino so I can to this for under $10 a pop (in parts). Once I get the basic listener running, I can add all kinds of crap on the back end.
The trick - the part that makes this work - is that I want it to be absolutely as basic as possible. I don’t want to monitor more than one hint, or subscribe to more than one event at a time. The goal is an output that will drive a signal to a MOSFET (for example) to turn something on or off.
Here’s an example: my wife runs a dog rescue and we have indoor/outdoor kennels with doors that we open and close for various reasons (weather mostly). I’d like to be able to monitor a hint on her phone system that we can turn on to “loose the dogs of war” and then turn it on again to close the doors. We can monitor the floor from anywhere, but have to operate the doors from inside the facility right now. Making so I can hit it from anywhere to an IVR or feature code is better.
Another example: doctor’s offices often have exam rooms. The status of each patient in the room drives a color coded flag system that tells the techs who needs to go where. Their phone system has the capability to monitor different statuses of the emergency phones in the rooms, so i could use that to drive different LEDs.
Yes, there are expensive solutions to each of these, but something that I could open-source and put together for $20 and market as a flexible, “single use” device would be awesome.
This is ancient, but did you ever get anywhere with this listener? I’m looking at doing a similar thing in an office environment. I’d like to have something that listens for BLF changes, then does a pub/sub type transaction for a “connected” micro controller (like a particle photon) which then controls some NeoPixels or something.
Running SIP subscription client on the microcontroller itself would also be possible. Particle Photon has 128 kB SRAM though and this is slightly tight (requiring micro optimizations and/or dedicated, somewhat incomplete SIP stack/parser), something with 256 kB SRAM (preferably as a single domain, maximizing continuous heap size) would be easier to work with (~192 kB heap should be good for few but likely less than a dozen simultaneous subscription dialogs).
