All Activity

This stream auto-updates   

  1. Last week
  2. I've added my project to Travis, for automatic builds. However, I'm using a SNAPSHOT locally, which cannot be found by Travis for obvious reasons. Are the snapshots deployed to any central repository that I can add in my POM? By looking at the .travis.yml file, it looks like a JFrog artfiactory, but I have no clue where that is actually deployed. If it is deployed in a central place, maybe also document it in the
  3. Earlier
  4. I like this idea. I have added a file to the repo with the currently known working devices and have updated the Wiki page accordingly.
  5. Agreed, this helped me a lot! Specially the last part, with the system property. I haven't found that anywhere else.
  6. Would it be an idea to have this list of supported devices as a markdown file within the Git-repository? If a contributor adds necessary code for a new device, the contributor could add it to the list themselves, in the pull request.
  7. The newest version of Hobson, 0.10.0, is now publicly available. There are a lot of changes in this release including: Added "Home" and "Away" modes to the hub. Added WebSockets support so web UI updates are immediate rather than delayed by 5 seconds. Added support for long-running, complex plugin and device actions. Added ability to disable tasks. Added support for manually deleting existing devices. Created new plugin for Pushover notification service. The Hobson runtime now persists meta-data about all published devices so plugins can obtain device information even if the device hardware is unavailable (e.g. sleeping nodes). Hub authentication and authorization are now managed by an independent plugin. This allows third parties to create custom plugins to support different identity stores and authorization implementations. Added device tagging API endpoints. Simplified event subscription model for plugins. Improvements to OpenID Connect implementation. Improvements to plugin and device configuration validation. Improvements to device availability tracking and reporting. REST API documentation is now in Swagger format and can be accessed directly from the Hub.
  8. The Hobson Hub listens on port 8182 (HTTP) or 8183 (HTTPS) by default. You could run multiple hub instances and put a load balancer in front of them but that would assume that all hub instances are identical.
  9. I want establish IoT cloud platform with Hobson, I want to deploy several Hobson instances to support high availability, How to do load balance?
  10. You can launch Hobson manually using Java 1.8. The current parameters you need to pass to the "java" command are as follows: java -Dhobson.home="${launcher:sys.launcherDirectory}" -Dhobson.logdir="${launcher:sys.launcherDirectory}/logs" -Dlogback.configurationFile="${launcher:sys.launcherDirectory}/conf/logging.xml" -XX:HeapDumpPath="${launcher:sys.tempDir}" -XX:+HeapDumpOnOutOfMemoryError -Dgosh.args=--nointeractive"${launcher:sys.launcherDirectory}/conf/jssecacerts" -classpath ${launcher:sys.launcherDirectory}/lib/org.apache.felix.main-4.4.1.jar org.apache.felix.main.Main You'll need to replace ${launcher:sys.launcherDirectory} with the full path to your Hobson install directory and ${launcher:sys.tempDir} with the full path to a temporary directory (varies by OS). If you're running on Windows, you'll also need to change the '/' characters in the paths to '\'.
  11. Hi Dan, I need in folder setup hobson have folder is "jre". I see "jre" is java 1.7 vs 32bit. I need run on java 1.8 64bit.
  12. Hobson should run just fine on Java 1.8 as is. What platform are you trying to run it on?
  13. Hi Dan, I need run on java 1.8 64bit
  14. Hi smartlake, What are you looking to do specifically? Get Hobson running on Java 1.8 or build it from source using Java 1.8?
  15. Hi Dan, I need build hobson on java 1.8 run time 64bit. You have support me
  16. The upcoming Hobson 0.10.0 has a lot of new features including real-time web socket support, arbitrary plugin & device actions, hooks that allow users to manually add plugin devices and runtime device meta-data persistence. Undoubtedly, with a lot of changes comes a lot of testing. Since a lot of Hobson's recent changes were to support sensor use cases, it made sense to perform testing using sensor devices. The question became what kind of sensors to use? I was turned onto the MySensors project by a Hobson user and have been very impressed with it. I was able to quickly build an Arduino-based sensor gateway and a couple of basic sensors very inexpensively and quickly. Furthermore, I was able to write a MySensors serial controller plugin for Hobson quickly and painlessly which both confirmed that the MySensors ease-of-use claims were true and that the recent slew of Hobson API changes were taking things in the right direction. It's safe to say that Hobson 0.10.0 has taken longer than expected but I think the changes are excellent and will help the platform to grow. Look for it and the Hobson MySensors plugin in the coming weeks.
  17. This page lists supported devices by WZWave:, but what does supported mean? Is it Basic support as it could be detected and support basic communication, or do we support all its functionality? How do we handle regression tests so that once working devices still works in new versions of the library? How does the process of adding new devices to the list look? I think we are several users out there with working devices that could possibly be added to the list and make the list more complete, if we only knew how and what criteria that need to be fulfilled.
  18. Hi, I just want to share some of my experiences with setting up and running the WZWave-library for the first time on a Linux machine. I think Dan is working on a "Linux Setup"-guide, just as his current "Mac Setup"-guide, in the meantime this short post just might get you going, I'm running Ubuntu but I think its applicable on any distribution. 1. First install Java JDK, if not already installed. I'm running Oracle JDK v.1.8, but OpenJDK should also work. Here is a nice guide if needed. 2. WZWave internally depends on the common used RXTX-library to be able the communicate with the ZWave controllers connected to your serial and USB-ports. We must thus install the RXTX-package, on Ubuntu this could be done like this: "sudo apt-get install librxtx-java". 3. On a Linux system you normally can't communicate directly with the hardware for security reasons, usless you have privileges to do so like the almighty root-user. We should add our user to a suitable user-group that has those privileges, to find out a suitable group run this command: "ls -la /dev/ttyS*". The output could look like this "crw-rw---- 1 root dialout 4, 64 aug 13 22:48 /dev/ttyS0", on Ubuntu and several other distributions the "dialout"-group is a suitable candidate. Add our user to the dialout-group using this command: "sudo adduser <YOUR USERNAME> dialout". 4. Create a Maven Java-project using your favorite development environment, see Example Client Code. 5. Start the application with the following parameter: "-Djava.library.path=/usr/lib/jni". It will point out for the RXTX-library where its drivers are stored (see step #2). Possible issues: If you keep getting this error when running the application "Something bad happened:" and your controller having a device name beginning with "ttyA....", try to add this additional parameter when starting the application: "". Some even created a symlink to get the RXTX-library on track. The parameter supports specifying several ports if needed, like this: "".
  1. Load more activity