This page last changed on Aug 10, 2015 by dwaun.

Hello,

I've been running openremote pro for a couple of years with good success, but recently I needed to move the controller server to a new location in the house and also onto a new server.

I tried running it on a server with Ubuntu 14.04 (LTS) and Java Open JDK 1.6. I am running a 100% z-wave network and ended up deleting all of the devices and re-adding them. I was making progress getting things to work, but noticed that after the server sits overnight, I would be unable to connect the client the following day. A reboot would clear things up, but only for a day or so.

I've now decided to switch to Fedora 22 server and I'm having trouble controlling any devices. I'm getting errors like "node not found". I didn't have problems setting things up the first time, but now I'm starting to wonder what OS and java versions are supported. I noticed that the linux install instructions still recommend java 1.6. Is it really the recommended java version? It's getting rather old.

My preferred server would be a Raspberry Pi 2 with Raspbian, but I had a similar problem of loosing communication with the iphone client software after the server sat overnight.

So my questions is... Is Openremote still being maintained and supported on newer versions java and linux? It appears as if there hasn't been a release in a long time. Are there plans to come out with a new release that supports the latest hardware/OS/java versions? What about new features?

You can follow maintenance status on http://jira.openremote.org

Posted by pz1 at Aug 10, 2015 09:01

I took a look at the site and see references to Pro version 1.3.0 of the controller, yet the resource manager within the pro designer is only allowing me to download pro version 1.1.0.

What's the best way to receive the newest version of the software?

Posted by dwaun at Aug 10, 2015 14:05

The best way to get version 1.3.0 is to wait a couple of years. Actually v1.1.0 is the latest version ; )

Posted by pz1 at Aug 12, 2015 08:33

OpenRemote is still being maintained... We'll be coming with a new version sooner than Pieter is expecting.
BTW, We'll also give you practical answer quickly.

For the last years we have been pulled into professional implementations with OpenRemote. Gradually it has been creating some breathing space to start thinking about a complete overhaul of our platform. We hope we can start sharing some of our thoughts with our biggest users and contributors.

For now we appreciate getting your (and others) feedback on a couple of things:

  • what's the ultimate reason you are using OpenRemote?
  • what are you missing beyond the obvious functions like copy/paste (yes, we know)
  • what would be your dream tool be capable of doing?
  • what's the ultimate scenario you like to use OpenRemote for?
Posted by pierre kil at Aug 12, 2015 14:32

JIRA is the issue tracking tool we use, so it includes future versions of the product so we can assign issues to it and plan releases ahead.
Also it is subject to change depending on the progressions we're making on different topics.

The latest released version of the Pro Controller is always downloadable from the Pro Designer (currently 1.1.0).

Posted by ebariaux at Aug 12, 2015 16:17

For now we appreciate getting your (and others) feedback

Go for a proper design instead of doing a ragbag of nice to have features.

Posted by pz1 at Aug 13, 2015 11:04

I appreciate all of the feedback on openremote's status and would be happy to give feedback on new features if I could get openremote running again.

I've been using openremote pro for several years to automate my home, but after being forced to upgrade to a new version of Linux, I'm finding that I'm no longer able to get things running reliably. After the openremote controller runs for a couple of hours, I can no longer connect to it. I've tried a couple of different platforms (Ubuntu 14.04 on i686 & raspberry pi 2), but get the same results.

Given the fact that I have been running it successfully and the only change that was made was the platform, I started wondering if there was a compatibility problem. That's when I started realizing that the platform install instructions were for a very old java version. There also didn't seem to be a lot of discussion about new installs in the forums, so that's when I started wondering about the health of openremote.

Unless I can get something running soon, I'll be forced to find a new solution.

Posted by dwaun at Aug 13, 2015 14:13

Hi Pierre

Is there a development thread that we can all do ideas into?

I've always got ideas I could throw into hat

I've been talking to Richard about an alarm style timer protocol, just something to trigger a Macro at a user definable time, he doesn't think it would be a major.

The only problem I have is finding his programming time, given what has been going on in the background for the last few months.

One thing I did briefly discuss with Richard was the possibility of a corporate / Pro user funded development budget?

Open source is great, but it doesn't put food on the table

Cheers

Stuart

Posted by mdar at Aug 14, 2015 09:23

Waun,

Just to throw my thoughts in the ring, what you're describing sounds more like your Linux OS is going to sleep.

I've been running 2 Pro servers for 6 months and they are very stable.

My next mission is to set up a small Linux server, I'll let you know how I get on.

May I ask which Linux distribution you're using?

Cheers
Stuart

Posted by mdar at Aug 14, 2015 09:49

May I ask which Linux distribution you're using?

His initial post tells you that

Posted by pz1 at Aug 14, 2015 10:03

One thing I did briefly discuss with Richard was the possibility of a corporate / Pro user funded development budget?

I suggested a Donate button in the past. I habitually do that when I regularly use open source like Wikipedia, LibreOffice etc.

Posted by pz1 at Aug 14, 2015 10:09

Ooh yeah, I missed that.

I'll try my Ubuntu laptop next.

Then I'll be trying to create a BeagleBone Black server in a nice little Din Rail housing.
I've got a 5 Inch touch screen HDMI panel mount display on order, just to add a status display in the cabinet.

The BeagleBone runs Angstrom and Ubuntu, so I'll report on my findings.

Cheers
Stuart

Posted by mdar at Aug 14, 2015 11:13

Hi Pieter,

Any feedback on what you consider to be a proper design?

Posted by pierre kil at Aug 17, 2015 11:32

Something along the lines of RUP or similar

Posted by pz1 at Aug 17, 2015 14:38

Hi Pierre,

if you'd like some feedback, I guess you've already got a look at : http://openremote.org/display/forums/How+to+improve+KNX+ETS+import http://openremote.org/display/forums/Device+template http://openremote.org/display/forums/Designer-+Copy+Paste http://openremote.org/display/forums/Designer-+SubPages+and+Graphical+Rules+engine http://openremote.org/display/forums/How+to+improve+KNX+ETS+import
+ independent UI resolution design
+ professional and maintened integration. External solution are evolving. Openremote need to be keep up-to-date (take the exemple of rr4j,emoncms, ...)
+ independant installation packaging: docker
+ faster release process
+ several UI design templates

Regards

Posted by yannph at Aug 18, 2015 07:58

Hi Stuart,

For my personal culture, could you tell me the model of your 5" HDMI touch screen?
Regards

Posted by yannph at Aug 19, 2015 09:51

Hi Yann

I found the touch screen on EBay.

This is the 5inch version

http://pages.ebay.com/link/?nav=item.view&id=271851796554&alt=web

Unfortunately, I didn't see the 7 inch version until much later.

I'll try one on another client's project

http://pages.ebay.com/link/?nav=item.view&id=281695875851&alt=web

My only comment so far is that they come shipped with a full size (short) flat HDMI cable, which apparently is fine for a RaspberryPi.

My BeagleBone Black has a Micro-HDMI socket.

So far I've only connected the screen to the DVI port of my laptop, but the picture is really good.

I ran a full screen webconsole session on it and while the panel I loaded was totally the wrong ratio, it was perfectly usable.

The screen does come with pre-compiled OS configurations for BeagleBone Black and RaspberryPi, so I'm not sure how you'd load the drivers onto an existing system.

Please do let us all know how you get on.

Cheers

Stuart

Posted by mdar at Aug 19, 2015 16:36

Stuart
Thank you for the information and your first tests results
Regards

Posted by yannph at Aug 19, 2015 19:12

Stuart, I want to make sure I'm not missing something here... what will you be displaying on that touchscreen? And why go with that versus an Android tablet (for example)? Thanks.

Posted by gregoryx at Aug 20, 2015 01:10

Hi Gregory

That's an excellent question

If I just wanted to display a user interface, I would have gone for an Android tablet.

What I'm doing is trying to use the BeagleBone Black as a mini OpenRemote server for a reasonably small Velbus and minimal AV install.
But I'm mounting the BeagleBone within the electrical cabinet, on the Din Rail.
So what I wanted was a really simple screen on the front of the cabinet to show a status screen for the maintenance team.

This is part of a much bigger project that is really exciting, ultimately there will be a serious OpenRemote server looking at dozens of these mini servers as a building management system.

So far it's on track.......

Posted by mdar at Aug 20, 2015 07:34

Not so much thinking about the process, more on UX and/or features.

Posted by pierre kil at Aug 21, 2015 10:01

Hi Yann and Pieter, thanks for the list.

So on features:

  • improvements KNX import
  • easier templating + copy/pasting + templates library
  • graphical rules editor
  • responsive design
  • installation packages

And on development in general (also to Pieter's point)

  • better maintenance and updates, faster release process

I think we are addressing the features side in a new version. The development side will still be a challenge with a limited core team.
We welcome the idea of donating to the pro development, so we welcome concrete ideas

We'll take you along in testing the first release!

Posted by pierre kil at Aug 21, 2015 10:16

I've heard this for over 25 year in the health ict domain...

Posted by pz1 at Aug 21, 2015 11:20

So far it's on track.......

But unfortunately this thread has been twitterised

Posted by pz1 at Aug 28, 2015 09:31

@Pierre

Hi Yann and Pieter, thanks for the list

A few additions in random order:

  • Incremental devices import facility from XML based source. (For my RaZberry application this may initially be restricted to virtual devices)
  • Imho, moving from Sourceforge to Github would make involvement of the user community easier.
  • Several people have asked for a different (e.g. phpbb type) forum. I do support those requests
  • Introduce a modeSwitch (more generally N-StateSwitch) and its companion sensor (in between binary and multilevel). For example climate control devices can have multiple predefined discrete settings. A virtual modeSwitch seems attractive for tracking the state of a set of rules.
  • More transparant policy on which user community developments will be included in the Pro version. Most recently the absence of UDPListener logging has been a nuissance.
  • Still relevant issues Jira 467, Jira 337
  • 20150930 Resolve the deadly embrace of JDK6
  • 201501001 Resolve this recurring nuissance. Happened again with Pro 1.20 upgrade to Synology
  • 20151007 Possibility for (user)defined plugins like modules in ZWay.
  • 20151019 The logfile stderrorout.log should have timestamps. Now it is pretty useless.
Posted by pz1 at Aug 30, 2015 11:20

One more feature:

  • A controller upgrade procedure that preserves user settings during upgrade (e.g. port settings, log settings)
Posted by pz1 at Sep 14, 2015 14:31

For me works unzipping the new controller into the old controller directory. You need to stop the old controller first and then allow unzip to overwrite all files. This way design files and custom jar's are still present after upgrade.

Posted by aktur at Sep 15, 2015 08:28

Thanks Pieter/Yann, and others. As you might have noticed we started 'cleaning up' on quite some JIRA issues on the current designer. In addition there are a few big burning issues, a new iOS console being one of them. We are also exploring a bigger update, that's also why we asked for your shortlist of wishes. Accompanying that, we are moving all code to Github. For forums and documentation we are still looking at the best options, so please share which forum and/or documentation formats are your favorites.

Posted by pierre kil at Sep 24, 2015 13:10

I too would love to be able to be involved in any beta releases. I am planning to startup a company in London in the next year or so, aiming to do home automation and integration systems largely based around OR.

As an addition to the ideas above, i wrote an article on controlling Sony TVs via IP. Possibly integrate that into the designer? Just another protocol to work with out of the box.
The ability to zoom in and out in the designer.
An updated android app, the current one can crash easily, also outdated to navigate.
+1 on stability for open remote controller - i too find it hangs when left overnight.
Android/IOS wear app? - not a priority
Integrate https://design.google.com/ into the designer? Would be awesome to be able to build 'big boy' apps. Really have the ability to compete with the mainstream control apps like Samsung Smart things, Philips Hue, Nest. You could build some incredible integration apps which would feel professional. Would also make creating designs easier, as templates for layout could be available, making a more drag and drop style of buttons, labels etc.
A graphing engine for the app?

Just some thoughts, lmk if you want more info.

EDIT: RE the Google design link, React and Material design http://material-ui.com/#/home

Posted by gedelstyn at Oct 07, 2015 19:44

Although new concepts of how a web app should work are appealing, I miss a bit if the 'problem' it solves is really worth the effort. Let's consider some objective points you've mentioned:
1) being able to be similar to 'big boys' is disadvantage IMHO. The future belongs to next revolutionary start ups.
2) Feeling professional is very subjective.
3) Templates are already available.
4) What do you mean by 'more drag and drop style'?

The bottom line is a responsive and reliable automation app. There are still some problems in OR in this area which should be addressed first before jumping into a new set of problems introduced by the new framework. Just my .02$

Posted by aktur at Oct 11, 2015 10:38

Whilst i totally agree, that there should be priorities, such as stability, and a steady rollout of features. I also agree that the future does belong to startups; if you look at the trend of apps, looking 2 or 3 years ahead, apps which are built from static images and dont feel quite so responsive and fluid as other applications, will surely feel increasingly outdated when being compared to many other modern apps. Mobile operating systems are also becoming much more responsive. It will only be for so long that you can create apps by just using PNG images, look at windows 8 onwards, look at OSX, look at the new versions of IOS and Android.

This may not be a feature to add in the next 6 or even 12 months, but surely it should be something which is planned for integration at some point?

I have seen developers in the forum say that OR is understaffed, and it is difficult to implement and develop OR. Dont you think that if OR was more made appealing to paying home automation installers, OR could raise some money which could be spent on development?

I might be way off base here but figure i might as well put it out there.

*4) by more drag and drop style, i mean if a few 'ready made' responsive buttons were made, they could be drag and drop just like the current implementation, it would mean those who dont know how, or dont have interest with designing interfaces, can still make great looking apps.

Posted by gedelstyn at Oct 11, 2015 11:01

Hi Guy, we'll invite you to review the first version of our next release. We are curious to know whether it addresses your points. We think it does

Posted by pierre kil at Oct 12, 2015 08:26

Hi Pierre, That would be fantastic!
Would love to be involved in the next release

Posted by gedelstyn at Oct 12, 2015 09:07

Hello Guy,

Pierre, Erik and I are attending an interesting meeting today, the outcome of which might help your new venture.

Would you be kind enough to grab my email address from my profile and drop me a line.

Best wishes,

Stuart

Posted by mdar at Oct 12, 2015 09:24

Hey Stuart,

Done, I pulled the email from your website,

Thanks,
Guy

Posted by gedelstyn at Oct 12, 2015 11:31

Hi Waun,

I'm wondering if you've made any progress on your issue. I've experienced similar issues running the controller on Ubuntu 14.04. I've actually built a WAR from source and am running it on Tomcat 7 with Sun JDK 7.x along with other services I host. In particular the behavior I see is that changes in Vera devices stop updating the state (other status appear to keep working - standard http requests..). I can see the messages coming through in the controller vera log... but they don't reflect on the panels until I restart either the console or tomcat. Was curious if you've got any best practices to increase the stability beyond 24 hours.

Thanks,

Dax

Posted by daximus at Oct 21, 2015 17:53

Hi Dax, I have found JDK8 to be much more realiable, I compiled mine using JDK 6 as I couldn't do it with JDK7 or 8 but it would crash every 24 hours or so, I have had no such issues with JDK8 and it hasn't missed a beat since.

One downside is since my version was compiled for JDK6 the designer won't load, but then that means less overhead which could also be the reason for greater stability.

Posted by glennl at Oct 22, 2015 08:12
Document generated by Confluence on Jun 05, 2016 09:34