- For the buttons - what neeo type are you assigning to? The NEEO type really enabled/disabled different types of things on the brain and could be part of it
- If I understand you correctly, you currently can’t get rid of that and is one of the complaints over on planet.neeo.com. I’m hoping that when/if they ever get around to doing a UI 2.0 on the remote - that will be addressed.
- Could you explain this further as I’m not sure what you mean by it.
I am assigning light type, because I want to control lights. The individual switches are fine. But I have also push buttons that switch all lights off. It does not need to have two states.
Understood. The longer I play with NEEO the more I am convinced the NEEO vision is not clear to me. The difficulties seem to come from the fact they want to make a perfect remote control but they also want to be it a smart home controller. These may be two different purposes. What I would really like to do is to put openHAB on the NEEO brain and create the NEEO remote UI for it. This could solve a lot.
I would like to create my own recipe that interacts with openHAB items. Currently when I try to do so and choose openHAB device, it says this device has no automation items (controls or whatever the term I forgot) exposed. I suppose the controls that I can use in the device control view could be made available for recipe interactions. The reason why I need that is for example to create a recipe that switches all lights off - that would be just one click on the recipe instead of starting the recipe and then clicking on the button or switch.
First of all thanks for the great work on that binding! It makes Neeo much more useful at the moment!
I have a short question. Is it planned to support adding virtual devices (items) to OpenHab Things in the transport IO? Not only to virtual devices.
This could be useful if you already have defined some items which triggers rules or something else. This could avoiding duplicate rules.
You can already do that depending on what you mean as ‘virtual’
- If you mean virtual items within .items file - this is fully supported. Create a virtual device, then press the add item button - that will open a dialog that will allow you to choose items (including virtual) that have been part defined in the system. If you don’t want to search for them - you can simply import the .items file containing them as well.
- If you mean virtual items that are not official items (ie only can be used by rules) - then on ANY device (virtual or real), you can hit the puzzle piece icon and define the item. This will item can then be used in a rule to be triggered when the corresponding button is pressed on the remote (you can download a sample rules file by pressing the rules icon on the device).
- I’ve never used the light type before - so that may be something they restrict for that type (only sliders/switches allowed). This is the fun of not having any documentation - you kinda got to try things to see what works or not.
- Yeah - I think they are trying to nail the remote part down before concentrating on the automation side. Personally - I do ALL my automation in openHAB and simply use the remote as my UI for it (which works for me). I actually use the brain as an IR transmitter for devices that can’t be controlled by openHAB (stupid samsung/sony soundbars).
- Ah - I see - the recipes are not very powerful and only work with a select amount of ‘home automation’ items (power state, sliders, sensors [sliders & switches] and a few other things that I’m forgetting). You can usually workaround it using openHAB rules however
FYI - posted a new version of the transport over at https://github.com/openhab/openhab2-addons/pull/2350. Changes:
- Named 2.3 but can be used on 2.2
- Added ability to add brains on brain tab
- Removed ability to specified brains in configuration
- Discovered brains now persisted in userdata/neeo/discoveredbrains.json (read at startup, modified as things are discovered/added/removed)
- Added ability to add existing thing items to virtual thing (ie cloning an existing thing made easy - add virtual item, press the + to add item, choose existing thing in dropdown and press “Add thing items”)
- Fixed a few edge case discover issues (like after a firmware update, brain advertises itself but is not available for a minute or two).
thank you for the fast response and the explanations.
What I meant, was something in between.
The idea was to add an item which I defined within an .item file to an “OpenHab Thing” . At the moment I can only use this kind of items for "Virtual Things"
At the “OpenHab Things” if I hit the puzzle symbol, I can only define a new trigger Item which I can use within a rule which is good but sometimes I already have a rule which is triggered by a command I send to an other item (like 1; 2; 3; and so on). Of corse, I can use the trigger Item to trigger another item but if I could add my already existing item from my .item file to an “OpenHab Thing” and assign buttons with different command like 1, 2, 3 and so on, I could trigger that directly.
Or is that already possible and I only miss something…
Ah - you can’t do that directly like you are asking. However, you can do it this way:
- Create a new virtual thing and give it a name (“Alternative” + other thing.name - or something to that effect).
- Press the “+” to add items
- Add all the items from your thing (or download the latest version and pick the thing to import all items from it - see above).
- Add a new item and select the item from your .items file
Save the items/save the thing - then find the new virtual thing in neeo.
Works the same way as what you are describing - just the virtual thing is a mix between your existing thing and the item in the .item file).
Thank you very much. You wrote that post in parallel That`s a good solution. I will try that.
Tim, thank you once more for your fantastic work on this.
I already posted in this thread about it before, but I am still looking for a more appropriate way of doing things. I am trying to use the NEEO as a Zwave controller. Currently I only have one Zwave device, switching a light on and off. I have it set up on the NEEO and visible as a device in openHAB through the binding. I couldn’t find an easy way to control this light from openHAB though, as the NEEO light is exposed as 2 separate macros without state (an on and off macro). The NEEO user interface does show a state aware switch.
I have now solved this with a set of rules (see my post from Dec 9th), but this gets complicated quickly if I would add more of these devices. It is also not perfect, as the state is derived on openHAB side without a guarantee.
Do you see any other way to do this?
Unfortunately the API doesn’t expose the state of internal devices - so getting that is impossible at this point. I’ll throw a request over on planet.neeo.com asking for it - but it would be quite some time before it get’s addressed (I think their developer is overwhelmed right now)
Just want to say thanks and WOW. This is very nicely done and the UI for the transport is great!
Best regards Mikael
Tested the IO which can be found here:
Running on OH 2.2.0 release
old config-file can not be used.
after deleting things are found, connection to the brain is working - i can “blink” it, configuration can be done.
But the neeo-app does not find a thing, if i search for “openhab”
old config-file is working here - i can switch my things with the remote.
same error like the 2.3.-snapshot - the neeo-app does not find a thing, if i search for “openhab”
where is my mistake?!
OK, i found it: i turned “Expose NEEO Binding” on in the Paper-UI
Weird - I’ll look into this today
i understood this as: “Discover NEEO Binding” - if turned on, it finds things.
at the moment it works like: “Hide NEEO Binding” - turned off, it finds things.
Ok - that statement totally confused me. What do you mean by that?
Maybe it´s an translation error:
Expose = Discover (correct?)
Turned off like in the picture is suggesting me, that the NEEO-app should not find Things made with Openhab.
But if it is turned off, the app finds Things.
Ah got it - I though you were talking about the NEEO binding itself. I’ll check in on that and get back to you…
Can you check your log (with debug turned on) - I’m betting there is some exception being thrown that I need to handle better
Ok, but i never changed the debug-level - what do i have to change?
Are you sure that it is an error? i just thought the switch is working upside-down.
What are those two switches for?