[Feat]: Extended MQTT status fields

[vbartik]

Describe the feature

Send extended states of camera, microphone, in-call/meeting to MQTT broker

Motivation

While the original great work of @Donnyp751 allows to propagate the Teams availability status, this status itself isn't always a correct trigger condition of an automation.

Extending the states would allow additional logic on top of them in home automation - for example RGB LED light translating the states into: red (camera on), orange (mic on), yellow (in call), and green (not in call).

The status (Available/Away/BRB/Busy/DND) doesn't hold much value, as just having something in my calendar triggers busy state irrespective on whether I'm actually on the meeting or not. Also, there is a vast difference between being on a meeting with camera and microphone off vs on.

Alternatives

Using the automation manually instead of relying on the MQTT information altogether in cases where the state doesn't reflect the proper automation trigger.

Additional context

No response

[IsmaelMartinez]

Thanks for the suggestion @vbartik , I will have a look and see if this is possible. I am almost certain that if we can do it we will NOT be able to limit it to things that happen in the MS Teams app, so you might get mqtt messages saying you have changed you mic status when you mute/unmute your computer or if you open other apps like zoom or the likes.

[vbartik]

@IsmaelMartinez do we really need to interrogate the device itself (mic/camera)?

Maybe basing this on the Teams controls would be sufficient? For example the control buttons (id: "microphone-button"/"video-button") and their "data-state" ("mic" vs "mic-off"/"call-video-off" vs "call-video"). These are "authoritative" for ongoing Teams call either way, and would be limited to what happen within the Teams app, right?

[IsmaelMartinez]

That will be pretty fragile, as ms do change those IDs regularly. I mean, we will have a similar issue with the status as I did mention initially on the other implementation, but we can see for how long we can keep the feature alive. I assume we will also need to check for shortcuts been trigger, as that will change that status without the app been in focus (if using the global shortcut options). Lets keep digging and digesting this feature so we implement it the right way. Maybe let's go back to the problem you are facing now, that is knowing if your status is because of a particular calendar event. It might be more reliable to know if you are in a meeting, and what type or meeting?? Thinking out loud in here. Ta

…

On Tue, 11 Nov 2025, 23:56 vbartik, ***@***.***> wrote: *vbartik* left a comment (IsmaelMartinez/teams-for-linux#1938) <#1938 (comment)> @IsmaelMartinez <https://github.com/IsmaelMartinez> do we really need to interrogate the device itself (mic/camera)? Maybe basing this on the Teams controls would be sufficient? For example the control buttons (id: "microphone-button"/"video-button") and their "data-state" ("mic" vs "mic-off"/"call-video-off" vs "call-video"). These are "authoritative" for ongoing Teams call either way, and would be limited to what happen within the Teams app, right? — Reply to this email directly, view it on GitHub <#1938 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADJHEBRZ6FLXWEEVRRSJED34JZRRAVCNFSM6AAAAACLZX7QG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMJZGI2DSMJRHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[IsmaelMartinez]

Maybe implementing 1st #1832 and then publishing those events might be a better solution if the main issue is around the meeting calendar? (is a bit of a verbose AI dump, but I did verify the app can re-use your authentication token to call the graphAPI, but mostly only for read only features)

[IsmaelMartinez]

Had a long conversation with AI and it came up with some idea in https://github.com/IsmaelMartinez/teams-for-linux/pull/1941/files , maybe we can discuss it in there but that will work better than my thinking of using the OS status. Instead uses the webrtc. Still need to validate it but it might work as that gets trigger when you are in a call, not when you got a meeting even. Feel free to ask clarifications or put suggestions in it. Hopefully is not too verbose.

I am not sure about the structure of the message and also if it will work for audio (as we do mute all the tracks as otherwise some linux OS systems do get a feedback loop) but something to explore. What do yo think?

[Donnyp751]

Seems awfully complex with the structure as it is currently. Those could be nice to have optionally as additional information to use for automations though, I didn't really consider those use cases when I initially was implementing this. I got the original idea from when I was in college the Dean of the department had a red light outside his door with a switch on it so you could see if the door was closed or not from down the hall, indicating if he was busy or not. This was essentially my modern version of that but for my office. I sometimes set my teams status to busy manually, or schedule time on my calendar to indicate "do not disturb" time via my RGB led outside my office. I just use the red, or green to indicate either available, or busy. I do have a zigbee button that can toggle and override the status light on my desk too I can tap for a quick change if I want.

[vbartik]

Lets keep digging and digesting this feature so we implement it the right
way. Maybe let's go back to the problem you are facing now, that is knowing
if your status is because of a particular calendar event. It might be more
reliable to know if you are in a meeting, and what type or meeting??

My use case ties to the fact that I work from home a lot. The main information I'm trying to relay here is how I need my family members to adjust their behavior. That is, when I'm on camera, they shouldn't barge in and get to the picture. When the call is on (either with/without mic), they shouldn't be excessively loud in close proximity to the room, nor come in and immediately just start talking to me etc.

The calls do often happen completely unrelated to the calendar, as sometimes someone just calls - i.e. used as a phone. Also, I don't want to prevent my kid to come in and ask for something if the 1-hour planned meeting took just 10 minutes and ended early. If I relayed calendar info, this would happen. In short - relation to "in call" is way more relevant than "calendar event running". And determining whether if this is a (planned/unplanned) meeting or just an ad-hoc call/meet now/etc. isn't too important for me.

Really mapping "on call + mic status + camera status" => real world indication is the answer for me that wouldn't require anything else and be completely automatic.

[IsmaelMartinez]

those will be extra events in any case, so you then can build your logic around a combination of them if required. I will try to reduce the size of payload and review the plan, but it should be doable, not sure how reliable. I want to close a few MRs before that as they are starting to pile up.

[IsmaelMartinez]

for info, having a chat in another issue found out there are others using other solutions for this feature. #1934 (comment)

I am cleaning up a few other changes I am on the go (some code/docs simplifications, new modals and the likes) but will be dedicating a fair bit of time to mqtt after that. It does seem to be an appetite to add commands/actions to it so we can "trigger" things in ms teams.

A few different moving pieces so trying to align it all! Thanks!