So a Java update killed my OH1 install and I finally migrated to 2.1. It has been a terrifying experience! Got my Insteon PLM stuff working the old school way quickly enough. Managed to get my mqtt stuff working. Rules imported. Modified REST stuff to go through classicui/CMD?Item=command, Astro and Squeezeboxes working. Can’t get Wemo added to the (lights) group via the GUI and manual setup doesn’t appear to work. Probably have to link them now via the GUI. So inconsistent.
Where the REAL problem is though is the crashing. I could run OH1 for months and I can’t run OH2 for days. This is an i5 NUC with 8GB RAM, SSD and Lubuntu! Java dies a horrible death when I’ve done things like leave a tab open on classicui so I’ve been using basicui instead. Last night I tried to open the Android Habmin app and when it tried to connect to OH I could hear the fan ramp up and OH died. AGAIN. WTF?! What happened to the super stable reliable easy to configure home automation platform I was familiar with?
Sorry to hear that oh 2.1 isn’t working as stable as your oh 1.x installation.
To help solving you issues, we need some more information about your installation.
What java version are you running, what bindings did you install and could you post the last log entries when your oh service seems to die.
I never experienced such a behavior running oh 2.x on my NUC with 4GB memory.
According consistency, you can setup your things through config files, just like with oh 1.x, even the WeMo things. If you have issues doing so, please post your things fole, so we can check.
“oh service seems to die.” - No, it DOES die. DEAD. Error on console (should have copied but was in a hurry this morning).
Oracle Java 8.
Bindings: Squeezebox, InsteonPLM, WoL, mqtt, YamahaReceiver, Astro, Wemo, SamsungTV. That’s off the top of my head.
Manual sitemap creation because I’m an OH1 fanboy and it WORKS. Adding items carefully due to stability. Same with rules. One by one pulling things in. I absolutely rely on the app and web interface as well as the REST API. I use echo-ha-bridge for better fine grained control over what the Echo has access to.
Are there default logs or do I need to enable logging when starting from the console? I extract and run from /opt FWIW. Not apt install.
I would recommend starting oh2 manually via script
start_debug.sh
When it dies, post your logfile so we can analyse what’s happening.
Also I would propose to use hue emulation instead of ha-bridge.
You are using two bindings using UPnP features, this could cause issues running a different UPnP emulating tool like ha-bridge.
It has literally NEVER been an issue. I’ve used echo-ha-bridge since it was announced. I’ll try the hue emulation though. I’m confident I can crash it in a timely manner tonight regardless of the UPnP features. LMS and Ubiquiti video server have never gotten in the way either. If it wasn’t for the Java 7 dependency I would have rolled back to 1.8.* in a heartbeat.
Please note, that oh1 did not have a built in UPnP service.
WeMo binding 1.x e.g. worked completely different. I wrote it with manually sending SOAP messages.
When running oh1.8, I also used ha-bridge, but never used it with oh2
This is what I see after it crashes. Right now it’s hovering at 90+ % CPU across all 4 cores so I’m going to kill it and start in in debug rather than wake up with it not working.
at org.eclipse.smarthome.core.items.GroupItem.collectMembers(GroupItem.java:120)
at org.eclipse.smarthome.core.items.GroupItem.collectMembers(GroupItem.java:120)
at org.eclipse.smarthome.core.items.GroupItem.collectMembers(GroupItem.java:120)
at org.eclipse.smarthome.core.items.GroupItem.collectMembers(GroupItem.java:120)
Exception in thread “items-20376” at org.eclipse.smarthome.core.items.GroupItem.collectMembers(GroupItem.java:120)./runtime/bin/karaf: line 409: 20254 Killed ${KARAF_EXEC} “${JAVA}” ${JAVA_OPTS} -Djava.endorsed.dirs="${JAVA_ENDORSED_DIRS}" -Djava.ext.dirs="${JAVA_EXT_DIRS}" -Dkaraf.instances="${KARAF_HOME}/instances" -Dkaraf.home="${KARAF_HOME}" -Dkaraf.base="${KARAF_BASE}" -Dkaraf.data="${KARAF_DATA}" -Dkaraf.etc="${KARAF_ETC}" -Dkaraf.restart.jvm.supported=true -Djava.io.tmpdir="${KARAF_DATA}/tmp" -Djava.util.logging.config.file="${KARAF_BASE}/etc/java.util.logging.properties" ${KARAF_SYSTEM_OPTS} ${KARAF_OPTS} ${OPTS} -classpath “${CLASSPATH}” ${MAIN} “$@”
I’ve had to remove a few things and avoid using classicui. Been stable for several days now. Waiting on the 2.2 release to see if my Yamaha Receiver will work properly again or not since it worked great in 1.8.3 but the 2.1 binding is broke. I keep an eye on the console with tail -f when I’m at the PC to watch for errors that could need fixing. So not everything I had before is working but at least it has been stable for now.
OH2 borked again. I was making changes and either when I hit allow 1.* bindings or a query on the Insteon PLM the CPU spiked and pretty much stayed up. Would bop down the ~33% then back over 90%. Hang, come down, back up, rinse, repeat. Killed it, restarted it, got yamaha1.9 binding configured and so far everything is happy again. Sure would be nice to see more than one week uptime.
Watching the log and it is complaining about the previously auto detected Yamaha stuff so I’m trying to purge it all through PaperUI so only my manual config exists. I wish OH2 had a “don’t use the gui for anything” option.
Have I mentioned my severe distaste for OH2? I wish OH1.8 ran on a newer Java version. I could run for MONTHS and tweak things all day long and never have these issues.
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x00007fa038acc7d5, pid=2803, tid=0x00007fa0387c3700
JRE version: Java™ SE Runtime Environment (8.0_131-b11) (build 1.8.0_131-b1
Java VM: Java HotSpot™ 64-Bit Server VM (25.131-b11 mixed mode linux-amd64
compressed oops)
Problematic frame:
C [libNRJavaSerial.so+0x77d5] read_byte_array+0x55
I don’t know what to say at this point. After giving openhab2 my best efforts for over a year, I am frankly very disappointed with how it has turned out for me. I had OH1 setup doing everything I wanted pretty much and it just worked. OH2 has been anything but that experience. I have gone around and around trying to configure things and it just doesn’t work well (at least I can;t get it to) at all.
The paper interface is confusing, buggy and Eclipse designer also feels like it doesnt work right either. There should be a one stop shop for configuration, but instead its a bit of config files, paper UI, designer, etc. and you aren’t ever quite sure if one bit is picking up another. Im about to throw into the towel with openhab which I thought I would never say, being such a fan and advocate of OH for years. WHY? With OH1 you knew that you just had to:
Install Binding for the release
Configure binding in one place (not a config file, or maybe paper UI, or wait maybe Habmin)
Define items all the same way (not channel, items always picked up from item file, paper UI doesn’t show any items to configure, wait sometimes they are there, sometimes disappear)
Place in sitemap how you wanted. Easy Peasy once you learned.
That’s it! It worked!! It was great.
I get that they have made things easier and more intuitive for developers, but that is NOT translating into a functional product at the end of the day and the user experience from my perspective has taken a nosedive! It’s the functionality at the end of the day that will prove the popularity of the platform and I think openhab took a wrong turn here for whatever reason. Incredibly disappointing, I just don’t get it and lord knows I’ve tried. Documentation is all over the place.
I’m not trying to bash here, I wish I could be of more help to improve things, but I just don’t see how to naviate through the change. I will probably either scrap all of the work I have done in OH2 for the past year and go back to 1.8 or I will try HomeAssistant which seems to be gaining traction and has a decent community like OH.
Thank you all who have contributed to this project and helped to ignite my passion for home automation. It has been an overall rewarding and educational experience that I am truly grateful for. Perhaps a major OH2 improvement will change my mind, but as things stand today, I feel like I am lost with OH2.
Well put. While I do not have the extreme of reliability as mentioned here - I struggle to understand decisions that make troubleshooting issues challenging for a 30 year IT veteran with moderate coding skills.
A few examples - config changes that are written into the database but since there is no deletion of the prior config…you have to go into Karaf and delete the config to assure that your current config is the only one. Current aggravation is the percent issue with state setting, http binding mysteriously going belly up with its config mysteriously remembering old configs even post cache/config clearing.
I would express the sentiment above - kudos to all the work done here and considering the complexity and the time to get from 0 to here - WOW! As with other opensource projects (watch the drama going on with Node) its the direction and spirit that ultimately determine its viability and lifespan.
From an end user perspective (my take) - the time needed to maintain a system that has had no additions has increased and its reliability has decreased as this project has evolved. If this were commercial software and there were no commensurate feature benefits offsetting the time for my staff to maintain the implementation…I would be talking to my rep saying we would be looking for a more stable supplier to meet the need.
@ubergeek ditto on well put. I do have to say OH2.2 Snapshot is running seemingly more stable than 2.1. I’ve dabbed at HA and find the lack of overall customization more limiting than OH (especially 1.). Laying out my sitemap and items in a way that made sense to me and having the seamless app has made OH worth fighting for. So even though 2. has some kinks to work out I’m hopeful they’ll get resolved in a timely manner. Especially for documentation and examples.
For my configs it boiled down to manually setting up Insteon and MQTT the 1.* way, manually creating my sitemap so it is how I want it (using Basic or Classic UI). Having my manually created items in the sitemap be pointed to discovered things or manually created things. My only remaining quirk as far as I can tell is the changes to Squeezebox binding. My attempt to directly start a playlist doesn’t work anymore and I need to finish figuring that out and I should be hopefully good to go.
Obviously didn’t read the whole thread. I only brought up the manual config as an example. Because in 1.* stuff just works when you do it that way or you track down a typo. The stability issues I have had have nothing to do with “No wonder”. Those not familiar with 1.* only get more lost in 2.* because of the bass ackwards configurations. Have some gui, have some text files, cross your fingers now.
I know the general rule with open source is no warranty but to have 1.* utterly useless because of needing old Java really sucks. Had it been maintained or updated I would have rolled back without a single moment of hesitation after the second time OH2 died. A proper 1.9 release would have been nice.
