Frustrating UI's not reporting state of Contact

[denisdmenace (Denis)]

Hello community,
This is trying my patience…need someone to help please.
Rain sensor unit outside which delivers open or closed contacts to a Fibaro FGK101 Door/Window Sensor mounted inside which reports rain or not in OH. Outside rain sensor is perfectly fine. Problem is Openhab NOT reporting output state changes of Fibaro Door sensor. Shows stuck in one state (Raining) and it’s clearly not. Am testing the Fibaro FGK on its own on the bench in front of me, closing/opening the INPUT contacts with a little switch, and looking at LACK of response by Openhab. Have State and Profile transformations set up on Item to translate Open/Close outputs from Fibaro to Raining/Dry values for the various OH UI’s.
The OH card based UI doesn’t report any changes - it’s stuck at ‘Raining’.
The older Sitemap UI doesn’t report any changes - it’s stuck at ‘Raining’.
HabPanel doesn’t report any changes - it’s stuck at ‘Raining’.
But wait for this… NODE RED correctly responds and shows the state changes and translations!! I attach screen shots to show this. Can anyone help on this please?
Problem started when I migrated over to OH3. Am now on OH 3.1.0 M4.
Have excluded & re-included the Fibaro many times, removed and set the items up again and linked/unlinked many times, started/restarted OH, Healed the Device blah blah… the usual merry dance.
Why can Node Red report and behave as expected but none of the OH UI’s can perform??

[rossko57]

@denisdmenace

Why can Node Red report and behave as expected but none of the OH UI’s can perform??

Is there any reason to think they/you are looking at the same Item? (There is not, from what you have shown us.)
What does your events.log have to say about the Item concerned?

[denisdmenace (Denis)]

Ross they are all looking at same item linked to correct channel as far as I can see…unless I’m losing my marbles… screen pics below.
Nothing at all shows in the event log which is strange.

[rossko57]

Okay, we don’t know what you expect OPEN/CLOSED to mean in terms of raining or not.

MainUI channel display shows OPEN. Is that good? This will not get mapped because it is an admin tool, it’s supposed to show you the raw state.

Your sitemap is going to try and do a MAP transform on OPEN/CLOSED to something, but we can’t see what from here,or if you have MAP add-on installed.
What’s in the sitemap will not affect what you see in MainUI, it’s only used for BasicUI and other sitemap-using apps.

@denisdmenace

Nothing at all shows in the event log which is strange.

The the Item is not changing, and Node Red is looking at something else.

If the Item is not changing, stop fretting at UIs and transforms, they’re no use until that problem is addressed.

[denisdmenace (Denis)]

I do have a MAP transform installed & working, sure how else would Node Red manage the transform.
Fibaro is config for Normally Open (NO) INPUT. When it’s DRY, Rain sensor unit presents OPEN contacts IN to Fibaro and Fibaro OUTPUT reports CLOSED. Thus Map coverts CLOSED to DRY. Conversely, RAIN makes Rain Sensor unit present CLOSED contacts IN to Fibaro which then reports OPEN OUTPUT which translates into RAIN. Yes the perverse logic is to do with how Fibaro is configured, but it used to work fine.
Yes I understand the MainUI is the raw state and it’s showing stuck at OPEN which is getting translated into RAIN on the other UI’s.
So the mystery is why Events log shows nothing and the Main UI shows no raw states changing and yet Node Red, which is definitely looking at same item, reports everything correctly. I’m baffled but will keep looking at it. Must be something obvious missing or something stupid I’m doing. Thanks for your replies anyway.

[denisdmenace (Denis)]

I have solved it myself.
Node Red WAS looking the same item as OH was supposed to be reporting upon, so it wasn’t a case of them looking at different items.
Quite simply OH had (and it has done this before on occasions) got itself 'into a knot or frozen state resulting from some conflict between item State Descriptions, Metadata, Channel Profiles, Category icons and Transformations. OH UI’s (Cards and Basic UI and Habpanel) were supposed to show a rainy cloud icon for rain and a sun icon for dry (my custom icons) and also append the text ‘raining’ and ‘dry’ as appropriate.
I set up a rule to trigger on this item changing just to confirm the item was frozen and indeed the rule didn’t trigger.
I unlinked and deleted the Rain Sensor item that had been frozen despite being correctly linked to the correct channel (remember Node Red had no problem and was able to report correctly). Then I recreated the ITEM as a ‘Door icon’ category and linked it to the channel again but did not explicitly add any profile and it all started responding again. Door Icon animated ok and text CLOSED/OPEN reported correctly AND the rule now triggered. I then edited the Door icon to my custom icon for rain/sun and that animated ok. Then I did the State Description MAP transform to get the text Dry/Raining.
I had problems with this Contact item before and realised from re-reading my notes I had made that if you fill in the channel profile with the Map name as well as filling in the State Description Pattern window with the same Map name, the UI’s can ‘lock up’!!
In contrast, with other items, I have found that the Map Profile button gets automatically chosen after I had only filled in the State Description Pattern and yet everything worked/reported ok, there was no lock-up.There seem to be system conflicts/inconsistent behaviour in this area.

[rossko57]

It’s a pretty weird configuration. Note that editing profile settings in-flight is known not to work well at release version, and not pick up until next reboot.
You did say you were using a profile, I missed that.

You do realise that a profile operates on transforming Item state passing between channel and Item, and Contact type Items can only take state OPEN/CLOSED?

@denisdmenace

I have found that the Map Profile button gets automatically chosen after I had only filled in the State Description Pattern

Really? I think there may be some confusion between profiles and transformations (which may be used in many other places too).

[denisdmenace (Denis)]

Hi Ross,
Some screen shots below of it all working as expected.
Yes I may not have been clear on the subtle difference between Profiles and State Transformation Maps. Indeed I am not clear when to use either or both and when NOT to use them. Can anyone spell out examples to guide their usage? Yet Node-Red could operate fine on the item despite all this stuff!
I also attach a pic of the Rain Sensor item config which doesn’t ‘like’ a Profile. The sensor produces only OPEN/CLOSED as you say. I do put in a Transform Map in the Basic Sitemap (built with VS code) because I prefer Sitemaps & HabPanel to those Cards.
I also attach a pic of a Leak alarm in my attic. It only produces ON/OFF yet it’s OK taking a Profile. It also has a Transform Map for the Basic UI.
So I’m bloody confused by this stuff and the inconsistencies.
Sorry about the long message, I wanted to clarify as much as possible. Thanks again for engaging.

[rossko57]

@denisdmenace

Can anyone spell out examples to guide their usage?

Profiles are applied to the link between the Item and a channel. They modify in some way the state updates or commands being passed over the link, before they get to the other side.

For example, you could use a transform profile to apply a MAP to data “2” incoming from a binding, and convert it to “Tuesday”.
But be careful of consequences - “Tuesday” cannot be used to update a Number type Item.

There are other profile types, for a drastic example one type converts any channel update to a datetime of ‘now’ - a timestamp generator.

Where you have a channel of type contact (providing states OPEN/CLOSED) linked to an Item of type Contact (accepting states OPEN/CLOSED only) there is little use or meaning for a profile.

---

State Description is a property of each Item, describing how to present its state data in a UI. It does not care where that state data came from. It massages the data to prettify for the viewer - typically limiting a number to one decimal place, or arranging a date in local format.
Importantly, it does not affect the Item state at all.

A more drastic way to use State Description is to apply a transformation here. Again, for an example we could use a MAP or a SCALE to convert state 2.0 into “Tuesday”. The Item state remains 2.0, the viewer sees Tuesday.
Beware of consequences here too - you cannot format the decimal place in “Tuesday”, its just a string now.

Using a MAP transform for the display of a Contact Item is not unusual, converting OPEN/CLOSED to more appropriate “Stop/Go” or whatever. The Item state remains OPEN/CLOSED.

---

When using a sitemap, you also have the opportunity to describe a State Presentation which is just for that particular widget.
As with the Item presentation, it does not affect the Items actual state. In this case, it does not even affect the Item presentation elsewhere - you might even have another widget in the same sitemap showing the same Item state with a different presentation.

---

Transformations are general purpose tools that can be used at many places within openHAB. Three different places described above, there are others such as within rules, or binding settings.

[denisdmenace (Denis)]

Hey Ross,
Thanks very much for that excellent overview with good examples
I understand the nuances much better now.
Just to be absolutely sure I understand:
If one applies a Map transform PROFILE in that Item window, like there is in the pic of my Attic Flood Alarm, that could be risky because it will affect the state update coming over the link to the item itself. I should really put the transformation as a State Description Map under the Metadata heading it the item’s edit window.
Have I got it straight now?
Finally, should one reboot after any in-flight updates of profiles, or indeed in-flight Map transformations because of what you mentioned earlier?
Thanks again for your help.

[rossko57]

@denisdmenace

If one applies a Map transform PROFILE in that Item window, like there is in the pic of my Attic Flood Alarm, that could be risky

It’s only “risky” if you don’t know it is doing, which involves understanding the nature of the parts involved.

It would for an example be perfectly reasonable to use a transform profile to mate a switch type channel giving ON/OFF state updates, and MAP those to OPEN/CLOSED to update a Contact type Item.

Use the same arrangement for a Switch type Item, it will fail - the Switch does not accept the transformed OPEN/CLOSED updates.

@denisdmenace

should one reboot after any in-flight updates of profiles

Maybe. I think the resistance to change is improved in recent OH versions.