I have been integrating using the HE provided Amazon Echo Skill. Recently, improvements on the Amazon side allow me to add sensors.
Putting motion, temp, humidity, and contact sensors allows me to have simple rules on the Amazon side and this has been great.
A problem exists which I believe is a foundational issue on both sides. Multi-sensors. It is very common that sensors have Temp and Humidity or Motion and Temp.
Using the Generic Zigbee Motion Sensor driver, also provided by HE is not useful. It comes over to Amazon as a Temp sensor, and the Motion sensing is not visible. Amazon knows this, and says it exposes the motion sensor separately.
I wish the device drivers by HE had a specific declaration of 'Primary' so when exposed to a bridged environment you can declare what the device is. I seem to recall drivers I wrote for Smartthings had that (along with Icons).
As it stands the bridge between HE and Amazon is weakening even though Amazon is improving in leaps and bounds.
What sensors are you using? I have Iris v2 devices using the generic zigbee motion driver and mine are showing correctly in Alexa. I use them for routines triggered by motion and can ask her the temp of the devices.
heading to the office but quick reply - its an aoetec motion/temp sensor. Now that you asked, I'm concerned it isn't actually a temp capable sensor at all.
Have you tried setting the “default current state” to the motion attribute in the Hubitat device’s preference page?
Tried that - honestly I didn't expect anything as that value I understood to be related to the new gui on hE, but I gave it a whirl - removed. rebuilt, re-added. still came up with 'temperature sensor'.
I dug into the model - samjin unit was sold under smartthings name and was later bought or owned by Aeotec. I've had 3 of these for ... well. since I started following dave G around 6-7 yrs ago I think to setup my first smartthings hub to manage some xmas lights. Point is, it's ancient.
I stand by my initial feeling - there outta be improved values for drivers going forward, as things evolve and improve. Using the designs of drivers from 5+ years ago isn't going to cut it going forward much longer. Values available in HE need to start passing seamlessly and with flexibility as bridging becomes a norm. I see how HA is evolving, and matter bridging but it doesn't feel bi-directional. Anyways. thats just opinion, and it is what it is.
I'm going to toss this unit out and put a third-reality in - they integrate much nicer than the 'generic xxx' drivers when I use my own customized drivers. Not that I do much differently of course. thanks for the thought.
I’m not sure I understand the problem as you’ve described it here.
The problem is some (1?) devices do not expose themselves to Amazon Skill correctly using the "Generic Zigbee Motion" sensor (which supports temperature). While named '... Motion' driver, it shows as a temp sensor when shared. User should have control of what functions are exposed, and which are primary.
The amazon system allows multifunction sensors - a motion and temp sensor can have alexa rules for both features, but it's primary declaration isn't an option.
I will solve this for now by using other manufacturer multi function devices that correctly get picked up by Alexa, but it is shoehorning old limitations without adapting. The HE "Amazon Echo skill" has a very limited feature set - it could with a little TLC, allow me to select what, for each device, that I want exposed, what is primary, what is a shared icon, what room it should join - etc. I recognize this is just as much amazon's fault - but their army of developers is marching forward faster and faster, and my HE world isn't keeping up.
It is only fair to also point out that the title of the app (HE provided) is Amazon Echo Skill - when it is obviously way past just the Echo integration - it really is 'Amazon Alexa Skill' or 'Amazon Alexa Bridge' more or less.
I have marked this as closed.
This has been a bit of a pet peeve for me too.
Since the first Echo device was released, Echo = a physical smart speaker device, whereas Alexa = the voice assistant that mostly lives in the cloud.
Might be less expensive to mirror your multisensors to single-capability virtual sensors (where the capability is what you desire) that are then exposed to Alexa.
This concern is being addressed in the newest hub beta platform release. Since not all users can see the beta category of the forum, here’s the relevant section of the release notes (emphasis added):
Revamped Amazon Echo Skill app to support changing primary device type exposed to Alexa; added ability to remove undesired attributes; changed "respond immediately" option to per-device instead of global option; added ability to override "open" voice command percentage per-device for blind/shade devices.
