Apologies if this has been raised elsewhere (I didn't find it).
I'm reasonable new to INDI, so some might view this as a cheeky request, but I would encourage the INDI development team to look at the benefits of building support for MQTT broker/client platform.
Running MQTT on hardware shared with INDI is currently possible, but the benefits will only occur once the INDI manager/drivers support the messaging protocol.
I see many benefits stemming from this truly hardware agnostic protocol.
- so many of the Forum issues being raised are driven by complexities across the hardware/comms platforms, which might be avoidable under this comms architecture.
- Provides an IoT portal - links immediately possible - and the world is then open to other integration opportunities (security, user automation and integration with other devices - see Cayanne-IoT for an example).
- drivers written under Topic/MsgPayload provides for flexible/adaptable systems.
- diagnostic support for MQTT exists, helping developers and users fault find and progress on a level that is difficult to replicate.
Obviously, this is not a simple task, and is one that perhaps is viewed by many as low priority. Indeed, I suggest this not from any selfish immediate need, but more from an observation on how I might approach future developments and keep INDI relevant to rapidly evolving hardware. If you make the writing of INDI drivers or provide for links to other platforms easier (which I believe MQTT will do) then that's a wining formula for a INDI-User group!
There are *tons* of communication protocols out there for all sorts of things. I worked on SCADA systems for a number of years and so I am familiar with a few protocols in that area. INDI is an XML protocol, so it can be incorporated into other protocols if necessary. For MQTT, the only real benefit would be in a case where an INDI driver needs to talk to a device that is solely available via MQTT and hence a bridge needs to be developed to perform a protocol conversion of some sort. There might be other case scenarios, but it is very application and device specific. INDI is open source, so anyone can develop such a connector/bridge/converter for whatever technology out there if there is a need for such functionality in order to achieve a set goal.
I think this is a good idea. It would remove the need for polling too. For example, polling the weather driver every few seconds. It would be 'nicer' if the weather driver could send a message to signal an event. It would also enable other applications to subscribe to these events. Not just weather though. It applies to all the systems too.
If someone does add it, It would be nice if the message protocol was abstracted out. So that AMQP or others could also be supported
I agree that there are lots of other protocols out there, but your conclusions I don't fully agree with. I offer the following:
MQTT is open source, and runs on just about anything. Its being built into home automation, IFTTT and IoT providers like Cayenne (mydevices.com) makes hardware currently unsupported by INDI, available. And every day more stuff is being added.
Some examples for you:
- If INDI were to broadcast that my dome has gone active, I could a set a listener on my home automation system (Raspberry Pi - no coding required) to perhaps stop the home external security flood lights triggering when the dome rotates or the cat walk on by, (and saves my night vision).
- INDI might benefit from information from the outside world: There is meteorological data available without needing build/buy/install my own weather station. I currently have my home heating come on when the temperature drops too low via IFTTT - yet I have not weather station, I'm sure I could also work out a dew point which would allow INDI to decide to trigger the scope dew heaters.
- If my house security alarms are triggered, I might want to abort a the observatory action and run the shutdown script to make everything secure.
Ok, these are a few vaguely relevant examples and are hardly core INDI priorities. However, imagine the increased appeal that INDI would present to users that don't necessarily possess the required software skills to write a new INDI driver, but can follow instructions on hackday.io to build a cheap motor mechanism to drive a dome, and avoid buying the manufacturers expensive offerings.
Don't get me wrong, I think you/INDI team have managed to create a world class product, and I'm focused on using INDI/Kstars as the work horse of my observatory (once I get it built!). I just feel that it would benefit from a wider integration library, but I also recognise that its time consuming!
I have a similar use case. I'd like to switch off security camera IR lamps when the roof opens and back on when it closes. Currently I manually call a script to do it but it would be nice to be able to subscribe to events like this. There are other ways as a workaround. Its possible to write a new client that connects to the dome driver and this would get notified of events too.