OpenHAB2 Rules and Bolean Operators

Setup, Configuration and Use Scripts & Rules
1

I am running OpenHAB2 on Raspbian, and have really been struggling.

I found a script here that is close to what I want to do on my server. However, obviously something has changed between OpenHAB and OpenHAB2 that makes the rule crash. Here is the error:

`12:31:11.179 [ERROR] [.script.engine.ScriptExecutionThread] - Rule 'luminance rule': An error occured during the script execution: The name '! <XFeatureCallImplCustom>' cannot be resolved to an item or type.`

From what I can tell, the error either has to do with a bolean declaration that fails, or with the use of the ‘!’ symbol in an IF statement. Both of these areas of the rule look okay to me. I am hoping someone can help me resolve this issue.

Here is the rule:

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

var Timer waitTimer = null
var boolean sentTemperature = false

rule "It's getting hot in here"
when
	Item TestTemperature changed
then
	logInfo("Temperature: ", TestTemperature.state.toString())
	if (!sentTemperature && TestTemperature.state > 75) {
		sendMail("<type your email address>", "It's warm", "Temperature reported by Arduino is " + TestTemperature.state)
		sentTemperature = true
		waitTimer = createTimer(now.plusMinutes(5))[|
			sentTemperature = false
		]
	}
end
2

Where does the rule exactly crashes? Did you get the logInfo? By the way logInfo does not work this way it should be something like:

logInfo("Temperature: {} ", TestTemperature.state.toString())

Of what kind is the item TestTemperatureß

Thomas

3

I’ve seen nothing to indicate that the old two argument way of logging has been removed. The {} notation is new but has not replaced the old way.

In short, the log statement above is perfectly valid.

It looks fine to me. Have you loaded it into Designer 0.8 to see if there is some subtle syntax error?

Try using Boolean rather than boolean. It shouldn’t matter but


Try being explicit

if(sentTemperature == false && ...
4

Thank you for your responses. I have not had much time to troubleshoot this problem. However, I do have a little more information:

The following works perfectly:

var boolean testBoolean = false

rule "home.rules"
when
            Time cron"0 0/1 * * * ?"
    then

        if (testBoolean){
                sendNotification("me@mydomain.com","testBoolean is false")
        else
                sendNotification("me@mydomain.com","testBoolean is true")
        }
end

So I am going to build up the rule I need from this. If it fails, I will repost here for help.

Thanks,
Brad

5

I’m confused, doesn’t the logInfo need the additional initial string that names the log entry?
Like: logInfo (“NameoftheRule”,“MyItem is:{}”, MyItem.state)

6

To be honest, i was not aware that there was a old or new way with logInfo. Rich is much more in details. I use it with the {} and it works and found that in the documentation.

So I thinks its worth to give it a try.

Unfortunatley debugging in OH is not very easy and from my side the beat approach is do log each line while searchin the error. so i am able to identify the right position. But first step is always to use the designer and see what it shows.

Thomas

7

I was referring to the string “Demo” in the below quote of docs.openhab

For each log level there is an corresponding command for creating log entries. These commands require two parameters: the subpackage (here: Demo) and the text which should appear in the log:

logError(“Demo”,“This is a log entry of type Error!”)

8

Ahhh, i read you first example not correct, The basic syntax is as described and the {} is for dynamic parameters in the second part.

Thomas

9

Thank you very much for the ongoing discussion about the log entries. I had read the information in the documentation, but it was pretty brief and I was not able to get it to work.

For someone who is just coming up to speed on logging (but I have been running Openhab for more than a year), the first thing I tried was:

logInfo("Why does this fail silently and not create any entry in the log?")

Intuitively the statement above would create an entry if the log level is Info or above with text, “Why does this fail silently
”. Unfortunately, it fails silently without any error messages.

Of course the correct entry would be:

logInfo:("WhatDoesThisDo",This text will appear in the log")

My question is, what is the function of the first entry in quotes in the logInfo statement above? I am sure it can be used to categorize different types of log messages, but is that all it is for?

10

Yes it does.

bgilmer’s original is correct:

logInfo("Temperature: ", TestTemperature.state.toString())

Dibbler42’s is incorrect:

logInfo("Temperature: {} ", TestTemperature.state.toString())

but a slight change would make it correct:

logInfo("Temperature: ", "{} ", TestTemperature.state.toString())

I actually missed that it was missing the two arguments and the point of my reply was to point out that even though the new {} notation has been added, the old way is still valid.

:joy:

It shouldn’t fail silently. It should generate a no such method type error. I find it odd that it fails silently. Designer would point that out as an error. All of the log statements take two arguments, a logger name and the message. If you use the { } notation, you have one additional argument for each { } in the second argument.

It is more than just categorization. It defines a separate logger. You can edit the logging configuration to, for example, log all the output from the “WhatDoesThisDo” log statements into its own file. At a minimum, you will find that text in the after the date time and log level part of the logging statement which gives you something to search/grep on.[quote=“bgilmer, post:9, topic:28423”]
Of course the correct entry would be:

logInfo:(“WhatDoesThisDo”,This text will appear in the log")
[/quote]

Actually, the correct entry would be:

logInfo("WhatDoesThisDo", "This text will appear in the log")

Note the removal of the :\ and addition of an opening quote to the log text.

1 Like
11

Thanks - of course.

FWIW, I am coming at this as a long-time (BSD 4.3??!!) Unix sys admin. So when you say you can define a separate logger, I immediately start thinking about syslog, and I am then not exactly sure what you mean.

Whether I am looking at /var/log/openhab2/openhab.log or using Karaf and log:tail, I see all of my logInfo commands going into the overall openhab log. Are you saying that Openhab creates a number of separate logs but they are somehow munged together into one overall log when I look at them using Karaf?

As you have no doubt guessed, I am just using VI to edit rules files, so I will install Designer and see how that works. I assume the best way to do this is to use a SAMBA share to access the running files on my Raspberry PI remotely from my desktop running designer?

BTW, if you can point me to some documentation then I can look it over and not keep asking a long series of questions.

12

In programming, you can separate the logging for different parts of your application and apply different rules and properties for each individually. For example, you cna turn off logging for one major subsection and turn another subsection up to TRACE level logging. You can split out the logging from one section into a separate file. And so on.

Look in /var/lib/openhab2/etc/org.<cant remember the full name>.logging. You will see two loggers defined by default. One catch-all logger that puts most everything into openhab2.log and another one that puts everything that goes on the event bus into events.log.

One common thing to do when debugging problems is to put the logging from one specific binding into TRACE level and into a separate file. See

http://docs.openhab.org/administration/logging.html

Not quite. OH creates lots of different loggers that are all configured to go to the same file except for the event bus that goes to a separate file. When you are in the karaf console you are seeing the output from all loggers, but again, this is by configuration. Though the nice thing about the console is you can change the logging config on the fly.

Make sure to get version 0.8 of Designer and yes, most people seem to use SAMBA to share out /etc/openhab2 folder. I believe openHABian does this by default.

Beginners Tutorial
Main Docs Page

13

Thank you so very much for these answers. It all makes perfect sense. I am not a programmer, but I have done some coding in “C”, and have written many Debian scripts. I am familiar with TRACE, so what you are saying about putting different areas into different loggers makes perfect sense.

Okay on the 0.8 version of Designer. I will check to see what I have. The SAMBA share is no problem - I will configure this now.

The documentation. Hum. I have gone through the tutorial and the docs page. I will go back through them again, but I have a feeling that this level of information is not there. At least I hope not - I try very hard to read the available documentation before asking questions.

There is a section on logging in the docs for sure, but I needed a little more context in order to be able to understand what was written there. Now that I understand the basic premise, I know what the doc entry on logging was saying. Thank you.

14

Just thought i would check back in to report what has happened.

I began building up the rule from scratch starting with the simple example I had above. When I got done, eveything worked. So I do not know exactly what was wrong.

One thing I did note as I was going through this exercise - sometimes, when I had an error in a rule, I would get an error message in the log, and then I would back out my most recent change, try executing the rule and
 nothing. It would not work. Which was crazy, because I was keeping careful track of what I was doing and the exact same rule worked before. I am not sure I am being clear, so let me explain another way.

  • Start with simple rule that works.
  • Introduce a change which generates an error message in the log.
  • Delete the change so I go back to the simple rule.
  • Run the rule. Silence. The rule does not succeed. The log has no errors. Silent death.

At this point I would stop openhab and then restart it.

  • Rerun simple rule. It works just fine.

So from this, I surmise that sometimes, the openhab rule engine chokes on a rule and dies. It utters an error message, but you don’t know it has quit. Now if you try to run a valid rule, it is still dead, so the rule does not run.

I suspect that this is what had happened at some point - the rules engine quit and I was unable to tell whether the rule was fixed or not.

Anyway, all working okay now. Thanks for the help.

15

Especially given you have a set procedure for reproducing this behavior, I recommend opening an issue on the Eclipse SmartHome github (I think. I’m sure someone will pop in and tell me no, it should go to the openhab github.). This behavior is not correct. It may be related to other reports where rules files are failing to be loaded when changed.