IMS and Home Assistant Communication

[David Ellis]

So what is actually desired to be automated? Servers and projectors have very many different ways to act and react. Yet I guess that what you want to do related to IMS/projector is probably limited.

Great question. The biggest need are que's in the playlist on the IMS that can send to Home Assistant. It can be any type of message, just as long as it can make it to Home Assistant. Then, within Home Assistant, it can be made to do pretty much anything and could automate many things, but the most basic is diming lights.

Real world example: Simply at film start the lights dim, at credit start the lights brighten.

My eventual dream would be if Dolby would enable the IMS to send via MQTT, or may manufactures create Home Assistant plugins that would also work. But I think that even right now there has to be a way for some type of communication.

[James Gardiner]

It wouldn;t be that difficult to make a Python bridge implementation of commands from Home Assistant to their SOAP API, Barco-ICMP-SOAP too. Or GDC socket protocol (But GDC are not forthcoming with their API unless you sign a NDA, so may not be possible to do an Open based translator for GDC.

You could list playlists, load playlists, Pause, play, control the player. I imagine that's what you are after.

It's just you would need a coder to build these tools.

I have asked a few manufacturers if they would allow VARIABLES into automation queue coming IN/OUT of the player, but no dice. For example, Volume commands that accept the VOLUME directly and not make a event for every possible volume. stuff like that. Or be able to send a ytrigger that has as part of it, the timecode, CPL-id, SPL-id. i.e. to fire external devices that, based on the show, can do different things.

Otherwisem if a HA to DCI-Player plugin did exist... would be very useful, especially to more dynamic based cinemas were the projector is part of a larger sequence of events,

[David Ellis]

It wouldn;t be that difficult to make a Python bridge implementation of commands from Home Assistant to their SOAP API, Barco-ICMP-SOAP too. Or GDC socket protocol (But GDC are not forthcoming with their API unless you sign a NDA, so may not be possible to do an Open based translator for GDC.

You could list playlists, load playlists, Pause, play, control the player. I imagine that's what you are after.

It's just you would need a coder to build these tools.

I have asked a few manufacturers if they would allow VARIABLES into automation queue coming IN/OUT of the player, but no dice. For example, Volume commands that accept the VOLUME directly and not make a event for every possible volume. stuff like that. Or be able to send a ytrigger that has as part of it, the timecode, CPL-id, SPL-id. i.e. to fire external devices that, based on the show, can do different things.

Otherwisem if a HA to DCI-Player plugin did exist... would be very useful, especially to more dynamic based cinemas were the projector is part of a larger sequence of events,

Hi James. Thank you. Do you know any coders who could do something like this?

[James Gardiner]

@David, That's difficult. It would need to be someone with access to the equipment to develop against.
So going to an online dev hire solution is not really going to work as getting access to the equipment to do this is not trivial.
You would be better off potentially trying to get a local school kid who likes to code that comes into your cinema and develop against your own equipment.

[Steve Guttag]

...I have asked a few manufacturers if they would allow VARIABLES into automation queue coming IN/OUT of the player, but no dice. For example, Volume commands that accept the VOLUME directly and not make a event for every possible volume. stuff like that. Or be able to send a ytrigger that has as part of it, the timecode, CPL-id, SPL-id. i.e. to fire external devices that, based on the show, can do different things...

The only server that did that was the Dolby DSS series. Oddly, Dolby, when acquiring Doremi didn't continue it even for their own sound processors.

Onto the subject at large. Getting people to agree to support an all encompassing standard is going to be a difficult one. The industry has two automation companies that span the globe...Eprad and Integ and due to their pervasiveness in the the film days, the non-OEM server manufacturers all seemed to set up special "hooks" just for them to allow for more seamless integration...particularly for doing what automations were doing with film equipment (lighting and such). The OEM manufacturers have mostly supported both but Barco, for instance, has built-in integration for Integ, not Eprad. And, really, that built-in integration was minimal...it helped some on the automation sending triggers to the server.

None of the established automations fooled with CPLs or SPLs...which is part of what you seem to be seeking.

Prior to the events of 2020, I would have said that Q-SYS could have emerged as a significant player in the cinema automation department. We certainly use it as such. Plugins for Q-SYS include Barco, Christie and NEC projectors (Series 2) and Barco Series 4. At the moment, for servers, just Dolby/Doremi for the IMS3000 (though where the commands are the same, it can work with earlier Doremi).

For instance, the cues you seek are part of the Dolby plugin in Q-SYS. It will poll the server for whatever cues it has and those can, in turn, be assigned to the plugin's buttons. It can also poll for the CPL and SPL inventory and, again, select the show/content and play it. You can do most anything, show wise, that you can do on the IMS' web-ui except actually building/editing the show itself. But, a plugin like that only comes about because Dolby invested their time/money into its development. And, to their credit, that does affect our selection as the IMS integration in a Q-SYS system is pretty easy and thorough.

I think a problem you will find with your Home Assistant (HA) plan is that you'd have to convince everyone, that already has an established API, to invest in making a plugin...which also means that they are investing in support for the plugin too...including if any changes to the HA platform cause a break that have to be addressed. What is the market penetration on HA for cinemas? Eprad and Integ are substantial. TMS systems also can do varying degrees of automation themselves and they already are talking to the projectors, servers and even traditional automations. What would the selling point be in investing in making HA plugins? And, if you only get 1 or 2 manufacturers to agree, it isn't enough to make the platform attractive.

The various companies can throw it back at you...they already have the API...if you want to automate your system, use their API to do it. As James has indicated, GDC seems to be the most stingy with their API by not openly publishing it. However, with an NDA, it is often available (that is how TMS companies integrate with it, as well as Eprad and Integ). I've asked all of the server (and projector) companies to make Q-SYS plugins for their current products, most have seem interested but definitely not all. I suspect that you'd get a similar response for HA if not worse as it is not nearly as well established as QSC/Q-SYS within the cinema industry.

So long as the API can be had, I guarantee you that there are people/companies that, for a tidy sum, will be able to generate a plugin for whatever platform you desire. But, unless you have a friend that just likes to code, you'll probably pay decently for it...until one of the LLM (like Chat GPT) can write it for you. They are already getting good enough to assist and help debug code and they'll never be worse than they are now.

[Marcel Birgelen]

The thing with custom plugins is that it also needs to be supported. It's not just write once and deploy forever. Eventually, something is going to break due to updates, ether on the HA side of things or on the DCI server side of things.

If you really want to use HA, then I'd opt to use an off-the-shelf "glue" solution. That could be the aforementioned TCP to MQTT route, although that also seems to be badly maintained, the "Neanderthal solution", like physical GPIOs *might* be an option. Another option I'd consider is using a device like the JNIOR as a bridge. The JNIOR is well supported in most DCI systems, also, it supports MQTT.

[Bruce Cloutier]

Okay. I can chime in. The nice thing about standards is that there are so many to choose from. Not my line but a good one. Not even a new line. But I did once work on IEEE and ASTM standards committees and, well, got my fill of that.

INTEG has not looked into HA. Not that we wouldn't be interested. But like anything else it takes a potential customer in need. The JNIOR is more generic and well-suited for things like protocol conversions. It is just an independent platform that can be programmed and happily sit in the middle of things.

So if HA has communications protocols (that are available) we can certainly look into the translation. Just bring up the topic with support. Kevin has been spending time messing with Ladder Logic trying to appease some of the PLC market. That is like a UI translation/conversion. It is archaic. I think he would entertain something more interesting.

[Bruce Cloutier]

I just checked, So we have helped some with HA and MQTT.

EDIT: JNIOR protocols (like JMP) are published. The HA community could easily make the JNIOR a friendly peripheral for those systems.

[James Gardiner]

I would disagree with the issue about support.
The APIs in use my manufacturers are very solid and do not change. (Its too risky)
Putting support into a plugin, the target API the plugin uses is likely to be very solid, but yes the HA software COULD make a breaking change. But this is usually well documented (As it has to be, as it is such a widly used tool for home automation. Makes the number of cinemas in the world look like a rounding error)

The point being, even if you get a vendor to make a plugin for their tool, how long does this tool last in the market? It has even more risk than HA, as HA will never go away, as its open source. And in some way is more reliable as anyone has the ability to fix it if it becomes incompatible for any reason. Compared to a vendor special purpose device which may completely disappear in all respects. Not available, no parts, manuals wiped from internet. (Well maybe apart from the doc repository here)

So I think its a good idea for the community to invest into this. If it breaks, it wouldn't take much effort for another person to contribute and get it working again.
In the long run, it most likely will work out more cost-effective for the cinema community.

[David Ellis]

I believe that (although a plugin would be optimal), if the manufactures would have any kind protocol options enabled then just doing that would hugely beneficial. For example, if MQTT capabilities were built into the IMS then even a novice could achieve pretty much any functionality needed with minimal skills. And not only would it work amazingly but it is widely used so it can talk to many other systems.

The problem currently is that there's almost no way for various systems to directly talk to one another. We have a JNIOR and it is a phenomenal device that has a MQTT plugin. We're working to set it up, essentially serving as a middle man language interpreter to relay messages. It is a little challenging to learn some of the advanced functionality, however their support has been some of the best support of any company I have ever worked with. And... good news is they have acknowledged Home Assistant https://jnior.com/home-assistant-and-mqtt/ so it's at least on their radar. I hope they create a true integration/plugin one day but till then, MQTT works.

For anyone who has not tinkered with Home Assistant, I encourage it. As long as you can get things to communicate with it, which almost everything can from direct plugins to Z-WAVE Zigbee LoRa MQTT etc, then the automations you can build are incredible. From having having a series of things happen to open at the start of night, to having a series of things happen if a projector or room overheats and send me warnings, it has become an indispensable part of the business. Even simple things, such as I have temp sensors attached to every projector and in every booth, so one night the power flicker and the AC stopped, I had a rule set to send me alerts if that happens, to wait X minutes to restart the AC, to then turn exhaust fans on, etc. I got the alert and ran to check it and it was already in the process of being fixed - automatically. If it had not been for this system then the projector would have overheated and shut down - no fun.

I have friends at a very large theme park, with a very complex automated ride, and much of it is run off Home Assistant. Think ride starts, show file plays, triggers ride to move, if sensor is triggered then ride stops, etc etc. This is what initially put me onto Home Assistant and I've been hooked ever since.

[Marcel Birgelen]

I have friends at a very large theme park, with a very complex automated ride, and much of it is run off Home Assistant. Think ride starts, show file plays, triggers ride to move, if sensor is triggered then ride stops, etc etc. This is what initially put me onto Home Assistant and I've been hooked ever since.

I very much like HA, but the thing for many big corporate players is the support on it. I've also done jobs for the theme park industry, including that Earful company and they have a general tendency to stick to stuff that works for them. For show control, that tends to be stuff from Alcorn McBride, which is also a relatively small company with support that's also on a very high level. It's not yet on that level that you can message their CEO directly on this forum, but they won't let you hanging in an endless support queue when your ride is down either.

The thing in this industry is that very much everything is its own island... DMX, GrandMA for lightning, Dante for audio, SMPTE 2110/Ravenna and NDI for video, maybe some QSys here and there and still loads of serial or GPIO based stuff. Cinema has created its own little digital island with DCI, where there, unfortunately, isn't a centralized API for playout control and Dolby can't even decide weather they support Dante or AES67...

MQTT is still often seen as a standard for consumer products, not as something that controls big, dangerous machines.

[James Gardiner]

Open source is typically more reliable than closed source. It's why the internet predominantly runs on Linux systems now. Open source tools get pounded-on a lot more, and in more interesting ways. The MAIN reason these larger companies use expensive proprietary systems is to have someone to potentially sue if things go wrong. "Cover thy arse" corporate culture. It's just a reality. Where the old saying, You cannot get fired if you buy IBM, comes from. The cinema industry has a lot of leaders from that era, so don't be surprised they acts this way.

From my perspective, with low level systems, open source rules. It's why all the larger mage tech companies rely on open source specifically for the tools they have. It's why they can be so innovative, and competitive. And ultimately profitable, growing into mega companies.

But yes, in our small pond, executive decisions are more likely to be decided based on plausible deniability stance over a technically better one.

There is nothing wrong with that. But understand that these decisions can lead to different outcomes.

[Marcel Birgelen]

We're going a bit off-topic here, sorry and stuff...

First of all, I'm a big proponent of Open Source and always have been... I've been running Open Source systems for at least 30 years now. I've even done some kernel development in another life... If you met me 30 years ago, everything I did was running, was running on FreeBSD (go give them some love, they deserve it)...

The nice thing about open source, obviously is, that when everything else fails, you still have the source. The problem though is, that's not something a smaller company can rely upon, as most of them aren't in the position to keep engineers on the payroll that actually know stuff about this source. And in reality, not all open source projects are created equal. For example, there are many open source tools out there, that could solve a certain problem, but many of those tools are only supported by a single developer, putting in his/her spare time into it. Many projects have become abandoned, etc. Navigating this space isn't easy and completely impossible for people without a good technical understanding of the matter at hand.

That's why I can't blame companies looking for solutions that come with some kind of guarantee, even if it's just on paper. It's not just to have somebody to sue if stuff goes tits-up, but also because stuff needs to be auditable and quite often, stuff also needs to be certified. While I agree that, in reality, most of those things are just paper tigers, it's the reality we find ourselves in.

Luckily, there are quite a few open source solutions out there that are sufficiently mature and supported by a sufficiently large ecosystem, so they can be used without much friction. I seldomly see any friction nowadays to deploy something like Debian for example, whereas, in the past you were quite often forced to use some of those dreaded "Enterprise Linux" distributions instead.

Getting back to those big tech corporations, like Google, Apple, Amazon, Facebook, Netflix and sure, let's not forget Microsoft: I despise those corporations to my very core for everything they represent, yet I need to work with their shit everyday. It's those corporatations who got billions and billions of dollars of value out of open source, but who essentially never gave anything of value back to the community. Like James indicated, they built their business empires on the back of this technology, but the contributions they gave back to the community are laughable at best. May they eventually all burn in hell for what they did to our society for the sake of unbridled greed.

[Ryan Gallagher]

I have an appropriately timed screening of Social Network today for Marcel’s vibes. ;-)

[Bruce Cloutier]

The open vs. closed source argument has been going on now for over 40 years. It won't be settled any time soon, if at all. The tide is turning towards open source now because all of us cannot for a minute stand the greedy for-profit drive of the big corporations. This SaaS stuff is truly annoying. I got particularly peeved when in the past I bought a software update only to find that there are little if no differences from the prior version. Isn't it fun to be taken for a ride?

I side with Linus. Gates had a hissy fit when people openly shared his copy of BASIC. I can understand his points as well. There is value in well-maintained and supported software worth some respect. But today that is grossly over-valued and for no reason other than they can get away with it. There are too many people scheming to tap your hard earned money. Not enough people working to help you out.

People love open source because they can get things for free. But when that doesn't perform it can be an eye-opening experience to try to work with that source code. Most of what I have seen is poorly commented. There have been too many chefs in the kitchen. You find work-arounds implanted as bug fixes. The whole thing reminds me of an multi-generation Xerox copy, degrading with every iteration. Bug lists grow unchecked. When some fresh code gets posted there is usually someone or a small group who are emotionally attached to the quality of it. That fades with time.

To head back towards the original topic....

Things become standard either because there is some (significant) financial benefit in it or when everyone adopts it and it just becomes the dominant choice. The problem as time goes on is that there are too many ways to get something done, none of it well-documented, and so it becomes difficult to know what to do. I have been saying lately that 'too many choices... are no choices at all'. You have too many options and so become completely baffled. I am not sure that HA can be moved towards any kind of automation standard. It is just another choice.

45 years ago equipment came on the market and they touted having RS-232 capability for connectivity (although that word I think wasn't known at that point). Missing was the fact that you had to have the right cable (connectors and wiring); You had to have the right baud rate, stop bits, parity; You had to have a protocol for requesting data; And, You needed to know how to decode the messages whether it be ASCII or binary. The point is that even with MQTT there remains something you need to know to get it to work. Maybe this is where AI comes in? Something to implement that DOWIM (Do What I Mean) machine instruction.