Module Request: MQTT

[mikelconnor]

Describe the feature I'm looking for a way to control things like projection screens. We have one that could be controlled with a dual relay that uses one relay to start it going down, and one that starts it going up. I've not located any protocols that are currently supported. I would like to request MQTT support Basically this is used for machine-to-machine communications in the automation world. It's a publish and subscribe form of communication. The companion app would allow for connecting to an MQTT server, and customizing the topic so multiple devices could be controlled. Then a button could publish a specific payload to a specific topic for other devices to subscribe to.

Is this platform dependent (windows, mac, ..)? No.

If documentation is required to implement, do you know where to find it? mqtt.org, https://github.com/mqtt/mqtt.github.io/wiki

Usecases Control projection screens, window treatments, other automation endpoints. There are many automation systems that use MQTT. Hardware controllers could be built using MQTT, ESP8266 chipsets, and simple relays to make a projection screen controller. Or you could use a Shelley 1 https://shelly.cloud/shelly1-open-source/.

[willosof]

I'm surprised MQTT is used by the automation world! Cool. I think this would a perfect issue for @haakonnessjoen :)

[AlgemeneBuurman]

Just started working with MQTT this weekend. Was thinking about how to use it with Companion. Nice function to have!

[JackTraore]

I'd also love to see this implementation.

Down the road it would be great for Companion to receive MQTT (and potentially be the broker). Would allow for simple remote buttons/inputs using just a small microcontroller and whatever interface.

A button forever in my rack room that mutes the outs on our X32 when I need to power cycle the amps, a wireless single button cue, a button in our secondary presentation space that routes everything appropriately for a simple laptop and single mic presentation, a input that tells when the screen is down to then transition from black to the desired input. Lots of possibilities.

[wilssonbrothers]

MQTT is something I really miss in Companion. We have for example started using MQTT for Tally for cameras.

[tap-chris]

Is someone already working on a module by any chance? I'm also using MQTT a lot for fixed installations to control equipment like screens, amps, house lights, and so forth. Before using Companion I solved this with my own software and now I'm using Companion in conjunction with node-red to communicate with my MQTT devices but if nobody is working on it I would actually consider to create a module for Companion so I don't need node-red anymore and to make it easier for people to work with it. Right now I'm using mosquitto as a broker and would consider having the broker separate from the module for the first implementation and after that's working add a build in broker to Companion to make it even easier. Any input on what people are sending over MQTT would be helpful though. A lot of devices I use are sending and receiving JSON so the actions and feedbacks would have to be very flexible. Or there is a base module and sub modules that have actions and feedbacks for specific devices. Too many ideas myself ;)

[oblogic7]

@tap-chris I just picked up a Stream Deck today with plans to integrate it into my home automation system. MQTT would be a very good way to do so. I think it would be best to allow definition of topic and message payload on a per button basis. I'm looking for a project, so this sounds like it could be fun. I can start up a repo for an mqtt plugin and invite you to collaborate if you would like.

[tap-chris]

@oblogic7 bitfocus staff will create the repo for us. Defining the topic and payload will be the basic minimum for a general implementation. Using Companion for events or home use is a different story though. While at home you have time to do all the configuration in peace, there is maybe only minutes to do that before the event. I don't know how much MQTT is in use for live shows though since I only stumbled upon such things on worship installations or smaller venues which may have a little more time to work on their installations. So the idea of having definitions for actual devices would make it faster for the user and no additional knowledge of the protocol would be needed. I do want to have a generic implementation for it so it can be used for all devices and this would have to be flexible enough like the one in node-red. Like the generic OSC and HTTP modules in Companion. The ability to add a definition for an actual device and have actions and feedbacks for it would be an awesome addition to it though.

[oblogic7]

@tap-chris I was reading through the development guide and have requested them to create the repo.

I don't know how much MQTT is in use for live shows though since I only stumbled upon such things on worship installations or smaller venues which may have a little more time to work on their installations.

I've worked on many productions of various sizes over the years. I've never seen MQTT used in a live event setting. It is likely more commonly used on smaller permanent installations like the original post on this thread. Even if it is used in a live event setting, it is not something that should be configured last minute. I would say it is more important to prioritize flexibility over speed and ease of configuration.

Regarding the idea of pre built device definitions to make things faster, I understand the idea, but am not sure that it would be very beneficial. Do you have any examples of MQTT enabled devices with a published spec that can be used to build such definitions? Building and maintaining such definitions would be a significant task.

[mikelconnor]

Thank you all for taking an interest in this. So we are mostly going to use it in a fixed environment, but that doesn't mean we won't use it for portable events. If we were to be doing an event that is portable, it would be planned out ahead of time to allow programming whatever is needed.

So currently I'm using Companion with a couple of devices that have been flashed with Tasmota (https://github.com/arendst/Tasmota). I'm using it on a 4 channel Sonoff device with Tasmota to control our projection screen at one of our church sites. We are a multisite church and the sermon is sent over a campus cloud DVR streaming system. I'm controlling the screen, a couple of the BlackMagic ATEM switchers, and a BlackMagic Smart Videohub, PJLINK for projector control, as well as the campus DVR decoder which is controlled with RossTalk. Our main campus has another Sonoff device flashed with Tasmota to control a device. I'm having to use the generic HTTP option to control the Tasmotized devices for now, which means no feedback. MQTT would provide better control, and hopefully feedback. Since it's MQTT, and since we are dealing with switching,

I would hope that a generic form of MQTT would be able to have standard payloads setup, and allow for customized responses for status. I plan to use MQTT mostly with Tasmota since there are so many devices that can be flashed with it. Tasmota and those devices give much flexibility on automation. In home automation, you could use Companion to send custom MQTT payloads through mosquito or your broker to home automation systems and those payloads could fire custom automations. That's the beauty of MQTT. What is sent is just a payload of info. That payload could trigger a relay, light, color change, a whole series of changes in an automation, and when the automation completes, a response could be returned, and responses could change colors of the buttons in Companion, etc.

I'd love to help code, but it's been years since I've coded, so that is why I put this out in the community. I'll be glad to provide feedback, do testing, things like that. Let me know what I can do.

Thanks, Mike

On Mon, Jan 27, 2020 at 5:05 PM Matt Snyder notifications@github.com wrote:

@tap-chris https://github.com/tap-chris I was reading through the development guide and have requested them to create the repo.

I don't know how much MQTT is in use for live shows though since I only stumbled upon such things on worship installations or smaller venues which may have a little more time to work on their installations.

I've worked on many productions of various sizes over the years. I've never seen MQTT used in a live event setting. It is likely more commonly used on smaller permanent installations like the original post on this thread. Even if it is used in a live event setting, it is not something that should be configured last minute. I would say it is more important to prioritize flexibility over speed and ease of configuration.

Regarding the idea of pre built device definitions to make things faster, I understand the idea, but am not sure that it would be very beneficial. Do you have any examples of MQTT enabled devices with a published spec that can be used to build such definitions? Building and maintaining such definitions would be a significant task.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bitfocus/companion-module-requests/issues/48?email_source=notifications&email_token=ADFG2LMFWU7EWLHGYWODRT3Q75LDXA5CNFSM4IOPSL42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKBH4DQ#issuecomment-578977294, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFG2LOKX335MFHLDNT2WFTQ75LDXANCNFSM4IOPSL4Q .

[oblogic7]

I'm just starting to piece this idea together, but one potential hurdle straight out of the gate will be allowing specification of complex payloads (JSON). I don't think a textinput field would be very user friendly for entering such payloads. Maybe we will need to add a new field type to the main project? Somebody with more knowledge of developing Companion plugins may be able to shed some light on this.

[tap-chris]

I've never had MQTT on a live event either but I do have a few smaller installations with Shelly devices installed that control the projection screens, house lights and various other small devices.

Creating a simple generic module would be quick.

Config
  URL: String
  Username: String
  Password: String

Action 
  Topic: String
  Payload: String
  QoS: Enum(0,1,2) - Default: 0
  Retain: Bool - Default: false

This should be enough to get going. On the feedback part as you figured we would have to get creative as data can get in as simple as a number, more complex with JSON objects or even binary data. With Tasmota or Shelly we could get away with simple string comparison for now. For example a shelly relay is answering with either on or off so a button could toggle the state and show the status even if it is triggered from a different device. I've there is nothing more needed from users we would be good to go for now. If users need more we can add more ;)

[oblogic7]

First step will definitely be working with simple palyloads. JSON object handling could come later on.

[oblogic7]

I've got message publishing working and have requested the module go ahead and be added to core.

@tap-chris Please give the publishing a test and let me know if you find any issues.

I am still trying to figure out how to approach receiving messages and possibly syncing button states based on the received messages. That is turning out to be more work than originally thought. I'm going to keep working on it though since it is critical to my use case.

[tap-chris]

@oblogic7 Will test it on Sunday in a event space.

I think the main thing we have to figure out is how to subscribe to a topic once a feedback has been added without having to subscribe to all topics. Would be great if there is a event once a feedback is added or deleted but I don't know if there is such thing or we have to iterate through the feedbacks and subscribe or unsubscribe. Once the messages come in we could store the states in the instance and call the feedback check to update states. Worst case we could add a config option so the user can add the topics to subscribe to.

[oblogic7]

@tap-chris Any luck with the testing? I think I have an idea for how we can subscribe to events. Going to try and test the idea today if I have time.

[oblogic7]

My idea for how to subscribe to topics took quite a bit of work, but it works pretty well. Here is a video of it in action. Code has been pushed to module repo, so feel free to give it a test.

https://monosnap.com/file/t3srmv6CSs75ql2SgW8ZFfqk09TMLC

It will be pretty easy to extend this work into other feedback types like setting button styles or changing device page via MQTT message.

[haakonnessjoen]

What’s the connection between the variable and the feedback? Seems like you are using both to solve what one of them do?

[oblogic7]

It could probably be done with feedback alone, but I didn't find a clear approach for how to set a button name from the feedback code. Using a variable also clearly indicates where the button name is sourced from and doesn't require the module to intercept and overwrite the button name on configuration save. I think this was a simpler approach that reused existing components of the application.

[tap-chris]

@oblogic7 I've tested it at the venue and it did work as expected. Only the QoS did not work. The reason for this is that you defined QoS as type number but you didn't add min and max so I could only use QoS 0 while I'm mostly using 2. Retain works though. Add min: 0, max: 2, that should do it.

[bmvetter]

I have a been working on a TCP<->MQTT bridge for control and feedback of some home automation/home theater devices. Thus far, I am talking to an Epson 5040UB projector and a Marantz 8802a AVR. This is in my home diy environment, not broadcast.

I have only discovered companion an hour ago, but maybe my related work thus far can be useful.

My nodeJS app makes a TCP connection to the AVR, and another to the projector.

For control, the app subscribes to a topic to listen for commands, which are sent verbatim via TCP to the device.

On these devices, state change events for any reason appear on the TCP connection as a new line of text. The nodejs app simply mirrors these feedback events by publishing each line of text verbatim to the MQTT topic as a string (not in a JSON envelope). At this point it is up to the subscriber to interpret the event, which is specific to the device protocol.

So, this is just an opaque bridge at this point, that knows just a little about connecting to these particular devices.

What started all this was that I wanted to be able to change something either from the unit, or a from an IR remote, or from an app, and to be able to see and display the current state change (e.g. the master volume) in several places. The Marantz device only allows one TCP connection at a time, so I needed a broker, and MQTT turned out to be perfect for this.

I own several streamdecks, and just today I have discovered companion. Obviously this is very interesting. I'll go take a look at the module code.

sending commands:

$ mosquitto_sub -t "prontto/#" -v
prontto/av/! PW?
prontto/av PWON
prontto/pj/! PWSTATUS?
prontto/pj PWSTATUS=01 00000000 00000000 T1 F1

spontaneous events coming from device.

$ mosquitto_sub -t "prontto/#" -v
### turn unit off
prontto/av PWSTANDBY
prontto/av ZMOFF
### turn unit on
prontto/av ZMON
prontto/av PWON
prontto/av SSINFAISSIG 02
prontto/av SSINFAISFSV 48K
prontto/av TFHDCMP
prontto/av TPHDOFF
prontto/av PWON
### increase master volume 
prontto/av MV505
prontto/av MVMAX 98
### increase master volume 
prontto/av MV51
prontto/av MVMAX 98
### increase master volume 
prontto/av MV515
prontto/av MVMAX 98

Control device by commands over MQTT

### use MQTT to send a MVUP command to the AVR to increase master volume
prontto/av/! MVUP
prontto/av MV52
prontto/av MVMAX 98

[oblogic7]

I think you have a really good use case for MQTT in companion. There are likely many other "bridge" projects like yours that enable MQTT support for certain devices. Ideally, Companion would have a dedicated module instead of using a bridge, but that will take time and serious effort to cover all possible devices that already have MQTT support/bridges. Even then, if the device is not widely used, a dedicated module may not be added to Companion. MQTT would open up the ability to use many different devices once it is added.

Take a look at the module code and feel free to make improvements. I'll take all the help I can get. Currently, I know there are some bugs around cleaning up the variables when a feedback is removed.

[josephdadams]

I moved this to the mqtt module repository. You guys can take it from here. Thanks!