Telekom TV / MagentaTV / EntertainTV Binding

binding
Tags: #<Tag:0x00007fe053f64a60>

(Markus Michels) #246

oh, “better than nothing” is better than nothing

@hmerk Do you know if the catchup for this could be realized by using the functionality build into the framework? We already discussed the UPNPIOService (maybe written differently, can’t remember exactly), which also seems to give some additional status information.

If it solves the problem I could implement your code - not a big deal to have a test build. This would cover a “soft power off”, a real power off should be detected by the periodic subscription renewal, because the send request should fail.

Any other ideas? I can’t believe that this is not reflected in the UPnP standard.

Did you saw any query of the app, which reflects the display state (standby with display off vs. standby with display on). The app loads several XMLs at startup, maybe there are additional calls after a certain amount of time.


(Hans-Jörg Merk) #247

I will check later tonight when back home.
Might be a possible way to go…


(Slugzero) #248

Not sure if I understand your question properly - what do you mean with “standby with display on”?

For the transition from standby (display off but network online) to on (display on) when pressing the power button on the remote control, my best bet right now would be to use the “new_play_mode” event, since it is already available in the EntertainTVHandler class. When switching from standby to on, one of the first things that happens is a change of the play mode to “20”:

[TRACE] [.internal.handler.EntertainTVHandler] - EntertainTV: process event, json='{"new_play_mode":20,"playBackState":1,"mediaType":1,"mediaCode":"3679","duration":0,"playPostion":0,"fastSpeed":0}'

So my suggestion would be to assume that any other play_mode than “0” means “power/display on”. Any thoughts on this?


(Markus Michels) #249

I think not a good idea. From experience I could say that the playEvents are no super consistent.
Code 20 is the status buffering, so not status off.

    // EVENT_PLAYMODE_CHANGE: for a complete list see
    // http://support.huawei.com/hedex/pages/DOC1100366313CEH0713H/01/DOC1100366313CEH0713H/01/resources/dsv_hdx_idp/DSV/en/en-us_topic_0094619231.html
    public static final Integer EV_PLAYCHG_STOP = 0; // STOP: stop status.
    public static final Integer EV_PLAYCHG_PAUSE = 1; // PAUSE: pause status.
    public static final Integer EV_PLAYCHG_PLAY = 2; // NORMAL_PLAY: normal playback status for non-live content
                                                     // (including TSTV).
    public static final Integer EV_PLAYCHG_TRICK = 3; // TRICK_MODE: trick play mode, such as fast-forward, rewind,
                                                      // slow-forward, and slow-rewind.
    public static final Integer EV_PLAYCHG_MC_PLAY = 4; // MULTICAST_CHANNEL_PLAY: live broadcast status of IPTV
                                                        // multicast channels and DVB channels.
    public static final Integer EV_PLAYCHG_UC_PLAY = 5; // UNICAST_CHANNEL_PLAY: live broadcast status of IPTV unicast
                                                        // channels and OTT channels. //
    public static final Integer EV_PLAYCHG_BUFFERING = 20; // BUFFERING: playback buffering status, including playing
                                                           // cPVR content during the recording, playing content
                                                           // during the download, playing the OTT content, and no
                                                           // data in the buffer area.

I defiantly prefer to get for the UPnP signals.

Lets see what @hmerk finds out.


(Markus Michels) #250

tried your code, but got an

EntertainTV: Exception in Poweroff listener: Can't assign requested address (class java.net.SocketException)

(Markus Michels) #251

I found https://stackoverflow.com/questions/18747134/getting-cant-assign-requested-address-java-net-socketexception-using-ehcache

but adding System.setProperty(“java.net.preferIPv4Stack”, “true”);
or -Djava.net.preferIPv4Stack=true to command lined
didn’t fixed it.


(Markus Michels) #252

progress and good news:wink:

a) the code works if I set the network interface for the socket

               socket = new MulticastSocket(UPNP_PORT);
                socket.setNetworkInterface(networkInterface);
                socket.setReuseAddress(true);
                socket.setReceiveBufferSize(1024);

b) the receiver send keep alives

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=120
BOOTID.UPNP.ORG: 1
CONFIGID.UPNP.ORG: 1
LOCATION: http://192.168.6.121:8081/xml/dial.xml
NT: upnp:rootdevice
NTS: ssdp:alive
SERVER: Linux/2.6 UPnP/1.1 zss/1.0
USN: uuid:70dff

So I could use the included IP to match the receiver renewing a timer. When the receiver is physically off the alive messages will stop.

c) The receiver send a byebye when going to suspend mode

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=120
BOOTID.UPNP.ORG: 1
CONFIGID.UPNP.ORG: 1
LOCATION: http://192.168.6.121:8081/xml/dial.xml
NT: urn:dial-multiscreen-org:service:dial:1
NTS: ssdp:byebye
SERVER: Linux/2.6 UPnP/1.1

which can be used to turn the thing into offline mode.

Need to find out if the alive messages come in only when the receiver is powered on.


(DeepZone) #253

Hello,

I get an error after I have entered my access data.

Status: UNINITIALIZED - HANDLER_INITIALIZING_ERROR javax.json.spi.JsonProvider: Provider org.glassfish.json.JsonProviderImpl not a subtype


(Markus Michels) #254

please include information on the environment

I saw this problem once abd it could be fiyed with a re-build, I‘ll doe this again later today


(Markus Michels) #255

give this one a try (not yet in the repo)
org.openhab.binding.entertaintv-2.4.0-SNAPSHOT.jar.pdf (172.3 KB)


(Heiko Fanieng) #256

Great work Markus👍,

for me you make Entertain smart :blush:, today i switched my old Entertain-tarif to Magenta TV and then i’ll order a MR 401 to replace the old “black hole” MR 303 B.

I was very happy to see that the Hue Binding (with Sensor-Support in development) and now the Magenta TV Binding seems to be able to close same black holes in my smart home.

Regards
Heiko


(Markus Michels) #257

Thanks, hopefully I could match your eypectations, otherwise you get a white hole​:flushed::sunglasses:

I‘m still working on multiple MR support, tricky, because I have only one and playing logfile pung
pong with Tobias. We made progress, but still some conflict when the 2nd comes online.


(Markus Michels) #258

any other feedback on the last build?


(DeepZone) #259

Thanks Markus, for re-build this binding. Now it works fine. :slight_smile:


(Markus Michels) #260

:grinning:


(Markus Michels) #261

Update:

  • beta1 has been closed. Together with Tobias we did various testing and multiple MRs are now supported! There is one situation, which needs to be analysed: After some unpredictable time one or more of the MRs do not accept sendKey or/and do not send status updates. This status stays until the binding does a SUBSCRIBE renewal. I found one situation, which might cause this problem: in theory the binding waits on the SUBSCRIBE answer and could run into an endless loop if nothing is received.

  • I opened up beta 2. This includes a fix for the potential endless loop AND the first implementation of the UPNPPowerOffListener. The binding listens to the UPnP-SSDP messages. If the receiver is powered off the binding receives an SSDP byebye. This will be used to turn the binding into OFFLINE state. An STB event (playContent & programInfo) turns the thing into ONLINE state if it doesn’t indicate a stop event.

The power channel now uses the thing status (ONLINE/OFFLINE) to decide if a POWER toggle has to be send, e.g. you switch to OFF and the thing is already offline or ON and ONLINE the binding will not send the POWER toggle - in this case only a log message is displayed. If the desired state doesn’t match the current status a POWER toggle is send. Worked well in my first tests, but needs to be verified.

https://github.com/markus7017/org.openhab.binding.entertaintv/blob/beta2/target/org.openhab.binding.entertaintv-2.4.0-SNAPSHOT.jar

PLEASE PLEASE: Do some testing and post your results here. The basic functions are quite stable now we are moving to the advanced level :slight_smile: Finally it needs more testing on recovery robustness, e.g. you physically power off the receiver - does the thing gets OFFLINE, because network I/O fails and does it comes up again and restoring power? etc.


(Markus Michels) #262

Please note: You could also send the key POWER if the power channel/item (switch) is not working properly for you

The Thing state will be used to decide if a change to the power button/switch will result in a sendKey POWER or not: If thing is online and item is changed to ON sending POWER will be suspressed, if thing is offline it will be send and vice versa if Thing is offline.

The following scenarios are open

  • The binding could not validate the initial status of the MR when starting/restart. For this I assume the Thing is offline until the pairing is completed and then switch to ONLINE. This might be wrong if the MR is powered off, because also in this state the network interface is up and it reacts on pairing etc. Persistence might cover some of the aspects (restoring the status before the restart), but anyways the state of the receiver and the Thing might be out of sync.
  • When the binding sends a POWER off the binding will try to re-connect (e.g. recover after a network error), will pair and the pairing completion will change the thing status to online, which is wrong is this situation.

Any ideas how to bring the power item, the thing status and recovery mechanism together to work stable?


(Markus Michels) #263

Did anyone verified a MR201? Like to confirm this and add it to the documentation.


(W. Althoff) #264

Only power off works

With power off the device will also turn on again

2018-11-15 19:20:07.935 [DEBUG] [.internal.handler.EntertainTVHandler] - Channel command: OFF for channel power
2018-11-15 19:20:07.936 [INFO ] [.internal.handler.EntertainTVHandler] - EntertainTV: Toggle power state (send POWER)
2018-11-15 19:20:07.936 [INFO ] [ertaintv.internal.EntertainTVControl] - Control: Send Key ‘POWER’ (keyCode=‘0x0100’) to device ‘DMS_172.17.2.152’ (513D06D14784C11F7A6EE2D74132706C)
2018-11-15 19:20:07.936 [DEBUG] [ertaintv.internal.EntertainTVControl] - sendKey keyCode=‘0x0100’ to ‘DMS_172.17.2.152’ (513D06D14784C11F7A6EE2D74132706C, 172.17.2.152:49152)
2018-11-15 19:20:08.191 [DEBUG] [.internal.handler.EntertainTVHandler] - STB event playContent: playMode=stopped, duration=-1, playPosition=-1
2018-11-15 19:20:13.447 [DEBUG] [.internal.handler.EntertainTVHandler] - Channel command: ON for channel power
2018-11-15 19:20:13.447 [DEBUG] [.internal.handler.EntertainTVHandler] - EntertainTV.POWER: No power toggle required


(Markus Michels) #265

what’s the thing state in this situation? Please change to TRACE mode. I could power off/on 10 times in a row.