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!).
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.
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.
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.
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.
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? …