Initial tests with running the unchanged Sony binding under OH 4.1.0.M3 show no issues so far.
My understanding of your patch of the Neeo binding is that the introduction of an HttpClient stack is the real fix for the exhaustive thread creation issue. So what is the relevance of the migration to the jetty client?
I’ve also started to introduce the jetty client for the Sony binding. However, I’m now struggling with the registration of servlet filters, which I think need the use of additional services or components. Do you have any hint on how to do this in the context of migrating to the Jetty client?
I’m glad it’s working cleanly. We’re still not 100% sure why some of the bindings leaked. What we believed was that http clients were not being closed properly. When they got discarded, trash collection didn’t dispose of them because they weren’t dead (even though we lost all of our pointers to them). This ultimately lead to memory exhaustion.
In the Neeo binding we did two things. First, we believed that ClientBuilder was causing some of the issues due to an update there in karaf. So moving to the jetty client seemed logical because OH actually maintains a central pool at the core level. I’m more of a fan of aligning with the core than using different libraries. Less chance of something breaking and not being caught. Where we could use the central ones we did. Unfortunately Neeo also has some added complexity where it does a ton of things very fast (specifically when keys were pressed on the remote). That’s where the stack came into play. Instead of allowing the system to spin freely we maintained a stack of clients in a waiting state. If more than the stack ever was needed we would create them on demand (to avoid congestion), but then once we filled up the stack we would force close and discard to avoid the stack growing out of control. This gave a really good balance between speed and memory resources.
I recently found out that my Sony TV ( KD-65A85 ) was using about 30 Watts when the TV is off, I think this is quit a lot and would like to reduce it.
If I disable the binding it will reduce the power consumption to about 0 Watts 5 minutes after the TV is turned off, but when the binding is enabled it continues to use about 30 Watts.
I originally had Remote Start enabled even for apps on the TV and I tried to disable that but that did not change anything. I only use the system#powerstatus channel.
When I turn the TV off the system#powerstatus channel goes OFF so this is fine (The binding remains online).
If I disable both Retry Polling and Refresh Interval the Tv will reduce power, so it must be the polling that keeps the TV awake.
If I enable Retry Polling and Refresh Interval after the TV has gone to sleep it will remain at 0 watts.
So disabling both Retry Polling and Refresh Interval will fix the issue but then on off status is unreliable
So the question is if anybody else is seeing the same ?
and if anybody knows of a solution ?
I guess that if the binding could stop polling for some time after it has detected the TV is off this would fix the issue.
Thank for your feedback.
I was thinking that a simple solution might be to allow setting a poll interval for when the device is online but off. This could then be set to something above 5 minutes.
Then incase the device wakes up unintended the binding would allow it to fall asleep again.
I tried your suggestion with Android TV and it looks like it works so that the tv goes to sleep. I will keep a watch on it for the next days. Thanks.
