Alexa Smart Home Skill V3 is now live!

jeshab · August 16, 2019, 7:36pm

Unfortunately, you can only use OH devices as routine actions for the moment. For the same reason I mentioned just above related to proactive reporting. Routine triggers requires states to be pushed to Alexa.

BoBiene · August 16, 2019, 7:37pm

No, my items are like this

Switch Proxy_Logo_1_Q_2 “Gäste WC” (gErdgeschoss, gLogoLightProxySwitch) [ “Lighting” ]
Switch Proxy_Logo_1_Q_3 “Herd” (gErdgeschoss, gLogoLightProxySwitch) {alexa=“Switchable”}

and i have a rule

val Functions$Function4<Object,SwitchItem,SwitchItem,SwitchItem,Object> LogoSwitchLogic = [
Command, RuleProxySwitch, RuleReadLogo, RuleSwitch |
logInfo(“DebugOutput”, “Rule start with:” + RuleProxySwitch.name.toString + " " + RuleReadLogo.name.toString + " " + RuleSwitch.name.toString )
switch(Command)
{
case ON: {
logInfo(“DebugOutput”, “Rule case ON”)
if (RuleReadLogo.state != Command) { // only if state changed
logWarn(“DebugOutput”, “Rule case ON:switching”)
RuleSwitch.sendCommand(ON)
Thread::sleep(400)
RuleSwitch.sendCommand(OFF)
}
}
case OFF: {
logInfo(“DebugOutput”, “Rule case OFF”)
if (RuleReadLogo.state != Command) { // only if state changed
logWarn(“DebugOutput”, “Rule case OFF:switching”)
RuleSwitch.sendCommand(ON)
Thread::sleep(400)
RuleSwitch.sendCommand(OFF)
}
}
default: {
logInfo(“DebugOutput”, “Rule case default”)
Thread::sleep(350)
if (RuleReadLogo.state != RuleProxySwitch.state) { // if state changed really
logWarn(“DebugOutput”, “Rule case default:state changed externally”)
RuleProxySwitch.postUpdate(RuleReadLogo.state) // update the state without triggering the rule

}
}

}
]

rule “Switch Light through Logo 1_Q_3” when System started or Item Logo_1_state_Q_3 changed or Item Proxy_Logo_1_Q_3 received command then LogoSwitchLogic.apply(receivedCommand, Proxy_Logo_1_Q_3, Logo_1_state_Q_3, Logo_1_state_VB_103_0) end

jeshab · August 16, 2019, 8:14pm

I didn’t see any error with the items you mentioned above. The skill is responding to each of the report state requests it received.

However, I can see errors for the Innr_Light1_Color_Temp item which seems to not have a defined state and is probably the reason for the error you saw.

Normally, any items you exposed to Alexa should have a proper state but there is a special implementation for color temperature-enabled lights such as hue. In order to do so, you will need to convert that color light using a group endpoint. Something along these lines:

Group gInnr_Light1 "Licht Esszimmer1" {alexa="Endpoint.Light"}
Color Innr_Light1_Color "Licht Esszimmer1 Farbe" <light> (GF_Eating, gInnr_Light1) [ "Lighting" ] {channel="hue:0210:xxxxxx:5:color"}
Color Innr_Light1_Temp "Licht Esszimmer1 ..." (GF_Eating, gInnr_Light1) [ "ColorTemperature" ] {channel="hue:0210:xxxxxx:5:color_temperature"}

jeshab · August 16, 2019, 8:30pm

Based on the skill logs, the issue here is that your group gErdgeschoss is tagged and therefore considered as a group endpoint. In that setup only one light can be linked to that entity and all the other ones will be discarded. Here, it’s the Proxy_Logo_1_Q_12 item which was associated to it (probably because it’s the last light of that group).

My advice would be to remove that group tag and trigger a rediscovery.

BoBiene · August 16, 2019, 8:59pm

Thank you, it’s working now again perfectly

jeshab · August 16, 2019, 9:06pm

No worries

I forgot to add that if you want to control all the lights as a group, you can set them on the Alexa side. Or, if you want to achieve this on the OH side, you would need to give your group an item type. In that setup, the group would not be considered as a possible endpoint and all its members would be discoverable.

Group:Switch:OR(ON,OFF) gMyLights "My Lights" [ "Lighting" ]

BoBiene · August 16, 2019, 9:32pm

My skill is working again, but i came across some unexpected behavior in my alexa app:

When i open the a group all lights indicate a problem:

When i go to detail of a lamp i shortly get the same “problem” message:

But shortly after i get the correct state of the lamp

And if i go back i can see the correct state for this item in the group

DiLucca · August 16, 2019, 10:12pm

Thanks Jeremy, great job! Looking forward to the proactive reporting implementation. I would love to be able to trigger Echo’s music with an OH rule.

jeshab · August 16, 2019, 10:45pm

I just checked my Alexa app and I am experiencing the same. I am running my own skill and I don’t see any poll requests coming in unless selecting a specific device. Hopefully, this is temporary issue on their end as I don’t recall behind that way in the past.

idkpmiller · August 17, 2019, 2:18am

Hi,
I am looking into the new v3 documentation and I must confess I got a little lost, could your provide an example using the item below as to what I can do to support both old v2 categories and the new v3 format.

Number BR4_Temp "Temperature [%.1f °C]" (gTemperature, gBR4_Temp, chartpersist, gBR_Temp, gBedroom4Thermostat) 	["CurrentTemperature"] 	{ channel="mihome:sensor_weather_v1:158d0002789d27:temperature" }

Thanks

Paul

jeshab · August 17, 2019, 3:00am

I am sure exactly what you mean by supporting both v2 and v3 format. The example you provided works fine as it is if you don’t want make any changes. If you want to set Alexa v3 metadata settings just for learning purpose, this is how it would look:

Number BR4_Temp "Temperature [%.1f °C]" (gTemperature, gBR4_Temp, chartpersist, gBR_Temp, gBedroom4Thermostat) 	["CurrentTemperature"] 	{ alexa="TemperatureSensor.temperature", channel="mihome:sensor_weather_v1:158d0002789d27:temperature" }

Keep in mind that you can keep the v2 tag unchanged for other assistant integration but it won’t be proceed by the Alexa skill once the metadata parameter is configured.

idkpmiller · August 17, 2019, 3:55am

Thanks, you answered perfectly I was referring to the v2 way as catorgeries needing to stay as we often have other systems that use those tags.

Now that I see the {} squirly bracketed stuff can be a comma separated list I would guess the below is also valid?

Number BR4_Temp "Temperature [%.1f °C]" (gTemperature, gBR4_Temp, chartpersist, gBR_Temp, gBedroom4Thermostat) 	["CurrentTemperature"] 	{ alexa="TemperatureSensor.temperature" [scale="Celsius"], channel="mihome:sensor_weather_v1:158d0002789d27:temperature" }

I just added the option in the square brackets for the scaling to be used.
Can the square brackets be defined anywhere inbetween the {} brackets or must is be along side the ‘alexa=’ definition?

e;g; is this permitted?
Number BR4_Temp “Temperature [%.1f °C]” (gTemperature, gBR4_Temp, chartpersist, gBR_Temp, gBedroom4Thermostat) [“CurrentTemperature”] { alexa=“TemperatureSensor.temperature”, channel=“mihome:sensor_weather_v1:158d0002789d27:temperature”, [scale=“Celsius”] }

Thanks

Paul

jeshab · August 17, 2019, 4:24am

No it has to be specified just after the metadata value like in your first example.

Related to the scale configuration, it is now determined automatically using your OH regional settings. So unless Celsius isn’t your default setting, you don’t need to specify that parameter.

idkpmiller · August 17, 2019, 4:31am

Thanks Jeshab,
I am working my way through the documentation, theres a lot
Well written too.

I am sure I will have more strange clarifications as I read and play so far after initial issue not knowing about the v3 migration and all my devices (180) failing it has been a great journey.

I have noticed one thing now I come to think of it that may not be the new skills issue but let’s bring it up anyway in case others have seen it too.

When I expose new items to alexa in openhab and then ask her to ‘discover devices’, she always says “no new devices were found” and yet they are added correctyly to her list in the amazon app. Any ideas?

Regards

Paul

csdcc · August 17, 2019, 5:16am

Since the v3 update Alexa has not been able to find any new devices. I left it for a couple of days since the upgrade, but always got Device is not responding. So, I essentially removed all the configuration and linking of Alexa to Openhab Cloud and removing the tags and trying the v3 style - but to no avail. I am running on Release 2.4.

Examples from my items.config

Number  FridgeTemperature "Fridge Temperature  [%.1f °C]" <temperature>   ["CurrentTemperature"]        { alexa="TemperatureSensor.temperature" [scale="Celsius"], channel="mihome:sensor_ht:158d00012cc0ba:temperature" }
Dimmer  LoungeDimmer    "ZWave Dimmer [%d %%]"  <slider> (All,AllLights) {  alexa="PowerController.powerState,BrightnessController.brightness",channel="zwave:device:8617eeea:node7:switch_dimmer" }

Perhaps a syntax error? I have 125 items and some of them are image items.

Although I do get many of the these messages below when triggering a discovery from the Alexa app:
2019-08-17 17:12:52.207 [WARN ] [thome.io.rest.internal.DTOMapperImpl] - Field 'editable' could not be eliminated: Can not set boolean field org.eclipse.smarthome.io.rest.core.item.EnrichedItemDTO.editable to null value

and it’s always no new devices found for awhile after that.

michi · August 17, 2019, 6:16am

My recommendation for 2.4 users is to use the release candidate version of the binding from here. It works fine with 2.4 installations. Or of course, the 2.5 M2 includes the same version out of the box.

Thomas_Schwieters · August 17, 2019, 7:02am

will this version be included in OH 2.4 Release version soon?
Because I would like to avoid manual installation of non released components

sihui · August 17, 2019, 7:16am

No. There are never changes to the stable builds.

Celaeno1 · August 17, 2019, 7:26am

This is exactly what I discribed before. Ok, it seems all users are getting this.

BoBiene · August 17, 2019, 8:14am

Actually they went normally again in my app.
All items shows now the correct state.
The only thing I did was: going to sleep