I agree with everything you just said. This doesn’t seem all that well thought through.
It may still be a tiny bit easier than defining generic items for everything… but then again I’ve spent several days on Homie now with not a lot to show for it.
I did learn to use AsyncMqttClient rather than PubSubClient and I did write (and publish) my own library, which was a first for me… so I guess any knowledge is good knowledge.
If you think there is something wrong with the way the slider (or up/down jiggler) in UI works, there will be a difference in the commands logged in the events.log
If you think there is a difference between the way that Number type Items and Dimmer type Items are handled by the binding, you can create one of each Item and link to the same channel for a demo.
I’ll throw in a wildcard; the format [ ] in the Item definition label CAN influence values exchanged between binding and Item. Something to do with UoM, meaning I dunno how that works.
Maybe try with no [ ] content to see default behaviour. Or rather, no [ ] at all.
This is about Item, not sitemap entries.
@leif - it’s a shame as I do constant battle with the homie3 spec and always come away feeling it’s still lacking. Indeed if I create a dimmable bulb in homie3 I get the two UI objects of number and on/off in OH . If I create a colour bulb I get the three sliders for hue, saturation and brightness. Inconsistent.
Also OH does not seem to re-read the homie topic for new devices - even if you take $state back to init and then ready (which it does notice, but it doesn’t refresh).
Also if you create topics that specify an update interval then OH was very fussy about that happening ontime. This may have chnaged I don’t do that - rightly or wrongly
However I’ve also implemented the HomeAssistant MQTT discovery protocol and use that to import to OH as well as HA (this has the advantage of working on both). It’s also a lot easier to implement, just 3 MQTT topics (state, set and the config payload). I’m not sure if your goal is to just get your nodes into OH via some flavour of MQTT discovery or to specifically use homie - but it’s an alternative approach.
My goal was just to get nodes into OH via some flavour of MQTT discovery. Had I known what I know now, I may have tried the HASS approach instead! 
Hey, about three weeks ago (feels like a lifetime) when I was deciding which open source smart home system to go with, based purely on marketing blurbs or whatever other written information I could find, I actually chose Home Assistant over openHAB! I installed it, and got handful of Z-Wave devices in. The devices showed up as a hot mess of individual items and properties with no hierarchy whatsoever.
I actually found a screen shot I took to show a friend at the time (Snagit history ftw!).
Holy crap. I don’t think I spent more than a few minutes until I realized “this ain’t gonna work”, and instead looked into openHAB… and the rest is history.
How is HASS working for you? How are you using it? Are you using any Z-Wave devices?
I came from Fibaro HC2 so most of my network was Z-Wave.
Would love to see some screenshots/pictures of your setup.
I’m not leaving openHAB at this point (finally starting to get the hang of it after A LOT of time invested) but I am curious.
If anyone else is watching I’m being unusually quiet because I’m finishing up my esp8266 homie library
I’m sort of in that same boat but did the reverse of you for various reasons choosing HA . I used OH about 3 years ago, with some pain. But I will use both for a while just in case I did make the wrong choice. I too come from Fibaro (and HomeSeer / Vera / HE)
Well yes… this ‘parts explosion’ as I call it happens. Each entity appears as a separate bit of information. But you then can group these back onto a single card. However I have now found out how to discover these under their parent device from MQTT directly but it still requires a small UI config step to then make that card appear. So I’ve contained my ‘parts’ explosion’ - but would prefer it to be more a bit more straight forward.
It’s the same sort of here in OH though isn’t it ? The dimmer control - currently numerical and the on/off are separate and you have to UI edit to make them appear as you want ? You’re creating manual item entries for each discovered device still ? The channels are sitting under the homie ‘device’ in OH rather than the ‘node’ ?
I have just started on OH really so nothing exciting to show and I’m rather loathe to post screenshots from a competitors product but can send you some privately if you wish.
Sorry forgot to add I only use Z-Wave and ZigBee if I have to. I’m just not comfortable with the reliability even as an RF Electronics Engineer ! I see so many grief and frustration stories.
Nearly all my home devices (lighting, heating, security, AV) are wired bus or Ethernet (WiFi is OK). When I do use it it is on HomeSeer (Z-Wave) or Hubitat Elevation (ZigBee) and hence my interest in MQTT bridging of devices… also the Z-Wave and ZigBee to MQTT projects.
You should be a politician 
For MQTT maybe, but for Z-Wave, openHAB does a remarkable job. Device support is second to none, including commercial products. A couple of hitches here and there (i’ve never been able to get it to exclude a node) but overall I’m blown away at the quality of Z-Wave handling in a free, open source product made by volunteers which has bindings for probably close to 100 technologies by now. Z-wave + JSR223 (Python) scripting is what sold me on openHAB. Not to mention the level of support I’ve received here! With all this, I knew I could make openHAB do what I needed it to eventually, even if I would have to beat it into submission. There’s enough there to work with.
My HomieLib seems to work nicely with openHAB now. I’m not quite sure what the first project to actually use it will be… maybe my doorbell, which already has an ESP8266. After that maybe I’ll tackle my sliding gate controller. That one deserves a thread of its own one day!
Sure, PM me a link to photos of your setup, would love to see.
There is an issue open for that. That’s why we introduced “extensions” to allow vendors to define “types”. Homie is a discovery specification, not a home-automation-semantics one.
We as the openHAB community should maybe propose an extension to define some basic types, that the openHAB controller than understands and presents correctly.
That’s true. openHAB reacts to node and property re-publishing though. It only listens to $nodes and $properties. If a single attribute in the topic tree changes, that goes unnoticed.
Agree, we some basic types defined. At least to match the existing OH item types such as switch, dimmer, contact, etc.
I have built an ISY994 to Homie bridge - it creates about 300 or so Homie devices.
Also, a standard on naming of items created would be nice. Ie. using a combination of the device name and the property name.
When linking a dimmer item to homie channel, the allowed values are 0-1, not 0-100. Is this the intended behaviour?
Dimmer HomieTestDimmer "Homie Test Dimmer" {channel="mqtt:homie300:Queen:testdimmer:dimmer#dimmer"}
The range can be configured. 0-1 could be the default depending on your version.
Is the binding using the unit property to change the range? I have the datatype property set as float.
I know it has been a while but I am encountering this issue as well. Homie 3 spec is detecting everything as intended / i see the type set as integer and the range set as 1:100 in mqtt but openhab is sending decimals. IE 50% as .5 - this obviously doesnt work - how can we work around this? I can make the item a ‘number’ format and that kindof works as it doesn’t translate the 50 to .5 before sending but that also messes with other things like alexa control as its no longer a dimmer. I have 50+ bulbs so preferably anything I can do within the items file is preferred vs attempting to edit each channel in paper UI. even better - is there a way to force openhab to actually follow the homie spec as advertised rather than ignore it? I’m running 2.5.2 release build.
Thank you!
No, this problem keeps coming up and has been discussed but not formally addressed. I use .items files that look like below. What devices are you using?
Dimmer MF_PantryLight_Dimmmer "Pantry Light" <light> (gMF_Pantry,gLightSwitch,gOccupancyItem) ["Lighting"] {alexa="disable",channel="mqtt:homie300:Queen:dimmer-19d01a1:dimmer#dimmer", OccupancyEvent = "OnOff"}
Looks relevant
Mine is similar - however that fails me because openhab outputs a .25 for 25%. I’m using this with a hubitat hub so luckily I’ve been able to custom mod the code on the hub side to multiply this back out and make it into an integer. I honestly feel this is a no brainer that openhab should be following the specification defined in the homie 3 discovery (publishes a format of 0:100). I’m only doing this because the built in zigbee is useless to me now that there is no way to tell if a bulb is on or its dimmer state when it is in CT mode.
Dimmer Light_GuestShower_DM {channel=“mqtt:homie300:7d0ef5b3:hubitat:guest_2Dshower#dim”}
I’m confused by the wording of that - it says if there is a % character found within the unit value then it will send percentage - else it will do ‘the old way’. Isn’t ‘the old way’ how it is now where it is sending a percentage already? Why do we need extra attributes when you already have a defined range? we can map that with the fact a dimmer is always 0-100 and map it out. IE homie publishes range of 0-50. OH should then know 100% on a dimmer is 50 and 50% dimmer is a 25. This seems incredibly simple to me. Is there something I’m missing? …
Don’t ask me. So far as I can see, there are doubts about what the homie spec is, a % or a fraction of 1.
FYI, this has been fixed in 2.5.4. If a property has the % as the unit type, it is not longer converted to a fraction. The Homie4 python package has been changed to reflect this.