I have linked Google Assistant to openhab. And for most, it´s working great.
But I have run into a rather serious matter here which I cant figure.
I can´t make use of push buttons. It seems like Google Assistant never reads the switch actual state. A switch is a switch in Google home, and it can not change the state of the switch from openhab, probably because Google home never reads the actual state of the switch from openhab. This means, Google home just assume.
Small precision to the above.
I can control a push button by the use of voice command. But I have to say "turn on… " to turn the light ON. And I have to say “turn on…” (again), to turn the light OFF.
I know… Sorry… Will post the items later, as I´m at work and cant reach my items files. Untill then I´ll try explain below.
It does, because it seems like it doesn´t read the actual state of the switch. When I hit the I/O Button in Google Home app, the switch stays ON, and doesn´t return to OFF like a normal push button would do.
However… I noticed when using voice command, I can operate the light by telling Google to turn on the light twice. First on, turns the light ON. Second on, turns the light OFF. The same goes for my garagedoor, which is puls operated as well through a push button, to open and to close the door.
Problem is, it´s not that normal to tell something to turn ON, when you actual want it to turn OFF
But in a principal manner, (and my suspection of how Google works), this is exactly how it´s suppose to do, cause a real push button needs to go ON to send the puls as well. It´s the actual results which needs changing.
This is why I believe its a design issue of Google or a none supported situation.
I cant figure how to do a work around.
One thing though. I cant really explain why is works like that using voice command, but when using the app and the switches it doesn´t behave the same. I guess it´s because it makes no sense to swich on a switch, which is already swiched on. It needs to go off, before it can go on again, (logic), which is why I can operate the light by pushing the I/O button four times. But this tells me, that Google do not read the actual state of the switch from openhab. It just sets the state of the switch from either commands or by the switch.
OH doesn’t really have a push button type Item and neither does Google Assistant.
So what you can do is create routines in Google Assistant (if available) to translate something like “close the garage door” to “turn on the garage door”.
Or you can create a Proxy Item linked to Google Assistant and then write a Rule triggered by received command that triggers the actual Item bound/linked to the device.
I’d need to see more details about how you have this configured because it works for me when using a Switch element with Mappings. For my garage doors, the Items are only ever ON. I use subsequent ON commands to trigger the opener. I use the proxy item/Rule approach as described above.
If you are not using mappings, there simply is no way to send two ON commands one after the other from a sitemap. With a toggle UI element you can only ever send and OFF if the Item is in the ON state and ON if the Item is in the OFF state. You cannot send two ON commands in a row. You need a mappings for that to create a button.
I’m pretty certain that is the case. As far as Google is concerned, it doesn’t need to know the state of the Item to do what you asked of it, sending an ON command. Maybe if Google Assistant supported something like “toggle the light” it would need to read the current state so it can send the appropriate command in response. Based on a test I just ran though, it appears Google does not support a command like that.
I´ll have to get back to you on this one. I just learned today, that the IHC binding is suppose to have build-in push button. And I´m sitting here trying to figure it all out.
I can provide my “old” item file though, in case I can not get this new method to work.
/**
* This is a rules to simulate the push button behaviour...
*/
rule "PushButton of group gV"
when
Item gV changed
then
// waiting a second.
Thread::sleep(200)
// Foreach-Switch-is-ON
gV.allMembers.filter( s | s.state == ON).forEach[i|
// switching OFF
sendCommand(i, OFF)
]
end
Based on what I’m seeing here, you can potentially eliminate the rule entirely by using the Expire binding.
You probably want to use
expire="1s,state=OFF"
Unfortunately expire doesn’t support milliseconds so that may not be an option.
If you need faster than a second, at least use a Timer instead of a Thread::sleep.
Finally, it is much more efficient to avoid the filter on gV.allMembers and instead just rely on triggeringItem.
rule "PushButton of group gV"
when
Member of gV changed to ON
then
createTimer(now.plusMillis(200), [ | triggeringItem.sendCommand(OFF) ])
end
Only trigger the Rule when an Item changes to ON. Then don’t wait around and instead schedule a Timer to set it back to OFF.
This will eliminate a lot of extra triggers of this Rule (since the sendCommand(OFF) will retrigger the same Rule because of the change) and a lot of extra work filtering.
expire will not do in this situation, just as you mention, for a push button is has to be faster than 300ms.
I´d originally copied the rule the binding to controle Velux windows. I understand it´s a bad idea to use Thread::sleep as I read you wrote somewhere else. But I had no idea how to use a timer insted. I´ll give your rule a try.
Why? I’m not saying it doesn’t but that seems like a pretty specific requirement which would need some justification.
But one thing that has been completely ignored is my suggestion that the item need never have to go back to off. Just let it stay ON and user commands sent to driver the behavior. Is there some reason why the item must go to off at all?
Due to the logic in the IHC controller. If the press is longer than 400ms, while it´s connected to ie a Dimmer or something. The logic in the IHC contoller will think of it as a long press, and starts to regulate the dimmer (or whatever function block connected to the switch in the IHC logic).
Yep, as written above, due to the logic in the IHC controller.
The idea (my idea) using openhab together with the IHC controller, is to have a parallel control of the IHC system, as well as the possibility to add other devices (devices IHC doesnt support) to have influence.
Due to the reason that the IHC installation is hard-wired through-out the whole house, it´s important to me to keep the main logic in the IHC controller, in case I might loose interest in openhab/smarthome, or perhaps one day have to sell my house. In that case, I just unplug openhab, and the installation will still be working.
OK, that makes sense. I see all the time users come up with these self imposed requirements that are not real requirements but just self imposed constraints. There is a really good technical reason here. The Timer approach should serve you well.
This is a really good approach. I like to keep the smarts in the devices and let OH control them. I don’t implement HVAC logic in my Rules. I let the Nest do it’s thing but I can control things from OH through the Nest. It makes the whole house fail gracefully.
