I'm a Hubitat/SmartHome newbie. I have two WiFi bulbs and a WiFi smart plug, they're connected through Alexa. No issues with Alexa controlling them. I have about a dozen Zigbee light bulbs on order, and would like to control everything through Alexa. While I wait impatiently for my shipment to arrive, I have been working on the HE/Alexa integration of the existing WiFi stuff. Based on what I've read, I should be able to create a virtual device switch that gets turned on by Rules Machine when my phone's presence is detected, then trigger an Alexa routine to control those WiFi bulbs as well as the new Zigbee bulbs that are coming. Here's where the issue comes in:
I have the Skills app installed in the HE interface. I have the virtual device selected. I installed the Hubitat skill on Alexa and linked the account successfully. I was able to confirm with the Alexa app on my phone that the VD was authorized during the skill setup process. Alexa then goes through discovery and successfully identifies the switch. It then says the switch is unresponsive and doesn't turn it on or off. It also popped the following error in my logs:
2019-12-30 06:16:56.984 pm errorError making Call to Alexa message gateway: {"header":{"namespace":"System","name":"Exception","messageId":"31ef150d-c7ae-410a-b06c-1bac951a2fe2"},"payload":{"code":"INVALID_ACCESS_TOKEN_EXCEPTION","description":"Access token is not valid."}}
(https://192.xxx.xxx.xxx/logs#app100)2019-12-30 06:16:56.098 pm errorError making Call to refresh Token: [error_description:The request is missing a required parameter : refresh_token, error:invalid_request]
I've already tried disabling and re-enabling the skill on Alexa. I deleted and reinstalled the app on HE. I also rebooted the HE, just in case.
I'm running HE software version 2.1.7.127, which appears to be the latest. I'm in the US.
I've searched the forum for every iteration of this issue that I can think of and the only thing I can come up with is something relating to HUE integration; I have no HUE devices.
You cannot trigger an Alexa routine based on a switch. You can only do it based on a Virtual Contact Sensor. FYI...this is going to be very delayed as well. Plus, this will not work if your Wifi is out, completely defeating the point of Having Hubitat in the first place.
When you installed the Alexa skill, did you do it from Alexa or from Hubitat. You just have to install it from Alexa and the app will automatically install in Hubitat.
@michaelyorkpa, how'd you end up resolving this? I am getting the exact same error, but my situation is a little different.
My Alexa stopped functioning a few weeks ago. I'm finally getting around to fixing it today. Ended up deleting the HE app and the Alexa skill, starting fresh. Now when I add enable the Hubitat skill in Alexa, I get "We were unable to link Hubitat at this time" (repeatedly).
In my Hubitat log, I get the same error as you (below). Anyone have any ideas?
app:42532020-10-18 02:40:48.128 pm errorError making Call to Alexa message gateway: {"header":{"namespace":"System","name":"Exception","messageId":"XXXXXXXX Redacted XXXXXXX"},"payload":{"code":"INVALID_ACCESS_TOKEN_EXCEPTION","description":"Access token is not valid."}}
app:42532020-10-18 02:40:47.828 pm errorError making Call to refresh Token: [error_description:The request is missing a required parameter : refresh_token, error:invalid_request]
I haven't had any issues with the Alexa skill since this. I created virtual contact sensors, per Ryan780's instructions and use those to control WiFi devices with the Alexa. It's a bit cumbersome, so I avoid buying WiFi devices now and stick to Zigbee or Z-Wave for all new purchases.
The contact sensor is pretty easy to setup in Hubitat. It's creating the routines in the Alexa app when the contact sensor is used that's time consuming (depending on what you're doing). I also got lucky with the one WiFi device, as it's LiFX and there are user created drivers and apps for it on Hubitat.
Yes, that's exactly what it was for me. I figured it out, with help from @ogiewon, when he suggested that I go look at my cloud accessible dashboards from outside my LAN environment. Sure enough, when I pulled up the HE mobile app, and selected the hub in question, it said "unavailable" or "disconnected" (can't remember the exact term).
I tried to reboot the hub--that didn't fix it. So, at @bobbyD's suggestion, I did a soft reset from the hubitat diagnostics page after backing up the hub. That solved it for me. Alexa and I have been getting along just fine since then.
Hope this helps. Let me know if I can help you -- the experience was frustrating, but the solve is fresh in my mind for the moment.
First thing I did was backup and reboot the hub which did nothing. Still no cloud connection even though I could get to the internet and obviously this forum. I decided to reboot my router thinking that was a long-shot and that fixed the problem! No idea if it was DNS or what but all is well now.
So for now I avoided the soft reset and restore which sounds easy on paper but you never know!
@ogiewon, my mysterious hub behavior has continued. At first, everything was fine after the soft reset and restoring an earlier backup, but then I noticed some odd symptoms:
• When I “Select Hub” from the mobile app, main hub says “(Unavailable)” and is greyed out after the hub name, implying it’s not cloud connected (see picture below).
• If I go to your HE Portal page, that hub doesn’t show up (my other 4 hubs do).
• However, if I search for hubs on my LAN by entering the MAC address, the hub in question is found instantly.
• Strangely, I can still access cloud dashboards from outside my network.
Any idea what is going on? It’s causing all sorts of connectivity problems, so my automations are out of commission. Pretty much dead in the water.
Turned out I've hit the maximum number of events on my main hub. The errors show up in the log and essentially stop processing. I don't understand what this would have to do with the hub being available for cloud connectivity, but okay I guess.
Support didn't have much to offer about how to identify the event-spamming culprits. Trial and error, for now.
