All,
I would like with the dev team understand if the issue
is due to design choice and - if yes - where I have to look in the code to understand how to modify my sensors to match such choice.
A summary of my issue: I have MQTT sensor publishing OPEN/CLOSED topics that are discovered as “switches” instead of “contact”.
Thanks for your help!
Max
P.S.: I love OH, so I am not going to give up before finding a solution 
openHAB derived channel type seams to be based on datatype property. If it seems type boolean it identifies as Switch. See openhab-addons/Property.java at 7141a091ff29946136ec562f1f5aea4624dbf64f · openhab/openhab-addons · GitHub
But I don’t know the design or choice behind this.
Thanks a lot! This explains a lot! I cannot see any place where a openClosed channel is created…
Does it mean that the Autodiscovery in Homie does not support Contact channels? I can agree that it is not possible to distinguish between the two, unless the payload is examined…
What actual homie datatype are you identifying as?
If you must link a switch type channel to a Contact type Item, you can do that with a transform profile set on the link. Probably a simple MAP type.
If I read the code correctly. Then yes it does not support Contact channels.
I think this could do the job and I will try. Actually I can even reprogram the microcontroller to send “switch” payloads ON/OFF instead of OPEN/CLOSED. Just to be consistent for a future enhancement of the homie discovery able to support Contact channels.
I will also have a look to the binding code and see if there is a clean way to get both type (or more) of boolean nodes supported.
Max
If you can determine the difference between a homie read/write boolean and a homie read-only boolean, then the OH binding could be enhanced to discover either Switch or Contact type channels.
I thought homie required true/false for boolean payload.
This is exactly where I think the binding is not compliant with the standard - if I look to the binding documentation
The contact channel by default recognizes
"OPEN"and"CLOSED". You can connect this channel to a Contact item. The switch channel by default recognizes"ON"and"OFF". You can connect this channel to a Switch item.
This is exactly what I tried when I reprogrammed my microcontrolled from ON/OFF to OPEN/CLOSED - w/o success, since in the code boolean datatype are automatically assigned to switches (onOffValue).
I can surely work around that, but I would lose some of the elegance of OH 
But that’s the generic MQTT “things and channels” binding, requiring manual Things creation because it allows unlimited MQTT formats. This can be configured to accept ORANGE and LEMON as payloads for binary channels.
The binding also can detect and auto-configure Homie compliant devices. Things are auto-configured, the details are visible of course but should not need editing.
This part of the binding should be automatically taking care of converting Homie compliant data (true/false) into openHAB flavour (ON/OFF).
It might well be incomplete or buggy,mind.
The only “easy” option I can see is to use the currently meaningless Type node attribute. Both Homie standard
https://homieiot.github.io/specification/#node-attributes
and the current code
public class NodeAttributes extends AbstractMqttAttributeClass {
public @MandatoryField String name;
public @MandatoryField @MQTTvalueTransform(splitCharacter = ",") String[] properties;
// Type has no meaning yet and is currently purely of textual, descriptive nature
public String type;
do not care about this attribute. 
But, isn’t discovery looking at the $datatype? Integer, float, boolean, etc. and deciding the openHAB channel type from that?
If discovery only looks at that, Homie boolean must map to openHAB switch - because it might be read/write.
However - discovery could look for the optional $settable, and if does and finds it true, it ought to use OH switch, while if it is false it ought to use OH contact.
Homie spec actually defaults as ‘false’ in the absence of $settable, so really OH should default to contact type if absent.
However - it has long been debated amongst OH binding authors whether Contact types are only for doors and windows, and it’s okay to use Switch for any other read-only binary. You’ll find this in other bindings too, and to honest it’s not a great handicap. Historical oddity having separate read-only and read-write binary Items - there is no read-only Number Item type etc.
But in all cases, for Homie compliance the remote end should be sending true/false payload to boolean properties, and it is the binding’s job to convert to OH suitable channel updates.
Which part is going wrong for you?
thanks for the great insights in the history of the binding 
I did not know that such a simple sensor could create such philosophical questions among developers 
I have now made my microcontroller compliant (“true” → open window; “false” → closed). I can see that the channel has got the right settings (Retained, Non-settable) and is defined as switch.
If now I link the channel to an item switch, everything works fine, opening/closing the window will turn into an ON/OFF
2021-01-29 22:45:13.325 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'espgateway_GuestRoomWindowSensor_Status' changed from OFF to ON
2021-01-29 22:45:21.691 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'espgateway_GuestRoomWindowSensor_Status' changed from ON to OFF
Then I use a MAP transformation when linking the channel to the item (now turned into a Contact)
OFF=CLOSED
ON=OPEN
NULL=unknown
Have I got it right? Up to now it seems to work…
That’s the important thing.
I do think it would be reasonable to request a binding enhancement to interpret $datatype=boolean with $settable=false as openHAB contact channel.
But I wouldn’t expect any rapid interest.
I have opened a PR to resolve this.
Whether Contact is the best name for a generic binary sensor (ie not settable/controllable) is a separate discussion, but right now Contact is the best candidate (that I know of) in openHAB.