MagentaTV Binding for Deutsche Telekom MR 4xx

UPnP is enabled, does it have to be disabled?
BTW, i own a 7490 and a 7270, which also do not have the /html/capture.

But anyhow, with the doku on the avm-page you also get the info how to run the packet-captures, so no issue at all.

Thanks HJ

PS: Looks like the “B”-version of the MR401 is just the actual software-release…

PPS: That´s what the openhab.log say:

Questions:

  • Should there been anything at HOST= ???
  • Does the UDN have to match anything? If s, where can i find it?

The UDN field has to be left empty, once the Binding discovers your receiver, it will set the correct value.
UPnP has to be enabled…

It does not let me to let the UDN empty at “manual add” :frowning:

I see, in that case, we have to wait for Makus, he is actually trying to do a new build for 2.3 …

Found another issue:
Both of my entertain-receivers do not listen to port 49153 nor 49152 (tested with Angry-Scan and telnet). They even do not react on a “ping”, (no matter if they switched on or off) although they are shown up on my fritz-box (and certainly work well).
Do i have to configure something at the receivers itself??

ok some points from my side

  • open the OH console and make sure that bundle:list shows the entertaintv binding with state Active
  • you need to have the upnp transport installed, e.g. by installing the HUE binding or any other from the standard distro, otherwhise starting the bundle will fail
  • if the state is not active try “bundle:list” to get the bundle id and then "bundle:start " and check if errors are displayed
  • Port 49152 was dfiscovered from the iOS App, 49153 doesn’t work in my setup
  • UDN and MAC address are discovered automatically when the UPnP discovery is completed successful
  • How did you get your thing into the inbox when the discovery didn’t worked? Did you created this manually?
  • There is no need to empty the UDN, this will be filled by the binding and should not be modified (that’s the reasons why it is a mandatory field)

I your screenshot I see “HTTP GET” failed…connect timed out. This is a clear indicator that the IP address is incorrect or the discoery was not completed. Again: did you manually created the thing?

the procedure should be

  • copy the jar to the addon folder
  • do NOT create a thing manually / don’t create a .things file or entry
  • turn on the receiver
  • a thing should come up in the Inbox when initially discovered, otherwise do a manual scan from the Inbox

This thing has to be discovered automatically! This fills the receiver’s IP address, MAC address, UDN. The port is currently hard coded in the binding (see above) so don’t worry if a different number is displayed.

By the way: /htm/capture.html also works for the 7490 (that’s my setup) or you could do a tcpdump on the raspberry to get the data.

did you verfied the network setup on the receiver? the receiver must be running, the network connected and the ip address accessible from the raspberry. if you use wifi this should run in bridge mode to clients could reach each other

here is a 2.3 build, but I won’t expect a difference in general
org.openhab.binding.entertaintv-2.3.0-SNAPSHOT.jar.pdf (39.6 KB)
(rename xxx.jar.pdf to .jar before copying to the addon folder)

Yes, you have to enable remote connection at every receiver. I‘m not home atm, so cannot exactly point to where to find this setting.

Check Einstellungen->Dieses Gerät->Systemeinstellungen->Netzwerk
you see the IP address and MAC address

Here are some answers to your questions:
Binding looks to run, that´s what the bundle:list says

image

This is also the state after a restart.
After the (automatic AND the manual) discovery failed, i added the thing manually. Deleted them in the meantime.
Installing the HUE-Binding and/or HUE-Emulation did not change anything, still the discovery do not find anything:

IP-Adress on the receiver is verified to be 192.168.0.42, network-config on the MR401 is ok (and btw. working well.
The system do not run on a raspberry but on a virual Linux-machine (i do not think that makes a difference). But at least, the linux-box is not using WLAN but a cable-connection, so bridge-mode on the fritz should not be necessary (it is anyhow switched on, so also not a issue).

@hmerk: As the receiver is controlable with the mobile-app, i assume the remote-connection IS switched on and working. There is only a setting “mobile Geräte können sich verbinden”, which is think is the one you are looking for. And this on is ticked on.

start of the bundle in openhab looks also pretty ok, until up to an error “unknown:512”. Maybe this points into the right direction??

could you please check if UPnP is running

bundle:list | grep *.upnp

if not, do a

feature:install openhab-transport-upnp

Hmmm, get this, which makes me confused, as the paper-ui is running well:

any idea??

No idea, could you please restart openhab and check if UPnP was installed. Also check if you MR was discovered.

Didi a restart in the meantime of the Router, the receiver and the whole openhab-server.
But things are going more and more strange, i`ve two times the basic UI now and get the same error as above.

Maybe it´s time to do a clean install and not do tests in my productive environment. My family would not be happy, if the whole stuff is not working :wink:

Let you know the outcome, but this may take a while.

Anyhow, thanks for your help…

Please use this jar I posted above

doing a bundle:list
38
check that that both “EntertainTV Binding” and “Eclipse Smart Home UPnP Transport” are listed with status Active

Please remove any manual thing definitions and make sure that the thing is not listed under Configurations->Thing

Try to install the HUE binding - this brings the UPnP support anyways (was the trick which worked for me).

ok, I saw the same connect problem with my setup. It’s simple: After the receiver was discovered the thing became ONLINE. After a while the received went to standby, which is a deep sleep in my case (Standby+). When restarting OH I saw exactly the same error, because the receiver was simply off and not responding. So, make sure that the receiver is powered on when pairing. PING has to work, otherwise the box is not reachable.

For now the binding has no auto recovery when the receiver becomes online again. I will also add a feature to power up the receiver with wake-on-lan, but that will be implemented at a later stage.

For the moment: If the thing becomes offline you need to remove it and re-discover or restart OH so it runs a new discovery process.

fixed a problem in detecting the local ip address on raspberry (non Mac-OS?) and also Windows
use this build - the local ip is required for the pairing callback
org.openhab.binding.entertaintv-2.3.0-SNAPSHOT.jar.pdf (40.3 KB)
(rename .jar.pdf to .jar)

@scha: I got a MR401B and did some debugging, so far

  • reports a different model number (MR401B vs. DMS_DMS_TPB=
  • uses a different port (8081 vs 49152)
  • a different description url (/xml/dial.xml vs. /description.xml)
  • has a different OS

I’m going to make those thing dynamic, so should be no problem to support different models.

Does someone has a MR402 - I would be interested, which model id is reported for this one. This is shown when the binding runs in TRACE mode. Search the log for "EntertainTV: Device discovered: - " and post the result here.