[ALMOST SOLVED] Point not created?

[Max77 (Max)]

Dear community

my journey in OH3 continues…

I have my homemade MQTT contact sensor (Homie 3.0.0) and I want to include in OH.

The MQTT side works perfectly when opening/closing the window

openhabian@openhabHost:~ $ mosquitto_sub  -v  -u openhabian -P <password> -t homie/esp_gateway/guestRoomWindowSensor/#
homie/esp_gateway/guestRoomWindowSensor/$name Guest Room Window Sensor
homie/esp_gateway/guestRoomWindowSensor/$type reed_sensor
homie/esp_gateway/guestRoomWindowSensor/$properties status,battery
homie/esp_gateway/guestRoomWindowSensor/status OFF
homie/esp_gateway/guestRoomWindowSensor/status/$name Status
homie/esp_gateway/guestRoomWindowSensor/status/$datatype boolean
homie/esp_gateway/guestRoomWindowSensor/battery 4.15
homie/esp_gateway/guestRoomWindowSensor/battery/$name Battery
homie/esp_gateway/guestRoomWindowSensor/battery/$datatype float
homie/esp_gateway/guestRoomWindowSensor/status ON
homie/esp_gateway/guestRoomWindowSensor/battery 4.15
homie/esp_gateway/guestRoomWindowSensor/status OFF
homie/esp_gateway/guestRoomWindowSensor/battery 4.15

I went on in the UI and created an Equipment from Thing, linking the two relevant channels during the creation phase

You can immediately see, that while the battery is immediately recognized and value assigned (4.15 V), the Status is in an UNDEF state. Below the point definition

The result does not change if I try to use a MAP transformation.

The “funniest” thing - filtering the log file for this particular points, I can find only this

2021-01-21 21:10:44.170 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'espgatewayWindowSensorGuestRoom_GuestRoomWindowSensor_Battery' changed from NULL to 4.15

So, no trace of the battery item.

What is the next debug step I can take? Or is my mistake clear to everyone but me?

Max

[hafniumzinc (T)]

Can you show the Channel definition that’s linked to the Contact Item?

@Max77

So, no trace of the battery item.

Isn’t that exactly the battery Item in your log?

[Max77 (Max)]

@hafniumzinc

Apologize, I meant the status item, of course.

Below the link definition

[hafniumzinc (T)]

Can you show the Channel definition? The Thing Channel definition?

[Max77 (Max)]

Below the Thing definition and the relevant channels. FYI, it is a Arduino based system (self-programmed) with a single micro-controller acting a gateway for all sensors and communicating with the MQTT broker (publishing channels, sending updates).

Can you spot anything?

[hafniumzinc (T)]

Can you click Configure Channel for your Status Channel and show the configuration?

Or just click the Code tab and copy/paste the YAML!

[Max77 (Max)]

I slowly see where you are getting at Perhaps cannot it taken as boolean?

Below the screenshot - is it normal I cannot see the code? The tab is empty - does it need some time to be generated?

[hafniumzinc (T)]

@Max77

Perhaps cannot it taken as boolean?

Yeah, that’s what I was suspecting, as you’re sending ON and OFF. I don’t use the Homie convention, so don’t quite recognise this configuration page. What options have you got for Data Type? Is this all the page shows, or are there more options?

Or, I guess, change your code to send 1/0 or true/false?

[Max77 (Max)]

There are the usual options

• Integer
• Float
• Boolean
• String
• Enumeration
• Colour

I quickly tried String w/o success.

[Max77 (Max)]

Ok,. I am getting there…

The point is actually defined as switch - if I change to switch I can see ON/OFF.

But I guess I can go to the source of the problem and reprogram the gateway to define the sensor as a contact - as it has to be

Give me another 5 minutes

[Max77 (Max)]

Found it!!!

Actually I am sure there are a couple of guys around in the community who are rolling their eyes and laughing like mad

I found this post and I understood the whole issue

1. Contact accepts OPEN and CLOSED states only - ON/OFF are related to switch type
2. Actually homie specs define only true/false as valid payloads
3. BUT, since I am the owner and master of my sensors I just reprogrammed the gateway to send OPEN and CLOSED, violating the specs but avoiding the issue @rossko57 described (channel transformation maps to a string and makes the value unusable for Contacts)

Everything seems to work now!

@hafniumzinc

thanks for your online support

[rossko57]

@Max77

avoiding the issue @rossko57 described (channel transformation maps to a string and makes the value unusable for Contacts)

That issue should now be fixed in OH3 - a transform profile still yields strings but any type Item will (try to) parse it into something suitable for the Item state. So a transform profile yielding “OPEN” should work with a Contact type Item.