How to check for undefined in OH1

Hi There,

I’ve created the following rule for checking if Value is Undefined (OH1)

if (Humidity_Limit_GF_Bath.state == Undefined) {
  sendCommand(Humidity_Limit_GF_Bath, 65.0)
}

But this is never triggered so the values stays undefined.

What am I doing wrong?
Bests
Pascal

That you’re still on OH1.
In OH2, you would compare === NULL, not sure if that was applicable in OH1 (it’s too long ago).
Start moving to OH2.
You will have to rework those code portions anyway.

Thanks @mstormi for that useless answer. Anyone else?

You’re welcome. You obviously don’t want to hear, but moving to OH2 is the only reasonable resolution if you want others to solve your problem.

I simply don’t have the time for moving. I’m on it and do it step by step but it’s a bunch of work to do and I don’t want do shut down my home for weeks. So I have to build a system in parallel and when it’s done switching it to production.

It’s good advice but there can be practical obstacles to moving to OH2.
Meantime, OH1 Items can also have state Uninitialized

Don’t forget you can use logInfo() to find out an Items state.

A simple solution would be this one:

if (!(Humidity_Limit_GF_Bath.state instanceof DecimalType)) Humidity_Limit_GF_Bath.sendCommand(65)

instanceof DecimalType is “when it’s a decimal number” the ! is “not”, so the condition is "if the state isn’t a decimal number)
Please whenever possible use the method, not the action, as the action needs two strings (and sometimes the automatic casting will fail) where the method will use any input that suits the item, i.e. it will convert integer to float and so on…

Note that if you follow the Migration tutorial, you should be able to get your current config up to the OH 2.3 core running with your existing 1.x bindings and configs with a few minor changes to the Rules. You should have to shutdown your home for weeks. And you can even put OH 2.x on the same machine as OH 1.x, just don’t try to run them both at the same time. Then you can shut one down, start up the other one, make some progress on updates and changes for what ever time you have, then close it down and start up the old one.

It’s not an all or nothing process. You can chip away at it little by little as you have time.

But to more clearly state Marcus’s point, There are fewer and fewer people who use OH 1.8 anymore and as far as I’m aware almost none of them are contributors on this forum any longer. The number of people who will be able to help with OH 1.8 problems is rapidly diminishing to zero. At some point you will need to switch to 2.x or largely end up on your own as there will be no one left who can help.

1 Like

THX @Udo_Hartmann for your solution.

@rlkoshak it’s a little bit of history. I’ve startet the way you describe with OH 2.0 and I was shocked about the bunch of problems I ran into. In addition I didn’t have a profit of the migration (no new rule engine, no solution of problems like my problem in this thread, a intransparent configuration storage, …). So I decided to wait. After the KNX 2.0 binding was born, I startet with the migration, again. And wow - I have to add every item twice. Once as an item, once as a thing. Also when I started the migration, the binding died after 30min which only a reboot could fix. The current version seems to run on my stand by installation but I didn’t have the time going on with the migration.
Summary: A lot of problems, no benefit (except a better support here in the community).

See this.

I think you missed my point. It sounds like you are trying to migrate everything all at once.

Step one is to get all your 1.x version bindings, rules, etc running on OH 2. 1.x bindings work just like they always have.

Only once you have all your existing 1.x setup working on 2.x should you look at upgrading from the 1.x version of the bindings you want to migrate to. There is nothing that says you have to ever move to the 2.x bindings if you don’t want to or have no benefit from. And you should only migrate one at a time and probably should start with the simpler bindings like Astro.

So you take the migration in small stages. You would/should already be happily up and running and fully migrated to the OH 2 core before you ever start looking at migrating to the KNX 2.0 binding.

Not new but much improved with a much better IDE in VSCode and much better syntax error checking that tells you line and column numbers where syntax errors appear.

if (Humidity_Limit_GF_Bath.state == NULL) {
  sendCommand(Humidity_Limit_GF_Bath, 65.0)
}

But the real problem you have on this thread is there are not many of us able to help answer your question any more. The answer, where you using OH 2 is easy.

You can and many of us do have 100% text file based configurations. Except for the introduction of Things and splitting up of the monolithix openhab.cfg file, text based configs are the same as they ever were. You don’t have to use the UIs at all. But, should you chose to use the UIs to configure some or all of the OH config (I use PaperUI to manage my Things since I really like automatic discovery of things so I don’t have to “add every item twice”) all of that is stored in an easy to read and configuration control text based JSONDB file.

The fact that you had to come and ask this question points to the import of this “feature” of OH 2.