PanasonicTV / OH3

I don’t think the thread issue is a problem here. I rewrite all the code on OH side.

This is an interesting threaddump. I see no references to any bindings at all in that file. When I run a dump on my OH and grep for org.openhab.binding I get a solid 100+ lines to indicate what’s owned by each specific binding. When I grep that threaddump, I don’t get a single one.

Yeah that’s plausible. This was an empty openhab with the panasonictv binding and jupnp feature installed. Just one thing and some items. If I understand the upnp service correctly there is only a jupnp executor active that discovers and registers services and a polling executor of the panasonic binding.

I’ve submitted Add retryAfterSeconds/maxRequests - Disable HTTPS from UPnP action calls by morph166955 · Pull Request #128 · jupnp/jupnp · GitHub to add the retryAfterSeconds code to the jupnp train officially based on the work from lolodomo. I can post a jar if anyone is interested.

Ok, dumb question for those having this problem. What happens when you add the following lines to services/runtime.cfg

org.jupnp:asyncThreadPoolSize=60
org.jupnp:threadPoolSize=30

(and if it helps, what happens if you increase those further)?

Cross posting from the sonos thread.

For those interested in testing, this is a very experimental image (although it seems to be stable on my system) that may resolve this issue. In fact, it may significantly improve performance of upnp devices.
This version of jupnp has some extra code on the threads that let them work without a pool. There is a chance that this can cause instant spikes in memory or cpu, but they should be short lived.

In addition to retryAfterSeconds, you can add:

org.jupnp:asyncThreadPool=false
org.jupnp:mainThreadPool=false
org.jupnp:remoteThreadPool=false

Please make the config addition with OH stopped, it will be highly disruptive if it’s active.

Please report success or failure so we can determine if this should get merged. Thanks!

You still have the jar File of panasonic binding?

For anyone waiting on the jupnp update, it’s now committed and in the current snapshots (as of 2414). I’ve written up a how to guide for anyone who needs it. This should likely help the 10 minute delay problem substantially.

Are still working on it? Otherwise I’d be interested in maybe finishing or at least advancing it (if I’m able to find a bit of time for it), I haven’t tested it at all yet though and I have an HZ(W)-Series TV so I can’t ensure compatibility with older TVs.

1 Like

Currently I don’t have enough time to work on this. You can fork it from openhab-addons/bundles/org.openhab.binding.panasonictv at panasonictv · thinkingstone/openhab-addons · GitHub

Im excited, This would be awesome!!!

So… I’m basically already stuck at getting UPnP to work at all (even the UPnP binding doesn’t find anything, even though there should be multiple targets available) even outside a docker container without any firewall, even though I can find the TV using GUPnP on the same server, so unless somebody has any idea why openhab doesn’t even seem to listen on 1900 and there is some way to debug it, I’m afraid, I can’t even start working on it.

That’s a shame, it would of been awesome to get this working!

Oh well… you already sorted out my first guess…
I had problems with a firewall on the openhab server and solved them by disable the firewall completely. UPnP uses broadcasts. Maybe docker is not very happy with them. Broadcasts were my second problem. A switch was not forwarding them on all ports.
Maybe try to run openhab on your developer machine and disable the firewall.

Having it on my dev machine actually worked, I’m still not sure why, because it’s on the same network and runs on the same release. but somehow this worked and on the server it didn’t.

Well quick update.

The good things:

  • I have a capture of the remote control
  • I found information on the encryption for the remote control.
  • It’s probably possible to read information about what it’s currently playing.
  • We seem to have direct control over the inputs.

The bad things:

  • UPnP is sometimes a bit wonky.
  • I have to bind a way for the bridge to run through the pin authorization (challenge-response) and to save the resulting token afterwards. I would be glad if someone could help me in that area.

That good news! The older tv models don’t use encryption/pincodes. So it would be nice to have an option to enable/disable encryption/pincode.
The upnpcontrol addon has album and playlist infos as well. Maybe it is not necessary to implement this again.
Upnp should be more stable since 3.1 there was a bug fixed in jupnp. See above.

Yeah I’m already using 3.1, the problem is on the TV side, it stopped working even on the App and I had to turn the TV off and on again (completely off, not just standby).

I don’t think that’s something I can do, as I lack the equipment to test it, but I imagine it’s either very easy to re-add or I find a way to leave the old logic in there.

I guess that’s only for UPnP content though, right? The API I found can also give me the name of the channel currently running and an URI for it, so you can jump directly to it.

The “encryption” is sucessfully “cracked”. If someone wants to have a look at the code or want’s to test it out (the last call is still failing, but the PIN transaction is working successfully), here’s the PoC code I’m using: Cromefire_ / Panasonic UPnP PoC · GitLab (a compiled jar is available via the pipelines; JVM 11 required).

If someone wants to test how to distinguish between encryption-needing and non encryption needing TVs, here’s my http://<ip>:55000/nrc/ddd.xml:

ddd.xml
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0" xmlns:vli="urn:schemas-panasonic-com:vli" xmlns:viera="urn:schemas-panasonic-com:viera" xmlns:pxn="urn:schemas-panasonic-com:pxn">
  <specVersion><major>1</major><minor>0</minor></specVersion>
  <device>
    <deviceType>urn:panasonic-com:device:p00RemoteController:1</deviceType>
    <friendlyName>[censored]</friendlyName>
    <manufacturer>Panasonic</manufacturer>
    <modelName>Panasonic VIErA</modelName>
    <modelNumber>TX-65HZ100000WW</modelNumber>
    <UDN>uuid:4D454930-0200-1000-8001-B46C47C655FC</UDN>
    <viera:X_DMSUDN>uuid:4D454930-0000-1000-8001-B46C47C655FC</viera:X_DMSUDN>
    <viera:X_DMRUDN>uuid:4D454930-0100-1000-8001-B46C47C655FC</viera:X_DMRUDN>
    <viera:X_NRCUDN>uuid:4D454930-0200-1000-8001-B46C47C655FC</viera:X_NRCUDN>
    <viera:X_PACUDN>uuid:4D454930-0300-1000-8001-B46C47C655FC</viera:X_PACUDN>
    <vli:X_MHC_DEVICE_ID>0679169536380281</vli:X_MHC_DEVICE_ID>
    <viera:X_VERSION>NRC-4.00</viera:X_VERSION>
    <viera:X_DEVICE_TYPE>DTV</viera:X_DEVICE_TYPE>
    <viera:X_KEY_TYPE>PAL-41,PAL-21,PAL-1</viera:X_KEY_TYPE>
    <viera:X_PAD_TYPE>15-1</viera:X_PAD_TYPE>
    <viera:X_NRC_ID>B46C47C655FC</viera:X_NRC_ID>
    <viera:X_NRCCAP>VR_POWER,VR_DMR,VR_DMS,VR_PAC,VR_VECTOR,VR_BROWSER,VR_LAUNCH,VR_RECDMS,VR_TUNERDMS,VR_MEDIADMS,VR_LVDMS,VR_VGADMS,VR_UPDMS,VR_TUNER2,VR_WOL,VR_OWNPLAY,VR_XRC,VR_MES,VR_UPBROWSER,VR_MC,VR_AREKORE</viera:X_NRCCAP>
    <iconList>
      <icon>
        <mimetype>image/png</mimetype>
        <width>48</width>
        <height>48</height>
        <depth>24</depth>
        <url>/nrc/dlna_icon_48.png</url>
      </icon>
      <icon>
        <mimetype>image/png</mimetype>
        <width>120</width>
        <height>120</height>
        <depth>24</depth>
        <url>/nrc/dlna_icon_120.png</url>
      </icon>
      <icon>
        <mimetype>image/jpeg</mimetype>
        <width>48</width>
        <height>48</height>
        <depth>24</depth>
        <url>/nrc/dlna_icon_48.jpg</url>
      </icon>
      <icon>
        <mimetype>image/jpeg</mimetype>
        <width>120</width>
        <height>120</height>
        <depth>24</depth>
        <url>/nrc/dlna_icon_120.jpg</url>
      </icon>
    </iconList>
    <serviceList>
      <service>
        <serviceType>urn:panasonic-com:service:p00NetworkControl:1</serviceType>
        <serviceId>urn:upnp-org:serviceId:p00NetworkControl</serviceId>
        <SCPDURL>/nrc/sdd_0.xml</SCPDURL>
        <controlURL>/nrc/control_0</controlURL>
        <eventSubURL>/nrc/event_0</eventSubURL>
      </service>
    </serviceList>
  </device>
</root>

And a screenshot of the available actions and state variables:
image

Maybe that helps to find something that can be relied on for the decision to encrypt or to not encrypt.

Edit: Is anyone aware if kotlin is allowed in the openhab-addons repo or do I have to translate that code?

I switched away from openhab, so I will not directly work on this anymore, though I will in someway or another keep working on it and might post an update, if I’ve got something substantial that can be ported to openhab.

On last thing I’ve discovered though is the control4 driver for it. I wonder, if that can be reverse engineered somehow (it’s just a zip with some XML and lua code): http://drivers.control4.com/tv_Panasonic_TX-65HZW1004.c4z