the events.log doesn’t record anything for that item. the openhab.log does however.
openhab.log
2017-01-19 21:43:35.095 [INFO ] [.eclipse.smarthome.model.script.Mode] - Mode received state:1
2017-01-19 21:43:35.106 [INFO ] [.eclipse.smarthome.model.script.Mode] - Mode updated to: 1
2017-01-19 21:44:50.726 [WARN ] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve color item online for widget
The INFO line for the Mode is me clicking to set it.
And there is no line later on when it goes grey in the UI? That seems to point to something odd going on with the UI. Not sure I’m any closer to knowing what. …
I wonder if receivedcommand is a string. Try case “0”: and case “1”:
I don’t think that’s the case. The Scene is exactly the same just changed the names and it works right.
@rlkoshak Nope no further line. Weird.
I’m absolutely on the same frustration side.
I’m using OpenHab for two years now (starting off with 1.X, now 2.X).
It IS frustrating, once it is up and running - and everything is set up - it works quite well.
As a programmer, I do not understand the concept (and I’m a programmer for 30 years).
To add one “thing”, I have to edit at least three files:
.items file
.rule file
.sitemap file.
lovely.
But when we are talking about documentation, I have few questions:
Everybody explains how to “discover” things so you get it into paper UI- Great. It’s there!!! What is the purpose of having it there?
Dashboards: There are Dashboards!!! Finally!!! Great stuff.
Aehm, just one issue: What is the purpose of having a dashboard?
Why I think Loxone is doing a better job (and no, I’m not having one and I’m not going to buy one as it is too expensive and does not have a UI that is as flexible as a sitemap-):
They organize the stuff by functionality, not by file type as OH is doing.
Why isn’t it possible to just have ONE kind of object for a “thing definition”.
It should contain the config, the rules, the items, the sitemap (fragment).
I know this is a completely different approach to what we have now - but this would finally enable somebody to just say, hey, I have a great “thing” here. A nice toolset to target a certain issue.
Just to give an example: I’m owning an electric vehicle and a PV. Also a KEBA P30 (using KEBAP20 binding, that was the reason to switch over from 1.8).
There is a rule set which allows me to charge my car with exactly the current I calculate which I do not consume elsewhere in the home.
This should be packaged in a nice way to provide this to others (in an easy way).
It is also not possible to have input/output parameters (which I have seen at Loxone) where I can define logical switches for On/off based on conditions.
What we should have is a set of LEGO bricks which we just put together to produce a nice home automation.
What we currently seem to have is an instruction set which explains how a machine can be built to produce exactly ONE of the LOGO bricks you need.
OH is not an iphone, well that’s right, but we should get close to it.
Just to clarify: I’m not having, ever had or ever will have an IPhone. I’m more an Android man.
These are three very distinct things.
As a programmer you will understand this simili.
Think of your .items files as your .h
Think of your .rules files as your .c
Think of the .sitemap as the user interface code which, if you are following MVC is separate.
So to turn around your question “In C why do I have to declare a bunch of stuff in a .h file and write functions in a .c file and what’s with all that code over there that runs the UI?” Its because they serve a different purpose.
http://docs.openhab.org/concepts/index.html
http://docs.openhab.org/tutorials/migration.html#new-concepts-things-and-channels
If you are coming from OH 1, Things and Channels replace the config stuff you used to put between { }. This needed to be abstracted to enable autodiscovery and management of everything through the UIs.
How would you propose to mix the functionality across them? For example, create behavior that triggers based on events from multiple sources? If all my zwave stuff is stuck located together, how can I let ym zwave stuff control my MQTT stuff and vise versa?
The primary reason d’etre of OH is to act as a kind of universal translator between multiple (over 150 at this point) technologies and APIs. As such it used the common architecture of layers of abstraction. If you compare it to the OSI networking model you will find a lot of parallels.
Application Sitemap
Presentation Sitemap
Session Rules
Transport Items
Network Channels
Data Bindings/Things
Physical Dongles/APIs
Obviously the simili above is not perfect but I hope it is at least illustrative. These things build upon each other and the layers of abstraction allow, for example, Rules to work with any Item with no knowledge of what that Item represents nor how that Item communicates with the device it represents.
This is in the works and one of the main reasons for the Experimental Rules Engine.
And this is what the Experimental Rules Engine is intending to create. However, even with this you will still have a layer of abstraction between Items and Rules because a Rule should not know nor care what technology or device an Item is attached to.
That is why you do not distribute your .h, .c or whatever files, but compile a DLL from it.
The final question will be: What is the target audience for OH. Should it be a system for nerds and programmers, or do we want to allow a broader range of people using it.
I will not go and enter a discussion about the design pattern.
I’m also not expecting any justification about why are things as they currently are.
All I say is:
If you create a “thing” which has rules, input and output parameters, and you can just use ONE output parameter of ONE thing as an input parameter of another thing, just by connecting them, you are on a good way to get the thing growing.
As long as a switch is a switch for you, and all you want to do is switch lights on and off, maybe change the color, you are good with items and sitemaps. As soon as you are going to implement conditions, you are lost if you are not a programmer.
The commercial providers of this type of house automation - yes I know, they are not as flexible as we are - understand that this must become a drap & drop solution.
I can give dozens of examples of “things” you could manage in combination and related to other things.
Example:
Let me call it a “PV Info Pane”:
For monitoring your PV, you would have two input parameters: “PV Current Output”, “Total Power Consumption”.
You could also have an output parameter which shows the difference between the two where negative values could mean that you are buying power, positive values could mean you are selling power.
Within your “PV Info Pane”, you could define to display both in two different rows with individual icons in front.
You could also have a chart in that info pane, showing the values in relation to each other.
So where to get these input parameters from? Well, there is another “thing” which is your inverter and that one could give you these values. All you need to do is draw a line from the output of one thing to the input of another thing. So basically “Drag & Drop” the output parameter from one thing to the input of another thing.
Of course there are also things which do mathematic operations. There is one which is called “Add”.
It has two input parameters of the type “number” and one output parameter.
And so on.
The “Experimental Rule Engine” is a nice idea, unfortunately unusable (unfindable).
My PaperUI (currently) shows: {{title}} > {{subtitle}}
Most probably this can be solved easily by formatting the SD card, reinstall everything, hopefully remember what you have added in paper UI, copy the files you have backed up (hopefully) back to the (hopefully) right place.
Please do NOT misunderstand my notes here. I do like the idea. I do appreciate the hard work of everybody invloved in this project.
Unfortunately most of them are coming from the programming side of the world. There should be some judging the usability of concepts.
Maybe I can provide some ideas for OH3.
… sounds like nodeRed 
You have probably seen my struggles with OH – and rest assured: I hear you… at the end of the day it is take it or leave it, like any other product out there in the world. I am not having a go at you… this is it really. A bunch of people who share a code base and develop it collaboratively on a voluntary basis.
The car is what it is, if you want something different, modify it or build your own.
IMHO OH is for nerds and programmers! Anyone else will be pretty lost with it; follow and try to examples and if they do not work, fall on their noses and hope some forum will pull them out of misery.
Having said this; I also say OH is the best thing I have seen out there when it comes to the possibilities of integrating anything you can think of.
My solution to the difficulties I have experienced during my initial trials with different system and OH in particular, I settled on a architecture where MQTT became a major component to the overall solution. The sensors I am building (so far pretty much all of them) are based on Arduinos with Ethernet ‘talking’ MQTT.
E.g. I changed iPhone presence detection only yesterday: from EXEC binding and shell script, to shell and MQTT. So far, I could realise any solution I had in mind with Arduino > MQTT > OH.
I would not be able to write a binding in this system, despite years of writing code in other languages, and managing large scale commercial software developments.
I use rotini as a UI… very nice…
BTW: I have a PV set-up with 12kW arrays, two inverters and an inverter charger, using excess to run pumps and A/C, etc. The interfaces are Arduinos, the relevant values are displayed in OH, it all talks MQTT.
What I am saying is: talk to different people, and they will use OH differently… different solutions for the same problems… in different languages… different levels of using OH-internals.
If you want to change OH, participate in its development.
If I may…OH2 and its community is different from what I have seen elsewhere. The ambitions are great, the potential and the platform chosen are a match, resulting in a powerful system. The implementation, as the developers move quickly from release to release is great, but, and here we come to a lot of the difficulties that users experience (me included), the documentation and some of the periphery (e.g. Designer) lacks behind.
BUT, this is all opensource, I cannot even imagine the woman/man hours it takes to develop a system as complex as OH2 to this point. My undying gratitude, as I am confident that in this lifetime, I will play the role as afficionado in home automation, meaning I imagine myself being able to appreciate the work of others adequately, using it for my needs, but I am very aware that I am not even remotely able to contribute to the development.
By definition and by the way the project operates, it will not, cannot and does not compete with an off-the-shelf solution. There are other HA projects out there that come closer to that, that have more out of the box stuff that works, easier rule engines, easier architecture for that matter, but more restrictions at the same time.
So it is a choice, OH2 seems to have focused on flexibility, openness, inclusiveness, and interoperability; making it complex. @Max_G mentioned it being a system for nerds and programmers…my hobby programming skills stopped several decades when Pascal included an object-oriented approach…the learning curve for OH2 is and contains to be steep, that is all I can say to that… but I may qualify for the nerd denomination…
I truly believe, that we cannot have it all (and sometimes that is frustrating): there is no system that is designed to allow for utmost flexibility, that is developed by volunteers, that is progressing at a brisk pace not the least because it tries to accommodate the needs or desires of its users, that is opensource and hence free of charge AND that has mechanisms to keep the overall governance (by which I mean that people still work towards a common goal and not start forking incompatible and competing branches).
The only way to keep it going is if we all contribute, chip in and be patient. It is a choice afterall…
I’m on my phone so can’t do a lengthy reply. All I will add is the developer’s an maintainers ate aware of the problems with rules and nonprogrammer users. Frankly a lot of programmers hate it as well given they are written in a customized version of an obscure language.
The entire reason there is an OH 2.0 instead of a 1.9 is to address some internal architectural changes necessary to get to a state where monkeying Aarons in a bunch of text files is no line needed.
We are not there yet. We are a long way from there. But that is the goal. All the work that went into PaperUI, Habpanel, the introduction of Things and Channels, and the Experimental rules engine are all steps towards that direction. Hell, even Habmin has a way to build rules using a Scratch like environment.
Finally, some users are very happily using Node Red with openHAB.
I’m confused. If i add the z-wave multisensor from monoprice do i have to have a hub or does openhab operate as the hub?
You need to provide a Z-Wave stick to your openHAB server
To elaborate, you need a zwave controller which is a USB device that you plug into your OH server. With that then OH acts as the hub. The docs for the zwave binding list some dongles known to work. The Gen5 Aeon Controller seems to be the most popular around here.
You might also want to look into the z-way binding which is an alternative way to work with zwave in OH. It requires purchasing a controller with a specific license though. Again, see the docs.
Finally, some people, either because the existing bindings do not yet support a needed command class (e.g. SECURITY to include door locks) or because they are transitioning off of a commercial system like Vera, leave their zwave devices connected to one of these external hubs and interact with then using the hub’s API.
If you define parameters in a .cfg file, but later change the key or comment out the key (to the left of the = sign), the old key and value remains in the configuration stored in the server. This can wreak havoc and lead to many otherwise inexplicable problems. Users expect, quite reasonably, that the old key no longer mentioned in the .cfg file disappears from the configuration, but it doesn’t. This is particularly irksome when you use a 1.x binding like MQTT or the Weather binding that allows dynamically named keys, like myhouse.url=…
Thanks a lot, you just saved my night!!
Being a seasoned programmer myself (mainly C/C++ on embedded devices) my main problem with obenHAB is the complexity of the architecture. I once tried to implement a bindig myself, but having no Java/OSGI/Eclipse experience and the notorious lack of time just in resulted in not being able to get started in reasonable time.
Main issue with openHAB is the lack of “forgiveness” of the rule language regarding undefined elements and type casting. I have quite a few rules where are more testings if a value is undefined and typecasts than actual code.
But having said that, openHAB is a great project I like a lot. Coming from MisterHouse and having tried some other home automation projects, it is by far the best I now!
There are ways to deal with this sort of thing:
if(timers.get("foo") != null) timers.get("foo").cancel
can be replaced with
timers.get("foo")?.cancel
if(MyItem.state as DecimalType > 20) any longer.With the above I find I have no more tests than I do in any other not strongly typed language such as Python or JavaScript.
Thanks for your explanations! I already used persistence and this really helped a lot, but I had to implement a delay in some rules to allow for restoring the items. The ? operator is nice, I did not know it! And I will surly test automatic casting in openHAB2!!
Regarding the cache: What would I use if I cleared the cache on every startup ( I am only using textual configuration)?
I don’t understand the question. You can use a script to clear it out on every restart but be aware that all the bindings will reinstall so startup might take a lot longer. You need to define your addons in addons.cfg as well.
Thanks, that answers my question. I just was not sure, what side effects deleting the cache might have. I do not mind, when starting takes longer. My openHAB 1 Installation is nearly never restarted, so that does not matter.
The designer is unfortunately no help for OH2. Not even the ESH and OH methods (logDebug, postUpdate, …) are available and one can’t integrate any actions (sendTelegram, …). For example my security.rules has 55 lines of source code without blank lines. 33 of these are marked as defective.
Which version are you using? You should be using Eclipse SmartHome Designer version 0.8 at this point. When you go to the official download page: https://github.com/eclipse/smarthome/blob/master/docs/documentation/community/downloads.md#designer-builds
that is the version made available.
Version 0.9 which was there for awhile has an issue that pretty much breaks its ability to recognize pretty much everything.
openHAB Designer only works with 1.8.
It is true that and separately installed actions are not recognized yet even with the 0.8 version. But that should only amount to a handful of lines marked as errors and in these cases it will be obvious that it is not a real problem.
Because OH’s errors are not all that helpful in identifying syntax errors having the ability to have something syntax check Rules (and sitemaps and items) for you will save tons of time.
The issue to fix what broke 0.9 is actively being worked and long term there is work to create a web based replacement for Designer.