Proposal: Control Teufel WAMP Settings through hassfeld

[thomaskonrad]

I'd like to propose extending the library so that settings can be changed and subscribed to through hassfeld. The Teufel main host exposes a WAMP interface (based on WebSocket) on port 55555, where settings can be changed and subscribed to, even if the setting is changed externally (e.g., from the infrared remote or from the app).

I think it would be nice to then expose a service in the Home Assistant integration where settings can be changed, e.g., in order to change the audio input for a specific scene.

I've written a Proof of Concept Script for Managing Teufel Settings through WAMP. It uses the autobahn Python library and asyncio. Here's an example output:

$ python3 main.py
Please enter the Teufel main host [10.0.0.21]: 
Please enter the Teufel WebSocket port [55555]: 

Available players:

    [UID "uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"] "Speaker Mobiler Lautsprecher" in room "Mobiler Lautsprecher"
    [UID "uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"] "Speaker Soundbar Wohnzimmer" in room "Soundbar Wohnzimmer"

Please choose a player UID [uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx]: uuid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Available settings:

    Setting "audio_input_source"
    Setting "sound_mode"
    Setting "display_max_brightness"
    Setting "led_brightness"
    Setting "auto_standby_delay"

Please choose a setting you want to subscribe to and/or change [audio_input_source]: audio_input_source
Please set a value for setting "audio_input_source": 3
Please set a value for setting "audio_input_source": 
    Received updated setting from the player. New value: 3
Please set a value for setting "audio_input_source": 2
Please set a value for setting "audio_input_source": 
    Received updated setting from the player. New value: 2

I can help with the implementation, but if you agree @B5r1oJ0A9G, I'd like to coordinate the changes with you.

[B5r1oJ0A9G]

Hi there,

In general I am open for it. Although I think to remember that the settings of your example can be also be set through the already implemented API. Did you happen to have checked for this possibility yet?

I am currently quite busy, hence also my late reply.

[thomaskonrad]

Oh, I haven‘t checked for this possibility. How can I check for that? Can you point me towards a way to do that?

[B5r1oJ0A9G]

Hi again,

So, I walked over the DLNA interfacesand I think what had in mind was SetDeviceSetting

<action>
    <name>SetDeviceSetting</name>
    <argumentList>
        <argument>
            <name>InstanceID</name>
            <direction>in</direction>
            <relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable>
        </argument>
        <argument>
            <name>Name</name>
            <direction>in</direction>
            <relatedStateVariable>A_ARG_TYPE_SettingName</relatedStateVariable>
        </argument>
        <argument>
            <name>Value</name>
            <direction>in</direction>
            <relatedStateVariable>A_ARG_TYPE_SettingValue</relatedStateVariable>
        </argument>
    </argumentList>
</action>

Provided by the rendering control service of a speaker:

<service>
    <serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType>
    <serviceId>urn:upnp-org:serviceId:RenderingControl</serviceId>
    <SCPDURL>/rendercontrol.xml</SCPDURL>
    <controlURL>/RenderingControl/ctrl</controlURL>
    <eventSubURL>/RenderingControl/evt</eventSubURL>
</service>

However, after tracing the web service used by the mobile app I noticed it is downloading the framework wampy.min.js and is connecting to the concerned speaker on port 55555 to for instance adjust the brightness.

Until we get proven wrong that there is a way to reuse the existing DLNA resp. webservice interfaces, I think your proposal could be a nice improvement to hassfeld.

If you're still interested I'd propose to separate the wamp related code in a dedicated wamp.py file. The functiosn to be exposed have to go of course to __init__.py, perhaps in a dedicated block for a better overview. What's your opinion?

[thomaskonrad]

Yeah, I have done some research in the meantime and also saw that SetDeviceSetting is exposed. However, I wasn't able to find any valid device setting name that corresponds to the ones exposed by the WAMP interface. I tried all different ways of spelling the settings, with no success. I now opened a ticket with the Teufel support, hoping that they can help me out on this one.

I'll wait for their answer before I continue with the implementation of the WAMP-based client. If it turns out that we cannot use UPNP, I'll give it a try.

[thomaskonrad]

By the way, here's what I see when I subscribe to changes on my Teufel host:

$ upnp-client --pprint subscribe http://10.0.0.25:57913/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xml \*
[...]
{
"timestamp": 1644007632.440327,
"service_id": "urn:upnp-org:serviceId:RenderingControl",
"service_type": "urn:schemas-upnp-org:service:RenderingControl:1",
"state_variables": {
"LastChange": "<Event xmlns=\"urn:schemas-upnp-org:metadata-1-0/RCS/\"><InstanceID val=\"0\"><SettingValue SettingName=\"Source Select\" val=\"OpticalIn\"/></InstanceID></Event>"
}
}

It says that the SettingValue named Source Select changed to OpticalIn. So that's at least something I can subscribe to, but I cannot fetch or change it. When I do

$ upnp-client --pprint call-action http://10.0.0.25:57913/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xml RenderingControl/GetDeviceSetting InstanceID=0 Name="Source Select"

I get this:

upnp error: 404 (Setting not found)

I tried SourceSelect, sourceselect, source_select, source, Source, ... without success.