Sign in to follow this  
Followers 0
ronaldde

First impressions of Hobson

3 posts in this topic

Hi all,

 

Here my first impressions of Hobson! Wauw - it's already a nice piece of software that can compete with openHAB, certainly in regard to usability!  And nice work on the Tasks! Really, really cool!

 

Some small questions:

  • the HomeEasy/ClickOnClickOff protocol is fire and forget and there is no querying of the devices (senders/receivers) possible. So, my guess is that the plugin will need to publish devices as they are discovered (e.g. when somebody presses a lightswitch button) and thus not on startup. However, once some devices were found and the user configured (=named) them, I think we need to store state between HUB restarts. Any idea on how to this? Is this up to the plugin and can I just store it in a Json file, or? 
  • It even get's worse: with the HomeEasy/ClickOnClickOff protocol, one does not know what the receiver/actuator will be since one can only intercept the senders/sensors... So, in JMom, I wanted to add the ability to allow the end user to choose what type of device is being controlled (e.g. a socket or a lamp, or X-mas light bulbs, ...) (depending on the protocol(fire & forget protocols: let end user choose; request & reply protocols: suggest device based on deviceId/info from database))
 
  • The VariableManager.setDeviceVariable(String userId, String hubId, String pluginId, String deviceId, String name, Object value) has too many parameters according to me...
    • userId: don't know what to fill in there 
    • hubId: don't know what to fill in there
    • or should I be using onSetDeviceVariable(); ? Javadoc pointed me to the VariableManager
 
  • are there any plans to add a way to structure devices in form of a tree?
  • What about multilinguality? I like English but not everyone over here :-)

Share this post


Link to post
Share on other sites

Hi ronaldde,

 
Thanks for taking the time to try out Hobson and for the kind words!

 

  • the HomeEasy/ClickOnClickOff protocol is fire and forget and there is no querying of the devices (senders/receivers) possible. So, my guess is that the plugin will need to publish devices as they are discovered (e.g. when somebody presses a lightswitch button) and thus not on startup. However, once some devices were found and the user configured (=named) them, I think we need to store state between HUB restarts. Any idea on how to this? Is this up to the plugin and can I just store it in a Json file, or?
 
This is something I knew would eventually need to be addressed. My current thinking is to keep the knowledge of “previously encountered” devices in the plugins themselves so that the device manager doesn’t need to worry about cleaning up stale information (e.g. when a plugin is uninstalled or a physical device is removed from a plugin’s “ecosystem"). Having said that, I’d hate to see every plugin developer re-writing the same code to persist device information. I’ll have to give this some thought and I welcome your opinions on it as well.

 

  • It even get's worse: with the HomeEasy/ClickOnClickOff protocol, one does not know what the receiver/actuator will be since one can only intercept the senders/sensors... So, in JMom, I wanted to add the ability to allow the end user to choose what type of device is being controlled (e.g. a socket or a lamp, or X-mas light bulbs, ...) (depending on the protocol(fire & forget protocols: let end user choose; request & reply protocols: suggest device based on deviceId/info from database))

 

This is an interesting use case but I think there's a reasonably clean solution for it. My suggested approach assumes that there is a unique identifier for a discovered device that allows you to identify whether it is a "known" device or not. 
 
I think the easiest approach would be to:
  1. Create a single HomeEasyDevice class (extending AbstractHobsonDevice) that can represent any HomeEasy device in the system.
  2. Give the HomeEasyDevice a configurable property called "deviceType" (using the addConfigurationMetaData method) that includes an enumeration for all the different device types you want to support (e.g. DeviceType.LIGHTBULB, DeviceType.SWITCH, etc).
  3. Override the getType() method for your HomeEasyDevice to return a value based on the "deviceType" configuration property.
  4. When your plugin detects a device it hasn't seen before, it creates a new HomeEasyDevice instance with a type of "Unknown". This will cause it to show up in the device list but it won't be usable because it's type is unknown.
  5. Because the device has the "deviceType" configuration property, the unknown device will be configurable through the web console. The user will be able to go into the device's preferences and change the device type to one of the enumerated values via a dropdown. This part is all handled automatically by Hobson.
  6. When a HomeEasyDevice detects a change to its device type (via the onDeviceConfigurationUpdate callback) it should publish the variables appropriate for its device type (e.g. if the user says it's a switch, publish the "on" variable, etc.)
This probably sounds more complicated than it really is. I'll put together a quick example plugin that demonstrates this in action.

 

  • The VariableManager.setDeviceVariable(String userId, String hubId, String pluginId, String deviceId, String name, Object value) has too many parameters according to me...
    • userId: don't know what to fill in there 
    • hubId: don't know what to fill in there
    • or should I be using onSetDeviceVariable(); ? Javadoc pointed me to the VariableManager

 

The userId and hubId arguments are there because the Hobson API supports both local API calls and remote, multi-tenant API calls. You can use the UserUtil.DEFAULT_USER and UserUtil.DEFAULT_HUB when making local calls to the VariableManager.
 
I am still working on the second part of the screencast where I discuss the plugin event loop and callbacks :-) onXXX() methods are callbacks from the Hobson runtime (and all guaranteed to be on the same thread) so in general they shouldn't be invoked directly by plugin code. 

 

  • are there any plans to add a way to structure devices in form of a tree?

 

Yes, the new user interface currently under development has the concept of arbitrarily putting devices into named groups. That way we can accommodate the concept of “rooms” but also any arbitrary grouping concept a user might want to use. I plan to implement this very soon. It will likely use some sort of tree or virtual tree structure.
 
  • What about multilinguality? I like English but not everyone over here :-)
 
This is planned but has been a bit lower on the priority list. If this is an important consideration for you to use Hobson, I can make it a higher priority.

Share this post


Link to post
Share on other sites

A couple of updates to your concerns...

 

  • The VariableManager.setDeviceVariable(String userId, String hubId, String pluginId, String deviceId, String name, Object value) has too many parameters according to me...
    • userId: don't know what to fill in there 
    • hubId: don't know what to fill in there
    • or should I be using onSetDeviceVariable(); ? Javadoc pointed me to the VariableManager

 

I've introduced the notion of a DeviceContext to encapsulate the details necessary to unambiguously identify a device. I've also introduced a static method on DeviceContext called "createLocal" that will create a device context for the local hub (what 99% of developers will want to do).

 

So, for example, the signature of the method you referenced would change from:

 

setDeviceVariable(UserUtil.DEFAULT_USER, UserUtil.DEFAULT_HUB, "myPluginId", "myDeviceId", "varName", "myValue")

 

to:

 

setDeviceVariable(DeviceContext.createLocal("myPluginId", "myDeviceId"), "varName", "myValue")

 

I believe this should simplify things a bit. The new changes will be available in the 0.5.0 release which is currently in progress.

 

  • What about multilinguality? I like English but not everyone over here :-)

 

I've added i18n support to the new web-based configuration wizard and am also in the process of adding it to the new web console. So, all the web-based user interfaces in 0.5.0 will be fully localizable. Localizing the backend Hub API should be easy in comparison :-)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0