Thanks Mike - that's inline with what I've read too - although it doesn't 'solve' it unfortunately it does stop me spending any time on it.
Supporting the mapping of a single MQTT topic to several HE devices and then several attributes within, and alongside that mapping potentially many JSON keys in that one MQTT topic to several HE devices and attributes has left me with some interesting work in lookups.. I'm on it but it's quite challenging, and needs significant changes.
I may put out an interim version supporting multiple attributes and JSON in which one MQTT topic can only map to one HE device.
Meanwhile there's a pre beta2 link above for the adventurous (if you're not using virtual MQTT devices this I believe is pretty solid)
1 Like
Hi - newly switching to hubitat here. I got this beta set up and am using openhab with it. I noticed that with the color channel - openhab sends HSB with the brightness in range 0-100 but it looks like your code is expecting 0-1 for the brightness is that correct?
I've also noticed that the dimmer channel does a similar mismatch behaviour - if I define it as a dimmer in openhab the system sends .25 as 25% to mqtt which takes the bulb to 1% as hubitat is expecting 1-100.
I guess my main question is - does anyone else integrate this with openhab and are there any pointers to facilitate this? I've noticed a lot of complaining on the openhab side as far as importing the devices / my thing gets stuck in configuration pending.
Second question is - should there be a limit of the number of things I can expose via one MQTT app on the hubitat hub? I've got around 65 or so zigbee items and maybe 10 zwave items that I'm trying to share to mqtt. If i put them all in one MQTT app instance it seems that many of them dont get detected correctly within openhab / when I split them out they do.
my publish format is - homie 3 protocol, complete and compliant homie topics, retain homie states. I've left the HA discovery protocol disabled- when i had that on the devices were detected by openhab but never came online.
Thanks so much for all of your help on this - by being able to integrate hubitat I will finally have a strong / reliable zigbee network 
(openhab's inbuilt zigbee lacks some support for items I need / their recent strategy for handling only a color channel and ct channel while wiping the color channel out when bulb is in ct mode has completely rendered it useless - you cant even tell a bulb online status or brightness when it is in ct mode 
Wanted to follow up with this - watching the logs I noticed that hubitat was complaining because some bulbs didnt' have an active 'colorname' so the nulls caused issue. once i powered all bulbs and set to a ct the name populated and i reran the config. after that openhab shows online and all of my devices are listed within the thing in openhab.
Kevin,
Thanks for this app! It is exactly what I was looking for. I know that this is still in beta but was wondering if you can point me in the direction to resolve the log errors I am getting similar to the below one:
Unknown Category for type power reported by device Zooz Zen25 Plug #1
@jfrank1845 Are you citing HE devices exposed to OH via homie discovery or OH devices exposed on MQTT and imported manually to HE ?
I've been focusing on getting the HE<>MQTT aspects working well and secondly the HE<>HA integration. OH has had less attention because I don't personally use it and in the past it is OH itself that has been problematic with the homie implementation. Also very few OH users have responded with feedback so glad to have you here.
homie defines ranges for things like dim levels - and so OH should take account of that and adjust accordingly, for example when setting level - I think you're saying it isn't doing that.
Let me take a look, but possibly not immediately. I want to get beta2 out first (very close now).
BTW There is a specific topic for OpenHAB with MQTT app here, it's a better place to get an OH informed response.
I will try and get it working if it is something I'm doing wrong. colorname should not be an issue - I don't use that topic.
1 Like
It shouldn't be an 'error' is it ? More likely a 'warn' which are nothing to be worried about in the beta releases..
That's just means that at the moment I am not supporting the 'power' category reported by your plug device... a few bits still to expand on... (although I did think this one was already there)
Is there a character or something before 'Unknown' such that I can pin the exact line down. ? I'm guessing it's not [s] as I do handle 'power' there..
e.g. [o] Unknown Category ....
It is showing as an error.
errorMQTT: [o] Unknown Category for type power reported by device Refrigerator
There are other categories as well, such as energy.
Ah OK - it's not an error as such (wrong message) and it should be fixed in beta2. Thanks for reporting...
.. what other ones have you got ?
Is 'energy' an [o] ....
Do you happen to know what 'energy' is reporting alongside 'power' that is instantaneous watts. Maybe it's wHr or KWHr , or cumulative over a period ?
There are 3 categories that I see (power, energy, voltage) coming from 3 Zooz products (Zen15, Zen20, Zen25). These are all plugs.
From what I can ascertain these are the units of measurement for each:
Power - watts (W)
Energy - kWh
Voltage - volts (V)
thanks.. and 'voltage' is showing an error too with a [o] prefix ?
Yes, they all have the same prefix.
OK 'voltage' is going to take a bit more digging into as that shouldn't have been throwing an error.
I'm going to post beta2 in the next hour or so tomorrow. Voltage won't be fixed in that but the other two should. Update to that and let me know if you still see errors (although they would now be warns anyway)
1 Like
Will do. Thanks Kevin.
Thanks for the quick reply. I am just looking to export HE devices and control them in openHAB. I was able to change the data type from enum to text in your app to allow openHAB to import everything correctly - the OH thing now finishes configuration and goes online now.
Regarding the dimmer / hsb I do see where homie says to do 0:100 for the dimmer but OH def ignores that. I’ll have to put a ticket in on their board. For hsb That one OH is door brightness in 0-100 so it may be on your end why it always goes 100
Ahh OK - interesting - am I publishing a homie node topic with a $datatype of enum that isn't enum ? Could you screenshot me an mqtt expanded topic of the device and a copy of the code #line that you changed.
In lighting I can only see enum in color-mode
OH should discover devices published using HA Discovery too (some say it works better). They would stay offline until the $state topic shows ready. This might take a few minutes if you have a lot of discovery - although it sounds like you dont.
Beyond that it's something else.
It's hard for me to know what homie topics OH is using and there maybe some that are not to it's liking - I wish they would document this somewhere
Just re-read your comment about problems with large number of devices ~ 65+. I think my app is fine with this - I have someone using 350+ devices who seems quite happy... I suspect that might be a OH issue but can't be certain of course. I've never seen any topics become wrong after many devices are enabled...
Hmm - I'm quite surprised that works actually - the app wasn't designed to have two instances running and 'might' have issues with that... I realise it allows you to split devices , and for those wanting multiple homie devices it might be desireable but I will include such features in time. Definitely don't have two MQTT client drivers installed.. that is known to be problematic and will cause concurrency issues.
On hsb - I'll check - the 1.0 ranges came as a legacy from Athom's Homey implementation where all values are represented as 0.0 to 1.0 , maybe I need to revisit that. Homey was the only controller I had to test against supporting homie specification. homie spec does say it should be 100
1 Like
Hi Kevin - yeah as follow up to my earlier messages - the multiple instances definitely "kindof sortof" worked. My main issue was the fact that OH did not like the enum data type combined with the null errors from some of the bulbs being freshly discovered and not having a colorname defined. Once I turned the bulbs on / got them to populate a name and changed enum to text (your code totally does the enum correctly - i saw where you tell it the two valid types - I think OH just doesn't do that one correctly). After those two tweaks all of my devices were discovered and are controllable via openhab. The only remaining issue is the HSB color command always turning the bulb on at 100% because OH sends a brighness component of 1-100 and it seems you mentioned that your code is expecting 0-1. Then dimmer channels are the swap - I do see them stating in MQTT that values should be 1:100 but OH doesn't care and sends out 0-1 values. This is easy to work around tho as I just defined the dimmer channels as text so it doesn't convert to a percentage.
I haven't tried the HA discovery option with OH though - currently I really like how all of my zigbee/zwave items are living under one 'thing' within openhab. It keeps my things list much more tidy 
Hi Kevin-
I believe I've identified an issue with the MQTT publish to Home Assistant.
On Hubitat I have several virtual dimmer switches and their brightness level on initial publish doesn't seem to be set on the Home Assistant side. On HA they just show up as "on" with a level of 255 even though in hubitat they have an arbitrary level like say "80".
As soon as I change the level of the hubitat virtual dimmer, it's reflected in the Home assistant entity, but the initial startup always shows 255 on the HA side rather than the level the hubitat switch is actually set to at the time it is discovered.
Make any sense? Thx.
Makes perfect sense although I thought I synched them all at start. Do you have several different dimmer devices (drivers) and is it the same for all ? If only one type, which driver are they ?
I want to get beta 2 out hopefully tonight (I lost some of the code changes I made last night) and then, assuming no issues I can focus on HA (and OH) integration a bit more.
Thanks for reporting this..
Kevin - I was popping in two tweaks to ease my operation with your code and I noticed a bug in the most recent release beta 2 relating to the color commands.
This is line 5440 in the code - this block. This is where you are processing the brightness part of the HSB /HSV command. as you can see when you are grabbing the number for manipulation you are actually looking back at the saturation number for brightness
Your Code - references saturation instead of the brightness value:
if (data.payload[2] != null) {
float v = Float.parseFloat(data.payload[1]) + 0.5
val = (int) (v)
if (val>100) val=100
else if (val<0) val=0
}
Should be
if (data.payload[2] != null) {
val = data.payload[2].toInteger()
if (val>100) val=100
else if (val<0) val=0
}
