@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.
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.