SkyQ Receiver Binding [3.2.0;3.9.0)

As far as I know there is no direct way to control the volume via a Sky Q control command.

I have an interesting issue… Command Up doesn’t work. Left right down work but up doesn’t work. Are you know why? Using 3.2.0 installed binding via market and setup via gui.
ChannelState and TransporState are UNDEF.

I can confirm that the up issue is a bug. I will provide a fix shortly.

Are you experiencing other issues or strange behaviour? I’m asking because you mentioned the Channel and Transport states. These are initially set to UNDEF until the physical state is retreived from the device.

Thanks! I will test other things within next day. Then I’ll give feedback.
If I use Apps are they visible to title and transport?

Not yet, but that is on my to do list (assuming this is possible at all).

Unfortunately, there is no official documentation regarding the control of the SkyQ receiver over IP, and I’m completley relying on the work of others. This means I can’t make any promises regarding the supported featues of the binding going forward.

It’s great that you invest time into this! We will see what the future take to us.

I’ve published a new version that fixes the up command issue.

Thank you very much. Will give a try tomorrow.

Great, UP Command works now.
TransportState and ChannelTitle stay UNDEF. I’ve tried with pause at live tv and play but TransportState stay on UNDEF. I don’t get any ChannelTitle. Stay also on UNDEF. Using this with freeTV channels and payTV. Are you know which TV channel work with it?

Hi all,

This thread is a few months old now but I’ve just stumbled onto it.

I’ve installed the binding and I’ve got Status of Offline and Communication_Error: not reachable.

The SkyQ box is on a static IP, 192.168.1.50

UID: skyq:skyqreceiver:SkyQ
label: SkyQ Receiver
thingTypeUID: skyq:skyqreceiver
configuration:
  configurablePresets: true
  hostname: 192.168.1.50
  retryInterval: 60
  checkStatusInterval: 60
  refreshInterval: 30

Can’t see what I’ve done wrong…is this binding still working and if so…any pointers???

Hi,

The SkyQ binding should still work at least for UK, Germany, and Italy.
Definitely it works for my German box with latest firmware.

As simple check you could try to receive the system information with the following link: http://192.168.1.50:9006/as/system/information

You could also enable debug logging for the binding to get some more information. I’m happy to review the logs once available.

I’m also in Germany and I use the binding since several months, nothing changed, it is still working. I just never could get the statusChannels#currentChannelTitle and statusChannels#currentTransportState to work. I tried reinstalling several times but finally gave up.

Same for me in Germany.

The issue with the current title and transport state channels will be fixed in the next release of the binding, which I plan to make available within the next 1-2 weeks.

This release will also include some minor enhancements (e.g. defining macros for control commands, improved power on/off handling, show current programm information).

1 Like

A new release is available (see initial post). The ‘show current programme’ feature will be provided in a later release.

I am using 3.4.0 binding with OH 3.4.3 and get following error message in log

2023-04-20 04:00:34.488 [ERROR] [skyq.internal.protocols.RESTProtocol] - nulljava.lang.InterruptedException: null
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1343) ~[?:?]
        at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:232) ~[?:?]
        at org.eclipse.jetty.client.util.FutureResponseListener.get(FutureResponseListener.java:100) ~[bundleFile:9.4.46.v20220331]
        at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:730) ~[bundleFile:9.4.46.v20220331]
        at org.eclipse.jetty.client.HttpClient.GET(HttpClient.java:377) ~[bundleFile:9.4.46.v20220331]
        at org.eclipse.jetty.client.HttpClient.GET(HttpClient.java:362) ~[bundleFile:9.4.46.v20220331]
        at org.openhab.binding.skyq.internal.protocols.RESTProtocol.getChannels(RESTProtocol.java:83) [bundleFile:?]
        at org.openhab.binding.skyq.internal.SkyQHandler.refreshSkyChannels(SkyQHandler.java:206) [bundleFile:?]
        at org.openhab.binding.skyq.internal.SkyQHandler.refreshState(SkyQHandler.java:479) [bundleFile:?]
        at org.openhab.binding.skyq.internal.SkyQHandler.refreshState(SkyQHandler.java:467) [bundleFile:?]
        at org.openhab.binding.skyq.internal.SkyQHandler$RefreshState.run(SkyQHandler.java:396) [bundleFile:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:829) [?:?]

Does the error appear regularly? If yes, do you use any other special addons for HTTP/REST communication?

Just from reading the log I’d conclude that this error results from a temporary issue. Furthermore, I haven’t seen this error in my OH 3.4.3 envrionment with the same binding version.

UPDATE
I’ve just seen the same error also in my logs.

From the pattern of the occurances it seems that the error is related to the event when the receiver goes offline (deep standby) or becomes temporarily not reachable. I will consider an improved handling of these events.

Thanks for your support :+1:

An additional feedback. With latest binding I get a lot of INFO messages in openhab.log.
Currently I am filterung these with following string: “services from SkyQ”

Due to filtering I cannot provide the full string. If you need more details to recognize the string, please give feedback and I will temporary deactivate my filter.
My wish would be to minimize this regular info message because it spams the log.

Can i stop this Infos from the binding? Is it necessary to know that the channels/services are updated? It’s spam my log and I can’t took a point of view to other issues.

Oh i see there is a new version for 4.0.0 → SkyQ Receiver Binding [4.0.0;4.2.0) but i stay on the old one. I’ve remove and install the binding.

This issue is fixed in the 4.0 version. As a workaround for this version, add the following line to the log4j2.xml file under the Loggers section to supress the Info logs:

<Logger level="WARN" name="org.openhab.binding.skyq.internal.SkyQHandler"/>
1 Like