@kevin I am interested in testing. I have HE and am flashing Tasmota to Tuya switches.
All the alpha requests are up to date and there’s updates in that topic. The alpha seems very stable and has a lot of testers.
The beta is near, I have just made quite a big update to some of the code that has changed the way virtual devices are implemented so I wanted that included before beta. Just testing and then alpha 5 will be in a very short test phase and released as beta 1 assuming no major issues are found.
The beta will be essentially feature complete but may (will) still have bugs and some areas will need ‘fleshing out’ with more complete device support, based on feedback.
Santa should have it on his sleigh...
I would love to get in board of the alpha testers, just received and setup HE and plan to move z-wave devices to it from hassio.
hi, new user here. would like to join the alpha so i can integrate hubitat in with the rest of my system. thanks in advance!
I want to join the Alpha as well if that is possible,
This is working well for me.
I am working on a MQTT app for release (initially alpha testing) that will allow easy integration of adhoc MQTT devices, as well as publishing existing HE devices to MQTT. Supporting onoff and dim devices only ATM but easily expandable.
Shortly I'll be looking for anyone that is using homie 3 (perhaps from Homey) or using Home Assistants MQTT statestream and wants to experiment. I need to work on the UI a bit to make the adhoc devices easy to configure.
If you need a beta tester, let me know.
Besides HA with MQTT, I am also running Zigbee2mqtt under Hass.io.
@lsilva171 morre like alpha but yes would be interested in you trying this with HA. I'll be in touch shortly.
Me too please !
I would definitely be in for testing and working on any issues that might arise. I've been waiting for this for sometime. Thanks Hubitat for opening the door!
I would love to be a part of this alpha/beta too. I have a RPi MQTT broker setup.
So, at this time I’m after people who have MQTT devices supporting discovery. This typically means HomeAssistant with MQTT or the homie protocol e.g. Homey. Exposing HE devices to MQTT is OK too using a simplified homie topic structure.
Currently this is for onoff/dim devices but will expand fairly easily. Ad hoc individual devices will come shortly a few days afterwards,
PM me if you’re interested in early testing and have a suitable setup.
So I'm reading your post and thinking about this more and I'm confused about your use case with discovery...
If you support discovery via the HAss methodology, and you run both HAss and Hubitat, won't you get multiple devices discovered on both platforms? I would think that would be an undesirable behavior.
Or are you simply trying to recreate the discovery method? Could it be selectively disabled?
Just some thoughts.
All of the 'discovery' features (protocols) can be selectively disabled, and having discovered devices I intend the HE users to choose the devices they wish to create in Hubitat.
In the reverse sense I intend to let the HE user choose which devices they expose using either the homie or HA protocol , or both. The homie protocol, at least initially, will only be partially supported as it is in a state of flux still. There may (or may not be) a further filtering of devices provided by the other platform for selecting devices to add into their system based on their discovery mechanism.
However only Homey is a real contributor to publishing its devices in a discoverable format (homie) . Although both openHAB and HA promote their own standard neither of them implement it for their own device exposure !! It's a very one sided endorsement to get devices into their own application.
HA has an MQTT feature called statestream that does expose the status of it's devices but does not provide control. I have worked around making this bidirectional using a small automation script installed on HA which currently supports lights and switches. More device type support can be added fairly easily using my approach. There is also eventstream which I will explore later if it more useful but it doesn't accomodate MQTT with the same granularity so I chose statestream.
You will also be able to add specific 'ad hoc' MQTT devices into HE by providing the topic/state information when you create the Virtual MQTT device. This is what most people will use I think so I have to make it as easy to use as possible, while maintaining some flexibility
So I'm hoping this will prove flexible enough for everyone from the HE standpoint. They can pick and choose devices they wish enabled from and to MQTT. If there's other concerns you have let me know because hopefully I can then accommodate the needs of more users early on.
NB The first alpha added all 'discovered' devices to HE, next will allow choosing to add only specific enabled devices. ad hoc device addition was untidy in this version, and likely the subsequent release will focus on this.
I think I understand. My use case, I think, is far easier - I hope. I'm looking to replace the MQTT Bridge solutions that are currently out there and in various states of support. I have added a number of IoT devices to HE via ZigBee and ZWave, but I wish to control them via HA. MQTT seems to be a good common protocol for this but, until recently, was a bit complex to setup. Until a deeper integration between HA and HE (Maker API maybe?) comes around - I'd prefer HE to just publish events on MQTT-enabled devices (user selected) for consumption in HA. In this scenario, discovery is of little value to me. I'm joining the devices to a "device hub" (HE) and leveraging MQTT as common protocol between the "device hub" (HE) and the "control pane" (HA).
Still interested in your application to see if it meets my needs.
Got quite a bit done over last weekend and decided to get a bit more into the next alpha which should be out in a day or so . It should suit your needs Jeff , although bear in mind it's switches/dimmers only at this stage.
Stay tuned.. I'll contact all the people who have PM'd me directly
@chuck.schwer @andrew.rowbottom are there any plans to create MQTT broker within HE?
It is a crucial part of the whole system and performance improvement to be able to have an MQTT broker internally and connect it to Rules Engine with everything else across the system.
It'll remove additional hop from HE Client to external broker.
@podarok When you get your hub and are ready for some MQTT playtime let me know and I'll join you in the MQTT alpha application group. I have about 50 testers now across platforms and it's working really well. Just adding LWT and I need to do some code refactoring before I post it here as an open beta but will do that in due course.
Re. an internal MQTT broker on Hubitat. I'm a little undecided on that. It's certainly not a necessity and I feel that the more advanced user requiring MQTT likely already has an existing/external MQTT broker. I wouldn't want to impact the responsiveness of the HE hub by adding this although I understand that HE is more likely I/O restricted than CPU, but this an I/O intensive feature. When (and if) MQTT become more plug and play and useful to an average HE user I can see that having it onboard is tidy and advantageous.
Also a comment on Home Assistant's experience. They added an internal broker based on Mosquitto and a lot of support questions arose related to that broker rather than external. They now recommend an external broker but that maybe to do with Docker issues, or it maybe that new users of MQTT start with the included broker, or it may be a resource issue based on a lot of people running HA on Raspberry Pi's.
Give me a shout when you're ready (as can anyone else here BTW using MQTT) and ...
Ласкаво просимо - welcome - maybe the first Ukraine user ?
Broker itself is not a performance bottleneck. I have it on my rpi3b+ more than a year now and cpu load is less than 1% ( mosquitto )
Yes, it depends from number of clients connected, but still .
I'm going to have ~25 mqtt devices connected to broker, just fyi. And I'll share use case, for sure.
Дякую за гостинність @kevin
Hi - the MQTT app will connect to HA one of two ways. Either using the HA statetream capability via MQTT with a handful of small automation scripts on HA to make it two way, or using HA's MQTT auto discovery.
It also supports publishing HE devices to MQTT and bringing 'adhoc' MQTT devices into HE. Lastly it supports the homie3 MQTT discovery protocol both for advertising it's own devices so things like OpenHAB can discover them and for HE's own discovery of devices.
If you are using this just for Home Assistant a component might be tidier but the MQTT app is aimed for generalised but feature rich support of MQTT in HE.
There's probably just one more alpha release hopefully just after this weekend supporting Hubitat's latest release of the beta driver and last will and testament, and then there will be a public beta after a bit of code refactoring.
PS. Sent you an invite