Rules, openhab vs habmin

Hello Everyone,

If I understand it correctly, I can define rules in both openhab and habmin.

Any pros and cons for these approaches?

thanks.

Iā€™m not sure you do understand it, but that is not a problem, here is an explanation. habmin is an IDE (Integrated Development Environment) designed exclusively for openhab. openhab is really the runtime so you donā€™t define rules ā€œinā€ it. You can use a straight text editor or habmin to write code in a rule file for openhab to execute. habmin is a good tool to use because like other IDEā€™s it is aware of the syntax used in the rule files, sitemaps and items files so it helps you visualize and check the code as you write. It also has some code assist to help you with knowing what commands are available.

Perfect. Thanks for clarifying that.

I think you are actually describing openHAB Designer. In Habmin2 there really isnā€™t much typing to create a rule. Instead it looks to be based on Scratch where you build up the logic of the rule by dragging and dropping and not have to worry too much about the text syntax.

One pro to using Habmin is that the interface and approach to development is a little more intuitive to non-programmers. The con though is that there might be limitations as to what you can do in Habmin and the rules it generates may be more difficult to figure out verses hand coded ones.

Thanks @rlkoshak

am gonna start trying building some rules for my home now. looking forward to it.

Yes I was describing openHAB Designer, sorry for my mistake. I havenā€™t moved to openHAB2 myself an prefer the programmer way of doing things. Thanks for clarifying this for @rm65453

Just to be clear, Habmin is an addon to openHAB created by Chris Jackson is not necessarily part of openHAB, though if you do z-wave it is almost a must. Habmin 1 has ceased development in favor of Habmin 2. Either version works with openHAB 1.x and both versions have the graphical Scratch based rules development feature.

I do not believe that openHAB 2 is going to remove the ā€œprogrammer way of doing things,ā€ at least when it comes to rules development. I know one of the main focuses is on making configuration (i.e. openhab.cfg) much easier to manage and adding some automatic discovery and configuration of things which are today manual. I also know the rules engine is undergoing a rewrite. But I donā€™t think the rules syntax is going to change that much if at all.

I personally havenā€™t moved to OH 2 yet primarily because the z-wave plugin isnā€™t ported yet. Plus, I want my production home automation stuff to be more reliable than OH 2 is ready to provide.

I already have a thread relating to my rule building woes but thought I should post here as well.

I have created a rule from one of the examples but it doesnā€™t seem to work. How should I approach the debugging when nothing shows up in the log?

I would suggest to make sure you start openHAB in debug. In my case I just launch start_debug.sh or (.bat) instead of openhab.sh (or .bat).

Then sprinkle a bunch of log commands in the rule. Something like this, obviously using the Item or Items you would be interested in knowing the value of at a given point.
logInfo(ā€œWhatever you want hereā€, "Light_Switch at this point = " + Light_Switch.state.toString)

Debugging openHAB can be pretty tricky. When nothing at all appears to happen this is the process I follow:

Check the binding is working:

The exact steps will usually depend on the specific binding.

The first thing is to make sure the binding is installed so check the addons folder and make sure the jar file for the binding is there. This goes for all bindings.

Next I make sure it is configured correctly in openhab.cfg. Each binding has its own section and the meanings of each property is documented in the wiki page for that binding.

Now Iā€™ll restart openHAB and watch the log. As openHAB starts up there should be at least one INFO level line for each of the bindings as they successfully load. For example:

  • MQTT: ā€œStarting MQTT broker connection ā€˜mosquittoā€™ā€
  • HABmin: ā€œStarted HABmin REST API at /services/habminā€
  • ZWave: ā€œSerial ports has been initializedā€
  • NTP: ā€œNTP refresh Service has been startedā€
  • NetworkHealth: ā€œNetworkHealth Refresh Service has been startedā€
  • Astro: ā€œAstroConfig[latitudeā€¦ā€
  • Nest: ā€œNest Refresf Service has been startedā€
  • Weather: ā€œStarting and scheduling weatherJob-home with interval of 10 minutesā€

If I donā€™t see these lines in the log I know that binding has failed to load for some reason. You can tell which binding the log comes from by looking at the square bracketed part just before the text of the statement. For example:

2015-10-04 10:32:13.302 [ERROR] [g.openhab.io.net.http.HttpUtil] - Fatal transport error: java.net.SocketTimeoutException: Read timed out

The above log statement breaks down as follows:

  • Timestamp telling me exactly when the error occured
  • The ā€œseverityā€ of the log statement. This will be, in order of increasing severity ā€œDEBUGā€, ā€œINFOā€, ā€œWARNā€, and ā€œERRORā€. By default the logging level of openHAB is INFO which means that any log statement of severity INFO or above will be logged but anything below (i.e. DEBUG) will not be logged. So when @George recommended putting openHAB in debug, what he is saying is to change the logging level to also include the DEBUG statements.
  • The next bracketed section is ā€œwhoā€ is generating the log statement. In the above example I know that the HTTP part of the core openHAB is what generated the log. When you add logging statements to your rules, you will see org.openhab.model.script.<Name> where <Name> is the first argument in the log statement (e.g. logInfo(ā€œFooā€, ā€œMessageā€)) will show up as [org.openhab.model.script.Foo].
  • Finally, the last part of the statement contains the actual log statement where, in this case the error is described.

With this information you should be able to at least determine which binding is generating the error and possibly why. For example, if I get an error statement from the ZWave binding saying it cannot find /dev/ttyUSB0 I know that either my zwave stick is unplugged, it moved to another device, or the openhab user doesnā€™t have permission to read/write to it.

Checking that the Items are configured correctly:
If Iā€™ve convinced myself that the binding is working I need to make sure that my Item is configured correctly. Sometimes you will see errors in the logs complaining about invalid Items that canā€™t be loaded but the parser is pretty forgiving so there isnā€™t always an error. Also, a lot of time you may have something perfectly valid but incorrect for what you want to do. For example, if I have an Item that is supposed to be populated by data published to an MQTT topic and I define my Item like this:

Contact N_D_Front "Front Door [%s]" <frontdoor> { mqtt=">[mosquitto:entry_sensors/main/front_door:state:default]" }

I will have an error but openHAB will be perfictly happy with the Item. The error is that as written it is configured to publish to the MQTT topic, not received data from an MQTT topic. It should be { mqtt="<.

To solve these sorts of errors you need to read the wiki page for the binding you are trying to use and compare what you are doing with what the wiki says.Some experimentation can help here as well. Also, putting lots of your items on a sitemap just to see what they are set to can help as well.

Another place to look for help to see if your items are working correctly is the events.log file. Every update or command to an Item generates a log statement in this file. So you can check here to see if the Items you are trying to debug are receiving the events you expect or not.

Debugging the Rule:

Once Iā€™ve verified that the binding is working and the Item is generating and/or receiving events as it is supposed to I know the problem must be with my rule.

First add a log statement as the first line of your rule to make sure it is triggering at all. Next add a logging statement after each major section of the rule to see how far the rule is executing before it dies. You should be able to narrow it down to a single line of code. Now add log statements for all the Itemā€™s states and variables that are used there to check that they are set to what you expect.

Ask for Help
If you get stuck on any of the above come back to the community and ask for help. When you do ask for help be sure to provide as much relevant information as you can. This includes:

  • what bindings you are having problems with
  • copy and paste your Items you are having problems with
  • copy and paste the rules you are having problems with
  • copy and paste the part of your sitemap you are having problems with
  • copy and paste any relevant logs, in particular errors and warnings.

Not all of the above will necessarily be relevant. For example, if the binding isnā€™t coming up we donā€™t need your Items, rules, or sitemap but absolutely need the logs. If you are having problems with the Item showing up correctly on the sitemap we need your Items and Sitemap, and maybe your rules but not the logs if there are no errors in the logs.

Sorry for the wall of text. Iā€™m starting to work through the sorts of things that need to be in a Quick Start and Beginners guide and posting these long and more explanatory postings is helping me work through that. :slight_smile:

1 Like