feat: publish to an MQTT broker

[ymauray]

This PR implements the ability to publish messages to an MQTT broker. If you're happy with this, I'll look into implementing the counterpart, listening for incoming MQTT messages.

[Kruiser8]

I changed the base to develop as I can then include it in the next big release.

I see a couple minor things I would change, but they're easy enough to change once it's been merged in. Did you want to do the triggers in this PR?

Also, how are you testing this?

[ymauray]

If you're ok with what you see, I can amend the PR later this weekend with the triggers. Let me know what you'd like me to change, and I'll do the work. To test this, I run a stock mosquitto server locally. I'd be happy to craft a quick "howto" guide if you want.

[Kruiser8]

Hey @ymauray,

I updated develop with some updates. I think you have to merge in the changes and resolve the index.html conflict. Shouldn't be a big issue.

This update has been in progress for awhile, so I'd like to get the next KC version out this week if possible. I have the release notes written up so all I have to do is click a few buttons :) I can wait a bit for this since I think it'd be a nice-to-have in the update.

Sorry for the delay, but here were my minor changes:

• KC should try to reconnect in the event that the MQTT Websocket is disconnected/closed.
• On connection, call this.success() on the Handler so that the MQTT handler is marked as set up successfully for the _unsuccessful_ and _successful_ parameters. See this example for reference.
• Instead of keeping track of the client with this.initialized, I would probably use the client.connected check instead.

[ymauray]

I'll get on that ASAP !

[ymauray]

Quick note about reconnecting : the mqtt.js library does that automatically, nothing needs to be done on the client side.

[Kruiser8]

@ymauray, is this good for me to review again? I didn't know if you were still working on things.

[ymauray]

I have been extensively using the MQTT Publish action for two weeks now, on live streams. I do not use the OnMQTT trigger - yet - on my streams, but I have tested it :

• Two triggers on the same topic : both fire and do what they are supposed to do
• Two triggers on different topics : each one only fires for the topic they listen to
• Starting OBS before the broker : everything reconnects once the broker is present

I'm confident this is good to go. I'll be happy to look back at it if/when someone has a problem with the MQTT part.

And given I'm going to use it for a while, should I find a bug, I'll send a PR to fix it.

[ymauray]

By the way, the way I use this is for my own overlays : I do not use StreamElements or any other provider. I did my own, that I use as local browser sources For example, I use that for my todo list : In KC, I have a OnCommand trigger that sends every !todo stuff to a dedicated topic on MQTT broker. In my overlay, I listen for that topic, and I use indexedDB to store the items and update the display. I also use a OnEveryChatMessage trigger to manage my own chat widget.

KC is really a great piece of software, thanks a lot for building it !

[ymauray]

Thanks for proving that my code architecture isn't too hard to follow 😅 You're the first person to build their own integration.

You're welcome ! I took a little while but it's well documented and well written, and there are so many different cases implemented already that it's not too difficult to replicate.

Keep up the good work !

[Kruiser8]

It sounds like you may not need the MQTT broker for your use case. Why not use the OBS websocket for communication?

The KC widget has examples of that: https://github.com/Kruiser8/Kruiz-Control-Widget#configure-the-script

[ymauray]

Well, two reasons why I did that :

1. For the fun of doing it !
2. Because I didn't realize KCWidget was a thing 😀