I think it was because it was a fresh broadcast.
Thank you for taking the time to reply and trying to help
What device driver is that and was it auto created by the MQTT Discovery or changed later ?
When it was created by the app it became “Virtual Omni Sensor” but the result was incorrect so I have tried a number of different drivers e.g Generic Zigbee temperature sensor, Aqara temperature and humidity sensor (which it is) but the result was the same.
In the screenshot you have a different temperature sensor which was created by the app and which I have not changed i.e. still Virtual Omni Sensor and it also using battery status as temp (yes, battery level is around 70 for both sensors)
Ahh my pet hate the Omni Sensor. I’ll fix this ..
Your device has temperature, humidity, pressure, battery and battery alarm. Matching this to one HE virtual might be difficult. It maybe should be Omni... hmm. Matching capabilities across controllers and retaining just one device is not always possible.
There aren’t a lot of people using homie discovery into HE due to lack of originating devices so you are pioneering here. It’s not as evolved as HA Discovery but now I have users that’s good. Keep the bug reports coming and I’ll squish them. I have Homey too.
Are you using homie discovery from HE into Homey too?
Thank you. So far I have not tried the other way around but I am planning for it with some water leak sensors (since the Zigbee rewrite for homey is taking quite some time). Will let you know if I run into any issues.
I have tried to use HA Discovery as well from Homey to HE but this is impossible to get working for me. No devices are being found. But this issue is for a different thread 
HE MQTT app does not support HA Discovery into HE .. just HA Discovery from HE. It’s on the list but not near the top. Discovery from HA uses HA statestream.
@peter.rohman I was looking over the beta code and I'm not going to be able to get homie discovery for sensors with multiple $properties working in time for the beta2. It's a lot of changes. This will have to be for a later version .. sorry. I might have to break them into separate HE devices as an initial solution or throw multiple property devices into an Omni Sensor which requires some different handling for that device.
You won't be able to import these values as a manual device either if the Homey topic is within the same topic tree i.e. homie/homey/... as 'nodes' within this tree are not parsed as possible manual virtual devices.
If you can move the Homey tree outside of homie/... then you would be able to import values manually.
If you want to PM me I can talk you through this but it's not an autodiscovery possibility currently for sensors.
Are onoff and dim devices $type=light $type=socket working OK for you ?
Hi,
Thank you for your efforts and to support me. No exceptions to include the changes in beta2 (or ever for that matter). I am grateful for the basic functionality in beta1 and any improvements are bonus.
As soon as I have time I will go through all my devices and outline default virtual driver and if they work as expected.
The basic capabilities for onoff and dim seems to be working as expected, once they have been created as devices. For some reason I still have issues with this when I add new devices to be discovered via homie protocol. As you see from the attached screenshots I have a device called “trappa-vägg”. This is discovered and once I select it in the drop down and hit done I can see the device under app settings, I can see that HE receive the MQTT message in the logs but there is no device in the device list. Any suggestion?
w
There are some aspects of homie discovery that are not 'discovering' as expected (multiple properties). beta2 implements groundwork to support this better and I intend that beta3 will fully address this. Whether this is the problem you're seeing I'm not sure but I'll take a look. The fact the device isn't created is an obvious issue.
Where does the device originate from ?
Is it possible you can show me a screenshot of the fully expanded mqtt homie topic for trappa-vägg , mqtt explorer is a good tool if you don't have something that can do this ..
Kevin
Hi Kevin,
Thank you for your reply, This is a device originates from Homey and since I did not manage to capture the issue last time (post 37) I thought it be best to screenshot and reach out now when it presented itself again.
Thanks for all of the help and please let me know if I can support in any way
/Peter
Each of these 3 $properties dim, color, light-mode have no associated value (payload) 
- onoff does with 'true'.
Whether that is pertinent I'm not sure but after I get beta 2 out (tonight ?) it'll be much higher on my todo list 
Hi,
Just an update. As before, the device showed up during the night. Not sure why since there have not been a restart or change. Just left everything as it was.
So a Homey issue - not one with my app ? Having a dim and onoff payload is required for discovery as it works currently
Anyone else run into issues when rebooting the hubitat hub? I get this message until I rerun the config on HE.
Is that not just an effect of the homie broker topic $state going back to init and then ready ? I do notice the spec now implies I should send a disconnect status before returning to init.. I could add that if it's important ?
The only other thing I can think is that OpenHAB is wrongly still reading payloads during init and during that time I am building the tree including progressively building the $properties topic. If you do not have 'Mode Changes' from HE enabled then this $properties value erroneously starts with a ','
1 Like
I do not have mode changes enabled - I can switch that on to see if it makes a difference. I dont think adding the disconnect would hurt either. The reason I needed to reboot though is because after a number of days the system became unresponsive to mqtt commands. Do you recommend I update to the newest HE firmware since I have the latest of your code that should work with that?
That's your call on firmware updates but I believe beta3 works fine with 2.2.0 firmware and prior.
If you try manually changing the value in $state back to init and then ready does OH throw that same warning too ?
Another thing that would be nice to update - whenever I add the item to openhab initially I get the error:
java.lang.Exception: Did not receive mandatory topic value: homie/hubitat/$name
To get the thing to come online I have to manually resubmit the process in HE to republish everything. Do you think this is something on your end or the openhab end?
