What exactly do you mean by the above statement? Hubitat's Alexa Skill allows one to issue voice commands to Amazon Echo devices as well. Thus, my confusion. 
It is also completely free on Hubitat as well. The Hubitat Alexa Skill is pretty darn decent. What is different about the Home Assistant integration with Alexa that makes you prefer it?
Update: version 0.1.48 added minimal support for rgb lights and include @mboisson PR (Airthings support)
Rebooting and closing current browser did not help.
Although, I did see that in driver section, it was showing version 0.1.48, but HPM was still reporting an update is available.
Anyway, after doing a "repair" via HPM seems to have fixed the issue and HPM is now up to date.
Thanks
No it's free. I have been looking at alternatives to Echo Speaks solutions now we will have to pay for Heroku. I managed after 4 days(sigh) looking / trying alternatives to get something to work for free. No subscriptions. So In HA I can send a text message to my Alexa speakers. So the very last step would be to access via HA Device Bridge so I could send messages from HE.
I use the HE Alexa app to turn stuff on and off etc. It does not allow you send messages to Alexa speakers.
It seems like you are talking about two different things: the ability to send TTS to Alexa devices to speak (and possibly some advanced features like commanding Alexa-connected devices with what would otherwise be voice commands via text) versus the ability to add Hubitat (or HASS) devices to Alexa for voice control of those devices via Alexa. My understanding is that HASS per se does not provide the former, though a (free) community integration/component does. This is similar to Hubitat. There is unlikely to be anything official here because Amazon does not officially support this, though to date, at least one unofficial solution on each platform has continued working.
My understanding is, further, that as mentioned above, the latter (voice control by integrating non-Alexa devices into Alexa) requires either doing it yourself or a Nabu Casa subscription. This is included, built-in and free, on Hubitat.
If you have a functional HASS setup with Alexa Media Player (the component I suspect you're talking about, or possibly anything else that works similarly), support probably could get added this app/driver for easier integration, and that would certainly make sense if you're already using it. But, that's not my call, and I don't use it myself or have a need to look into that. I do keep a test HASS box around for basically only this purpose (because it's still easier than setting up something else for only this) and wrote a Hubitat driver to get TTS from Hubitat into these devices (or possibly anything else that works similarly): [RELEASE] Home Assistant Alexa TTS Proxy (another Alexa TTS option). It's pretty basic, but it fills this one specific need I have, and maybe it would work for you, too, if I'm understanding you correctly (at least until something better comes along, if it does 
).
I can't believe I missed this! Many thanks. Tomorrow, I try and get [[RELEASE] Home Assistant Alexa TTS Proxy (another Alexa TTS option)] working as I have done all the hard work on HASS already!
Nice one.
Fix for missing commands: anyone using the recent RGB functionality would need to 'repair' in HPM to get the fix.
I opened another PR to support sensors of unknown types. This can be used to handle generic sensors which have device classes or units that are not yet supported.
Note to anyone using HPM, I accidentally left a few of the new child types off of the optional drivers list. So, be sure to use HPM to 'Repair' and 'Modify' if you want to add those (Carbon Dioxide, Radon, and Volatile Organic Compounds).
Big thanks to @mboisson for new features in versions 0.1.48 and 0.1.49.
device_class sensor that isn't fully support in HADB.I like the idea to handle Unknown Devices! 
May I suggest a small addition?
Among other things I use the bridge to monitor the ink levels of my printer. But everytime the printer goes in sleep mode, Homeassistant sets all the attributes to 'unavailable'.
IMHO in this case it would be better to simple ignore this and just keep the "old" values...
Therefore I have modified the driver code of my local instance of "Generic Component Unknown Sensor" to optionally(!) solve this problem. Here are the changes I made:
preferences {
input name:'txtEnable', type:'bool', title:'Enable descriptionText logging', defaultValue:true
input name:'ignoreGlitches', type:'bool', title:'Ignore Glitches (UNAVAILABLE etc.)', defaultValue:false //JS20221206
}
void updateAttr(String aKey, aValue, String aUnit = ''){
if (ignoreGlitches && aValue in ['unknown', 'unavailable']) return //JS20221206
sendEvent(name:aKey, value:aValue, unit:aUnit)
}
With this changes (and with ignoreGlitches = true) the values are always available, independently from the wake state.
=> Even if the printer is sleeping, the correct ink levels are shown.
Please, could you add this to the official code?
May I point out that this unavailable status is return by HA for all entity type, not only unknown devices. Setting it to the last known state may result in inconstistencies. The state usually correct itself when the device becomes available again.
Is this causing problems with other type of sensors? If so, maybe it should be handled at another level.
I agree. I don't think we want to start adding "special" logic to HADB to account for the behaviors in HA itself. It works really well as a pass-through of the events that come in, but if something like this needs to be filtered I would do it in the automation logic in RM or some other app that is using the device.
I agree with Jost that it would be nice to be able to filter values: i.e. don't update if it doesn't fit what is expected (for example a number).
Doing it in RM would mean creating other virtual devices that get updated based on the ones created by HADB and then update or not based on a filter, rather complex.
Yes, I have had that happen with other types of sensors (thermostats).
As for implementation, maybe have, as an option, a list of "forbidden values", configurable on a per device basis or in the parent. If the received value is in that list, don't update. That list would be empty by default.
I was thinking more that you would just trigger only on supported values (and others would be implicitly ignored). Which, in my mind means there is no reason to have an intermediary virtual device to track states. I guess this way works well for triggers in RM but maybe not so well for visible inspection of the data like in Dashboards.
Right, that does not work for dashboards. Also, if you set triggers in RM for "on change", then changing for unknown/unavailable is seen as a change and it triggers the rule. You can of course handle that in a rule, but if you integrate into other apps that you don't control (for example, I have the app AverageThis, to average noisy data, which would get triggered by that, and probably try to average "unknown"/"unavailable" and barf on that value).
Ultimately, the right behavior depends on context, but having the flexibility to do so in HADB would be handy.
Also, if you want to do a trigger on "attribute X becomes Y", then it will trigger multiple times if attribute X goes from Y to "unavailable" and back to "Y" (and back to "unavailable" and back to "Y", ...)., even though in reality it did not change multiple times.
I actually encountered that trying to automate events based on a notification. I had to use a virtual switch that just stays on if the value is "unavailable", as a mean to track the "clean value". Short of a filter in HADB, such situations can only be handled through some other mean of storing the value, an intermediate device/switch/variable that is clean, and then trigger on changes of that value, rather than the "dirty" value.
I remember this was discussed in the early stage of developement and it was decided to live it but it doesn't mean it as to stay like this. In my opinion, Handling it at the component level is not ideal since HADB rely heavily on build-in components. Building lists of acceptable values for devices seems to me, quite an endeavor.
As far as I can see, HE deal with unavailability by doing nothing (witch amount to keed the last value). Maybe that would be the approach we should persue for all devices.
Download the Hubitat app
