Interesting, the same issue was reported on Github. Had this also in the very beginning. But my latest tests yesterday went fine with Home mini and Assistant on the smartphone. I am a bit lost here, since I can not reproduce and debug this.
Not yet. Ony turning it on and off is supported so far (if I remember it correctly).
IĀ“ll try play around with itā¦
Btwā¦ Did you see the error about using more than 4 digits for pin ?? If it only handles 4 digits, perhaps it should be mentioned in the doc
Just for Informationā¦
i changed my .items files accordingly to the new metadata-type and its working after renaming .items files and syncing Home-App like before. I added the Roomhint feature and it works great even with german āĆ¤Ć¼Ć¶ā.
Thermostats working also like before.
I have a feeling this SecuritySystem is highly dependable on how things are beeing said.
Can you tell me the exact phrase you use, specielly for the pin kode. It seems like āsheā thinks the PIN code is a search phrase. Sometimes she even respond with the PIN code beeing a community code here in Denmark. ItĀ“s totally unuseable
It could be a missing language feature for the danish GA langague. Do you use the english langauge?
EDIT!
Just tried with the ga="Lock" [ tfaAck=true ]
as well. ItĀ“s the exact same issueā¦ As soon as I respond to the PIN or acknowlegement, Google thinks IĀ“m asking about a search
Can someone else please try this so perhaps we can figure out if itĀ“s language issue?
Easiest way to test it, is by setting up a proxy item, and add the ga=āLockā [ tfaAck=true ] like this:
Switch nilanVent0 "Test switch" <switch> { ga="Fan" [ tfaAck=true ] }
Lock function works for me with DanalockV3 zwave. It asks back for confirmation as it is in the description. I use it in English in Hungary.
Both the TFA acknowledgement and the PIN (with 4 or 6 digits) are working for me.
Yes, according to the docs there is no limit for the PIN length. Also the examples state a longer one.
I will try this in my setup later.
Overall, I have to say, that I strongly doubt that there is an issue in our implementation. Since we return the correct answer and Google asks for the ack or pin. Afterwards, it is completely out of control of the openHAB action. We will only react on a new request that should be send after the user has confirmed the challenge.
@Kim_Andersen, Iāve just learned that when I fail to give the correct PIN the first time, Google will ask me for it again. However, when I give the code a second time, it runs a search. So it seems like something is buggy with Googleās TFA implementation. At least I get one chance to get the PIN right before getting booted over to search.
Just tried 5 digitsā¦ It didnt gave any issue this timeā¦ Thats just weirdā¦
IĀ“m almost positive this is not a openhab/integration issue. IĀ“m more concerned this is a language issue. Seems like the Two-Factor-Authentication simply dont work fully using Danish GA languageā¦ It does ask for the PIN code allright. And it does ask for acknowledgement also. But any correct answer Google somehow mix up, and start to seach for the internet for the word respond. And ifs a PIn code. Google starts searching on Spotify for a track which start with this PIN/numbers or city codes.
An incorrect answer result in a new request from Google. Answer correct to this second aproch, Google starts to seach againā¦
I just gave it a few tries where I answered in englishā¦ When answering āyesā, IĀ“ll get the Google āFantasticā! jingle. (Give it a try yourselfā¦ Just say āHey Google, yesā.
Answering ānoā result in either silence or she acknowledge and doing nothingā¦
This is very bad cause I have no idea howto or where to file this issue to Google Also I have no way to document this issue, (which I truly believe is a Google issue).
I dontā¦ I get booted everytime
I wonder if the issues IĀ“m facing has to do with the feature ācontinue conversationā in Google Assistant. According to the notes from Google, this feature only work on english langauageā¦
So I guess, what we need is someone without english language installed to test thisā¦
Mind you though, Google is VERY bad to update their docs. Sometimes features has been added (or changed) and the Docs are not updated.
I have set up Gree Aircon with Gree binding, transforming with .map file.
It suppose to have the following modes:
GreeAirConditioner_Modechannel mappings=[0=āAutoā, 1=āCoolā, 2=āDryā, 3=āFanā, 4=āHeatā]
I can use Cool, and Heat what is enough, on/off is a separate channel.
Intesesting is that at the beginnig I received āheatā, āheatcoolā from GH but after some trials, I received numbers instead of strings and they are not matching with .map file. E.G. cool is 2 and heat is 1.
2020-01-19 13:26:16.890 [ome.event.ItemCommandEvent] - Item 'GreeAirConditioner_Modechannel_GA' received command heat
2020-01-19 13:26:39.447 [ome.event.ItemCommandEvent] - Item 'GreeAirConditioner_Modechannel_GA' received command heatcool
2020-01-19 20:08:25.316 [ome.event.ItemCommandEvent] - Item 'GreeAirConditioner_Modechannel_GA' received command 2
2020-01-19 20:08:51.403 [ome.event.ItemCommandEvent] - Item 'GreeAirConditioner_Modechannel_GA' received command 1
So now my roules looks like this:
rule āTranslate Mode from GAā
when
Item GreeAirConditioner_Modechannel_GA changed
then
// GreeAirConditioner_Modechannel.sendCommand(transform(āMAPā, āairconmode.mapā, GreeAirConditioner_Modechannel_GA.state.toString))
if(GreeAirConditioner_Modechannel_GA.state == ā2ā ) {
sendCommand(GreeAirConditioner_Modechannel,1)
}
if(GreeAirConditioner_Modechannel_GA.state == ā1ā ) {
sendCommand(GreeAirConditioner_Modechannel,4)
}
if(GreeAirConditioner_Modechannel_GA.state == ā4ā ) {
sendCommand(GreeAirConditioner_Modechannel,2)
}
if(GreeAirConditioner_Modechannel_GA.state == ā0ā ) {
sendCommand(GreeAirConditioner_Modechannel,0)
}
end
It works. Is that possible to remap it somehow?
I tried turning off Continued Conversation and still got the same behaviour. I think itās just that Googleās TFA programming is buggy.
Iāve noted that Google sends the following values, depending on whether your thermostatMode
item is a string or number:
- heat (1)
- cool (2)
- on (3) - equivalent to āOtherā in Google Assistant (e.g. heat or cool)
- off (4)
Thereās no telling what mode values are needed for other HVAC systems, so I think thereās often going to have be a user-defined rule to transform the Google state to the HVAC state, as youāve done.
If you havenāt already done so, you might want to make a reverse rule to update GreeAirConditioner_Modechannel_GA
when there are changes to GreeAirConditioner_Modechannel
. That will keep GA in sync when you turn on/off your Gree Aircon via another method.
And I tried install english langaugeā¦ Still no go.
I really hate Google for making it this way. Works for some and not for others. And no explanation at all or updated docs to findā¦
This is why I asked some time ago where this translation from modes to numbers came from in the initial implementation. Nobody so far could explain me this.
From my side, I would remove the number state completely and rely on the translation on the userās side (on/off/heat/cool/auto to whatever your binding needs).
What I could also imagine is a configuration for that in the metadata, like the fan speed is implementedā¦ but just for thermostat modes.
Would it go both ways, so that GA and the device are always in sync? If so, thatād be great.
Iām really struggling with some of the possible devices. Lights and outlets works great, but Iām having no luck with Locks and Valves. They show up in google home with a gear icon in the top right corner. I canāt control it nor show any status. If I click on them the only option I can configure is to move them to a different home/room.
I suspect it has something to do with onoff vs openclose, and is properly something Iām missing or not understanding.
Thats because they can only be controlled by voiceā¦ Did you try?