lol - me to. Basically the brain will forward actions to the transport (an action is a json object like { action: launch, recipe: myrecipe}). I convert this to an event (with a topic of ‘smarthome/neeo/{brainid}/action’) and throw it onto the event bus. Very similar to ItemStateChangedEvent, ItemStateEvent, ThingUpdatedEvent, etc. My question is - how would I use that in a rule. It’s not an item or a thing, so you can’t do something like ‘when item xxx changed’ or anything.
I asked about ‘forward actions’ because I saw that there is an entry for (only one ?) IP address to forward to. The Homey connector sets this field to point at Homey so I can see that this might become an either/or choice with multiple controllers. It’s all new to me and maybe more addresses can be added or one controller can forward to another or a hub type arrangement could be used.
I’m still having issues… some of my switches setup for separate channels are updating as the same switch in shortcuts - i.e. several shortcut switches change state simultaneously in the UI if updated from OH.
My eui page does not update in a timely fashion at all - should it ? The remote is quicker than eui
The forward actions only allows a single forwarding and openhab will do the same thing (set it to itself). However, I’m also including a ‘forward chaining’ configuration option that will allow you to setup other devices to receive the events as well (so the brain can forward to openhab which processed them and can forward them on to homey). I’ve also asked Neils to add this to his homey implementation as well.
As for the issue you are having - I’ll need you to turn on TRACE logging for the transport, do whatever action updates the same switch and send me the file (and the neeodefinitions.json file in userdata/neeo).
The EUI and remote (TR2) are totally different beasts and each have their own issues - so that doesn’t surprise me.
@tmrobert8
There is a when channel ... triggered condition possible in the rules. You can then retreive the payload. However, that would imply a trigger channel exists.
Here is an example of such rules:
rule "Alarm"
when
Channel 'nikohomecontrol:bridge:440e003a24e6:alarm' triggered
then
var message = receivedEvent.getEvent()
logInfo("alarm.rules", "Alarm: {}", message)
end
rule "Notice"
when
Channel 'nikohomecontrol:bridge:440e003a24e6:notice' triggered
then
var message = receivedEvent.getEvent()
logInfo("alarm.rules", "Notice: {}", message)
end
There are 2 separate channels defined in the binding (alarm and notice). I can trigger a rule based on the channel being triggered and retreive the payload.
I am not experienced with the experimental rules engine. I don’t think you can currently do anyting beyond the classical rules approach on the trigger conditions when defining experimental rules through the paperUI at the moment. But I know there are some ‘hidden’ features not exposed there. Maybe defining through REST already allows more.
I have been thinking about the actions over night though. I have the feeling these forward actions may actually fit better in the binding than the transport.
My conceptual understanding is that the transport allows you to expose OH to NEEO, to allow NEEO to add OH things as NEEO devices. It is kind of allowing NEEO to discover the OH things. It then takes care of this thing-device interaction. This will even become better as you will allow further mappings to allow virtual and OH1 items.
The binding exposes NEEO rooms, scenarios and recipes to OH to allow OH to discover them and interact with these. This is great if I want to trigger a NEEO recipe from OH and keep on interacting with it. It only works on rooms, scenarios and recipes already defined in NEEO.
To me, a NEEO action forward is on something defined in NEEO. E.g. see my example on planet NEEO. I pause video. This send an infrared signal to my cable box (my cable box is not IP controlled or OH controlled). This pause action needs to go to OH . But because watching video is in a running recipe, OH should catch the trigger. To me, that looks like it should be the binding catching it, because that is the one knowing about recipes. It could then also trigger a channel linked to the specific thing (i.e. recipe or scenario), rather than a general one. That would make the rule filtering work as expected.
You may actually be able to get the added advantage in the binding, not to have to do polling to get the recipe status updates. You could interpret the forwarded actions and update accordingly.
Notice the potential for some loops in using both at the same time. E.g. I have a light thing in OH. I use the transport to expose it to NEEO. I add it as a device in NEEO. A recipe is created with this light in it. The OH binding will now expose this as a channel in OH. I think this may actually point to a need to integrate both a bit more to optimize things.
I may have missed something here. But I hope my insights are helpful in progressing the great work you are doing. Many thanks for this.
Yeah - I’ve struggled with many of the same points. I was also thinking of putting it into the binding but I’m finding the binding to be less useful the more I add to the transport. The problem is that the transport doesn’t have concepts like things/channels and the binding doesn’t have concepts that the transport has. The transport already does support everything the binding does - only in slightly harder ways (rather than explicit like the binding, you send on/off to the power channel of the device).
However…
I figured out how to do the events in the transport (basically I’m defining a hardcoded item name called ‘neeo_forward_actions’ that you can then use in rules and it works well. Might make the item name configurable later on.
But since I’ve done that - it brings up the whole question as to whether we need a binding. I could use the same approach to simulate the binding - have a recipe channel, active scenario channel, etc - all in the transport. Heck - I could even add rule actions to make it easy for rules to stop/start recipes as well. The downside is that it’s harder to manage since it’s not wrapped in the thing/channel paradigm (and thus is largely hidden from paperui - for what that’s worth). If I did that approach - I’d probably create another tab on the connector string to manage the items (can specify names and get/set current values (similar to what paperui does). From a functional standpoint - it will still be the same - just the items come from the transport rather than the binding.
The more I type this - the more I’m convincing myself that’s the proper approach to do and remove the binding side. Any thoughts?
Just posted the newest binding that includes forward actions from the brain.
Sample rule:
rule "NEEO"
when
Item neeo_forward_actions changed
then
var String data = (neeo_forward_actions.state as StringType).toString;
var String action = transform("JSONPATH", "$.action", data);
var String device = transform("JSONPATH", "$.device", data);
var String room = transform("JSONPATH", "$.room", data);
var String actionparameter = transform("JSONPATH", "$.actionparameter", data);
logInfo("neeo", "action: " + action + ", device: " + device + ", room: " + room + ", actionparameter: " + actionparameter)
end
@tmrobert8
I can see your point. You are well advanced in the development of all this. And I very much like what you have already achieved. You are less dependent on some parts of the framework the way you do it, and that sometimes is a good thing.
Personally I like to stick as close as possible to the OH concepts. Therefore I like to have things with channels and items I can link to these channels. In my view, the only thing a pure binding would not be able to do is provide discovery of OH items to NEEO. All the rest could be handled by the binding.
The advantage of the binding concept is that it will benefit from new functionality being created in the framework. I think a good example with potential also for the link with NEEO is profiles. That would allow to define a link between 2 channels (items) without needing rules in between. I just saw today @Kai developed a ‘demo’ binding benefiting from that here: #4579. It is probably early days, but still.
I am not sure in the binding you should have one thing for each room. The only physical thing is the brain. I would represent all the rest as channels in different channel groups. I made that mistake with my NHC binding. The result is I need to also manage a lifecycle for the things on the bridge, while only the bridge has a real initialization and online/offline lifecycle. If I would have used dynamic channels, that would have been easier and simpler to the user. I was lucky do, because in the current version of your binding, it does allow me to expose my lights to NEEO, as each light is a thing.
So, if you ask me, my preference would be to limit the transport to exposing OH things/channels/items to NEEO to be able to add them as devices in NEEO and use the binding for all the rest. I will happily live with the way you are doing things though.
I will test your forward actions approach one of these days. An immediate reaction I have is why you use a hardcoded item. An item typically has a state. What you want is a trigger channel with a payload. Is it possible to create a hardcoded trigger channel instead of a hardcoded item? An example where that would make a difference is when you use persistence. I, by default, store all item states in mapdb for restore at startup. If it is an item, it will get stored. I would need to tweak all rules reacting on the item change to exclude the reload at startup or change my default persist all strategy, making it more difficult to maintain. Also, as shown in the profile approach above, we may still be able to map triggers to items when profiles become fully available.
Thank you for all the effort. It is great to see this improving all the time.
I’ll get some logging at the w/e… here’s my json. Very simple atm.
Not sure if the channel numbers should all be 1 ?
One other aspect - I have added the two switches and they appear on the first page of the recipe and work dependably for control and initial state but remote lags by about 10/15 secs in reflecting status changes, and from app or eui doesn’t show changes at all but will control reliably. Then I’ve added all three components as shortcuts (two switches and text display). It’s these two switch items in the shortcuts on the remote that get updated erroneously as one item and change state together if touched. The ones on the main recipe startup page don’t.
Also the text labels on those switches don’t display on the remote and the buttons are way over to the left of the screen on the remote but central on the app Not sure if its possible to get a pic of the remote screen (except by photo). The app screen is different and curiously doesn’t link the button behaviour. Looks like this is a Neeo bug.
btw just a language thing… “ACCESSOIRE” ?
[{
"uid": "loxone:miniserver:EEE000AC006E",
"adapterName": "loxone:miniserver:EEE000AC006E",
"type": {
"text": "LIGHT"
},
"manufacturer": "openHAB",
"name": "Loxone Main",
"channels": [{
"itemName": "KWdownstairs",
"label": "KW pulse",
"channelNbr": 1,
"type": "switch",
"range": {
"minValue": 0,
"maxValue": 100,
"unit": ""
}
}, {
"itemName": "LoxoneMain_LoxoneSwitch",
"label": "Courtyard Corner Light",
"channelNbr": 1,
"type": "switch",
"range": {
"minValue": 0,
"maxValue": 100,
"unit": ""
}
}, {
"itemName": "LoxoneMain_KWtotal",
"label": "KW total",
"channelNbr": 1,
"type": "textlabel",
"range": {
"minValue": 0,
"maxValue": 100,
"unit": ""
}
}, {
"itemName": "LoxoneMain_LoxoneKWcellar",
"label": "KW cellar",
"channelNbr": 1,
"type": "",
"range": {
"minValue": 0,
"maxValue": 100,
"unit": ""
}
}, {
"itemName": "LoxoneMain_KWdown",
"label": "KW downstairs val",
"channelNbr": 1,
"type": "",
"range": {
"minValue": 0,
"maxValue": 100,
"unit": ""
}
}, {
"itemName": "LoxoneMain_KWup",
"label": "KW upstairs",
"channelNbr": 1,
"type": "",
"range": {
"minValue": 0,
"maxValue": 100,
"unit": ""
}
}],
"timing": {
"standbyCommandDelay": 5000,
"sourceSwitchDelay": 5000,
"shutdownDelay": 5000
}
}, {
"uid": "lifx:colorirlight:D073D525832B",
"adapterName": "lifx:colorirlight:D073D525832B",
"type": {
"text": "ACCESSOIRE"
},
"manufacturer": "openHAB",
"name": "Table Light",
"channels": [],
"timing": {
"standbyCommandDelay": 5000,
"sourceSwitchDelay": 5000,
"shutdownDelay": 5000
}
}]
@Mherwege
Again - good points. @Kai also mentioned trigger channels (of which I didn’t know about). That’s definitely bringing me around to leaving it out of the IO and put it into the binding (which fits OH vision better for this type of functionality). Plus it does simplify some of the issues (since I have a one to one relationship between brain/thing - I don’t have that in the IO, so it always has to carry around the brainid in everything [which I forgot to do in the forward actions part). Additionally, I can remove the polling from the binding as well (since I’m getting it in real time - I’d just need to poll initially then).
I’m heading out for the weekend - so I’ll give it some brain (haha, get it!) time in the car and see what I can come up with…
Tim
- Don’t blame me for ACCESSOIRE - that’s what NEEO named it. They promised to fix it some day (which will break everything) but that’s what we are left with. I’ve been asked this enough that I’ll add it to the readme.md
- Since you can have more than one neeo capability mapped to a item - the channelNbr lets me know which capability called it. The first one (which shouldn’t be deleted) will always be channelNbr 1. Actually - bad name on my part since ‘channel’ is a openhab verbage thing - should have said “itemNbr”. Might change that and have provide backward compatibility.
- Without the logs I can’t really comment on your situation
- Timing - I’m sending it as fast as the system can process (tail the log and you can atleast watch when we see a message and when we dispatch it). The lag should be on the TR2/EUI is really NEEO’s issue
- Remote layout is definitely something I can’t control - but UI 2.0 is suppose to fix all of that (Neils, I think, has it - but nobody else)
All makes sense, I’m kinda suspecting that the two switches I see separately in shortcuts are actually the same switch displayed twice.
Have a good w/e …
Tim… I just reinstalled OH 2.2 latest snapshot and I’m pleased to say that my latency issues have now gone in both app and remote - so that’s really good news.
I do still have the visual discrepancy between app and remote displays in shortcuts and also on the remote my separate switches are still updating from and controlling the same item for some reason… but not in the app, where they behave correctly. So again this looks like a Neeo issue.
Hope that makes your weekend a little more satisfying.
K
@tmrobert8 Hi Tim … Today I connected Alexa to OH2. For that reason I had to ad a xyz.items file. As soon as I ad this file to /opt/openhab2/conf/items all my things in neeo transport are disappeared. In the same second when I delete the file they appear again.
Is there a way to user Alexa and neeo at the same time?
Wow - no idea on that one. Could you open up your log file and see if there is any error messages in it (may need to turn on debug to see them).
I have my items mixed too - no problem here.
Maybe your xyz.items-file has errors.
Did you already configure these items within the paper-ui?
You should not use the same item-name twice…
1 Like
I just posted two new version of both the binding and transport. The binding had some big changes to it.
Transport Changes
- Removed forward actions from transport
Binding Changes
- Many bug fixes
- Added forward actions - each Brain thing will have a forward actions channel that will be updated with each action. You can then do a changed rule to use the data (similar to above)
- After you add a room - it will discover all DEVICES within the room
- Each device will then expose the MACROS for that device. You can then trigger the MACRO by sending “ON” to the channel.
- In the binding, it would do polling for the active scenarios. That has changed to use the forward actions - so you get immediate feedback now. The polling still happens (however set to 2 minutes now) because a power failure or restart of the brain (firmware, etc) is not detectable via forward actions
Note: MACROS are what NEEO defines on the device and usually correspond to what get’s mapped to hard button. So if you have an audio device - you’ll likely have a VOLUME UP, VOLUME DOWN and MUTE TOGGLE macro. You can then trigger those macros from openHAB by sending “ON” to the corresponding channel. This works for ALL devices (basically this lets you send out IR signals from the NEEO brain to IR devices!!).
@tmrobert8 Great job you have done on this!
Here are just a few observations.:
- When I remove a device that was first discovered, discovery will not pick it up anymore. Normally, the next discovery run (background or triggered from the UI) should put it back in the inbox. I noticed this for a device I removed by mistake. I could not bring it back unless I removed the brain thing and re-added everything. EDIT: Also a restart brought it back in the inbox.
- I couldn’t check your code, but I am not sure the channel on the brain is a trigger channel. It has type string. I don’t think a trigger channel has a type, from what I remember. Using a trigger channel avoids needing an item. It can directly be used in a rule.
- I keep on getting the following errors when starting OH, caused by the binding. This was already present in the previous version. These messages are the very first messages in the log after a restart. Everything works though.
2017-11-21 23:18:41.356 [ERROR] [org.openhab.binding.neeo ] - [org.openhab.binding.neeo.type.NeeoChannelTypeProvider] Cannot register Component
org.osgi.service.component.ComponentException: The component name 'org.openhab.binding.neeo.type.NeeoChannelTypeProvider' has already been registered by Bundle 10 (org.openhab.binding.neeo) as Component of Class org.openhab.binding.neeo.internal.type.NeeoChannelTypeProviderImpl
at org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:222) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:448) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:315) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:268) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:388) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator.access$200(Activator.java:54) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:265) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:254) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:227) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.addingBundle(AbstractExtender.java:187) [46:org.apache.felix.scr:2.0.12]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469) [?:?]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415) [?:?]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) [?:?]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) [?:?]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) [?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:903) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:156) [?:?]
at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) [?:?]
at org.eclipse.osgi.container.Module.start(Module.java:467) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1599) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
2017-11-21 23:18:41.397 [ERROR] [org.openhab.binding.neeo ] - [org.openhab.binding.neeo.type.NeeoConfigDescriptionProvider] Cannot register Component
org.osgi.service.component.ComponentException: The component name 'org.openhab.binding.neeo.type.NeeoConfigDescriptionProvider' has already been registered by Bundle 10 (org.openhab.binding.neeo) as Component of Class org.openhab.binding.neeo.internal.type.NeeoConfigDescriptionProviderImpl
at org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:222) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:448) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:315) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:268) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:388) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator.access$200(Activator.java:54) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:265) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:254) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:227) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.addingBundle(AbstractExtender.java:187) [46:org.apache.felix.scr:2.0.12]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469) [?:?]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415) [?:?]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) [?:?]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) [?:?]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) [?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:903) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:156) [?:?]
at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) [?:?]
at org.eclipse.osgi.container.Module.start(Module.java:467) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1599) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
2017-11-21 23:18:41.405 [ERROR] [org.openhab.binding.neeo ] - [org.openhab.binding.neeo.type.NeeoThingTypeProvider] Cannot register Component
org.osgi.service.component.ComponentException: The component name 'org.openhab.binding.neeo.type.NeeoThingTypeProvider' has already been registered by Bundle 10 (org.openhab.binding.neeo) as Component of Class org.openhab.binding.neeo.internal.type.NeeoThingTypeProviderImpl
at org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:222) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:448) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:315) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:268) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:388) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator.access$200(Activator.java:54) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:265) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:254) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:227) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.addingBundle(AbstractExtender.java:187) [46:org.apache.felix.scr:2.0.12]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469) [?:?]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415) [?:?]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) [?:?]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) [?:?]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) [?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:903) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:156) [?:?]
at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) [?:?]
at org.eclipse.osgi.container.Module.start(Module.java:467) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1599) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
2017-11-21 23:18:41.411 [ERROR] [org.openhab.binding.neeo ] - [org.openhab.binding.neeo.type.NeeoTypeGenerator] Cannot register Component
org.osgi.service.component.ComponentException: The component name 'org.openhab.binding.neeo.type.NeeoTypeGenerator' has already been registered by Bundle 10 (org.openhab.binding.neeo) as Component of Class org.openhab.binding.neeo.internal.type.NeeoTypeGeneratorImpl
at org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:222) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:448) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:315) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:268) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:388) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator.access$200(Activator.java:54) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:265) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:254) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:227) [46:org.apache.felix.scr:2.0.12]
at org.apache.felix.utils.extender.AbstractExtender.addingBundle(AbstractExtender.java:187) [46:org.apache.felix.scr:2.0.12]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469) [?:?]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415) [?:?]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256) [?:?]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) [?:?]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) [?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:903) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:156) [?:?]
at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) [?:?]
at org.eclipse.osgi.container.Module.start(Module.java:467) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1599) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
The binding:
After installation i can add the brain, but after this i am stuck (still working on Synology).
The Brain shows initializing and does not connect to the brain - no rooms showing up (tried to restart OH, reinstall, delete tmp/cache, waited over night,…)
Tried the binding before - everything working fine within minutes. Do you need a log-file?