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?
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).
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?
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
Contact accepts OPEN and CLOSED states only - ON/OFF are related to switch type
Actually homie specs define only true/false as valid payloads
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)
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.