State management

[jmarcgit]

Hi,

I try to automate my entry gate. I'm having issues with the state management.

I defined a gate type device and connected input and output to MQTT topics. One topic is used to send commands (switch) and the second one to report state (input sensor). Everything almost work except that the state of the gate in Google home is toggled automatically. I want to use a sensor to report the state of the gate because it can be opened with remotes as well. And it's nice to have continuous report of the state of an entry door, especially when I'm away.

So my question is : is there any way to fully control the state of an OpenClose trait ?

[Caprico85]

Sorry, but I don't understand the problem yet.

You mean, if somebody opens or closes the door with a remote (not via Google), you send the new state of the door into the Google device, but the new state is not shown in the app?

[jmarcgit]

No. When I send a new state it is show in the app.

The problem is that when I close the door using the Home app, the state moves immediately to close without waiting for the sensor event.

After analysing the debug log I think I have to change the state during the command processing to override the state returned in the response to Google right ?

[Caprico85]

Thanks for the clarification.

Something similar was discussed in #474. For each command (such as "Unlock the door") Google waits for confirmation from our side. Currently, we confirm each command as successful, which leads to the state change in the app. Google also allows different return codes such as "Door not unlocked, motor is stuck". But this is currently not implemented in our module and there is no schedule on when (or if) it will be done.

After analysing the debug log I think I have to change the state during the command processing to override the state returned in the response to Google right ?

After we handled a command, we immediately report the new state back to Google. Technically, this is not necessary, as our state would not be that different from the state Google sent us a few milliseconds ago. But that is how it's currently implemented. However, you cannot change this state that is reported immediately after the command (at least not without changing the source code). You can always send another new state report with the correct state right that, though.

[jmarcgit]

Thank you @Caprico85

1- I think that the confirmation can be sent a bit later. Maybe it could be possible to wait that the flow has completed and send the confirm message then. So if expection occurs, an error status could be returned.

2- Regarding the state, I think we could just manage an option for that. By default, state could be updated and reported automatically because this suits simple use cases where no sensors are available (current behaviour). But we could also offer the option to not updating the state automatically. Therefore state would be driven by sensors only.

What do you think ? Proposal 2 seems quite simple right ?

[Caprico85]

No, proposal 2 is not that simple. It is not our state reporting that changes the state display in the app.

The process is as follows:

1. User presses the "unlock door" button in the app
2. Google calculates that the new state is now "door unlocked". New state is not yet displayed in the app.
3. Google sends the command and the new state to node-red-contrib-google-smarthome.
4. We respond with "Command successful".
5. Google displays the new state in the app.
6. We send the state "door unlocked" to Google.
7. This changes nothing. Google already knew that the door was unlocked. This was the state that Google sent us right before.

As you see, Google displays the new state with step 5. This happens before we even reported our state in step 6. Disabling step and 6 and 7 with an option would not change anything, the new state is already visible in the app with step 5.

With the changes discussed in #474, this would change to:

1. User presses the "unlock door" button in the app (exactly as before)
2. Google calculates that the new state is now "door unlocked". New state is not yet displayed in the app. (exactly as before)
3. Google sends the command and the new state to node-red-contrib-google-smarthome. (exactly as before)
4. Wait until we know more (e.g. got a sensor event), then respond with "Command successful" or "Command failed"
5. If we sent "Command successful", Google displays the new state in the app.
   If we sent "Command failed", Google discards the new state and shows an error message.
6. and 7.: report the state again (or not)

With this changes it would be possible to do what you want. You can delay the response until you got an answer from your sensor.
But as said, nobody has worked on #474 yet.

[jmarcgit]

I think I got the point. I didn't believe that Google Home was waiting the the reponse before refreshing the UI, because it was so fast... What is strange is that I set a 10 seconds blocking sleep in the device_exec function but the status is still updated immediately in Google Home.

[Caprico85]

You are right. I tried it myself now. The state immediately changes in the app. Even with a sleep it immediately changes. And even if we return an error code and the old state for the EXECUTE request, the state in the app changes and doesn't change back.

That's really strange. I have absolutely no idea how we could fix this.

[jmarcgit]

@Caprico85 : Update : I changed code to allow commands not to update state. It works. Button falls back to the current state after 1 second. I think we can add an option like "Automatically update state" in the node configuration that could be activated by default ? Do you want me to do the changes and create a pull request for that ?

[jmarcgit]

  @Caprico85 I think we can support this with 2 enhancements:

1/ Disable state automatic update. Today when a command is received, the device state is updated to the requested state and the new state is returned. When working asynchronously you may want to control state manually based on sensors for example.

2/ Return state or error asynchronously. Why not extending the existing state update feature instead of adding a new node ? Basically the callback message could be the same + follow-up id + error message. If a valid follow-up id is in the message then we send a callback response instead of using the Graph API to update state. Simple right ?

I don't think it's a huge work to do. For me 1/ is very important because I manage state from sensors even in synchronous mode. I can work on them.