Recent entrant to home automation and a lot of shelly 2.5 lying around my house. I managed to add the shelly 2.5 using both the built in driver and the SHELLYUSA driver. The shelly USA driver provides a lot of information, however the on/off actions don't work. The native driver is a simple on/off that works.
Is there any reason why it wouldn't work?
clicking the on/off buttons in the device page doesn't do anything, but I switch it on from the shelly app and poll the device it reports "on" stage.
It would be nice to have a confirmation by @mike.maxwell about the issue. I'm not quite sure if it's an Alexa limitation or an Amazon Echo Skill app limitation. In the latter case it could be fixed I guess.
I am correct on this issue. If you have a contact switch that also reports temperature and add it to Alexa the default attribute used is temperature in Alexa and not open/close.
I tested this using a spare Iris contact sensor(3320-L) that also reports temperature and Alexa reports it as the default a temperature sensor instead of a contact sensor. Now even though Alexa defaults to this I can still make a rule for the contact sensor using Alexa.
I have to admit this is very odd behavior considering this never happened until recently. @mike.maxwell may not answer this and confirm this but I am very sure of my testing.
I don't doubt your observations Scott, I just wanted to understand if the problem is the HE app that presents the devices to Alexa or it's Alexa that doesn't manage correctly devices with multiple capabilities. Since this odd behaviour never happened before, it could be some changes in Alexa APIs or the HE Echo skill implementation.
Seriously it's the SKILL not the API... in either case why it's happening is beside the point here. What it is doing is exactly what I have explained which makes it NOT a driver issue or a Shelly one.
This issue shouldn't even be in this thread and instead reported under the support threads.
I have a VERY VERY beta driver ready for the Window/Door2 device if anyone is interested in it. You need to have a MQTT broker for this to work.
What doesn't work correctly still is the vibration detection... that seems to be a hit-or-miss problem which may or maynot be because of the device or the Shelly FW. Everything else works as far as I can tell.
Apart from the latency due to the sleepy nature of the device, it is like other Smart Buttons on the market. I use other brands too for those (Osram/Sylvania 4 button zigbee devices, and also the Philips Smart Button (zigbee). The Philips is a really cool device, very easy to configure and very very fast reaction times, it's like having a physical button when turning on/off the lamps.
I guess also the drivers for those were tricky to develop, in order to manage all the buttons and combos (short/double/triple/long). This Shelly button is different just because it uses wifi and so it needs to sleep in order to save the battery. If connected to usb power, it doesn't sleep though.
Did you choose to do it via MQTT just because of the sleepy nature of the device? What if the device is connected to USB? In that case it would be good to treat it like all other smart buttons. Can you determine from the driver if the device is connected to USB power so you can bypass MQTT? Or maybe have it user selectable "MQTT option" and "Direct interface" option. Just brainstorming a little bit...
My H&T does pretty well with event-based reports over HTTP even when on battery power. Since I haven't used MQTT before, I'm curious -- does MQTT offer a certain advantage with sleepy devices?
I wrote a driver for the i3 for fun. I don't actually have one of those devices. I used the URL callback methods in /settings and just configured the Shelly device to signal all events to this URL.
My event mapping looks like this. tripleTap() just made up to go with the custom attributes, similar to the built-in ones that Hubitat actually supports. In those handlers, I just sendEvent() always, but I figure Hubitat is probably smart enough to filter the ones that aren't needed. I suppose you could track the event counts if you wanted to make it smarter.
Maybe this is useful, assuming you agree with the event mappings.
for(input in status.inputs)
{
if("" != input.event && input.event)
{
// momentary events
switch(input.event)
{
case "S":
push(input.input.toInteger())
break
case "L":
hold(input.input.toInteger())
break
case "SS":
doubleTap(input.input.toInteger())
break
case "SSS":
tripleTap(input.input.toInteger())
break
case "SL":
// TODO: something for shortpush + longpush?
case "LS":
// TODO: something for longpush + shortpush?
default:
logDebug("unsupported event type: ${input.event} on button ${i}")
}
}
}