I have a working binding that most likely only works on 1 TV and only offers on/off status and commands, nothing else. Is that really what you want/need?
Yes I’m interested. Maybe I can use that code with the binding and finish it.
1 Like
@Flole any chance of posting your work in progress binding. all I need is the ability to turn a Panasonic tv on from a power off state so this would be perfect for me! having to get up to turn the master bedroom tv on when you are cosy in bed sucks since upgrading to OH3
1 Like
Found something in the code.
Scenario: TV is off. Openhab is running and tv is switched on.
Openhab (exactly the jupnp bundle) finds the newly started upnp device. Jupnp then tries to load the service descriptor via HTTP GET from the tv. But this request fails. Maybe the upnp notification is sent from the tv before it’s webserver is fully functional.
The failed request results in the jupnp AbstractStreamClient to wait for 10 minutes until it tries again to download the service descriptor. The device will not be registered until the service description was successfully loaded.
The binding is working fine if you can wait these 10 minutes after power on.
Now I have to figure out something to mitigate this.
Any idea?
Logs and hints: panasonic.txt (67.7 KB)
Thought I would weigh-in here to share my experience with Panasonic TV Binding. I’ve been using OH 2.5 (1.x Binding) and now OH3 (3.x binding) to control basic functions on my VT60 Plasma. I do find that it can take up to 30 seconds for the TV web server to fully come to life. I am using a ProxySwitch item to trigger a rule that toggles the TV OFF/ON. For starting the TV once the TV shutdowns I have no access to the web server to turn it on. What I do is test if the TV is OFF by pinging the IP. If I get favorable response then the TV is ON, otherwise it is OFF. If it is OFF I send a WOL to turn it ON. To turn it OFF I just send the KeyCode for NRC-OFF command to the TV. I am also able to select the video input through KeyCodes. I am also controlling Volume and Mute. I’m sure I could do more through KeyCodes and Rules, but that is all I really need from OH. It took me a long time to determine how to best handle the PowerON/PowerOFF cycle, but what I now have does work for my needs and the binding performs well. The Panasonic VT60 is a very peculiar device because unlike my Receiver it isn’t possible to access the TV web server when it is in StandBy/OFF state, so a work around is needed.
To test my theory I changed the retryAfterSeconds to 20 in the JUPNP library AbstractStreamClientConfiguration.java. The tv device is registered 20 seconds after power on.
A forum search shows other bindings have this problem too. e.g. Kodi takes sometimes up to 15 minutes to come online - #3 by djpsycho82 and Too much time before a Sonos thing becomes definitively ONLINE - #22 by morph166955. Someone even mentioned to restart the jupnp bundle with a rule.
@J-N-K Can you give me some tips on how to change this code? Where to create a issue? How to create a suitable pull request? Or someone to discuss a possible solution. I assume the 10 minute retry was set for a good reason.
1 Like
@John_Siemon If you enable the option “Network - TV Remote App Settings - Powered On by Apps” (may be different on other panasonic tvs) in the tv, it should stay online even after switching it to standby. Then you should be able to power it on with the binding.
Hi all,
an alternative idea came into my mind replacing the 1.x panasonictv binding.
I installed the generic upnp binding.
Both Panasonic TV’s are detected as a upnp renderer
and with those things I get some basic controls:
I created the items and put them into my sitemap.
In fact this works.
The only thing I miss now is the option to turn the TV on and off.
Do you think this could be made with the http Binding or the exec Binding?
For me this would be sufficient. Off/On, Mute and Volume would be enough to be integrated in OH. For all more complex things I would use the original remote anyway.
Greetz
Christoph
1 Like
The issues with jupnp turned out to be an issue with thread contentention. Some recent merges fixes some of these issues in 3.1
That would be the correct repo. IIRC Kai is a maintainer there.
Thanks for the feedback, but unfortunately that option “Powered ON by Apps” does not exist in my Network Menu or any there menu that I can find. Instead, the “Network - TV Remote App Setting - TV Remote” is just ON/OFF and apparently does not keep the TV web server active in Standby/OFF.
I would be very intrigued to see a thread dump of this binding in the broken state. I’m curious if it has the same thread issue that the other 4 had. If anyone wants to do one and post it we can see. If so, then we know how to fix the issue.
My approach has currently my openHAB server IP hardcoded, so I need to find a way to fix that and then I can publish it (so if anybody knows how to do this properly please let me know). This only allows on/off and gets the status and might be buggy, but it works for me.
S3.1.0-S2130 and beyond have all the fixes that should resolve threading issues across several bindings. I would suggest that if you have any upnp issues to move to that snapshot (or later) and see if you still have issues.
I solved my issue a bit. I had 1 kodi desktop pc and 2 kodi smartphone apps as things configured. The smartphones we didn’t use much so I deleted them and the problem with the 15 minutes is mosly gone. But the binding is still buggy, not sure if that has to do with upnp. Sometimes I press Play > openhab sees the control change to play and in less then a couple of seconds it goes back to pause and the movie is still playing. Cannot find when this happens, it just happens sometimes.
Tested with 3.1.0.202101111158 snapshot and the problem still exists.
I think the issue is the circute breaker in jupnp that does not execute requests for 10 minutes after a failed request. I will create an issue in jupnp on github and provide a pull request that changes this to around 5-20 seconds. I really do not understand why one will not try further requests for so long after failure.
There was already work done to make the timer a variable. I have that code from @Lolodomo and can submit the PR for it. The ultimate issue was that the threads for the things were exhausted on the OH side. I’ll see if there is something similar in your dump when I get a few minutes.
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.