I get two channels created - you’re getting one I assume, and my dim level is a ‘Number’ so I think that is why we see different things ?
@xAPPO I just deleted my Homie thing to do what @rossko57 suggested 
hang on
This works! The slider results in (decimal) values between 0 and 100.
But hang on… what are “value transformations”? Are value transformations somehow getting imposed onto the Homie channel?
Noo I meant leave the homie thing alone and hand-crank a regular thing (different topic) as well - you can link two channels to the same Item and observe for differences in payload.
I might expect that if the OH homie implementation honours $format that it would use input and output transformations to map the values. They may remain ‘hidden’ but it would seem a logical thing to do. But I think that’s a red herring… rossko57’s suggestion will I think show a value between 0.0 and 1.0 .
At some point I had this working much better
It IS a regular thing!
I deleted the Homie Thing, and instead made a Generic MQTT Thing and tied a channel to a topic. The Generic MQTT Thing has no concept of homie and doesn’t know or care that i happened to point it at a single topic in an entire homie tree, right?
Agh, we sound like imbeciles. I wish they would named them something other than “thing”!! 
Okay I’m starting to get somewhere.
@xAPPO, that dimmer that I have and you don’t?
It’s coming from my Dimmer Definition in the items file!
Dimmer DimmerTest "Test Dimmer [%d %%]" <slider> (FF_Homie) { channel = "mqtt:homie300:homie:examplehomiedev:nodeid1#dimmer" }
I’ll bet THIS is where I need to specify my own value transformation!
I commented out all my homie items (keeping only the default channel links) and now Paper UI presents the following:
The dimmer is no longer a slider, it has little buttons to nudge the value up and down… and if i go outside the 0-100 range, it’s flagged as invalid by visual cues:
Okay that’s interesting. I’m going to go change the range ($format) of my Homie property to -64 to +64 in the ESP source code now!
…well, shit.
It works!!!
Now I understand how it’s supposed to be working.
So the whole 0 - 1.0 thing was a GUI CONFIG ISSUE all along??? It looks like @David_Graeff’s binding is totally doing the right thing.
One of the strange things about homie is that it doesn’t seem to define device types, or capabilities - just attribute ranges - although there is a $type it doesn’t seem relevant. Why a slider isn’t presented for a dim I’m not sure but there doesn’t seem a way to convey a ’ dimmable light bulb’ as a simple device to the OH UI - to just appear as such. Needs you to mess around with UI config.
I have no homie items in the items file.
OTOH That colour bulb device above was created from homie directly - not via some UI edit… can’t remember how as I’m not an OH user … strange
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
1 Like
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.
1 Like
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.
1 Like
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.