I’m optimistic that I found the SendKey problem with MR400/MR200. While reviewing the original bash script and the binding implementation I notice that there was one call missing to verify the pairing result. It seems that MR401/MR201 don’t require that, but has a good chance that the MR400/200 sees that as "pairing successfully completed“.
I also reworked the device dispatcher for pairing and events. This should now support multiple MRs.
I also reworked the recovery handling.
Periodically renew the event channel subscription and re-connect if necessary
Periodically verify the pairing and re-pair if necessary
Re-connect on SendKey if thing is offline
You noted “re-worked”, so I need more time for testing to catch the various scenarios and make it robust. However, I’m very interested to hear if we beat the MR400/MR200.
Add the MR400, check for initialization, SendKey, events
than add another MR
change channels on both MRs and check if the event information is displayed properly
SUPER. I first activated the MR400 alone, and it can be controlled. Great job.
Have then added the MR200. This is displayed.
Unfortunately, I can not continue testing with the MR200 at the moment. My wife uses that right now.
I know those handicaps😎 That‘s good news!!
to magen expectation: that is an as-is build, I need to do some more work on ehe recovery handling to make it consistent
The on/off topic is still open: Currently I didn‘t found a way to identify the power on/off status if the receiver is connected to the network. In this situation it accepts the requests even when in suspend mode or off. PING doesn‘t work at all with 401/201, http request will be answered, but I found nothing so far giving me the disllay status. So when you send a power button from a rule/scene you could turn if off while you want to start watching and vice versa.
Any idea welcome.
They made the portal the default start screen, which means that you need to go to the TV icon and press OK. The TV button on rhe remote doesn‘t do that job nor dis I saw ankey code for a TV button in the Huawei spec. This also means you need the physical remote ro start watching TV even you like to use only the mobile with a HABpanel oder the OH App - Telekom: that‘s bad!
If the UI displa a system dialog the OH doesn‘t work either. You need the physical remote to close those dialogs before the OH remote continues to work. Not nice, but is’s not a drama
So now it’s time to head for my actual destination. The integration in ALEXA. If someone has an idea of what the sitemap must look like, let’s get started. Do I need a Translation MAP? I’ll try it out
I have an integration in Alexa for Scenes, I’ll also add some major channels (our 10 favorites), but not all.
I have two integrations
A HABpanel-based one for the iPhone (in fact having buttons for all major keys sending the key code to the _Key channel and including the displays for the program info)
Integration with Alexa based on the HUE biding and then exporting control items with the [“Switchable”] tag. This works for scenes (triggering more complex rules) as well as single controls (items)
The hard part could be finding the right keywords. Alexa gives buildin devices names priority, e.g if you say “Alexa turn the radio in”/“Alexa schalte das Radio ein” it will activate the amazon service rather than the smart home device. Same with abbreviations. “ARD” doesn’t work so I use “DAS ERSTE” - sometimes tricky to remember. The could use the Alexa App to see what she understood and sometimes it helps to adjust the keyword, but sometimes you have to be created with the name.
What’s missing from my point of view is a nice HABpanel widget:smiling_face_with_three_hearts:. This gives more graphical options (e.g. embedding the program infos), but my HTML knowledge is rare, esp. when it comes to style sheets. Any input here is welcome.
If you are going to create a sitemap for the OH App be so kind and post it here. I still need this section for the doc, but I’m not using the OH App anymore (for remote access I use a VPN into my home network, so no proxy or cloud service is required:grimacing:).
Please provide feedback on longer use, event consistency, recovery or any other issues, which can’t be reproduced by just starting the debugger.
pairimg renewal disabled - I noticed that even a verification shows the „openHAB connected“ on the Tv screen. Lets see what happens when pairing was completed and verified (maybe the not working after 30min was also because of the missing pairing verificatiin)
Periodic event sunscription renewal increased from 2 to 5 min - it seems that high frequence interferes with event notifications
I can now control the following functions with ALEXA.
Channel up / down, volume up / down.
on / off (without knowing the status).
I solved that in Alexa with ROUTINEN.
What the binding can not yet do is direct selection of the channel.
It can, send a “1” to _Channel and it will select channel 1…
Not sure if more than 1 digit works, “12” will be broken down to 2x SendKey (“1” and “2”) etc.
How do you implemented “on / off (without knowing the status).”? Keeping the state doesn’t help when you control it by OH/Alexa and then someone picks up the physical remote and press power (the binding does not get an event).
I can not specifically turn it on or off.
When the device is on it is switched off and vice versa. Better than nothing.
with the direct selection of the channel, I do not understand.
Here are the different attempts of the sitmap.
no, you need to write the channel string info the _channel item
a) HABpannel allows you to add a button item with command string “1”, “2”, “99” or a selection list
b) The Selection, Setpoint and Text items should work, but I’m noch familiar with sitemaps
b) with a rule
Did you checked the OH log? What happens if you trigger the action?
try PapierUI->Control and edit the Channel value. If that doesn’t work post the TRACE log of the sequence
and another fix: The right program info is displayed (not the next one) and start time is now in local time
duration from play event will only be used if > 0, so the one from program info for live TV
First of all, awesome work! I discovered this binding only 3 days ago and it does a really great job for me already. The only thing I am still missing is proper detection of the on/off state.
I had a look at the network traffic in my setup, and I noticed that there is a DIAL (http://www.dial-multiscreen.org/) uPNP device, which is not discovered by the UpnpDiscoveryService, which sends a byebye broadcast when the receiver is powered off:
Since I am not yet familiar with the whole openHAB development, I did not come up with a proper implementation (via the UpnpDiscoveryService does not seem to work), but this should serve the point:
package org.openhab.binding.entertaintv.internal;
import java.net.DatagramPacket;
import java.net.InetAddress;
import java.net.MulticastSocket;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class EntertainTVPoweroffListener extends Thread {
public static final String MULTICAST_ADDRESS = "239.255.255.250";
public static final String STB_ADDRESS = "192.168.1.121"; // FIXME hardcoded EntertainTV address
public static final String BYEBYE_MESSAGE = "ssdp:byebye";
public static final int PORT = 1900;
private Logger logger = LoggerFactory.getLogger(EntertainTVPoweroffListener.class);
protected MulticastSocket socket = null;
protected byte[] buf = new byte[256];
@Override
public void run() {
try {
socket = new MulticastSocket(PORT);
socket.setReuseAddress(true);
socket.setReceiveBufferSize(32768);
InetAddress group = InetAddress.getByName(MULTICAST_ADDRESS);
socket.joinGroup(group);
while (true) {
DatagramPacket packet = new DatagramPacket(buf, buf.length);
socket.receive(packet);
String message = new String(packet.getData(), 0, packet.getLength());
if (message != null) {
if (message.contains(STB_ADDRESS) && message.contains(BYEBYE_MESSAGE)) {
logger.trace("EntertainTV: Receiver powered OFF. Message: " + message);
}
}
}
} catch (
Exception e) {
logger.error("EntertainTV: Exception in Poweroff listener: {} ({})", e.getMessage(), e.getClass());
}
}
}
I know that listening to an event to determine the power state is not ideal, but it is better than nothing…