@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.
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?
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.
for me you make Entertain smart , 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.
Thanks, hopefully I could match your eypectations, otherwise you get a white hole:flushed:
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.
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.
PLEASE PLEASE: Do some testing and post your results here. The basic functions are quite stable now we are moving to the advanced level 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.
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?