Debugging Google Assistant, (openhab cloud) how to?

Add-ons Bindings
1

I have an rather difficult issue (at least difficult to explain) with a binding, which behave strange when I try to control an item though Google Assistant (Google Home). It has simply driven me nuts for a few days now.

I believe the issue is cause due to a push button mapped to an switch item, which, from openhab, is predicted to be stated OFF. I use a rule to force it OFF 200ms after it has been turned ON (since it´s a push button).

It seems like Google Home can´t get the “triggering” command trough the binding, when asking to turn the item OFF, maybe because openhab had this item already predicted OFF, (my guess).
Turning the item ON works fine every time. Only Off seems to be a huge problem.

I can see from the normal log, that when asking Google to turn OFF the item, it respond with item OFF and it stays OFF. It should actually toggle the switch from OFF to ON, and then my rule force it back to OFF. But it doesn´t.

This is what happens, when I ask Google to turn ON the item:

2019-03-04 23:22:37.378 [ome.event.ItemCommandEvent] - Item 'testIHClysKip' received command ON
2019-03-04 23:22:37.393 [nt.ItemStatePredictedEvent] - testIHClysKip predicted to become ON
2019-03-04 23:22:37.405 [vent.ItemStateChangedEvent] - testIHClysKip changed from OFF to ON
2019-03-04 23:22:37.408 [GroupItemStateChangedEvent] - gV changed from OFF to ON through testIHClysKip
2019-03-04 23:22:37.708 [ome.event.ItemCommandEvent] - Item 'testIHClysKip' received command OFF
2019-03-04 23:22:37.717 [nt.ItemStatePredictedEvent] - testIHClysKip predicted to become OFF
2019-03-04 23:22:37.727 [vent.ItemStateChangedEvent] - testIHClysKip changed from ON to OFF
2019-03-04 23:22:37.740 [GroupItemStateChangedEvent] - gV changed from ON to OFF through testIHClysKip

This is what happens, when I ask Google to turn the very same item OFF:

2019-03-04 23:24:43.345 [ome.event.ItemCommandEvent] - Item 'testIHClysKip' received command OFF
2019-03-04 23:24:43.360 [nt.ItemStatePredictedEvent] - testIHClysKip predicted to become OFF

Thats it, nothing more… It should have toggled the item (switch) from OFF to ON, just like it did, when asking Google to turn ON, cause it´s a push button. But it doesn´t.

This is the item:

Switch testIHClysKip  "Stue M2 kip [%s]"   <switch>   	(gV) [ "Lighting" ]	        { channel="ihc:controller:elko:input30298" }

I also tried to change the tag to [“Switchable”] it doesn´t change anything.

This is most probably binding issue, cause the old binding for openhab1 work fine. I have contacted the author of the binding about it. But it might as well be a Google Home/openhab cloud issue, cause the push button normal state is always OFF. So there has to be something different in asking Google to turn ON or OFF.
So if possible, I would rather have a debug log file to present to him. Or does anyone have other suggestions how to deal with this/debug??

2

Don’t pay too much attention to the Predicted to be logs in events.log.

Whenever an Item receives a command it doesn’t automatically update the Item to the new state in the command. If you have autoupdate=false configured on the Item, OH will not directly update the Item itself and instead will wait for the binding to update the Item once the device has reacted to the command. I don’t think you will see the “Predicted” log entry in this case.

If you have autoupdate=true (which is the default) then OH will update the Item based on the command. You will still see the log predicting the future state of the Item, but it will immediately be followed by the update/change that is predicted. Remember, not all commands result in the same type of update. For example, if you send ON to a Dimmer, the actual update will be a number. The “Predicted” log entry is just OH telling you what it expects the Item to become based on the command. You will then immediately see the Item updating or changing to that predicted state.

I can’t see how any of this would have anything to do with Google Assistant interaction.

I think your problem is that Google doesn’t have a concept of a push button. It only has switches. So whatever command you send to it is going to be like a switch and therefore it is going to rely on the state of the Switch. When you ask Google to turn OFF the switch and it is already OFF then there is no change as a result of the command. events.log does not show updates so that is why you only see the two log entries. But I bet if you triggered a Rule based on updates to the Item you will see that the Item is in fact getting updated to OFF. And I know you can trigger a Rule based on this Item receiving the OFF command.

But both Google Assistant and OH appear to be working as designed. Google is sending the OFF command to a switch. The switch is receiving the OFF command. It’s already OFF so it gets updated to OFF. Done. Neither OH nor Google Assistant has the concept of a toggle.

Neither Google Assistant nor OH supports a push button natively.

To deal with this I think you may need write a Rule and you probably need to use a proxy Item. Let the proxy Switch Item be a switch that keeps whatever state it is in. When it receives a command, sendCommand ON to the actual light. If I understand correctly, this should toggle it.

3

Which I will never be able to understand. Pushbuttons should have its own defintion, like switches, contacts, dimmers etc… But thats another issue I´ve got with openhab, google home etc, apart from the actual problem…

This actual problem seems to be related to understanding the new 2.4 IHC binding, (it hasn´t been merged yet). The old IHC 1.13 binding works great with pushbuttons and google home, but seems like it´s using another strategy… I´m in contact with Pauli who make the binding, and hopefully I´ll learn soon…

In the mean time, I really dont understand how a proxy item will be able to do the trick…
The problem using pushbuttons is to get openhab to understand when the item is beeing toggled for event ON or event OFF.
Using a proxy item will most probably result in getting the sequence out of sync, specially if openhab restarts when the proxy item is in the opposite state of the event state (device)
Or, openhab needs somekind of confirmation of the state of the event/device.
Example, a wired dimmer, which is operated using pushbuttons, short/long press etc… If openhab doesn´t know the state of the dimmer, openhab wouldn´t know what to do, next time it receives a toggle from the item. openhab can only assume.
The best would be, if the device (ie wired dimmer etc) could return it´s state to openhab. But most wired dimmers I know, hasn´t got this option. Therefore, using a proxy item is a bit of a chance, and it will probably result in out of sync, sooner or later.
This however could be due to my lack of undestanding how to use proxy items in a rule when dealing with pushbuttons.
In general I think pushbuttons are a real pain in the a** when creating logic. On the other hand, they´re very powerfull if the logic can be made correctly. One will have lots of options available from a single pushbutton, ie, short-pres, long-press, even-longer-press, even-even-longer-press etc, ON, OFF, single, doubble, tripple push etc… Probably unlimited options, as it all depends on, for how long time you push and hold the button and/or count the pushed. It´s all down to the logic… Thats why I prefere pushbuttons… But it´s a nightmare creating the logic for a device which doesn return its state, in my opinion. I could be wrong though.

4 
rule "Proxy Item received command"
when
    Item MyProxyItem received command
then
    // We don't care what the command it, toggle the light
    MyLight.sendCommand(ON) // assuming sending ON will toggle the light

    MyLight.sendCommand(if(MyLight.state == ON) OFF else ON) // if the original is a Switch, though we don't really need the proxy in this case
end

Maybe I don’t understand how this is all supposed to work. But state of the proxy Item doesn’t matter. It’s just there to receive a command. Any command sent to the proxy Item will cause the Light switch to receive the ON command, which from your description should toggle the light’s state. If it isn’t then I don’t see why a Switch as a Switch won’t work.

Then you have this problem already, whether you use a proxy or not. If the device doesn’t provide feedback, OH is only guessing the state based on the commands it has received.

The problem with timed presses is OH only receives events (i.e. button pushed, button released). And you don’t want to wait for the release event (assuming there is one) before you start taking action with a long press event.

It’s possible to do this to some degree as long as the times are relatively long (500 msec or longer). When the NGRE becomes the default, this is one of the things I intend to release a Rules Template to achieve. Until then, there are some examples in the forum for how to handle this, but your device either needs to report what type of event it is, or you need to keep track of the time in a Rule.

5

Hmm I see what you mean… And this could actually work, I think…

I do… However the logic in the IHC controller do have some return state from a wired dimmer, which is uses… It isn´t the actual dimmer itself, it´s the logic which controles the dimmer.