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
}
Thanks I'll take a look - probably one of those 6am great ideas... although I have a nagging recollection that payload[2] is sometimes not provided or null ( I see you protect against that ) .. but that could be to do with something totally unrelated... I have a vague memory of having to 'fake' brightness.
1 Like
Hi .. I always try and test against the new firmware release you guys might be updating to so over the last few days I have been trying the next 2.2.0 (beta) and it has raised some issues that I am still talking through with Hubitat.
One of these is that backups have changed in the way they are pre-processed and this is causing a long delay for backups where there are a lot of events involved.
If you are updating from MQTT topics that change frequently (maybe many times per minute or definitely every second) then the backups now take forever and this is obviously undesirable.
Whether HE can alleviate this in the public release I am not sure but it points to a different way for me to process these changes and to not utilise the HE event system as all events are included in backups. This is a major change and will take quite a bit of work, emerging as beta 3. But HE have offered helpful and achievable suggestions on how to alleviate this.
So in the meantime I shall continue with releasing beta2 imminently but if you update to 2.2.0 please be sparing using MQTT topics that update frequently - (over every minute should be fine). Prior to 2.2.0 this is not an issue as backups are higher priority and so complete quicker.
Any application with copious numbers of events will experience this issue. The MQTT app generates an event for every payload change on subscribed MQTT topics you have and for every device attribute on any device that changes state that you publish to MQTT.
1 Like
I have posted an update to the pre beta 2 code - it's for those intrepid users wanting something to look at if confined to home this weekend. As always backup first.
It corrects most reported bugs,and most importantly changes the way virtual devices are implemented. Beta2 is imminent so if you prefer to wait then do.
I will post a message explaining what's changed in virtual devices shortly. It will require you re-create your virtuals to the new data structure but it's I hope much tidier, more functional and it also supports JSON.
NB this does not address the 1.0 vs 100 reported brightness issue
1 Like
Virtual Devices in beta 2:
I have redone the implementation of virtual devices (MQTT > HE) for beta2 to be easier, more flexible and include JSON support.
I am however still not happy with my 'Page 2' virtual design page but it's getting there. It still seems to occasionally populate values from the previous device into the next one so do keep an eye open for that.
What's changed.
-
Any _Topic or _Cmd data field can appear against any attribute within a device, including duplicates within the same device.
Any _Topic or _Cmd data field can appear in multiple devices. They will all respond.
So this effectively can achieve a single topic (multiple values if json) mapping to multiple attributes and multiple devices. Many to many. Very flexible I hope.
-
In the attribute_Topic and attribute_Cmd values you can now use either a standard topic name like
topic1/topic2/topic3..or append a JSON key value like
topic1/topic2/topic3{myKey}In the latter case the json value for the key 'myKey' corresponding to the JSON payload in topic1/topic2/topic3 will be used. This works for both incoming messages and outgoing e.g. commands.
-
Mapping of the payload values to the default (HE) attribute values has been changed and will break existing devices.
Gone are the individual entries for each attribute and instead is a single entry for all attributes, that positionally map to the HE defaults. Here's a screenshot for a switch device.
Note that the HE expected default values are shown
[on, off]but these have been mapped to[True, False]. Any incoming payload will be matched against 'True' or 'False' and mapped to 'on' or 'off' automatically. Any change of the device within HE will be reported back to MQTT as 'True' or 'False' instead of 'on' or 'off'.
Much tidier I hope and more flexible .
N.B. One thing (bug/feature) to be wary of - occasionally the blank values presented for editing on the Virtual devices page actually already have a ' ' space character included at the beginning. Make sure this is removed if you update the value to a topic address or mapping
Hey Kevin-
I do have a few different dimmer devices. The only ones I've noticed it on are virtual dimmers though.
These were virtual dimmers I created directly through hubitat, not using the interface in your app. I wasn't quite sure what that does differently.
@bill Virtual devices created within HE (cf my app) are a bit different. They lack some data entries. Although they then become editable in my app they won’t work correctly there ignoring topics and mappings.
They should however work just fine as inbuilt HE devices publishing and being controllable within the homie topic tree
At startup I try and recover brightness for initial state publish , maybe virtuals aren’t providing that or maybe I don’t even try to get it, I’ll check
So - the latest pre beta2 has now been made available - please if you find issue let me know (once again if needed).
The reason is I have some significant changes to make to the architecture of my app, moving from event driven to parent/child and they will be implemented in beta3 and are probably needed for 'demanding users' updating to HE 2.2.0 firmware. So I'm not intending working much further on beta2 and will promote this pre release to release unless I hear of any issues.
Please if you're using pre beta2 without issues let me know too - it keeps me happier.
I'm optimistically hopefully that beta3 is an easier change than I anticipated in that when changing the code and creating the MQTT client as a child driver it's surprisingly (well to me) working already 'as is' still using the event calls - so I just have to progressively deprecate those replacing them with parent method calls.
1 Like
Hi Kevin,
I am using pre beta2 and I am not seeing any issues so far. My use-case is controlling HE devices from within HomeAssistant UI. I only have about 10 sensors left at this time on Hubitat as I moved most of the ZigBee devices to conbee ii usb stick to work natively within Home Assistant (using Deconz integration). Deconz does not support some of my motion/contact sensors yet so I will continue to use this integration and will report back if I notice any issues.
By the way, I don't notice see any extra lag when using your integration vs a native sensor directly connected to home assistant. Thank you for this integration!
Thanks!
@rmotapar Thanks for replying - it encourages me that people are using this and it's working well. When it's working OK few people seem to post.
My next version might have something included that indicates how many people are using it - (but absolutely provides no personal details) just so I can sleep better.
1 Like
Exactly. What are we supposed to do, keep posting 'it works' every morning? 
That would be chaos!!!
I'm using it a lot less these days now that the node-red integration exists, but still am using it and for the devices I am using it with it is working great.
I go back and forth if I am going to use the node-red integration or mqtt integration long term. Need to think on it.
I'm going to try and connect my PWS (Personal Weapons System Weather Station) to HE using this and weewx-mqtt.
Have to set up my PWS and weewx first of course.. MQTT seems very adaptable which is appealing.
I have my weatherflow station going to MQTT, working well. I only bring over illuminance to Hubitat, though, as that is the only value from the PWS I use for automation.
1 Like
