eclipse-archived / smarthome

Eclipse SmartHome™ project

#THIS PROJECT IS ARCHIVED

Eclipse SmartHome Build Instructions

Thanks for your interest in the Eclipse SmartHome project!

Building and running the project is fairly easy if you follow the steps detailed below.

Please note that Eclipse SmartHome is not a product itself, but a framework to build solutions on top. This means that what you build is primarily an artifact repository of OSGi bundles that can be used within smart home products. Besides this repository, a VSCode extension is available for editing configuration files with full IDE support.

1. Prerequisites

The build infrastructure is based on Maven in order to make it as easy as possible to get up to speed. If you know Maven already then there won't be any surprises for you. If you have not worked with Maven yet, just follow the instructions and everything will miraculously work ;-)

What you need before you start:

• Maven3 from http://maven.apache.org/download.html

Make sure that the "mvn" command is available on your path

2. Checkout

Checkout the source code from GitHub, e.g. by running

git clone https://github.com/eclipse/smarthome.git

3. Building with Maven

To build Eclipse SmartHome from the sources, Maven takes care of everything:

• set MAVEN_OPTS to "-Xms512m -Xmx1024m"
• change into the smarthome directory ("cd smarthome“)
• run "mvn clean install" to compile and package all sources

If there are tests that are failing occasionally on your local build, run mvn -DskipTests=true clean install instead to skip them.

The p2 repository that contains all bundles as a build result will be available in the folder products/org.eclipse.smarthome.repo/target.

smarthome's Issues

Runtime validation of configuration parameters

migrated from Bugzilla #465428
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2015-04-24 09:53:11 -0400, Chris Jackson wrote:

Currently, when saving a parameter, ESH is not checking the type that is in the thing XML file (at least this is my working assumption from looking at what is happening). The problem is that if we send a parameter "6", then ESH saves this as a string, and then restores it as a string when the getConfig function is called. However, if the binding thinks this is going to be an integer, and assumes this (as per our previous discussion) then it throws an exception. The way to solve this is for the rest interface to write this as 6, not "6".

I know that you could (and probably will) consider this a bug in the UI and I agree that the UI should send back the data correctly. However given the consequences that it will cause the binding to crash if it's wrong, I think this should be checked, and converted where possible, in ESH.

The other option is for the binding to perform type checking to see what is returned from getConfig, but this seems wrong to me. The binding has stated it wants an Integer, so it should get one (or at least a BigInteger as per our previous discussion).

On 2015-04-25 08:17:09 -0400, Dennis Nobel wrote:

Hi Chris,

first I think that the application should send correct values. In the Paper UI I´m converting the values at the client. If the binding expects an integer or boolean, the Paper UI sends the native type as part of the REST call:

'configuration': {
'stringParameter': 'value',
'decimalParameter': 20,
'booleanParameter': true
}

But I agree that we should have type checking as part of the framework. We planned to do so, but as usual we did not find the time to implement it.

The other option is for the binding to perform type checking to see what is returned from getConfig, but this seems wrong to me. The binding has stated it wants an Integer, so it should get one (or at least a BigInteger as per our previous discussion).

Yes, converting inside the binding makes no sense, as (ideally) the binding should not get wrong values if we add type checking and config validation.

Regards

Dennis

On 2015-04-25 08:22:23 -0400, Dennis Nobel wrote:

If it is ok for you, I will change the title of the bug to "Runtime validation of configuration parameters" and put it to the list of feature requests.

On 2015-06-27 08:06:18 -0400, Chris Jackson wrote:

Dennis,
Just another example of this issue. I have the following parameter defined -:

Channel
Specifies the channel the sensor is using

Channel 1
Channel 2
Channel 3
Channel 4
Channel 5
Channel 6
Channel 7
Channel 8

This is saved by paper UI as a string and I then get an exception in my binding. I think this might be a bug in paper ui though since it works ok in HABmin.

I missed the comment when you said you would change the name to 'validation' - to me it should be conversion as well as validation (ie conversion where possible, and validation where not) Are you happy with that definition? IF so, I might have a look at fixing this.

On 2015-06-27 08:19:25 -0400, Chris Jackson wrote:

Actually, what I described above might be a bug specific to PaperUI when creating a new thing. If I edit the parameters, then it is correctly saved as a BigInt, but when it was first created, it was saved as a String.

On 2015-06-28 12:40:23 -0400, Dennis Nobel wrote:

Yes, it´s a bug in the Paper UI (see https://github.com/openhab/smarthome/issues/15). As commented before I would only expect a runtime validation, not a conversation. UIs should send data in the correct format.

On 2015-08-01 04:55:53 -0400, Chris Jackson wrote:

When adding the validation, we need to ensure that arrays are supported (for the multiple selection option)

On 2015-08-03 09:43:39 -0400, Dennis Nobel wrote:

Maybe I missed the forum discussion or the PR, but what is the format of an array value inside the configuration? Values just separated by "," or ";"? Or a real JSON Object like ["a", "b"]?

Early calls to updateProperties() throws warnings in AbstractManagerProvider.update()

migrated from Bugzilla #466778
status NEW severity normal in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2015-05-07 16:13:16 -0400, karel goderis wrote:

When creating a new Thing, and ThingHandler, code like

Map<String, String> properties = editProperties();
properties.put(selector.getChannelID(),
entry.getValue().getAsString());
updateProperties(properties);

throws a lot of these in the logs

2015-05-07 22:08:43 [WARN ] [.c.c.r.AbstractManagedProvider:138 ] - Could not update element with key tesla:models:v12killer in ManagedThingProvider, because it does not exists.

The call originates from the this.callback.thingUpdated(thing) here below

protected void updateProperties(Map<String, String> properties) {
boolean propertiesUpdated = false;
for (Entry<String, String> property : properties.entrySet()) {
String propertyName = property.getKey();
String propertyValue = property.getValue();
String existingPropertyValue = thing.getProperties().get(propertyName);
if (existingPropertyValue == null || !existingPropertyValue.equals(propertyValue)) {
this.thing.setProperty(propertyName, propertyValue);
propertiesUpdated = true;
}
}
if (propertiesUpdated) {
synchronized (this) {
if (this.callback != null) {
this.callback.thingUpdated(thing);
} else {
throw new IllegalStateException("Could not update properties, because callback is missing");
}
}
}
}

which contains

   public void thingUpdated(Thing thing) {
        thingUpdatedLock.add(thing.getUID());
        thingRegistry.update(thing);
        thingUpdatedLock.remove(thing.getUID());
    }

Is there a timing problem as to the Thing being created but not yet being added to the thingRegistry?

On 2015-05-07 18:20:58 -0400, Dennis Nobel wrote:

How do you add the thing? From the DSL or UI?

On 2015-05-08 03:18:44 -0400, karel goderis wrote:

The thing is created from the DSL.
The code is called upon in the ThingHandler after initialisation, but in a thread that is spawned in initialize()

On 2015-05-08 03:44:53 -0400, Dennis Nobel wrote:

Actually the whole concept does not work with the DSL files. The ThingManager tries to save the updated properties via the ManagedThingProvider. But if the things are configured through the DSL, there is no entry in the database. This does not only applies for properties, but also for configuration updates.

As long as we do not have a possibility to write back changes into the DSL, the only option I see is to leave out the serialization in DSL case and remove the warn logging.

On 2015-05-08 03:51:22 -0400, karel goderis wrote:

Ok - from the code I can see that updating configurations and properties is still ok and allowed. Per discussion with Kai, I am re-organising the Tesla binding by moving a lot of channels out of the DSL and store the corresponding values as Properties.

I understand that serialisation is not possible in the DSL case, but is there a need then for to have a thingUpdated() call? I can imagine that DSL-orginated Things also want to react upon changed in their Configuration and Properties?

K

On 2015-05-08 05:36:03 -0400, Dennis Nobel wrote:

We are mixing up two different cases

1. thingUpdated() is called by the framework to inform the binding a thing was updated
2. updateThing() is called by a binding to to inform the binding a thing was updated

If you want to write properties from the binding, you call 2) updateThing (implicitly via updateProperty). But it seems that this does not work for things configured through the DSL.

If you change the configuration of a thing in the DSL at runtime, 1) thingUpdated will be called in your binding. So this works.

On 2015-05-09 05:29:09 -0400, karel goderis wrote:

Ok. Will thingUpdated() also be called when the Properties change? (in other words, do we assume they can change over time as well?)

My assumption is that Property changes can be triggered in different place, e.g. the ThingHandler, or the Thing's BridgeHandler.

Today we do not really care what part of a Configuration has changed, since the base assumption here is that a dispose() and initiliaze() will happen anyways, and most probably, the complete ThingHandler will be reconditioned.

Now, with changes in Properties it would be handy to know which Property exactly has changed with the thingUpdated() call. This functionality can be part of the ThingHandler on a case by case need, or could be refactored in a sense that we would get a propertyUpdated(String property,String newValue) method in the BaseThingHandler?

K

GenericItemProvider very unstable

migrated from Bugzilla #469380
status UNCONFIRMED severity normal in component Core for ---
Reported in version 0.8.0 on platform PC
Assigned to: Project Inbox

Original attachment names and IDs:

• MSUQ.tiff (ID 254194)

On 2015-06-04 07:34:21 -0400, karel goderis wrote:

I have the situation whereby randomly GenericItemProvider is failing, and stops processing .items files, rendering the core (alpha2) very very unstable. I am about to give up on it.

example:

2015-06-04 13:30:04 [TRACE] [.e.s.m.i.i.GenericItemProvider:438 ] - Created item 'BedroomGeorgesBrightness' of type 'Number'
2015-06-04 13:30:04 [TRACE] [.e.s.m.i.i.GenericItemProvider:353 ] - Given binding config reader is null > query cache to find appropriate reader!
2015-06-04 13:30:11 [DEBUG] [s.c.internal.items.ItemUpdater:82 ] - Received update for non-existing item: Item 'BedroomGeorgesBrightness' could not be found in the item registry

is that Item now created or not?

Sometimes the Configreader of a binding (any one, this is random) is found, then it is not found and so

It seems that the startup order is really impacting things thereafter, yielding unpredicatble results. How to get to the root cause of this?

On 2015-06-04 13:50:51 -0400, karel goderis wrote:

I can accept that the cutting edge of technology is a bleeding edge, but ESH's core is really troublesome

Starting an OH2 alpha2 environment with a stable configuration will yield every time different results. The startup order in the core runtime is really really really ( I can stress enough) an issue. I can accept the architectural decision to have it OSGi style and thus modular, but it leads to disaster in this case. In my case, I have either no, some, a bunch, or all Items defined when I start up. It changes every single time

I dunno if I stand alone in trying to run ESH in an environment with 20-something OH bindings, a few 100 Things and a few 1000 Items, but it simply does not work as expected.

/me thinks that some thorough and scaled up testing of the ESH core should be high on the to-do list.

Or, that some sort of start-up order is enforced.( Which is a constant, but not a very logical one, is that .rules are processed before .items are read.)

Time to get out of the 3-device 3-binding stage into something that is stable!

K

On 2015-06-06 04:37:04 -0400, karel goderis wrote:

I also see from time to time that the Folder Observer thread (or how is it called) is exiting ungracefully, but reason why I can not see. (if that that is the thread where the Items are parsed, then this is normal cfr the problem mentioned here below)

On 2015-06-08 13:47:01 -0400, karel goderis wrote:

Created attachment 254194
Screenshot MS U Q thread

On 2015-06-08 13:47:35 -0400, karel goderis wrote:

I spend a lot of time in additional testing, mainly by attaching a debugger to the operational environment. I found that things improve when .items files with a lot of definitions are processed last by the FileObserver thread ("ManagedService Update Queue"). For example, in knx.items i have >3000 items, and when it is processed in the middle of the pack, the whole thread is like "pausing" for a while.

At a given moment in time, I found that this MS U Q thread was waiting for a lock object (see attachment) but it wasn't a real race condition either (as Eclipse did not indicate that all), but still, the thread was somehow blocked, and I only could restart the runtime by a "kill -9 ". To me, it seems that something funky is going in equinox.

On 2015-06-09 06:24:46 -0400, Dennis Nobel wrote:

Hi Karel,

we are very sorry about your stability problems. Thanks for all the log files. We will try to reproduce the issues and try to see where the problem is. Maybe a regression testing for startup really makes sense.

Regards

Dennis

On 2015-06-10 05:19:58 -0400, karel goderis wrote:

Running the full setup, but with an empty .things folder, yields good results. eg. Items are created as expected. When you start adding .things files one by one, after a few .thing files the OH start to behave erratically, with similar effects as in the screenshot I attached earlier on.

Reflecting on this, and I think we already discussed it elsewhere, the most logical flow (to me) is:

1. Instantiate all Things and Channels
2. Instantiate all Items (so that they can hook up the Channels)
   2b. Fire up Persistence, and restore values if necessary
3. Instantiate all ThingHandlers (so that data fed to the Channels is not fed to non-existing Items)
4. Load the RuleEngine

On almost every instance, the RuleEngine is fired up before the Items being created. For example, I have some Timers that are fired up 2 min after startup, and with the problems described below, the often are fired even before the processing of all the DSL files is finished.

Pls let me know what you would like to received as log-files in order to investigate. Maybe on a temporary basis we need to include a lot of TRACE in to the ESH core?

Karel

On 2015-06-10 16:16:31 -0400, karel goderis wrote:

After some more testing, it seems that the FileObserver thread gets stuck when you encounter stuff like

2015-06-10 22:10:45 [TRACE] [.e.s.m.i.i.GenericItemProvider:438 ] - Created item 'TechnicalFacilitiesElectricityActiveEnergy' of type 'Number'
2015-06-10 22:10:45 [TRACE] [.e.s.m.i.i.GenericItemProvider:353 ] - Given binding config reader is null > query cache to find appropriate reader!
2015-06-10 22:10:45 [TRACE] [.e.s.m.i.i.GenericItemProvider:438 ] - Created item 'TechnicalFacilitiesElectricity60minActiveEnergy' of type 'Number'
2015-06-10 22:10:45 [TRACE] [.e.s.m.i.i.GenericItemProvider:353 ] - Given binding config reader is null > query cache to find appropriate reader!

in any .items file, except if that given .items file is the last one to be processed in the /items folder. In that case, the items are correctly created the next around when the .items are traversed.

On 2015-06-25 11:39:41 -0400, karel goderis wrote:

Based on the June 22nd build, I think there is a NPE in GenericItemProvider

Each time I encounter an error like

2015-06-25 17:37:13 [DEBUG] [.e.s.m.i.i.GenericItemProvider:151 ] - Processing binding configs for items from model 'lifx.items'
2015-06-25 17:37:13 [TRACE] [.e.s.m.i.i.GenericItemProvider:438 ] - Created item 'LivingRoomLIFXLeft' of type 'Color'
2015-06-25 17:37:13 [TRACE] [.e.s.m.i.i.GenericItemProvider:353 ] - Given binding config reader is null > query cache to find appropriate reader!

then the item parsing stops completely, hinting at an ungraceful exit of the parsing thread.

Add support for conditional access based on user role

migrated from Bugzilla #423548
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2013-12-08 15:16:18 -0500, Kai Kreuzer wrote:

Migrated from https://code.google.com/p/openhab/issues/detail?id=387

On 2015-09-25 03:52:04 -0400, Kai Kreuzer wrote:

Some input from my side what I see should be covered. There are multiple levels of access control that can be addressed:

1. Global access control as it is done in openHAB 1 (see https://github.com/openhab/openhab/wiki/Security#authentication). I.e. for any access to the runtime, the user needs credentials and is then assigned a role.
   JAAS is probably a good option here. Note that the solution has to work in general for any OSGi HttpService, it must not be specific to Jetty (while in openHAB 2, we can add a Jetty-specific configuration for JAAS then).
2. Restrict certain urls and/or http verbs for certain roles. See the example discussed in https://www.eclipse.org/forums/index.php/t/1068387/.
3. Restrict access on certain data, e.g. return a HTTP 403 when my kids try to access localhost:8080/classicui/app?sitemap=admin. This could be implemented in phases, the most important resource would be sitemaps, then come items, things, rules, etc. But in general this mechanism should be available on all resources. Configuration of such restrictions should not only be by resource name, but possibly also by type/tag, e.g. do not grant access to any item that is tagged as "security".
4. Filter data within requests, i.e. if I do not have rights for sitemap "admin" (see 3), the REST url /rest/sitemaps should not even list it. Sitemaps that refer to items that I am not allowed to access should filter out these widgets automatically.
5. Check implications on automation rules. Normally, rules are executed by the system and not the user. But we could imagine that a trigger was caused by some user (e.g. an item state change) and thus the rule could be regarded to be executed on behalf of this user - then again, the permissions should be checked and e.g. sending commands to restricted items must be blocked.

Does anybody has further ideas/requirements?

Refactor TTS APIs into a general audio dispatching allowing different sources and sinks

migrated from Bugzilla #463802
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2015-04-02 09:11:10 -0400, Kai Kreuzer wrote:

The current TTS implementations combine the creation of the audio stream with its output. E.g. the Google translate TTS service generates an mp3 and outputs it on the local soundcard.
It would be much nicer, if the mp3 would be created by one service (the "source", here: Google Translate) and the output would be done by another one - this way, it could be played back as well on Sonos, Squeezebox etc. (the "sink").

When splitting it this way, it automatically means that it is not limited to TTS - but it could indeed be any kind of soundfile. So this refactoring should also address the "playSound" action at the same time.

Circular reference detected (ConfigDescriptionRegistry)

migrated from Bugzilla #483029
status NEW severity normal in component Core for ---
Reported in version 0.8.0 on platform All
Assigned to: Project Inbox

Original attachment names and IDs:

• org.eclipse.smarthome.config.core.log (ID 258281)
• circular-1.txt (ID 258293)
• circular-2.txt (ID 258296)

On 2015-11-25 13:28:01 -0500, Markus Rathgeb wrote:

I tried using the same start level for all org.eclipse.smarthome and the related Xtext bundles.

I get this message:

2015-11-25 19:20:47,931 | ERROR | pool-23-thread-1 | core | 99 - org.eclipse.smarthome.config.core - 0.8.0.201511251757 | [ConfigDescriptionRegistry(0)] Circular reference detected, getService returning null

(the only logged error)

Dennis, you already solved such a problem here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=477482

Could you have a look at, that is the best approach?
I will try to have a look at this, too, but I think you are much more familiar with this...

On 2015-11-25 17:32:37 -0500, Markus Rathgeb wrote:

Created attachment 258281
org.eclipse.smarthome.config.core.log

Add a more verbose log...

On 2015-11-26 05:29:31 -0500, Dennis Nobel wrote:

Hi Markus,

I can not find an obvious circular dependency there. The tracker tracks the ConfigDescriptionRegistry, which only tracks ConfigDescriptionProvider. The only ConfigDescriptionProvider is the XMLConfigDescriptionProvider, which does NOT have a dependency to the ConfigDescriptionRegistry.

So I have no idea :(.

Do you have any additional bundles installed? Or a specific branch?

Regards

Dennis

On 2015-11-26 14:29:14 -0500, Markus Rathgeb wrote:

Created attachment 258293
circular-1.txt

Hi Dennis,

thank you, that you have a look at this.

I have added some informations I currently collected. Have to learn all that diagnostic command lines of Karaf.

Perhaps "org.eclipse.smarthome.io.rest.core" is involved in the circular dependencies...

If you want to play with this setup, I can give you a link.

On 2015-11-26 14:57:04 -0500, Markus Rathgeb wrote:

Created attachment 258296
circular-2.txt

Improve event bus threading

migrated from Bugzilla #423517
status ASSIGNED severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Davy Vanherbergen

On 2013-12-07 17:21:38 -0500, Kai Kreuzer wrote:

Migrated from https://code.google.com/p/openhab/issues/detail?id=454

On 2014-05-23 18:00:49 -0400, Davy Vanherbergen wrote:

What happened to the EventPublisherImpl in SmartHome? I don't understand why all the synchronized blocks have been added. Doesn't this limit the concurrency of the eventbus to 1, whilst the EventAdmin is threadsafe and can handle concurrency?
Wouldn't it make more sense to remove all of the synchronized keywords and eventAdmin null checks and change the osgi binding policy for the EventAdmin to static, that way the EventPublisher will only be available if there is an eventAdmin already set..

On 2014-05-26 03:01:55 -0400, Kai Kreuzer wrote:

The synchronized blocks were added by a contribution that tried to cover every potential problem with dynamic behaviour - but it was indeed much too restrictive and thus causes problems like this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=435294. So the synchronized blocks will have to be removed again indeed.

On 2014-05-26 12:07:18 -0400, Davy Vanherbergen wrote:

I would like to propose 2 changes to the way the current event bus is implemented/used.

1. Change event bus implementation to something like:
   EventBus.java : Interface defining event bus. Defines methods for subscribers to (de)register themselves for events and for publishers to post events.
   EventBusImpl.java : default event bus implementation. This would be a custom implementation (not using EventAdmin) which is a multi threaded distributor of events. It would be limited to local (same jvm) events only.
   EventBusMQTT.java : an MQTT based event bus implementation. This could be an optional implementation in a separate bundle. Similar to the above, but using MQTT for delivery, which would make this very suitable to connect remote nodes.
   I believe that moving away from the EventAdmin would be the right way forward. It will help avoid the concurrency issues we are currently seeing with openHAB events and the OSGI service loading.

2. Change event hierarchy:
   I believe it would be useful to split events into more different types: StateEvent, CommandEvent, ConfigurationEvent, SystemEvent.
   ConfigurationEvents could be used for notifying changes in item/binding configuration and SystemEvents could be used for system related events like BINDING_ADDED, BINDING_REMOVED, BINDING_STARTED, NODE_STARTED, SYSTEM_STARTED, etc.
   Without system events, it will be very difficult to be able to know when the full SmartHome (master + nodes) is started and the startup rules can be triggered.
   Configuration events on the other hand, would be very usefull to configure items in remote nodes from the master node.

Would this fit within the SmartHome long term direction?

On 2014-05-27 09:25:56 -0400, Kai Kreuzer wrote:

1. Right, from our experience with the different EventAdmin implementations it is difficult to get a reliable behavior across different setups.
   So I would agree to move away from EventAdmin.
   Is the assumption that there is always exactly one EventBus implementation registered as an OSGi service? Or would there be any use case where multiple buses need to be supported?
   For the non-MQTT implementation, the Google Guava AsyncEventBus might actually be a good choice, what do you think?
   Could you come up with a suggestion for the EventBus interface? What features shall we put in there? Should it be more oriented towards Java objects like Guava or more towards topic structures like MQTT and EventAdmin? Furthermore, shall it support MQTT-like features such as QoS or last-will?

2. Agreed, we need to introduce new types of events (see also the "UI events" suggestion in https://www.eclipse.org/forums/index.php/mv/msg/628353/1376618/#msg_1376618).
   I wonder if the requirements for these "system/ui/config" events might be different than the ones for "item" events and if this could qualify for different interfaces? Probably not as it would make things rather complex. What is your take on this?

I would suggest to only address 1) in the context of this issue and create a second bugzilla issue for introducing new event categories.

On 2014-05-27 09:54:29 -0400, Davy Vanherbergen wrote:

1. I can't think of any use case where there would be a need for 2 eventbuses in a single runtime.
   At first sight the guava bus looks nice, but I'm not sure if it would make it more complicated to have interchangeable buses.
   I'll need to have a closer look at the Guava AsyncEventBus first.
   My initial idea was to keep the eventbus as simple as possible and orientate more towards Java objects.
   I haven't thought about QoS or last-will yet. I'm not quite sure yet what use cases for that would be.
   I'll see if I can come up with something more concrete for the EventBus.

2. Sounds like a plan.

On 2014-06-02 09:01:41 -0400, Michael Grammling wrote:

(In reply to Davy Vanherbergen from comment # 1)

What happened to the EventPublisherImpl in SmartHome? I don't understand why
all the synchronized blocks have been added. Doesn't this limit the
concurrency of the eventbus to 1, whilst the EventAdmin is threadsafe and
can handle concurrency?
Wouldn't it make more sense to remove all of the synchronized keywords and
eventAdmin null checks and change the osgi binding policy for the EventAdmin
to static, that way the EventPublisher will only be available if there is an
eventAdmin already set..

The synchronization stuff is neither related to the synchronization of the EventAdmin implementation itself nor the null-check. It's related accessing the EventAdmin. Nevertheless I understand the problem and the deadlock situation.

Example (without synchronization):
Thread 1: T1
Thread 2: T2

1.) T1: synchronous call by DS of OSGi to unsetEventAdmin(...)
2.) T2: e.g. postCommand(...), if (this.eventAdmin != null) -> true
3.) T1: unsetEventAdmin: this.eventAdmin = null;
4.) T2: this.eventAdmin.sendEvent(createCommandEvent(itemName, command, source));
5.) NPE

We can now improve the code a bit to:
EventAdmin localEventAdmin = this.eventAdmin;
if (localEventAdmin != null) {
localEventAdmin.sendEvent(createCommandEvent(itemName, command, source));
} else {
throw new IllegalStateException("The event bus module is not available!");
}

1.) T1: synchronous call by DS of OSGi to unsetEventAdmin(...)
2.) T2: e.g. postCommand(...), if (localEventAdmin != null) -> true
3.) T1: unsetEventAdmin: this.eventAdmin = null;
4.) T2: localEventAdmin.sendEvent(createCommandEvent(itemName, command, source));
5.) Undefined behaviour (e.g. no error or an IllegalStateException if it's a good implementation or a JVM crash, ...)

The synchronization is needed due to the dynamic behaviour of OSGi. The static feature will not help, because in that case you would have to synchronize against activate/deactivate instead of setEventAdmin and unsetEventAdmin.
All good OSGi service implementations handle such issues.
I will think about it which is the best synchronization mechanism for this use case (probably using a "localEventAdmin" and a try/catch block instead of using a synchronization block).

On 2014-06-26 11:03:14 -0400, Kai Kreuzer wrote:

FTR: The deadlock has been fixed with https://bugs.eclipse.org/bugs/show_bug.cgi?id=435294.

@davy: So are you looking into "the plan" from above? I hope so and hence I assign this issue to you, if ok.

On 2014-06-26 16:10:07 -0400, Davy Vanherbergen wrote:

Hi Kai,

Yes, I started working on it. Expect to see something soon..

Davy

On 2014-06-28 13:13:15 -0400, Davy Vanherbergen wrote:

I took a stab at creating a new EventBus. The result can be viewed here: https://github.com/dvanherbergen/smarthome/compare/threading

The implementation is a simple one which doesn't stray very far from the previous implementation.
To subscribe to an event you have to implement the appropriate interface and publish it via DS. There is currently a different interface to implement per event type.
Publishing has stayed almost the same as well, you inject the eventBus via DS and use it to publish events.

I wanted to do some fancy annotation based event bus, but I couldn't convince myself that it was the right way to go.
Using annotations only makes sense to me, if either one of the following would be true:

1. There would be many event types to support, which would lead to a large number of interfaces
2. There is a need to provide complex filtering methods to subscribers to only receive a subset of certain event types
3. The architectural direction of SmartHome is to move away from Declarative Services and to move towards annotations for osgi services (e.g. using OSGI 5 @component or peaberry)

For the first point, I can only think of 4 event types that would be needed for SmartHome (state, commmand, system, configuration), which is not that much.
With regards to the second point, currently the filtering is done in the subscriber and this keeps things rather straight forward, so I'm not sure if we need a change here.
The third point is really about consistency. If bindings already have to use DS anyway, it seems logical to also use DS for the EventBus. Maybe you can comment on the long term direction?

So far, the code hasn't been fully tested yet as the demo config seems to have disappeared ;-)
With the proposed implementation, it will be easy to implement an MQTT based one. I'll start on that once the default bus approach is 'approved'.

Note that I've also included a new thread pool service providing two thread pools, one for executing tasks in a separate thread and one for scheduling repeating background tasks.
If these thread pools are used consistently within openHAB/SmartHome, it will make it easier to tune the number of concurrent threads used by the application.

Looking forward to your point of view. I'm happy to change the implementation to annotations if it makes sense..

On 2014-06-30 01:03:12 -0400, Davy Vanherbergen wrote:

With regards to 3), the Weld CDI annotations (RFC 193) look like a good candidate to replace Declarative Services. It would keep things nice and clean and has the added advantage that J2EE developers will feel right at home without having to know Declarative Services. I would be in favor of such a move :-)

On 2014-06-30 06:11:48 -0400, Kai Kreuzer wrote:

Great, thanks, Davy! I will have a closer look at the code soon.

Wrt 3): I never liked the overhead of the DS xmls very much, so annotations were always on my mind - I just didn't find a suitable rfc-193 compliant implementation in the past that could be used as a replacement for DS. Weld looks interesting - as long as the one bundle with 1.5MB is enough to fully use it :-)

So in general, I am open to replace DS by CDI, but this is a major step that should be carefully tested evaluated. Good thing of DS is that there are many alternative implementations available and products based on ESH can choose one. So if we require a CDI implementation instead, things might become more complicated.

Anyhow, the main architecture approach for "addon" development is to hide as much OSGi specifics (such as DS) from the developers as possible. So the idea is to provide maven archetypes that generate required DS xmls for you and that you don't really have to deal with when implementing your logic - see e.g. https://github.com/eclipse/smarthome/tree/master/binding/org.eclipse.smarthome.binding.hue

Regarding the lacking demo configurations: Well, this should motivate people to write according OSGi unit tests :-) Besides this, I am currently working on an openHAB2 IDE, where these developments can be tested (with ESH bundles in the same workspace).

On 2014-06-30 08:35:54 -0400, Davy Vanherbergen wrote:

There is also the PAX CDI implementation (https://ops4j1.jira.com/wiki/display/PAXCDI/Pax+CDI), maybe that one is smaller.

Another alternative to DS in "addon" development could be to build custom annotations, e.g. @ThingHandlerFactory, @ThingTypeProvider, etc.
Then there could be a bundle in Smarthome which would be responsible for registering these classes as services when the bundles are loaded. Sort of like a SmartHome specific mini-CDI implementation.
Or it would also be possible to generate DS files from these annotations during the compile/build phase.
In both cases, it would result in some 'reinventing the wheel' of things already done in BND or WeldCDI, but it would be a loosely coupled solution for addons that doesn't require direct use of DS and no dependencies on specific CDI/Build implementations other than what is in SmartHome.

On 2014-06-30 12:02:54 -0400, Kai Kreuzer wrote:

Are you sure that PAX CDI is an implementation? At a first glance it seemed to be just a CDI API packaging using weld as well...
We also through about custom annotations for our own purposes, but didn't really feel good about developing our own DI solution - so we decided to stay with DS and rather try to hide it.
One thing to keep in mind about annotation vs. XML: For annotations you need to scan every single Java class at bundle startup, while for XMLs you just need to check a certain folder. On low-end systems like a RaspPi that can sum up to a substantial load at startup time. Remember that CDI comes from the EE spec, i.e. solutions that usually run on huge servers.

On 2014-06-30 14:20:09 -0400, Davy Vanherbergen wrote:

Looks like PAX-CDI is indeed not an implementation..

On 2015-04-27 10:45:33 -0400, Dennis Nobel wrote:

Dany, are you still working on this issue?

On 2015-04-28 04:12:34 -0400, Davy Vanherbergen wrote:

Nope, not actively working on this anymore. The code was written but never reviewed. You can have a look at it here:
https://github.com/dvanherbergen/smarthome/compare/threading

On 2015-04-30 09:17:00 -0400, Kai Kreuzer wrote:

The code was written but never reviewed.

Hm, this makes me feel pretty awkward now. I actually reviewed the code and liked it, but we never moved over to a PR because I somehow got lost in the "annotation" discussion...
Having said this, I am still interested in solving this issue and moving away from the event admin like you suggested.
One part of our discussion was about supporting additional new event types as well - this is actually a different issue, but one that we currently address (in a more generic and extensible way than in your prototype) - you will find some details here: https://www.eclipse.org/forums/index.php?t=msg&th=1066185&goto=1694087&#msg_1694087

Once this is implemented and merged, I think we could continue on the threading issue - provided that you are still interested at all.

On 2015-04-30 10:57:53 -0400, Davy Vanherbergen wrote:

Hi Kai, sorry, I never meant to make you feel awkward. I lost track of the issue myself too. The new event types look great. There is a lot going on at work at the moment, so the next weeks are really busy for me and I'm not sure when I will have time, but give me a shout when it is merged.

On 2015-04-30 11:08:32 -0400, Kai Kreuzer wrote:

Great, no worries, there is no hurry. Will keep you posted!

ScriptExecution throws "The TypeResolutionStateAdapter was removed while resolving"

migrated from Bugzilla #469189
status UNCONFIRMED severity normal in component Core for ---
Reported in version 0.8.0 on platform PC
Assigned to: Project Inbox

On 2015-06-02 14:29:47 -0400, karel goderis wrote:

I get a lot of these

2015-06-02 20:26:38 [ERROR] [.e.s.c.s.ScriptExecutionThread:48 ] - Error during the execution of rule 'MultimediaPowerRule': The TypeResolutionStateAdapter was removed while resolving

in my logs. It seems to be related to XText but I am a novice to the Xtext code to say what exactly is going on here

K

On 2015-06-02 14:31:54 -0400, karel goderis wrote:

For completion, the code of the Rule is

rule MultimediaPowerRule
when
Item KitchenTVCurrent received update or
Item SamsungKitchenPing received update
then
if(KitchenTVCurrent.state > 100 || SamsungKitchenPing.state == ON) {
KitchenMultimediaSwitch.postUpdate(ON)
} else {
KitchenMultimediaSwitch.postUpdate(OFF)
}
end

On 2015-06-13 14:41:17 -0400, Oliver Libutzki wrote:

Hi Karel,

is it possible for you to provide the whole stacktrace? Often this exception is caused by another exception.

Thanks.

Provide a distribution of Eclipse SmartHome based on Concierge

migrated from Bugzilla #466633
status ASSIGNED severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Jochen Hiller

On 2015-05-06 16:21:22 -0400, Jochen Hiller wrote:

Eclipse SmartHome (ESH) is currently using Equinox as underlying OSGi framework. As more and more users are using ESH or a solution based on ESH (e.g. openHAB2) on embedded devices, e.g. Raspberry, BeagleBone, it makes sense to provide an ESH version optimized for embedded devices. To reduce footprint of the OSGi framework, Equinox can be replaced by Eclipse IoT Concierge, the OSGi R5 framework with a small footprint for IoT space.

I propose to provide a Eclipse SmartHome distribution which is based on Concierge.
The pros are:

• an optimized ESH distribution for embedded devices
• lightweight OSGi framework underlying
• provide a self-contained download of ESH

I did some work on preparing a port of ESH to Concierge, which is the base for a contribution I plan to make. See more information at https://github.com/JochenHiller/concierge-tests/blob/master/docs/Concierge-EclipseSmartHome.md

storage.mapdb: require-bundle must not be used

migrated from Bugzilla #477271
status UNCONFIRMED severity normal in component Core for ---
Reported in version 0.8.0 on platform All
Assigned to: Project Inbox

On 2015-09-13 05:48:12 -0400, Markus Rathgeb wrote:

(This is a split of the bug 476024)

Our coding guideline states that we have to use "Import-Package" instead of "Require-Bundle".
It is also good practice to do so http://wiki.osgi.org/wiki/Use_Import-Package_instead_of_Require-Bundle

For the mapdb storage bundle I do not know if the classloader needs this or not.
Perhaps this one is related to: jankotek/mapdb#555

Discovery result properties need to be mapped to Thing config parameters or properties

migrated from Bugzilla #472733
status ASSIGNED severity normal in component Core for ---
Reported in version 0.8.0 on platform PC
Assigned to: Christoph Knauf

On 2015-07-15 08:54:46 -0400, Kai Kreuzer wrote:

When approving a DiscoveryResult, there should be an automatic check, which key of its properties is a configuration parameter - these will be used as such on the newly created Thing. All others DiscoveryResult properties should end up as Thing properties.

See also https://www.eclipse.org/forums/index.php/t/1066328/

Allow bindings to deactivate auto-update for channels

migrated from Bugzilla #481178
status NEW severity normal in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2015-10-31 19:43:07 -0400, Kai Kreuzer wrote:

By default, the auto-update binding sets the status for a channel after seeing a command for it. The binding must be allowed to deactivate this feature for certain channels, so that it can have the state updates under its own control.

Saving item doesn't save groups

migrated from Bugzilla #474568
status UNCONFIRMED severity normal in component REST/SSE for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2015-08-09 17:54:46 -0400, Chris Jackson wrote:

Saving groups though /rest/items/{item} doesn't seem to save the groups. The SSE event is sent, and it's not updated there either. If I restart ESH then it is updated ok.

On 2015-08-12 02:42:43 -0400, Dennis Nobel wrote:

Well it should work. So you mean the problem only is, that the SSE event does not contain the changed values?

Color widget does not support changing the saturation

For Color items only a hue and a brightness slider are rendered - but saturation is missing. Therefore only a fraction of possible colors can be used.

Make mDNS announcement Physical Web compliant (through a configuration option)

migrated from Bugzilla #468125
status ASSIGNED severity normal in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Yasser Aziza

On 2015-05-24 06:51:30 -0400, Yasser Aziza wrote:

The openHAB runtime should announce itself through mDNS in the local network.

This feature is needed for the Google's Physical Web integration [1].

Any smartphone that is in the same network and has the Physical Web app installed should directly find the instance and open the web client (Eclipse SmartHome Classic UI) of it.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=468124

On 2015-05-24 06:57:22 -0400, Markus Rathgeb wrote:

Didn't this work out of the box?
I this is not integrated in the current mDNS bundles, then I have implemented this already myself.
Will have a look at on Tuesday.

On 2015-05-24 07:30:09 -0400, Kai Kreuzer wrote:

Yasser, please note that Eclipse SmartHome already has the ability to broadcast mDNS annoucements, see https://github.com/eclipse/smarthome/blob/master/bundles/io/org.eclipse.smarthome.io.transport.mdns/src/main/java/org/eclipse/smarthome/io/transport/mdns/internal/MDNSServiceImpl.java#L71.
The REST API uses this infrastructure to announce itself already: https://github.com/eclipse/smarthome/blob/SHA: 1ffc8d4/bundles/io/org.eclipse.smarthome.io.rest/src/main/java/org/eclipse/smarthome/io/rest/internal/MDNSAnnouncer.java#L50

What is needed is to make this announcement compatible to the Physical Web format, i.e. it should announce the local url with it. Please note that for backward compatibility reasons, the current annoucement should not be changed, but adding the Physical Web compatible way could be enabled through configuration additionally.

Please also note that this is the Eclipse Bugzilla, this means that you should refrain from referring to openHAB here. If a functionality is related to openHAB directly, please add an issue at https://github.com/openhab/openhab2/issues instead.

@markus: No need for you to get active in any way. Yasser is working on this topic in the context of a GSOC project, so he will take care of all implementations.

On 2015-05-24 09:03:06 -0400, Victor Belov wrote:

Kai, if it would not possible to make announcements both GPW compatible and backward compatible with mobile apps I can have a look into supporting both on the mobile app side.

On 2015-05-24 10:27:26 -0400, Kai Kreuzer wrote:

Thanks Victor. Nonetheless, for the migration path it probably would make sense to at least allow to configure whether it is old or new style of annoucements. It probably indeed does not make too much sense to have both annoucement styles active at the same time.

On 2015-06-01 05:59:08 -0400, Kai Kreuzer wrote:

Hi Yasser, I have adapted the title of this issue accordingly. Did you already make any progress on this?

On 2015-06-01 17:26:32 -0400, Yasser Aziza wrote:

(In reply to Kai Kreuzer from comment # 5)

Hi Yasser, I have adapted the title of this issue accordingly. Did you
already make any progress on this?

Hi Kai, sorry for the late replay.
I will send a patch in the next 2 days to github.

On 2015-06-08 06:53:19 -0400, Yasser Aziza wrote:

(In reply to Kai Kreuzer from comment # 2)

What is needed is to make this announcement compatible to the Physical Web
format, i.e. it should announce the local url with it. Please note that for
backward compatibility reasons, the current annoucement should not be
changed, but adding the Physical Web compatible way could be enabled through
configuration additionally.

Hi kai,
just a last question: what is the best way to manage the annoucement configuration ?

On 2015-06-08 14:09:40 -0400, Kai Kreuzer wrote:

The annoucement is done for the REST API, hence the registered service can be found here: https://github.com/eclipse/smarthome/blob/master/bundles/io/org.eclipse.smarthome.io.rest/OSGI-INF/mdnsannouncer.xml
As you can see in https://github.com/eclipse/smarthome/blob/master/bundles/io/org.eclipse.smarthome.io.rest/src/main/java/org/eclipse/smarthome/io/rest/internal/MDNSAnnouncer.java#L42, this service already supports ConfigurationAdmin settings. So the configuration whether or not it should be Physical Web compliant could be done in here.

But looking at this, I wonder whether we might simply have multiple announcements? Because the entry will actually point to a different url (not the REST endpoint, but to the Classic UI or the Paper UI).
So maybe the MDNSService should simply offer an additional method "registerService(final PhysicalWebServiceDescription description)" and the UIs register an according service. What do you think?

On 2015-06-16 11:31:42 -0400, Yasser Aziza wrote:

Hi,

There is a problem with the android application announcement. After spending some time debugging this, i found that the problem is in the Physical Web implementation, i have opened an issue for this:

google/physical-web#414

I have implemented the fix and i am just waiting for feedback from the Physical Web team.

Nontheless, i will submit my code to the Eclipse SmartHome tonight.

On 2015-06-29 10:15:42 -0400, Markus Rathgeb wrote:

Nontheless, i will submit my code to the Eclipse SmartHome tonight.

Have your code been ever submitted?
Cannot find any PR.

On 2015-06-30 09:22:52 -0400, Kai Kreuzer wrote:

Have your code been ever submitted?

No, it hasn't :-(
Yasser seems to be submerged...

DateTime item-type not displaying consistently in classic UI / PaperUI

created a new binding for NTP in a OH2 way. However, having difficulties displaying the data.

When in the channel-type definition I define the channel with DateTime
and do the update updateState(c.getUID(), new DateTimeType(calendar));
It does not show consistently between the paper-UI and the classic UI.

If there is no description, it displays fine in the paperUI, but it remains empty in the classic UI.
if I add it displays fine in classic UI, but in paperUI it shows {{getStateText(item)}}

Expected behavior is that the paperUI shows the date/time according to the pattern.

Note: transfered from issue openhab/openhab-addons#374
Possibly related to openhab/openhab-addons#229 as this shows the same error in the browser console

SyntaxError: [sprintf] unexpected placeholder
    at Function.b.parse (sprintf.js:151)
    at b (sprintf.js:17)
    at n.$scope.getStateText (controllers.control.js:77)
    at ib.functionCall (angular.min.js:199)
    at Object.<anonymous> (angular.min.js:107)
    at n.$get.n.$digest (angular.min.js:123)
    at n.$get.n.$apply (angular.min.js:126)
    at l (angular.min.js:81)
    at M (angular.min.js:85)
    at XMLHttpRequest.F.onload (angular.min.js:86)

Enable easy use of reverse proxies

migrated from Bugzilla #423506
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2013-12-07 15:55:42 -0500, Kai Kreuzer wrote:

Migrated from https://code.google.com/p/openhab/issues/detail?id=235

Introduce a notification aggregation and dispatching service

migrated from Bugzilla #434010
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2014-05-02 11:23:59 -0400, Kai Kreuzer wrote:

It would be nice to have a notification mechanism that can be used throughout the system and where the user can configure, how he wants to receive the notifications (e.g. as push on a smartphone, SMS, email, etc.). Different notification categories and severities could make use of different channels.
This service should also allow to mark notifications as read or to delete them.

On 2015-04-20 05:42:01 -0400, Greg EVA wrote:

Some other ideas that are seen in commercial products:

Predefined notification destinations and methods depending on time of day, day of week, business/non-business hours, holidays.

• this allows fine grained customization and pertinent notification using users and groups which can then be easily managed (manually or automatically)
• groups such as "On Premise Users" or "On Call Maintenance" can then be used to only notify users who are interested or impacted by something
• Groups could also be used to limit distribution of notifications of things like system errors to the people who would deal with them

The methods to use to notify someone depend on severity, as well as if the other attempts to notify someone have failed or not. A severe error should perhaps be sent first to a smartphone UI, and if it is not acknowledged in a certain time be redispatched to an SMS, and eventually be able to be redispatched to someone else if a particular person is not responding.

There should be a way to "Snooze" a notification/alarm so that it will come back later should.... but here I think I am treading between the subjects of alarms and notifications which are obviously closely related.

On 2015-04-20 16:05:52 -0400, karel goderis wrote:

Kai,

this is very much https://github.com/jpmens/mqttwarn which works well with openHAB, but would deserve an full integration into the core

On 2015-04-21 04:04:25 -0400, Kai Kreuzer wrote:

Thanks for the hint, Karel, this is indeed a good source for inspiration and we can try to more closely integrate it.

On 2015-04-21 04:14:17 -0400, Benjamin Cabé wrote:

CC'ing JP Mens from mqttwarn, who might be interested in the discussion :)

On 2015-04-21 04:20:24 -0400, Jan-Piet Mens wrote:

Interested? Sure, Benjamin. :-)
I think Karel has hit the nail on the head in terms of mqttwarn's capabilities (and thank you, Karel). I'm not sure how much integration this would need in Smarthome core (please note: I don't have a clue of its inner workings), but I know many people are using MQTT extensively (some very successfully with mqttwarn) within current openHab with appropriate MQTT updates.

On 2015-04-21 04:26:05 -0400, karel goderis wrote:

Cfr a post in another thread/place, we could image things like NotificationStrategy (similar to Persistence in fact) that are bound to Items, etc.

I use mqqtwarn as well, but it clutters a bit the Rules as you have to explicitly write code to have things notified. Having this tucked away in the core would be nice

On 2015-04-21 04:32:34 -0400, Kai Kreuzer wrote:

Please also note this related discussion: https://www.eclipse.org/forums/index.php/t/1065848/

I think we should split the "general" notification mechanisms and the "alarm rule" definitions - this issue here is only about the notification mechanisms, where MQTT(warn) would be one "sink".

On 2015-04-21 04:57:01 -0400, Ben Jones wrote:

I am going to chime in here (after getting prodded by JP). I am definitely on board with this and agree it is something we need to get right from the start.

I currently use mqttwarn exclusively for all my notifications. Decoupling notifications from my rules was one of the best things I did in terms of simplifying my solution. Now I just have a series of virtual Notify_Xxx items in openHAB, bound to MQTT topics. So to generate a 'trace' notification I simply add Notify_Trace.postUpdate("message") to a rule.

I have various levels of notification which I use through out my rules. Never once having to directly call any particular notification 'channel'.

Then mqttwarn is configured to route the different notifications (via the MQTT topics) to different channels and end points. This has numerous benefits, one being that if say my Gmail password changes, I only have to update one piece of config, rather than every rule. Likewise if I decide that the wife doesn't need to receive Info messages anymore, it is a one line change to the mqttwarn config. Or I can disable all notifications instantly.

But like Karel - I agree this needs to be 'baked' into openHAB/ESH for it to be widely adopted.

On 2015-04-21 11:17:10 -0400, Greg EVA wrote:

I like and agree with the NotificationStrategies approach, but think that it should be possible to have two (or more) notification types for the same trigger. If I understand the idea properly, this would mean that the notification would be defined separately in two different *.notify files, and this could be troublesome to manage as it is the same notification. The UI could tie these together however.

I agree that this should be tied into the core. Certain notifications may need a response, or at least that the core knows that they were received/read. For example perhaps a notification would continue being sent to many people until someone read or responded to it.

On 2015-04-21 11:48:57 -0400, karel goderis wrote:

It would be like the Persistence feature.

Now, with responses to Events we could be a bridge to far, and a straight channel (e.g. using mqtt binding or other) could be a better solution. If a requirement, you could imagine that the response is given via the REST interface, e.g. make URI available for a given amount of time after the event is generated, but then, you have the problem of enumerating the events with a unique code, which might create compatibility problems with specific event notification channels/sinks

K

On 2015-04-23 03:55:27 -0400, Markus Rathgeb wrote:

Could someone state what kind of messaging is planned and what are the requirements for the different type of messages?

I am using messages as a synonym for different kind of stuff that should be send (not different kind of notification "levels").
Perhaps we need notifications, alarms, a message box, ...
The different kind of message types (notification, alarm, ...) need to suffer different requirements:

• severity / level
• read / unread flag
• persistent stored or could be volatile

So, what topics need to be catch by "this" notification this bug is used for?

On 2015-08-27 14:16:48 -0400, karel goderis wrote:

For all involved, pls see https://www.eclipse.org/forums/index.php/m/1706571/#msg_1706571

I have started an initial implementation based on the above, and inspired by mqttwarn

On 2015-08-29 16:05:10 -0400, Kai Kreuzer wrote:

Karel, I would suggest to keep the further discussion on this issue for the moment.
Before going into prototyping, my feeling is that we need to discuss many more details and design decisions. Once there is a rough design done, I think we should have it summarized in a post like https://www.eclipse.org/forums/index.php?t=msg&th=1066185&goto=1694087&#msg_1694087 or https://www.eclipse.org/forums/index.php?t=msg&th=668424&goto=1266584&#msg_1266584, which summarizes the requirements and shows the suggested design.

I think Markus' questions (https://bugs.eclipse.org/bugs/show_bug.cgi?id=434010#c1) are very good and worthwhie to answer, as he rightly points out that everybody has some different vision and ideas behind the word "notification".

For me personally, I think that a new notification feature should be MUCH more than just an extended/configurable event routing. Read-flags, re-sending, updating, deletion, a context, unique ids, possibly intents (=attached/linked actions) are all mandatory features from my pov. We probably can learn (and copy!) a lot from existing notification frameworks like http://developer.android.com/guide/topics/ui/notifiers/notifications.html.

On 2015-08-30 07:21:59 -0400, karel goderis wrote:

I would first of all look at who or what will be consuming the notifications. Adding all those fields or features to a notification might be interesting, but you will end up with a swiss army knife of which one will only use the tin opener. By that I mean, glansing at the services supported by mqttwarn, there are none that offer this kind of API. So, why would you build that? All these services take simple text messages, and depending on the service, some configuration parameter that is service specific, e.g. not something that can be generalised. Taking the route you propose, you would have to "blow up" Events into a Notification, with all the handling (sequencing, flows etc around it), to then strip all that away back to the original "string" that is compatible with the external notification service. That is a lot of complexity for little or no added value. You would also need to create a whole infrastructure to have a user interact with Notifications, e.g. change how the GUI's behave, introduce things like pop-ups? or dialog boxes and so forth. [Maybe it could be an idea to enhance openhab.ios to support for example push messages, badging and so forth]. Maybe the way forward is the re-evaluate Events, and make these more rich, introduce acknowledgments on the EventBus, etcetera

To me the biggest frustration of all those that are using solutions like MQTT binding+mqttwarn is that it is very hard to get any information out of openHAB/ESH. What you propose might be more interesting or challenging from the point of view of a code developer, but I just want to stay pragmatic and have a simple solution that works literally tomorrow. If you want to call it something else than notification, fine for me. If it has to be refactored into something more meta in the future, then this is fine as well.

Let me finish what I am actually hacking together, then rediscuss around that? I do not have a tool that yanks out OML schema's, so that's another reason to have this Agile-like approach.

On 2015-08-30 16:25:07 -0400, Kai Kreuzer wrote:

there are none that offer this kind of API. So, why would you build that?

Well, the most important use case in my case is exactly THIS API, i.e. notifications within Android (or iOS). So why not look at existing APIs for this, if this is one of the main use cases?

Another consumer are the web-based UIs like Paper UI and Basic UI. They might want to display the "current" notifications, so there must be a way for them to request them.

For all UIs likewise, if I receive a notification for my doorbell, I would like to be able to directly click on it and open a sitemap page with its IP cam - just as one example for a linked action. Furthermore, if I receive a notification that a certain device is not reachable anymore, I would like to have the context (here Thing UID), so that I can directly jump to the admin page of this device to reconfigure it etc.

you would have to "blow up" Events into a Notification

I think this is our misunderstanding. I am talking about notifications as a new concept, you are thinking of enhanced events instead. To me, events and notifications are fundamentally different concepts. Events are fire&forget. Notifications are "something that needs the users attention". A low-battery event it nice in a log file, but as a notification I only want to see it, if the battery hasn't been replaced meanwhile or if I haven't marked it as read on any of my UIs.

What you propose might be more interesting or challenging

It is not just me - from what I understand from the comments, it is also what Greg, Markus, Dennis and others have in mind here. That's why I asked to first align on the requirements.

Please also remember the discussion about the "alarm binding", which is also about managing state of alarms and not merely sending stateless events.

If you want to call it something else than notification, fine for me.

Indeed, maybe what you propose is not related to this issue here at all, but should rather be a kind of clever event-routing.

Let me finish what I am actually hacking together, then rediscuss around that?

Well, this depends of course on you. I just wanted to avoid that you are doing work that needs to be overhauled when discussing the requirements only after you already implemented it.
In this context, please note that I consider the ".persist" files to be 1.x legacy, since they do not fit well into the "manageable through REST/UI approach". It is one of the topics that I would like to modernize after tackling the Things, the rule engine and the sitemaps. So taking the current persistence infrastructure as a blueprint might not be a good idea at all.

On 2015-08-31 02:10:03 -0400, karel goderis wrote:

(In reply to Kai Kreuzer from comment # 15)

Well, the most important use case in my case is exactly THIS API, i.e.
notifications within Android (or iOS). So why not look at existing APIs for
this, if this is one of the main use cases?

I did, but I found this one in particular very much tied to the mobile phone as a platform. I think it is too specific. What I would grab from it are

• needs acknowledgement or not flag
• prioritisation level
• call back mechanism to send ACKs

Another consumer are the web-based UIs like Paper UI and Basic UI. They
might want to display the "current" notifications, so there must be a way
for them to request them.

For all UIs likewise, if I receive a notification for my doorbell, I would
like to be able to directly click on it and open a sitemap page with its IP
cam - just as one example for a linked action. Furthermore, if I receive a
notification that a certain device is not reachable anymore, I would like to
have the context (here Thing UID), so that I can directly jump to the admin
page of this device to reconfigure it etc.

Yep - I have those usecases as well, but I think a lot of time will pass before this is really integrated.

you would have to "blow up" Events into a Notification

I think this is our misunderstanding. I am talking about notifications as a
new concept, you are thinking of enhanced events instead. To me, events and
notifications are fundamentally different concepts. Events are fire&forget.
Notifications are "something that needs the users attention". A low-battery
event it nice in a log file, but as a notification I only want to see it, if
the battery hasn't been replaced meanwhile or if I haven't marked it as read
on any of my UIs.

Ah - I do not agree here. For me, an Event = Notification + {requires acknowledge}=false

Please also remember the discussion about the "alarm binding", which is also
about managing state of alarms and not merely sending stateless events.

Having developed a binding for the UTS ATSAdvanced alarm system I learned a lot about the complexity of alarm systems. It is really really complex stuff, I am not sure that we want that in ESH/OH. If one would opt then to have a kind of common front-end to alarm systems, then IMHO that will be very much limited to something like switch on/switch off.

In this context, please note that I consider the ".persist" files to be 1.x
legacy, since they do not fit well into the "manageable through REST/UI
approach". It is one of the topics that I would like to modernize after
tackling the Things, the rule engine and the sitemaps. So taking the current
persistence infrastructure as a blueprint might not be a good idea at all.

Mhh... that is almost a separate discussion. I presume that before they are tossed out, that a new mechanism to store configuration "state" will have to be implemented right?

K

On 2015-08-31 03:46:46 -0400, Dennis Nobel wrote:

I think we more or less agreed, that the notification concept has two parts:

1. Design and implement a Notification API and storage (maybe taking Android Notification as example)
2. Design and implement a configurable and extensible Notification push mechanism

We can not implement 2) before we implemented 1). So if you only want to dispatch events via some remote channels, it has nothing to do with notifications. Maybe it can be a separate add-on called remote-events.

But the Notification API is definitely a bigger topic and needs some discussions. If you want to implement a fast solution for remote evening, you can do that, but then let´s stop the discussion on this issue, as this is not related to it. Maybe it can be used later to implement 2).

On 2015-09-02 15:34:23 -0400, karel goderis wrote:

I have just created #436 cfr the discussion here below

On 2015-09-04 03:46:21 -0400, karel goderis wrote:

All,

I dunno what you use as UML tool, but since I do not have a professional tool at hand, I installed the Obeo Eclipse plug-in so that schema files can be pushed easily to github. Unless there is another better proposal to move forward, we could use that mechanism to share schema to stimulate the discussion/development?

K

On 2015-09-04 03:56:31 -0400, Dennis Nobel wrote:

I sometimes use https://www.draw.io/ or Google Draw, or just Power Point or plantUML. I don´t think that we need a professional UML tool for designing concepts. It should just help to visualize the ideas and should not be taken as some kind of technical reference.

On 2015-09-05 05:06:39 -0400, Kai Kreuzer wrote:

For diagrams that end up in the ESH documentation, we actually decided to use https://www.draw.io/, so that everybody has the chance to easily update it.

On 2015-09-05 05:28:46 -0400, karel goderis wrote:

I have already redrawn the diagram in draw.io. I will create a new thread on the ESH forum to discuss it

Show channels grouped by their group

When displaying the channels of a Thing, the Paper UI currently shows all channels as a flat list.
Instead, the channel groups should be made visible by grouping the according channels visually as well.

Support more configuration features

At the moment the following configuration features are not yet supported, but the Paper UI should be able to use this information when rendering the configuration pages:

• min
• max
• advanced (hidden by default, shown only by pressing a "more" button)
• groupName (labeled frames that group parameters with the same groupName)
• limitToOptions (best by a free input field with auto-completion feature)

Let's leave the "multiple" stuff out of scope for now.

sitemap fails to display on mobile - generates exception

migrated from Bugzilla #468642
status UNCONFIRMED severity normal in component UI for ---
Reported in version 0.8.0 on platform PC
Assigned to: Project Inbox

On 2015-05-28 10:30:08 -0400, Jim Howard wrote:

Per Kai, this has been moved here. The comment on the move:

This looks like a bug introduced in ESH with eclipse/smarthome# 313

Original ticket and exception follow.

Jim

I have a sitemap that contains:

Frame {
Group item=motion
Group item=battery
Text label=HVAC icon="temperature" {
Setpoint item=HVAC_HeatSetPoint label="Heat setpoint" icon="temperature" minValue=50 maxValue=90 step=1
Setpoint item=HVAC_CoolSetPoint label="Cool setpoint" icon="temperature" minValue=60 maxValue=90 step=1
Selection item=HVAC_Mode label="HVAC mode" icon="temperature" mappings=[0="Off",1="Heating",2="Cooling",3="Auto"]
Text item=HVAC_Temperature
Text item=HVAC_Humidity
Text item=HVAC_Fan_Mode
Text item=HVAC_Operating_State
}

This frame used to generate correctly in habdroid, but in the last couple builds, it does not work, and displays a blank page. With debug enabled in openHAB2, I receive the following exception:

2015-05-25 23:00:29 [WARN ] [lipse.jetty.server.HttpChannel:395 ] - /rest/sitemaps/jim/0202javax.servlet.ServletException: javax.servlet.ServletException: java.util.IllegalFormatConversionException: d != java.lang.String
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:130)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:497)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.servlet.ServletException: java.util.IllegalFormatConversionException: d != java.lang.String
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:421)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:386)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:222)
at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
Caused by: java.util.IllegalFormatConversionException: d != java.lang.String
at java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4045)
at java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:2748)
at java.util.Formatter$FormatSpecifier.print(Formatter.java:2702)
at java.util.Formatter.format(Formatter.java:2488)
at java.util.Formatter.format(Formatter.java:2423)
at java.lang.String.format(String.java:2790)
at org.eclipse.smarthome.core.transform.TransformationHelper.transform(TransformationHelper.java:80)
at org.eclipse.smarthome.io.rest.core.util.BeanMapper.considerTransformation(BeanMapper.java:114)
at org.eclipse.smarthome.io.rest.core.util.BeanMapper.fillProperties(BeanMapper.java:90)
at org.eclipse.smarthome.io.rest.core.util.BeanMapper.mapItemToBean(BeanMapper.java:37)
at org.eclipse.smarthome.io.rest.sitemap.internal.SitemapResource.createWidgetBean(SitemapResource.java:266)

2015-05-25 23:00:29 [WARN ] [lipse.jetty.server.HttpChannel:481 ] - Could not send response error 500: javax.servlet.ServletException: javax.servlet.ServletException: java.util.IllegalFormatConversionException: d != java.lang.String

The frame generates successfully in a web browser.

Thanks
Jim

Introduce an optional unit in Number item

migrated from Bugzilla #434006
status ASSIGNED severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: gael lhopital

On 2014-05-02 11:02:11 -0400, Kai Kreuzer wrote:

To facilitate type determination, value formatting and calculations, an optional unit property should be introduced to number items. This could e.g. make use of Eclipse UOMo.

On 2014-10-16 03:16:42 -0400, Kai Kreuzer wrote:

*** Bug 447299 has been marked as a duplicate of this bug. ***

On 2015-03-19 04:02:29 -0400, gael lhopital wrote:

(In reply to Kai Kreuzer from comment # 0)

To facilitate type determination, value formatting and calculations, an
optional unit property should be introduced to number items. This could e.g.
make use of Eclipse UOMo.

I'm ok to work on this point. I had a first look at UOMo and this introduces a dependency an issue with the package com.ibm.icu (version 1.50 needed while 1.52 is present). On the other hand, I found the JScience package that relies also on JSR-275 spec. Is it possible to choose go with this one in an eclipse project ?

I started my tests by adding a unit member in DecimalType, but wondering what would be the best approach : adding unit capability to DecimalType, subclassing DecimalType to something like MeasureType, or putting unit in NumberItem ?

On 2015-03-20 11:51:17 -0400, Kai Kreuzer wrote:

Gael,

I found the JScience package that relies also on JSR-275 spec. Is it possible to choose go with this one in an eclipse project ?

JSR-275 has never made it to be an official Java-API. Its "living" successor is JSR-363 (https://www.jcp.org/en/jsr/detail?id=363) and we were already in contact with the spec lead about it and filed a CQ for the Eclipse IP team about it. You can find its current reference implementation at https://github.com/unitsofmeasurement/unit-api.
I am not sure though, how it feels from a developer point of view in comparison to JSR-275. From your implementation it seems that JSR-275 is quite straight forward and useful. Could you check if JSR-363 is similar or if it is lacking anything you would expect?

I started my tests by adding a unit member in DecimalType, but wondering what would be the best approach

This indeed needs to be discussed. Originally, I though it could be some kind of optional field in DecimalType, but thinking about it a bit more, this does not seem to be a workable solution.
I pretty much like your suggestion with the MeasureType extending DecimalType - this seems to integrate pretty well with the existing structures.
I have one concern, though: It leaves the unit unspecified for a NumberItem, i.e. an item can receive first a state "1 m" and afterwards "4 V" and it would happily accept this. A solution to this problem is the very recently introduced StateDescription on the Item interface - this could probably the resolution for this problem. We could add a unit information in here. Or would dimension actually be the better choice (to allow cm, m, km as possible states)? I am still a bit undecided here and would welcome your opinion :-)

On 2015-03-20 11:59:58 -0400, Dennis Nobel wrote:

I though it could be some kind of optional field in DecimalType, but thinking about it a bit more, this does not seem to be a workable solution.

Why does it not seem to be a workable solution? What is better with introducing a new type? And for what kind of data is the NumberItem used then? If there is data without a unit (or maybe without a dimension) the unit can be empty or null in the NumberItem.

On 2015-03-20 12:15:42 -0400, Kai Kreuzer wrote:

Ok, this might probably depend on whether we choose JSR-275 or JSR-363.
I was already thinking along JSR-363 - in this case I would not want to split the value and the unit apart, but directly use a Quantity (https://github.com/unitsofmeasurement/unit-api/blob/master/src/main/java/javax/measure/Quantity.java) inside.
Having a subclass would make it more obvious what you are actually holding. Note that we also already have PercentType as a subclass of DecimalType, this is imho a pretty similar situation.

On 2015-03-20 12:33:16 -0400, gael lhopital wrote:

Funny, one of the expert in JSR-363 is the project owner of JScience (Jean-Marie Dautelle). Then I suppose the directions shall not be too different :)

Could you check if JSR-363 is similar or if it is lacking anything you would expect?

I'll do

This indeed needs to be discussed. Originally, I though it could be some kind of
optional field in DecimalType, but thinking about it a bit more, this does not seem to be
a workable solution.

It was my first attempt (to make it an optional field of DecimalType), but this introduces such ugly checks that I preferred to switch to MeasureType

On 2015-03-20 12:49:14 -0400, Kai Kreuzer wrote:

Regarding the naming, I think I would prefer QuantityType over MeasureType - especially in case we go for JSR-363.

On 2015-03-20 12:50:26 -0400, gael lhopital wrote:

You really never like the names I choose for my classes :)

On 2015-03-21 04:29:06 -0400, gael lhopital wrote:

Hello Kai,
I would need a bit of help, I really don't get how/what to add to project in order to have unitsofmeasurement operational in a project. There is so much spec docs everywhere but not concrete exemple on how to use this.

On 2015-03-21 06:19:01 -0400, gael lhopital wrote:

Forget this last comment, I think I got it.

On 2015-03-22 16:33:06 -0400, gael lhopital wrote:

Hello,
A new version of former MeasureType, renamed to QuantityType and now based on unit-api is available here https://github.com/clinique/smarthome/tree/bug434006 for your comments.

The transposition from JSR-275 is quite straitforward as you can see in the test unit. As I switched to quantity, it was not obvious why it should be a subclass of DecimalType, here I choosed to make it distinct.

On 2015-04-15 16:43:16 -0400, Kai Kreuzer wrote:

Sorry for not having answered yet - I just want to let you know that the JSR363 CQ has not yet been approved as there is some discussion with the license. Once this is settled, I will come back on this.

On 2015-04-15 17:42:25 -0400, Werner Keil wrote:

(In reply to Kai Kreuzer from comment # 12)

Sorry for not having answered yet - I just want to let you know that the
JSR363 CQ has not yet been approved as there is some discussion with the
license. Once this is settled, I will come back on this.

Hopefully it won't be necessary, but just to mention it, there's another (approved) CQ for Unit-API 0.6: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5260 I would go for JSR 363 if we all get the go, but technically the intermediary 0.6 API is far closer to 363 than JSR 275 was.

On 2015-04-17 05:43:36 -0400, Werner Keil wrote:

Had a short peek at QuantityType. Looks nice and similar to the idea that occurred to me when I saw the "types" library some while ago.

Even without exposing it in a public method or member (it's already protected though) instead of the RI-specific AbstractQuantity it would be good to treat quantity as Quantity (API/JSR type) instead.

Please note, for portability reasons and IoT support (Java ME) the JSR 363 RI does not support BigDecimal or BigInteger while the Java SE (8) port or UOMo (currently based on Unit-API 0.6, see https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5260) do as they are intended for SE/EE environments. If this is not a problem and individual data items won't exceed Double or Long number values, the RI seems fine, but to be flexible, it would really be good to stick to Unit and Quantity wherever you can.

On 2015-04-17 11:52:45 -0400, gael lhopital wrote:

Can you please point me more specifically on what you mean here :

Even without exposing it in a public method or member (it's already protected >though) instead of the RI-specific AbstractQuantity it would be good to treat >quantity as Quantity (API/JSR type) instead.

On 2015-04-27 09:41:46 -0400, Werner Keil wrote:

Sure, line 40 of QuantityType should be:
protected Quantity quantity; instead of: protected AbstractQuantity quantity;

If you'd merge back any relevant changes from your GitHub fork into either GitHub or Eclipse.org repositories if the changes go live, I'd be happy to check it out when I can, then I may offer a pull-request for this or similar changes.

On 2015-04-28 09:57:18 -0400, gael lhopital wrote:

Modified the code to follow your suggestion regarding AbstractQuantity and BigDecimal.

Do you mean I shall push a PR on ESH right now ? I thought we had to wait for the discussion on this topic to go on.

On 2015-04-28 11:24:09 -0400, Werner Keil wrote:

(In reply to gael lhopital from comment # 17)

Modified the code to follow your suggestion regarding AbstractQuantity and
BigDecimal.

Thanks, good, will have a look.
As long as you're passing or retrieving numeric values mostly via Number (or methods like doubleValue(), etc.) there should be no risk of a BigDecimal overflow.

Do you mean I shall push a PR on ESH right now ? I thought we had to wait
for the discussion on this topic to go on.

No I thought if I added a PR to your fork you may merge that.
http://dev.eclipse.org/ipzilla/show_bug.cgi?id=9154 states, it's up to the project (SmartHome) If you're in touch with Kai or other team members, feel free to ask them what their status is or if they have some internal clarification. Eclipse Legal and PMC all gave their "go";-)

On 2015-04-28 11:28:30 -0400, Kai Kreuzer wrote:

Werner, where do you read that Eclipse Legal is fine with it? Afaik, the CQ in question is https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9208 and there is no approval yet from the IP team, so I cannot do any further steps, I'm afraid.

On 2015-04-28 12:09:22 -0400, Werner Keil wrote:

(In reply to Kai Kreuzer from comment # 19)

Werner, where do you read that Eclipse Legal is fine with it? Afaik, the CQ
in question is https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9208 and
there is no approval yet from the IP team, so I cannot do any further steps,
I'm afraid.

But https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9154 says "Waiting for Project" (In reply to Kai Kreuzer from comment # 19)

Werner, where do you read that Eclipse Legal is fine with it? Afaik, the CQ
in question is https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9208 and
there is no approval yet from the IP team, so I cannot do any further steps,
I'm afraid.

The actual Orbit CQ clearly says

Approving for Orbit, subject to the projects approval.
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9154

I asked and was told, "project" here means those that would like to to use it, AKA SmartHome.

So since the actual Orbit CQ has been approved by Eclipse PMC, looks like there's an action item for you, on either or both of them (please ask Sharon or PMC members which, I also am not sure) Although one project is usually enough to justify adding to Orbit, I may file a similar request for UOMo referring to https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9154. However, all projects that are interested should approve their tickets´.

On 2015-04-28 14:43:59 -0400, Kai Kreuzer wrote:

I asked and was told, "project" here means those that would like to to use it, AKA SmartHome.

Right, and this is what Orbit probably usually does: They rely on the fact that a project CQ has been thoroughly checked and approved and then it is easy to add it to Orbit. But this does not mean that there is no approval for the project CQ necessary anymore. So let's see what Sharon will answer.

On 2015-07-02 03:45:55 -0400, gael lhopital wrote:

Hi all,

Any chance to move further on this topic ?

On 2015-07-09 06:09:38 -0400, Kai Kreuzer wrote:

Unfortunately, there is still no decision from the Eclipse IP team :-|
I will follow up on this, it is really time... Thanks for your patience.

On 2015-08-17 15:36:01 -0400, Werner Keil wrote:

I'm afraid, Eclipse IP team refuses to use JSR 363 due to a misunderstanding of the JCP Spec License that applies to a whole lot of JSRs already in Orbit. Most significantly JSR 275 (which was added to Orbit under the wrong assumption it was BSD licensed, but it isn't)

The only recommendation I can safely make is use Unit-API 0.6 like UOMo does, see https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5260

That is sound because it was done outside the JCP and not JCP Spec License applies here. The API is frozen but more supportable than the "dead" and rejected 275, so it would be a safe bet and do everything the JSR 275 or 363 API also do.

HTH,
Werner

On 2015-08-17 19:27:33 -0400, Werner Keil wrote:

From looking at the "NumberUnit" branch, it seems, that actually uses JSR 275.
Judging from https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7583 (which I had to correct since the license assumption was simply wrong, the relevant versions of JSR 275 between 0.9.3 and 0.9.5 all share the same non-final Spec License you may know from JSR 363) the IP team's assumption won't make JSR 275 advisable to use either.

Especially in the OSGi context of SmartHome, using Unit-API 0.6 and an implementation like UOMo could be best. It seems, ICU4J is also used by other parts of SmartHome, which (with~10MB) is the only significant dependency UOMo also uses under the hood. The actual UOMo bundles themselves are under 600 kb together. And the API JAR less than 50kb.

How does that sound?

On 2015-08-18 20:19:58 -0400, gael lhopital wrote:

As said higher, using UOMU v0.6 introduces a dependency issue :

I'm ok to work on this point. I had a first look at UOMo and this introduces a >dependency an issue with the package com.ibm.icu (version 1.50 needed while 1.52 >is present).

Any idea on how to workaround ?

On 2015-08-19 13:31:17 -0400, Werner Keil wrote:

Will have a look. In parallel we try to see, if a little to non invasive license presentation might work. Fortunately JSR 363 is still in progress, so before it's final we can make such changes more easily than others with an exact similar license file in place (e.g. JSR 107)

On 2015-08-20 04:54:52 -0400, gael lhopital wrote:

Thanks.
I've got some issues with this version of UOMo :

• I workarounded for ICU in adding correct version in a lib folder in org.eclipse.smarthome.core but it adds 9.2 Mb of jar
• The documentation of UOMo v0.6 is not in phase at all with sources, then implementation is really tedious
• Not much sources of information, examples...

On 2015-08-21 05:06:26 -0400, gael lhopital wrote:

Hello,

I finally managed to have a working version with UOMo, for your review here :
https://github.com/clinique/smarthome/tree/bug434006_UOMo

The point is still the ICU library, that I didn't found how to avoid including in
the bundle.

postUpdate/sendCommand not synchronous in Rules

migrated from Bugzilla #478435
status UNCONFIRMED severity normal in component DSL for ---
Reported in version 0.8.0 on platform PC
Assigned to: Project Inbox

On 2015-09-25 12:47:15 -0400, karel goderis wrote:

With the following simple rule, and with the Item TeslaScheduledDeparture holding a valid value (e.g. not NULL or UNDEF):

rule "Tesla - initiate variables rule"
when
System started
then
TeslaScheduledDeparture.postUpdate(UnDefType.UNDEF)
logInfo("org.openhab","System Started : TeslaScheduledDeparture "+TeslaScheduledDeparture.state)
end

the following is written to the logs:

2015-09-25 18:40:12 [DEBUG] [.m.r.r.i.engine.RuleEngineImpl:267 ] - Executing startup rule 'Tesla - initiate variables rule'
2015-09-25 18:40:14 [INFO ] [o.e.s.model.script.org.openhab:48 ] - System Started : TeslaScheduledDeparture 2015-09-26T08:30:00

Does this async behaviour stem from the introduction of the safeCall()s?

This is imho undesired behaviour, and leads to adverse effects in Rules. The workaround is to copy over Item.state(s) to locally defined variables at the beginning of each, to do the necessary processing, and at the exit of a rule, write back/postUpdate() any values to the Item.state(s)

Therefore, should lock()s be introduced on the ItemRegistry?

On 2015-09-26 03:40:32 -0400, Dennis Nobel wrote:

Does this async behaviour stem from the introduction of the safeCall()s?

No, the safeCalls are executed synchronously. Only if a call takes longer than 10 seconds, the thread will continue to work.

It´s because a postUpdate is by definition asynchronously. The whole eventing system only allows asynchronous events.

On 2015-09-26 04:34:11 -0400, karel goderis wrote:

mhh... do you think this would not lead to problems then? like, you are never sure to have the latest value of an Item when you call .state

Is there a recommended approach then for Rules?

Karel

On 2015-09-26 05:52:39 -0400, Dennis Nobel wrote:

It depends. Do you really want to query the state of an item directly after you have updated it in a rule? If you sent a command you either don´t know how long it will take before the binding changes the state. The behavior - independent from the eventing system - is just asynchronously.

What is your concrete use case?

If you want to get informed that a value was changed you can use the newly introduced ItemStateChangedEvent. This event is sent AFTER an item state was updated.

On 2015-09-26 05:59:06 -0400, karel goderis wrote:

I understand, but in this case the binding is not the limiting factor. it also happens with Items that are not bound to a binding.

ItemStateChangedEvent is not yet exposed to the ScriptEngine right?

K

On 2015-09-26 06:08:40 -0400, Dennis Nobel wrote:

No it´s not. But I think we don´t need it there, as the Rule engine already has something like "Item MyItem changed" as a trigger. Even if the state of an Item might not be changed at this time, I think usually there is no problem, because you just work with the value from the update event inside the rule.

On 2015-09-26 07:19:08 -0400, karel goderis wrote:

Ah - that I am afraid does not hold true. At least in my case - you do not only need the value that has effectively changed, but also the latest value of all the there Items, either in or out "Item changed" clauses.

You either have to build very long complex Rules, with a trigger for every possible variable/Item you need in the rule, or you make a bunch of rules that are less complex, acting on a single Item. In such a constellation, if you update the value of an Item in Rule A, you do need that exact value maybe in Rule B.

I can tell you from the use case I have here (automatic charging and pre-heating rules for my Tesla), that these "glitches" are very annoying and troublesome. And that is only relatively simple use case imho

Karel

Date / Time handling

migrated from Bugzilla #479362
status NEW severity enhancement in component Core for ---
Reported in version 0.8.0 on platform All
Assigned to: Project Inbox

On 2015-10-08 13:25:03 -0400, Markus Rathgeb wrote:

I would like to remove some warnings and realized that the FilterCriteria (and so some tests) of core.persistence is using the Date object.

If there is no reason we have to use that, I would like (if there is some time) to move form Date to another class.

Using Date without a Time does not allow set a begin and end time.
So, moving to a calendar object should allow an better filtering, too.

How does the persistence / the whole ESH framework handle time references?
Are all time references handled in UTC or in local time (e.g. using a begin / end mark, an expression in the rules, ...)?

If the local time is used do you see any problems if I use a UI on a system that using a different timezone as the system running ESH?

On 2015-10-25 01:42:01 -0400, Kai Kreuzer wrote:

Yes, currently the assumption is always "local time of runtime".

If the local time is used do you see any problems if I use a UI on a system that using a different timezone as the system running ESH?

Well, the UI would show the time of the runtime (e.g. my charts look the same from whereever I am). They won't tell me the sun is shining at midnight, just because I (and the UI) am on the other side of the earth.

But in general, I am also fine with moving to Calendar.

On 2015-10-25 05:47:24 -0400, Markus Rathgeb wrote:

• I would expect that the time (stored in the persistence) is an always increasing value
• We have to ensure, that it is stored with all informations.
• DST flag (handle transitions from 2:59 DST to 2:00 non-DST)
• Timezone (handle changes of time zone correctly)
• How to handle a decreasing time?

For the last point I used a monotonic timestamp and a offset in the past.
But I do not know, what we need to solve / grant at all?

If there is a method to get data points between a range, IMHO we must ensure, that the time is increasing only (could be solved with the offset, but perhaps we could state, that this case is out of scope of the framework and must be granted by the system).

On 2015-10-26 20:46:31 -0400, Kai Kreuzer wrote:

Doesn't "milliseconds since 1.1.1970" (i.e. the Date class) fulfill all your requirements, assuming that the runtime does not move and stays during its lifetime in the same time zone?

Add support for properties on ItemChannelLinks

migrated from Bugzilla #456213
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2014-12-27 03:59:13 -0500, Gerhard Riegler wrote:

A item should have item properties. Let's say a DateTime channel is bound to two items, but for the second item the user wants a item specific offset from the channel DateTime value. This implies, that there should be a possibility to update the state item specific too or, maybe the better way, a callback method in the ThingHandler for each item which is updated with the item properties to have a chance to manipulate the state before it is published to the bus.

On 2014-12-27 15:49:53 -0500, Kai Kreuzer wrote:

Not the item should have these properties, but the ItemChannelLink (since the configuration can be specific for each channel an item is linked to).

createTimer: Failed to schedule code for execution.org.quartz.ObjectAlreadyExistsException: Unable to store Job

migrated from Bugzilla #478495
status UNCONFIRMED severity normal in component DSL for ---
Reported in version 0.8.0 on platform PC
Assigned to: Project Inbox

On 2015-09-27 15:16:48 -0400, karel goderis wrote:

At line https://github.com/eclipse/smarthome/blob/master/bundles/model/org.eclipse.smarthome.model.script/src/org/eclipse/smarthome/model/script/actions/ScriptExecution.java#L94

a check should be added to check whether a Job with the same identity exists in the scheduler, and if so, remove the existing job before trying to schedule the new job

This problem occurs for when editing & saving a .rules that depends on createTimer[], e.g. that has actively scheduled jobs in the scheduler. When the rule starts again, possibly new jobs with exactly the same name are attempted to be scheduled

Alternative solution is to change the identity of the job and add a unique element to namen, like the current system time in milliseconds, but then the old job is still kept in place.

Adding Channels without Channel type definition on xml

migrated from Bugzilla #472280
status UNCONFIRMED severity normal in component Core for ---
Reported in version 0.8.0 on platform PC
Assigned to: Project Inbox

On 2015-07-09 08:08:25 -0400, Jayaraj Esvar wrote:

Hi,
You can't add channels dynamically to a thing . Without pre-defining or mapping channels to channelType definitions in the XML file.

 In class ThingSetupManager , addThing()
      this.thingTypeRegistry.getChannelType(channel.getUID()); is not getting populated without definitions of channels for Thing-Type in XML file

 For devices which we don't know the thing structure before we discover, how do we add channels and it expects static channel ids defined before.

           <channels>
      <channel id="0" typeId="switch-channel" /> <--- here this id part should be created dynamically. 
  </channels>

For creating channels dynamically there should be provisions to provide channel definitions. It should only check for channel - itemType, take category input too.

thanks & regards,
jayaraj

On 2015-07-15 11:10:59 -0400, Kai Kreuzer wrote:

Agreed, we need to provide some better mechanisms for adding channels dynamically. I am not sure though, if we can completely dismiss the channel types for this.

Please see my suggestion at https://www.eclipse.org/forums/index.php?t=msg&th=1065857&goto=1701766&#msg_1701766

Mapview rendering in Classic UI not 100% correct

migrated from Bugzilla #469244
status UNCONFIRMED severity normal in component UI for ---
Reported in version 0.8.0 on platform PC
Assigned to: Project Inbox

On 2015-06-03 05:20:37 -0400, karel goderis wrote:

On the classic UI, the generated MapView widget in a sitemap seems to be 2-3 pixels wider left and right than the frame where it embodied into, and the frame label text is rendered is a smaller font than the other items

Function is not stored with GroupItem

migrated from Bugzilla #477357
status UNCONFIRMED severity major in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2015-09-14 08:24:25 -0400, Smart Home wrote:

The function of GroupItem is not persisted. See more details at the discussion: https://www.eclipse.org/forums/index.php/t/1070256/

Version bumps / releases

migrated from Bugzilla #478597
status UNCONFIRMED severity normal in component Infrastructure for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2015-09-29 04:06:10 -0400, Markus Rathgeb wrote:

Eclipse SmartHome is a framework to build end user solutions on top.

If an "end user" would like to use that framework an do a release of his software, the software should not depend on a SNAPSHOT at all.

The ESH framework themselves is not bound (AFAIK) to any consumer release cycles and this is IMHO fine.

But I think it would be fine if we could produce releases from time to time so it could used as a reference for custom products.
I cannot depend on 0.8-SNAPSHOT all the time.

I do not mean a 1.0 stable framework release without API breaks anymore...
I just want to use a fixed reference in my sources.

Using custom repositories are possible, but this mean for every reference a new repository. That is not good.

If the process for a release is a long task for Eclipse products, I will ask, if we could bump the snapshot version from time to time without a official release.
So building a release could build by the consumers.

I cannot build a 0.8.0, 0.8.1, ... release myself if Eclipse releases an official 0.8[.0] some time.

On 2015-09-29 04:39:35 -0400, Kai Kreuzer wrote:

I agree that fixed releases would definitely help to have a reliable way to reference a specific code base from within a solution.

Note that I am currently preparing the 0.8.0 release, see https://projects.eclipse.org/projects/iot.smarthome/releases/0.8.0/

But creating such minor releases is some work; I would not expect more than 2-3 each year.

Nonetheless, we could maybe check if we do more regular service releases, which should be a bit simpler (but still means work).
We will have to check how much this can be automated (update version in sources, have documentation generated and published, adapt the build plans and download locations etc.)

On 2015-09-29 04:55:04 -0400, Kai Kreuzer wrote:

Probably a better option than regular service releases might be to create milestones, e.g. 0.9.0M1, 0.9.0M2 etc. This seems to be possible without following the release process and it I think we also would not need to publish documentation on the website for such milestones.

On 2015-09-29 07:38:43 -0400, Markus Rathgeb wrote:

Probably a better option than regular service releases might be to create
milestones, e.g. 0.9.0M1, 0.9.0M2 etc. This seems to be possible without
following the release process and it I think we also would not need to
publish documentation on the website for such milestones.

That would be enough. I just want fixed states we could point to. If this are alphas, betas, release candidates, milestones, releases, ... does not matter for me.
As long as it is fixed for a specific code base.

If the qualifier (M) is chosen correctly, Maven should handle this correctly, too.
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN400

On 2015-11-03 12:50:36 -0500, Markus Rathgeb wrote:

I started doing it for myself:
https://github.com/maggu2810/smarthome/commit/SHA: 04f8c94

But is there something we can do to get a solution upstream?

Documentation about I18N is broken

The documentation page about i18n is broken. Jekyll generated output is not correct. https://www.eclipse.org/smarthome/documentation/features/internationalization.html

Possibility to manage active timers created using createTimer command

migrated from Bugzilla #436937
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2014-06-08 17:27:02 -0400, Grzegorz Wo�oszyn wrote:

Hello,

my request is related to question which I've asked on openHab google groups:

https://groups.google.com/forum/#!topic/openhab/W4TGxpbByxc

and it is:

"...is there any possibility to list created timers (created using createTimer)? I'm using irrigation rule example from:

https://code.google.com/p/openhab-samples/wiki/Rules#Irrigation_controller

and I'm wondering if making changes to this rule can create multiple timers. IMHO since timer creation occurs only at midnight and not every time rule is being saved but I had some issue with multiple sprinklers running in the same time so I've started wondering about created by this rule timers.
..."

I've got one response from person which suggested that this is not currently possible but it looks like nice feature request so I'm requesting for it here :)

Can you consider enhancing openHab with this functionality?

Thanks

On 2014-06-11 03:44:08 -0400, Kai Kreuzer wrote:

My suggestion is to add new console commands to the core.scheduler bundle, which allows managing (listing/deleting) scheduled jobs through Quartz.

On 2014-06-11 04:00:45 -0400, Grzegorz Wo�oszyn wrote:

(In reply to Kai Kreuzer from comment # 1)

My suggestion is to add new console commands to the core.scheduler bundle,
which allows managing (listing/deleting) scheduled jobs through Quartz.

I'm wondering when we can get some info about openhab <-> smarthome? I'm just wondering if this will be added only to smarthome or maybe to openhab too and how smarthome will replace openhab (I'm waiting for your blog post about it).

On 2014-06-11 04:04:30 -0400, Kai Kreuzer wrote:

I am planning a blogpost on June 16 to clarify these things.

On 2014-06-11 04:06:27 -0400, Grzegorz Wo�oszyn wrote:

(In reply to Kai Kreuzer from comment # 3)

I am planning a blogpost on June 16 to clarify these things.

Ok. Thanks

On 2014-06-29 14:52:59 -0400, Kai Kreuzer wrote:

Just in case you missed it: http://kaikreuzer.blogspot.de/2014/06/openhab-20-and-eclipse-smarthome.html

On 2014-06-30 01:09:05 -0400, Grzegorz Wo�oszyn wrote:

(In reply to Kai Kreuzer from comment # 5)

Just in case you missed it:
http://kaikreuzer.blogspot.de/2014/06/openhab-20-and-eclipse-smarthome.html

Nope. I didn't missed that :). Now I'm waiting to see how things will continue with existing bindings. I saw that there have been added some backward compatibility to 2.0 but I don't see anywhere in google groups anyone talking about 2.0 version. IMHO there should be created dedicated forum for openHAB/smarthome where everything is more categorised.

On 2014-06-30 05:06:22 -0400, Kai Kreuzer wrote:

Well, I'll start talking as soon as things are really ready to be used (and implemented against) - for the moment openHAB 1.x is the main development branch and I don't want to cause confusion by talking too much about 2.0, which is not ready yet.

On 2015-04-09 01:05:58 -0400, Grzegorz Wo�oszyn wrote:

Hello,

is there any change here? IMHO this is quite interesting and helpfull feature.

Thanks

On 2015-04-10 16:28:15 -0400, Kai Kreuzer wrote:

No, sorry, there hasn't been any progress on this yet.

On 2015-09-27 15:19:20 -0400, karel goderis wrote:

The original problem encountered by Grzegorz potentially relates to https://bugs.eclipse.org/bugs/show_bug.cgi?id=478495

Get all members including group items

migrated from Bugzilla #465201
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2015-04-22 10:11:04 -0400, Smart Home wrote:

Currently getAllMembers() returns all members of group item excluding group items.
Can it be extended (new function?) to support returning all memebers including group items?

On 2015-04-27 09:09:45 -0400, Dennis Nobel wrote:

We can not change the existing method because of backward-compatibility, but we can introduce another method. Do you need in in the Java API or would the REST API be sufficient?

On 2015-04-28 15:29:29 -0400, Smart Home wrote:

I need it in the Java API as rest API is not supported with my application.

Do you plan to add something like predicates in the future?

On 2015-04-28 16:14:18 -0400, Dennis Nobel wrote:

I think this is related to the discussion in the forum: https://www.eclipse.org/forums/index.php/m/1692318/?srch=guava#msg_1692318 ?

I think the concept of predicates can be supported, but we need to decide wether we want to have Guava dependencies or we want to define our own interfaces.

On 2015-04-28 16:30:02 -0400, Smart Home wrote:

Maybe we can start by defining the same interface Guava have for predicates and in the future replace it if Guava will be used.

Starting using predicates now will save the need to add different functions of filtering and will be easy to replace by official predicates in the future.

On 2015-04-29 12:35:42 -0400, Dennis Nobel wrote:

Maybe we can start by defining the same interface Guava have for predicates and in the future replace it if Guava will be used.

This would break the API, if we later change to Guava.

Guava is already used in the internal implementation of Eclipse SmartHome, but it is not yet part of the API. As we tend to have a clean API without dependencies to third party libs, we should better define our own interface and see how it can be combined with Guava.

Make resolution of charts configurable in UI

migrated from Bugzilla #424868
status REOPENED severity normal in component Core for ---
Reported in version unspecified on platform All
Assigned to: Chris Jackson

On 2014-01-03 16:01:36 -0500, Thorsten Gilfert wrote:

It would he nice to be able to configure the height and width of the rendered chart images. The ChartServlet already contains support for height and width parameters.

On 2014-03-18 11:42:58 -0400, Kai Kreuzer wrote:

Hi Thorsten,
Sorry to reply only so late on this issue.
I think the required size of the images highly depends on the client - the same chart in a sitemap can be rendered in different resolutions for a smartphone, a tablet or a PC - so it is up the the UI to send these parameters, hence I would not want to include them in the sitemap.

On 2015-09-16 11:06:32 -0400, Kai Kreuzer wrote:

When closing this issue, I was under the false impression that it is about adding width and height parameters to the sitemap chart widgets.

I now just noticed that Chris had implemented this for openHAB1 to allow default sizes through the Config Admin: openhab/openhab1-addons@SHA: 2bcc99b

This change has never made it to ESH :-|

@chris, might I ask you to port it over?

Expanded group in site map / same page rendering of group members

migrated from Bugzilla #423533
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2013-12-08 09:47:51 -0500, Kai Kreuzer wrote:

Migrated from https://code.google.com/p/openhab/issues/detail?id=463

On 2015-06-18 06:51:09 -0400, Eclipse Genie wrote:

GitHub Pull Request 347 created by [clinique]
#347

Introduce a ChannelTypeRegistry

migrated from Bugzilla #476807
status ASSIGNED severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Dennis Nobel

On 2015-09-07 11:41:41 -0400, Dennis Nobel wrote:

A ChannelTypeRegistry must be introduced, which holds a list of ChannelTypes similar to the ThingTypeRegistry or the ConfigDescriptionRegistry. At the moment all ChannelTypes are part of the ThingTypes, which makes it hard to reuse them, especially in combination with ChannelTypes defined in XML and dynamic Thing Types.

See also https://www.eclipse.org/forums/index.php?t=msg&th=1065857&goto=1701766&#msg_1701766

Add GroupItemStateChangeEvent

migrated from Bugzilla #481716
status NEW severity normal in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2015-11-09 09:17:54 -0500, Kai Kreuzer wrote:

The GroupItem itself listens on state changes of its members (in GroupItem.stateChanged()) and recalculates its own state. It does NOT send a a change event for itself though, but only informs all StateChangeListener about it. The old (current) rule engine actually registers as such a StateChangeListener and thus is able to react on Group items even though there is no event.

It would be nicer if the Group Item publishes a change event as well - it then actually also has the chance to name the item that caused the state change of the group (which is a very regular feature request).

Introduce concepts for locations and persons

migrated from Bugzilla #443908
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2014-09-12 04:45:51 -0400, Kai Kreuzer wrote:

To better support use cases like geo-fencing, iBeacons / BLE tags, wearables and rules with user-context, we need to introduce new concepts for locations and persons.
There were already discussions around this in the past, e.g. https://www.eclipse.org/forums/index.php/t/781501/ or https://bugs.eclipse.org/bugs/show_bug.cgi?id=423550

PaperUI should support HTML tags for config descriptions/labels

As discussed here https://www.eclipse.org/forums/index.php/t/1068570/ UIs should support a minimum set of HTML tags to allow markup of config descriptions

Error state is sent when deleting a thing

migrated from Bugzilla #473674
status UNCONFIRMED severity normal in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2015-07-27 12:18:30 -0400, Chris Jackson wrote:

When deleting a thing, the UNITIALIZED state with HANDLER_MISSING_ERROR is sent. It seems that this probably should be suppressed.

{"topic":"smarthome/things/zwave:fibarosystem_fgs221_00_000:14e7e5d0c84:node8/status","payload":"{"status":"REMOVING","statusDetail":"NONE"}","type":"ThingStatusInfoEvent"}

{"topic":"smarthome/things/zwave:fibarosystem_fgs221_00_000:14e7e5d0c84:node8/status","payload":"{"status":"REMOVED","statusDetail":"NONE"}","type":"ThingStatusInfoEvent"}

{"topic":"smarthome/things/zwave:fibarosystem_fgs221_00_000:14e7e5d0c84:node8/status","payload":"{"status":"UNINITIALIZED","statusDetail":"HANDLER_MISSING_ERROR"}","type":"ThingStatusInfoEvent"}

PointType, or DecimalType, (or BigDecimal) do not test for empty strings

migrated from Bugzilla #467612
status NEW severity normal in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2015-05-19 14:58:46 -0400, karel goderis wrote:

Feeding an "" string to either parameter in

public PointType(StringType latitude, StringType longitude, StringType altitude) {
    this(new DecimalType(latitude.toString()), new DecimalType(longitude.toString()), new DecimalType(
            altitude.toString()));
}

throws a NumberFormatException on line 545 of java.math.BigDecimal

IMO the ESH core should test for empty variables, and initialize to a default value, for example 0 inc case of DecimalType. Shortcut is for example to initialize with PointType("0","0","0")

On 2015-05-20 09:04:57 -0400, Kai Kreuzer wrote:

My personal opinion is that it is terrible to have string-based constructors at all. Couldn't we just offer constructors that accept Numbers?

On 2015-05-20 09:09:55 -0400, Kai Kreuzer wrote:

The normal way to use it should be
PointType(52.52,13.38,36.1)

The only reason for strings might be to support degree formatting, i.e. instead
PointType("52° 31' 7.05'' N", "13° 22' 34.30'' E", 36.1)

On 2015-05-20 09:16:14 -0400, karel goderis wrote:

Ok, but what do you do if you are not able to provide the three parameters at the same time? In the case of the Tesla binding longitude etc are reported sequentially by the car, and on top, "0" is also a valid value.

On 2015-05-20 09:19:44 -0400, Markus Rathgeb wrote:

In general (without knowing your special use case), I prefer not using a valid value for an unknown value.

On 2015-07-03 08:55:46 -0400, gael lhopital wrote:

I submit these thoughts to yours :

master...clinique:bug467612

An approach to handle NaN at DecimalType level.
Didn't sort out how to handle it for intValue() and longValue()

On 2015-07-06 06:05:54 -0400, Kai Kreuzer wrote:

Ok, but what do you do if you are not able to provide the three parameters at the same time?

Not instantiating a type at all, because the content is simply not complete.

An approach to handle NaN at DecimalType level.

Why not throw an IllegalArgumentException if a there is a NumberFormatException? Why pretend everything is fine and silently use null internally?

On 2015-07-07 10:30:45 -0400, gael lhopital wrote:

(In reply to Kai Kreuzer from comment # 6)

Ok, but what do you do if you are not able to provide the three parameters at the same time?

Not instantiating a type at all, because the content is simply not complete.

An approach to handle NaN at DecimalType level.

Why not throw an IllegalArgumentException if a there is a
NumberFormatException? Why pretend everything is fine and silently use null
internally?

NaN was an option, but it clearly reaches its limits with intValue() and longValue(). Then I will dig the Exception approach.

On 2015-07-07 11:23:51 -0400, gael lhopital wrote:

...and raising an exception was the default behaviour - then what is the option ?

On 2015-07-08 03:21:13 -0400, Kai Kreuzer wrote:

Which option?

On 2015-07-14 06:36:03 -0400, gael lhopital wrote:

Updated the proposal made here master...clinique:bug467612

in order to raise an IllegalArgumentException in DecimalType when the argument is wrong and also to clarify the fact that string argument passed to PointType must be in Degree Minute Second format, decimal degree must be passed to constructor as DecimalType.

Your thoughts ?

I mess a bit in determining wether arguments transferred to constructor must be String or StringType, DecimalType or BigDecimal... Can someone help me clarify this ?

On 2015-07-16 06:12:05 -0400, Kai Kreuzer wrote:

Hm, in general I would suggest to align it with the HSBType, i.e.

1. There is one constructor that takes the "raw" constituants (i.e. 2 or 3 DecimalTypes im this case)
2. There is another constructor that takes ONE String parameter, where the string is expected to be in the format that toString() returns.

I'd therefore expect it to still be PointType("48.8566140,2.3522219") and not PointType("N48° 51' 23.81", E2° 21' 7.999"").

On 2015-07-16 07:34:03 -0400, gael lhopital wrote:

Ok, then I cleanup constructors, assuming that input are always and only decimal degrees and drop the option of inputing DMS format. right ?

On 2015-07-16 07:34:28 -0400, Kai Kreuzer wrote:

Would be my suggestion, yes.

On 2015-07-16 10:47:37 -0400, gael lhopital wrote:

Ok, then modified the code sample in this direction. If agreed, I'll then make a PR

On 2015-07-17 03:25:32 -0400, Kai Kreuzer wrote:

Thanks, look pretty good to me.

@karel, as you entered the issue, are you as well fine with the solution?

On 2015-07-20 08:19:59 -0400, Markus Rathgeb wrote:

Just a question:

1. There is another constructor that takes ONE String parameter, where the string is expected to be in the format that toString() returns.

I'd therefore expect it to still be PointType("48.8566140,2.3522219") and not PointType("N48° 51' 23.81", E2° 21' 7.999"").

In respect to # 434006 do we need to support different string representations for the same value? Are there already some thoughts about the toString and the creation from string using different units that codes the same value?

On 2015-07-20 08:32:14 -0400, Kai Kreuzer wrote:

In general I would say, the String constructor should be able to parse any string that the class can potentially create through its toString() method. Whether two values with different string values can be considered to be equal of not is probably something to delegate to the equals() method.

BaseThingHandler.thingUpdated has no copy of the old thing

migrated from Bugzilla #468613
status NEW severity normal in component Core for ---
Reported in version 0.8.0 on platform PC
Assigned to: Project Inbox

On 2015-05-28 07:44:00 -0400, Andre Fuechsel wrote:

The class member thing of the BaseThingHandler does not contain the old configuration before thingUpdated was called. The argument thing of this method is actually a reference to the same object that has already set the new configuration.

Suggested solution: the argument thing should be a COPY of the old thing with the new configuration so the class member thing still would contain the old configuration and thingUpdated implementations could easily compare the old with the new configuration to see, what's changed.

On 2015-05-28 10:07:24 -0400, karel goderis wrote:

Or you can keep as is, and it is up to the ThingHandler to store a local copy of the old configuration?

On 2015-05-29 02:45:13 -0400, Andre Fuechsel wrote:

Yes, but storing a copy of the old config by myself looks like a workaround for we.

On 2015-06-01 04:52:12 -0400, Dennis Nobel wrote:

I agree with Andre, especially the original thing reference should not be changed, before thingUpdated is called. There is something wrong with the handling of entities in the Core.

Add filtering/pruning configuration for persistence services

migrated from Bugzilla #423508
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2013-12-07 15:59:19 -0500, Kai Kreuzer wrote:

Migrated from https://code.google.com/p/openhab/issues/detail?id=251

DateTimeType isn't thread safe (see OH1 #2945)

migrated from Bugzilla #475975
status NEW severity normal in component Core for ---
Reported in version 0.8.0 on platform All
Assigned to: Project Inbox

On 2015-08-26 18:06:04 -0400, Thomas Eichstädt-Engelen wrote:

DateTimeType uses a public static SimpleDateFormatter meaning that this class isn't thread safe.

The formatter is used in lots of places in DateTimeType it is also public allowing anyone access (making this a little difficult to fix as it could be used in rules).

Proper fix would be to make these formats private and then provide formatting methods or a method to get a formatter that returns a new one each time.

An easy fix just for the DateTimeType object would be to use a synchronized internal SimpleDateFormatter internally in DateTimeType then at least this would be safe. There would still be a risk in rules using the public formatters.

A solution for OH1 has been provided by openhab/openhab1-addons#2962 which has to be ported as well to ESH.

On 2015-08-26 18:11:40 -0400, Benjamin Cabé wrote:

*** Bug 475976 has been marked as a duplicate of this bug. ***

On 2015-08-26 18:32:55 -0400, Thomas Eichstädt-Engelen wrote:

thanks for the cleanup Benjamin!

NPE in Wemo Discovery Service

Just found the following while happily browsing my log files:

2015-12-03T13:24:34.578+0100   313  ERROR          [symbolicName=org.eclipse.smarthome.binding.wemo, className=org.eclipse.smarthome.binding.wemo.discovery.WemoDiscoveryService] - Could not send Wemo device discovery
java.lang.NullPointerException
    at org.eclipse.smarthome.binding.wemo.discovery.WemoDiscoveryService.sendWemoDiscoveryMessage(WemoDiscoveryService.java:164)
    at org.eclipse.smarthome.binding.wemo.discovery.WemoDiscoveryService.discoverWemo(WemoDiscoveryService.java:124)
    at org.eclipse.smarthome.binding.wemo.discovery.WemoDiscoveryService.access$0(WemoDiscoveryService.java:122)
    at org.eclipse.smarthome.binding.wemo.discovery.WemoDiscoveryService$1.run(WemoDiscoveryService.java:86)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

Allow a newly discovered thing to be marked as temporary / unable to approve

migrated from Bugzilla #472442
status NEW severity normal in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2015-07-12 07:02:43 -0400, Chris Jackson wrote:

As per the discussion here (https://www.eclipse.org/forums/index.php/t/1068100/) it would be useful to be able to mark a newly discovered thing in such a way as to allow the UI to know that it can't be approved.

This would allow a binding to add a temporary thing when it discovers a new device but doesn't yet have enough information to allow it to be approved.

This could be acheived with a flag in the inbox, or by using a different state.

On 2015-07-13 03:37:19 -0400, Kai Kreuzer wrote:

I wonder if we shouldn't design this more versatile than just through a flag. E.g. allowing to pass a (localizable) message or even refer to some action (like referring to the installation of a new binding).

I wouldn't see this as a high priority for the moment, though.

On 2015-07-13 04:05:41 -0400, Chris Jackson wrote:

I would agree on both points. What I have at the moment works, so for me there's a workaround.

There must be a way to provide state descriptions for dynamically created things

migrated from Bugzilla #464141
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2015-04-08 06:16:48 -0400, Kai Kreuzer wrote:

When a ThingHandler needs to dynamically changes the existing channels of a thing, there is no way to declare what kind of channel type it reflects and therefore there is no chance to provide a state description for it. See discussion https://github.com/openhab/openhab2/pull/168/files#r27944327.

Manually providing a StateDescriptionProvider is also not possible as this refers to items instead of channels.

Implementing a ThingTypeProvider also does not make much sense as you would have to update the thing type definition every time when a thing changes - which means that you could not have two things configured in different ways (e.g. one for °C and one for °F).

Imho it should be possible to define channel types and then reference them from dynamically created channels (within the same binding).

The implementation of the method ThingTypeRegistry.getChannelType(ChannelUID) already seems to hint that there is some conceptional problem that should be addressed.

On 2015-04-08 13:42:42 -0400, Daniel Cunningham wrote:

I'm going to add my 2 cents about making channels more dynamically configurable in general. I'll give two examples from bindings I'm in the process of writing.

!.For the Logitech Harmony hub, I would like to dynamically create the options in the state of a channel. A thing (AV Receiver for example) can have a single channel (button press) which takes a string (button to press, play for example), but it will support dozens of possible strings, or more, that will vary from device to device (TV, xbox, etc..). I can discovery the possible values and would like to populate this on behalf of a user.

1. For a pool control binding, i have channels whose labels are configurable. For example, the pool controller has 10 pump channels (pump1,pumpN+1...pump10). A pool allows the user to configure the label of a pump, so pump1 may be "Spa" in the system. I can retrieve this name map and would like to update a channels label with the correct user setting.

On 2015-04-14 05:08:00 -0400, Jeppe Vennekilde wrote:

I'm working on a Wireless M-Bus binding at the moment where it is possible for each device to specify what type of data it provides, which makes it impossible to setup which channels it will have before runtime.

This would make implementing the binding a lot easier and also makes it easier for the user as the binding can set up only the relevant channels for the specific thing

Add Category to thing-type

migrated from Bugzilla #465478
status UNCONFIRMED severity enhancement in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2015-04-25 07:19:04 -0400, Chris Jackson wrote:

I think it would be useful to add category to the ThingType object.

Currently Category a member of the channel and item, and therefore is effectively added to a Thing once it's created, but I think it would make sense to have it available in the ThingType as well to allow users to sort/find/display information.

On 2015-04-25 08:08:33 -0400, Dennis Nobel wrote:

All the categories we defined so far are "functional categories". The problem with things or devices is, that the diversity is huge. Functions are the atomic buildings blocks of devices. When trying to categorize devices you end up creating an ontology, where a lot of people failed so far. Because of this we decided to not have a category for things.

For sure for some simple devices it seems to be straight forward. E.g. a thermostat could be a category for a device that supports temperature regulation. But what is the category of a more complex devices with multiple functions. Kai just me showed me the new Fibaro motion sensor (http://www.fibaro.com/de/the-fibaro-system/motion-sensor). Besides motion it also measures temperature and other values. So what should be the category of this device? "motion sensor"? "motion sensor with temperature sensor"? "device with multiple sensors"? I hope the problem is clear.

A lot of people and organizations try to create ontologies at the moment. Before we also try to create a new one, I would propose to wait until someone else comes up with a good approach (if this is possible at all - I´m not yet convinced that this is possible).

On 2015-04-27 09:43:28 -0400, Chris Jackson wrote:

I agree - there's a log of diversity in sensors these days, but to answer your question about the Fibaro FGMS - it's a motion sensor. Yes, it has secondary sensors that can be enabled separately (disabled by default), but it's sold as a motion sensor.

In any case, I understand what you mean, but I also think that some sort of category (or maybe we call it something else) is useful. We already have the ability to put a category into a thing (ie in the thing-item), so it seems a little strange that it can't also be attributed to the thing-type?!?

From a UI perspective, I think it's useful to have some field attributed to a device that allows searching. Maybe it can be done indirectly through the channel categories, but there's no way to say which is the 'main' channel and what are secondary. I guess that's another solution is to add some sort of 'channel context' so that we know if the channel is a primary or secondary (or third-ary) function of the device?

mDNS binds to IPv6 only

migrated from Bugzilla #423513
status NEW severity enhancement in component Core for ---
Reported in version unspecified on platform PC
Assigned to: Project Inbox

On 2013-12-07 16:11:55 -0500, Kai Kreuzer wrote:

Migrated from https://code.google.com/p/openhab/issues/detail?id=288

On 2015-07-02 13:10:50 -0400, Jayaraj Esvar wrote:

Hi,
In module org.eclipse.smarthome.io.transport.mdns under class MDNSClientImpl
activate() Please JmDNS.create(InetAddress addr, String name) instead of JmDNS.create().

Thanks & regards,
Jayaraj Esvar

On 2015-07-06 05:48:37 -0400, Kai Kreuzer wrote:

Thanks Jayaraj,

What do you suggest to fill in as addr and name parameters?

On 2015-07-07 01:26:12 -0400, Jayaraj Esvar wrote:

Hi,
Small logic needs to be added to find on which Ip version the controller is attached to and add that instance of Inetaddress.

InetAddress addr = getLocalIpv4/6Address(); <-- decide based on the current attachment, ignore if it is pointing to localhost.
String hostname = InetAddress.getByName(addr.getHostName()).toString();

On 2015-07-08 04:40:32 -0400, Kai Kreuzer wrote:

Would you like to suggest a PR for these changes?

On 2015-07-08 15:37:50 -0400, Kai Kreuzer wrote:

*** Bug 471727 has been marked as a duplicate of this bug. ***

ClassCastExceptions when updating SmartHome bundles

migrated from Bugzilla #478783
status NEW severity normal in component Core for ---
Reported in version 0.8.0 on platform PC
Assigned to: Project Inbox

On 2015-10-01 03:48:27 -0400, Jochen Hiller wrote:

We are using Eclipse SmartHome running on an OSGi framework where we make on a regular base updates of bundles.
It happened in rare cases (especially when a bundle does not stop correct) that during the update class loaders can not be cleaned up by the framework. This lead to the situation that after the update some bundles did use object instances from an old class loader.
This happened for bundles where object instances are shared between bundles, the packages are exported by an Export-Package directive, but NOT imported in bundle via an Import-Package. We changed that in according bundles which did solve this issue.

There is blog post from Peter Kriens about concepts of Export/Import package since OSGi R4:
http://blog.osgi.org/2007/04/importance-of-exporting-nd-importing.html

Peter recommends as a best practice that in standard case all Export-package should be reflected also as an Import-Package.

We recommend to apply this best practice to all ESH bundles. We will provide a PullRequest where we change all MANIFEST that every Export-Package will have a corresponding Import-Package.

Any comments on that? Especially from people running ESH on other frameworks, like Equinox, Felix, Karaf.

On 2015-10-01 04:09:24 -0400, Markus Rathgeb wrote:

I already stumbled over this topic after starting with OSGi.
I don't know why this is not done. Perhaps because the Eclipse IDE does not generate that stuff in the Manifest.

For myself I am using the maven-bundle-plugin for OSGi bundles and delegate the Manifest generation (sometimes with some additional instructions in the pom) to that plugin.
But the Eclipse IDE does support all that "non Eclipse stuff" (in a comfortable way).

On 2015-10-01 04:16:21 -0400, Kai Kreuzer wrote:

So this means that the maven-bundle-plugin also automatically creates imports for all exports? So I take this as an approval of Jochen's request then.

On 2015-10-01 04:23:13 -0400, Markus Rathgeb wrote:

maven-bundle-plugin:
is assumed to be "*", which imports everything referred to by the bundle content, but not contained in the bundle. Any exported packages are also imported by default, to ensure a consistent class space.