I’d like to start using some of the OH2 functionality but I’m not ready to fully transition yet to that platform since some of the bindings I use are not supported.
For example, I’d to test the OH2 Sonos binding because the OH1 binding crashes my server with runaway thread creation. Ideally, I’d like to control and monitor the OH2 Sonos binding from my OH1 server and sitemap. I thought about using the MQTT event bus binding but apparently that’s not supported in OH2 yet.
Another option would be to use the OH2 ReST API but it appears I’d need to poll for OH2 item changes. Are there other options I should consider?
I cant speaks as to this working or not, but i do know that mqtt for oh1 is compatible with oh2, as are a lot of other 1.x bindings. there is a list somewhere ive seen, but i cannot find it right now.
I’d like to start using some of the OH2 functionality but I’m not ready to fully transition yet to that platform since some of the bindings I use are not supported.
For example, I’d to test the OH2 Sonos binding because the OH1 binding crashes my server with runaway thread creation. Ideally, I’d like to control and monitor the OH2 Sonos binding from my OH1 server and sitemap. I thought about using the MQTT event bus binding but apparently that’s not supported in OH2 yet.
I got exactly the same idea few days ago and also recognised that MQTT event bus binding is not supported by OH2.
I have also rewritten some bindings to OH2 already, which benefits i’m not able take in use as i’m not yet comfortable to fully change my production system from OH1 to OH2. So MQTT event bus binding definitely could help to start migration work from OH1 to OH2.
I’ve now been able to configure the MQTT eventbus binding to connect OH1 and OH2. I have the OH2 SystemInfo binding running and reporting OH2 system information to OH1 items which I display on my OH1 sitemap. I’ve tested commands from OH1 to OH2 with a test item and a rule to log the received commands and that works too.
However, I’m not sure how, or if, this works with OH2 “things” used to represent the Sonos devices. I’m going to do some more experimentation but if someone knows that this definitely won’t work, please tell me to save me some time.
I’ve been able to sync OH2 Sonos item states to OH1 but I’m having a bit of trouble with the commands to the controller. So far, I haven’t been able to make the controller work even in OH2. It’s probably my lack of knowledge and experience with OH2 but the documentation is very limited. I’m also wondering if it might be a bit out-of-date. The docs say that Sonos things must be manually configurated but OH2 seems to recognize the Sonos things without any manual thing configuration. I’ll start a different topic for the configuration questions.
I’m now able to control and monitor a Sonos binding running in an OH2 slave server from an OH1 master server.
The OH2 Player item is not supported by the OH1/OH2 compatibility layer so that’s what was causing the NPEs when I tried to send a command. The only way I’ve found to control the Sonos (player commands) from OH1 is to create an OH2 “bridge rule” from a String item to the Player item. The OH1 server sends a command its local String item and that command is converted in OH2 to a Player command. A bit ugly, but it works.
I know what you mean. My primary goal is to determine if the OH1 bug has been fixed. I hope so, although the potential for the bug is still present in the openhab-specific UPNP library used in OH2. The only difference is that instead of exhausting process memory with thread creation, it will fill up the disk space with logged errors. However, maybe the way the OH2 binding communicates with UPNP will be different in a way that avoids the problem. Given that the OH1 binding problem was never investigated by the binding developer, I remain slightly skeptical. So far, I haven’t seen the problem occur but even with OH1 it sometimes happened after few days of operation.
For documentation, I’ve primarily been using the source code. There is some documentation but it doesn’t seem to have been kept up to date. For example, it describes manual thing configuration which doesn’t appear to be necessary now.
I’ll post the results of my experiment in another topic after I have some better information.
OH 2 Sonos binding use jupnp, which is based on cling 2.x and OH1 Sonos binding use older cling 1.x library, so I doubt that OH 2 binding have same memory problems. I have rewritten Samsung TV binding to OH2 which also use nowdays jupnp library and I have not seen any problems with upnp library at least.
Do you mean that you have made some adaptation to MQTT event bus binding? I tried to configure it in OH2 environment, but didn’t succeed.
I modified the OH1 Sonos binding (in a private build) to use the OH2 jupnp library and tested it over a period of time. The problem is a bit complicated (but well documented in other topics), but the newer jupnp library has some changes that bounds the number of threads created to handle upnp requests and insteads logs an error. Bounding the thread count fixes the memory problem but then the logged errors just fill up the disk so it’s not really a solution. Turning off the logging is also not a solution but is only hiding the symptoms. I don’t think you can infer much from the use of the jupnp binding for another device. The event sequences and binding implementations would typically to be quite different.
I was talking about Sonos binding documentation. I’m using standard MQTT event bus usage, as documented. The only challenge was handling the Player item which is not supported by the OH1 compatibility layer.
@steve1.
Thanks for the reply. I will carefully watch your results and experience.
The poor implementation of the 1.x Sonos addon caused so much frustating trials and error which I do not want to repeat again. These memory overflows made be already seriously considering to stop openhab altogether before I learned that is it all due to this sonos junk code.
Note that extensive testing has been done on https://github.com/eclipse/smarthome/pull/1196 and there are no memory overflows anymore. I am waiting for approval by the Eclipse IP team now, but I expect it to be available in a few days in OH2. It is a HUGE improvement over OH1 Sonos both in terms of stability and functionality.
