Hope all is well post surgery Kevin.
Thank you. As ever I have run out of time - its after 1am and I'm due in at 7am , just trying to release something !
In a few minutes, as promised, I'm going to post a link to a pre beta2. For those that are desperate for something new and want to live 'on the edge' then try it. It's not as tested or complete as I would like though. I'll finish it early next week. If you are publishing HE devices to MQTT or using the HA or homie integrations it should be OK and faster and incorporates the bug fixes to date.
For those using 'Virtual devices' configured via page two of the app there are issues still due to being incomplete. Your existing devices should work but you can't create new ones and you can't edit old ones. At least not any ones that map attribute values using the _ON and _OFF data values which are now deprecated. These are being replaced with a a single _MAP topic which is now present in the UI and also supports multiple attributes but is not fully implemented in the code to actually do the mappings. Likewise there are the starts of JSON support in the UI but it is not implemented in the code.
I have some UI issues to sort on page two (I want right justified input fields of smaller widths ... anyone? ) so please overlook page two 'Virtual Devices' layout for now.
If you find you have issues with the pre beta2 let me know but I wont be around until Monday probably to fix them ... so just revert to beta1
OK Here is the working repository for pre beta2. (The import URL's are not setup correctly).
Update MQTT app , client driver and text driver (if you use it). Copy/paste code across your existing versions. Do NOT install a second driver. After copy/pasting both app and code reboot your hub which will ensure only one MQTT driver is running.
Again please only try this if you're adventurous... there will be a release version within a few days once I get back on my feet. (see above post). I'll be keeping an eye on this thread though.
Backup first and if you have problems let me know.. and revert to beta1.
If you have a temperamental MQTT server that disconnects frequently you may find that this version takes longer - a few minutes to reconnect (will remedy that)
1 Like
Illumination!!! Thank you for that fix!
I was hoping the 'Everything (all capabilities/attributes)' setting in b2 would publish all my locks states (eg codeChanged, codeLength, lastCodeName, lockCodes, maxCodes) but it didn't. Maybe this isn't implemented yet?
Well I’m back home... time to get beta2 out. Looking through for any issues reported here for the pre-release but not seeing any and no PM’s either. Maybe people like official releases.
Let me know if you have any...
3 Likes
Hi @kevin ,
I have a Sonos connected to Hubitat, and have the issue where if I'm playing music and Hubitat sends a TTS message, it doesn't resume the track it was playing. Also tried controlling using playTestAndResume command in the device properties page and it doesn't work.
I read on another thread that Sonos was deprecating the API?
Does this app solve the problem?
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
