There is a protocol typically used with mid range to professional sound devices like qsys control and other products called OSC. Some DJs use this as well since its a way to use a hardware interface (like a mixer) to control the software on their PC acting as a DJ. This protocol is very simple and is a little bit simliiar to mqtt.
I guess i am not sure what is meant by missing capabilities. Any new feature is something that is missing, thats added to fill in a gap or that someone needs to make something work. In this case its a protocol like SMNP or DMX. There are a few control surfaces out that speak this protocol that would be very nice to have part of HA. This does include qsys, which I have a processer in my home that manages audio routing. It would be much easier for me to use OSC to control the levels for each room. It would also allow me to do some basic tunings like setting equalizers, gains and such. HA runs most of my audio sources but qsys deals with the routing and level setting, so having them more combined would be ideal. Also this protocol is extremely simple and basic, but I am not a coder. This protocol would allow for more integrations and solve some problems for other users. I dont want to elaborate more on specific use cases, so I will just say that having this protocol would be another useful aspect of HA.
I honestly didnt expect to get such a negative reply. This is very surprising. I am in the control industry and I deal with protocols all the time, but I understand there is not normally a place for these in the home environment, although some larger homes may require some amount of it.
Just trying to help you here. I’m not being negative, just looking for what you want to change.
I take it from your comment that you are looking for some new integrations that currently are not there.
Is there something filling these needs already written by someone as a Custom Integration or Add-on? Perhaps follow that up and help that move along. If this new function is not already part of Core’s thousands of built in Integrations or one of the multi-thousands of custom Integrations, well, I’m shocked there could be anything missing like that, honestly if it will be useful to a group of people using the project.
Remember, this is an Open source project. MOST new integrations are born as Custom Integrations built by the community first, they get bugs cleared and grow in popularity, and then they get pulled into Core.
Alternatively if you are looking to add this functionality to an existing Core function, please let us know which one(s) and what you would like to see changed so the owner can be identified to work it. Simply asking for protocol’s to be implemented in core has little or no chance of going anywhere.
So just trying to help you out here. Take it as you will, however it is meant to be positive.
I guess i am not sure how that works on the HA side. This is a network protocol very similiar to mqtt, and raw socket comms. You have to configure both sides to communicate. In my world this is actually a bit more like modbus TCP. Having the infrastructure and code to take values and have them be recognized by HA is what I am looking for in terms of an integration. Again as an example modbus TCP is just a protocol and you can use whatever hardware is supported and similiarly on HA side do whatever you want with the two way data. If I want to turn on a coil or read a sensor, I can do that now. I would be looking for the same type configuration for this OSC protocol.
I see the goal of this being something similar to the command line or RESTful command integration, however since the payload is likely to be very varied it would be good to be able to customize that. Maybe a notifier action?
Basically I’d like to be able to set up OSC receiver devices as integrations, then use action.send_OSC_my_receiving_device, with the payload “/eos/cue/13/go/” (this example targets ETC Eos lighting cues).
It seems like for somebody with the right skills, this shouldn’t be too big a deal - set up each OSC destination and then throw payloads at it from automations or buttons. I was frankly amazed it doesn’t already exist, given how prevalent OSC is in more and more control environments.
I would also like to see OSC (Open Sound Control) support added to Home Assistant. A native OSC receiver could be implemented in a manner similar to existing webhook support.
OSC is widely used throughout the entertainment and live production industries. In my specific use case, I would like an ETC Eos lighting console to trigger actions within Home Assistant. ETC Eos supports sending OSC messages but does not support calling webhooks, while Home Assistant supports receiving webhooks but does not currently support receiving OSC.
Adding OSC support would allow Home Assistant to integrate more easily with professional lighting, audio, and show-control systems, enabling reliable, low-latency event triggering without requiring external middleware.
OSC is an encoding method, not a protocol. A simple UDP listener is all that would be needed. Maybe a message decoder/validator would be useful as well so that only valid OSC messages get passed into HA.
Because of the “open” nature of the OSC addresses, it would be a never ending maintenance nightmare to do more than that, IMHO.
Even though it is a method, it would still be nice to make this easier to use. There is a lot of software out there in the DJ, staging and event arena that uses OSC and its not something you have to hand code. Its actually pretty similiar to MQTT where you have a topic and you have to subscribe to it. The handling is different. The same goes for SNMP, its easy to decode if you know how, but much easier if you have a parser already built and you enter the topic, or OID into it and it handles the rest. True node-red could very easily do this, which I may try out.
I finally got my devcontainer environment setup and was able to start looking into this. I think I’m going to use the MQTT integration as a starting point since it has both a publisher and subscriber, which is similar to an OSC client and server.
Each OSC address (or path) will have a device associated to it. I’ve only ever configured MQTT with YAML, so I’m going to base the PoC on that.
i was just thinking about this and found this thread. the thought that struck me is: this sounds like add-on territory. like the mqtt broker runs as an add-on, it seems like something akin to an OSC broker could be implemented in a docker container. those usually have options to set listening ports, etc. i don’t know if osc is consistent as to which ports are used…
usually, when an add-on like this exist, there’s then an integration that uses it’s output in HA. this one maybe would just integrate directly with multiple integrations…
just spitballing here, don’t have any real concrete suggestions.
I can look into making it an add-on but at this point I’d like to get some “real world” usage scenarios to better understand what people would do with this.
I’ve done a lot of work with OSC and so far I can do everything I need HA related with Node-RED and the HA nodes (node-red-contrib-home-assistant-websocket).
I’m just starting out with Home Assistant so my usage is likely rather simple. I have a simple UI in TouchOSC that sends OSC messages to Node-RED, which in-turn, turns on or off devices in HA. An “event” node triggers if a device is turned on or off another way, and that status change is sent back to TouchOSC, again through Node-RED.
Please tell me how you would use this and provide as much detail as possible.
As an example I have a skaarhoj waveboard, and I would love this device to work with homeassistant. It currently has a way to connect it but I want to see values go both ways. This device I would use to control the lights and audio in my office. It has 8 faders and 8 encoders, and many OLED displays that can show values. It also has RGB lit buttons that can change color too based on OSC values. I also have a DJ turntable that can speak OSC and I would love to be able to control things like music assistant or just spotify using HA. I will think of some more examples but those are two.
I’m leaning towards doing this as an add-on since it seems to be less complicated as opposed to an integration. However, OSC does not use a broker like MQTT. Instead it uses point-to-point connections. The add-on will also use the concept of a “connection” and should be able to support multiple “connections”.
While I can’t justify a Waveboard purchase, I can base my initial development on it, so you (@jaygrovr) can have something to test.
After spending some time getting a dev environment setup and building the example add-on, I’ve decided to put this on hold for now. In order to control devices and receive triggers I’d need to use the websocket API. This is the same API that is already implemented for Node-RED with node-red-contrib-home-assistant-websocket, so I feel i’d be somewhat re-inventing the wheel.
Instead, I’m going to put some time into documenting how I use OSC to control devices in HA using Node-RED.
@jaygrovr I’m happy to help you get your waveboard working. Using a button to control a device or a fader to dim a light seems worthwhile. I haven’t looked at that part of the spec yet, but setting button colors should be possible as well.
I think the part I am most interested in is being able to publish sensor data (values) back to the OLEDs on this device. There is a pretty complex setup on the skaarhoj side. I would also recommend contacting them. They may want to provide you with a loaner piece of hardware to get this going.
Do you have any links to the OSC spec for the waveboard? What I’ve found so far is very minimal and targeted towards controlling something else, not the waveboard.
I was able to write sensor values to labels in a TouchOSC template simply by sending an OSC message with a string parameter.