Fix bug where SHTC3 was not woken from sleep before operations

[jcoliz]

As discussed in Discord.

SHTC3 binding would only ever read one set of values, before triggering this exception:

Unhandled exception. System.IO.IOException: Error 121 performing I2C data transfer.
   at System.Device.I2c.UnixI2cBus.WriteReadCore(UInt16 deviceAddress, Byte* writeBuffer, Byte* readBuffer, UInt16 writeBufferLength, UInt16 readBufferLength) in C:\Source\jcoliz\dotnet\iot\src\System.Device.Gpio\System\Device\I2c\UnixI2cBus.cs:line 197
   at System.Device.I2c.UnixI2cBus.Write(Int32 deviceAddress, ReadOnlySpan`1 buffer) in C:\Source\jcoliz\dotnet\iot\src\System.Device.Gpio\System\Device\I2c\UnixI2cBus.cs:line 125
   at System.Device.I2c.UnixI2cDevice.Write(ReadOnlySpan`1 buffer) in C:\Source\jcoliz\dotnet\iot\src\System.Device.Gpio\System\Device\I2c\Devices\UnixI2cDevice.cs:line 28
   at Iot.Device.Shtc3.Shtc3.Write(Register register) in C:\Source\jcoliz\dotnet\iot\src\devices\Shtc3\Shtc3.cs:line 247
   at Iot.Device.Shtc3.Shtc3.TryReadSensorData(Register cmd, Double& temperature, Double& humidity) in C:\Source\jcoliz\dotnet\iot\src\devices\Shtc3\Shtc3.cs:line 148
   at Iot.Device.Shtc3.Shtc3.TryGetTemperatureAndHumidity(Temperature& temperature, RelativeHumidity& relativeHumidity, Boolean lowPower, Boolean clockStretching) in C:\Source\jcoliz\dotnet\iot\src\devices\Shtc3\Shtc3.cs:line 133

That's because the device was put to sleep (in the sample), but never actually woken up before getting the next reading. THAT was because the status was never set when device put to sleep.

Microsoft Reviewers: Open in CodeFlow

[Ellerbach]

Thanks for looking at this. Can you as well update the example and wake up the sensor? And then also update the README?

[Ellerbach]

Just remove this extra line

Suggested change

[jcoliz]

Oops! Sorry about that. Updated now.

[jcoliz]

@Ellerbach, thanks for reviewing. Doesn't look like the sample nor README need change. What did you have in mind?

The sample doesn't need to explicitly wake the sensor, because the call to TryGetTemperatureAndHumidity() does so implicitly. With this PR, that implicit wakeup will actually happen as-designed.

Likewise, the sample isn't able to explicitly wake the sensor, because WakeUp() is private. Not trying to be pedantic here... It seems that the design of the binding is that user explicitly sleeps the sensor when done with it, and then the binding will implicitly wake it back up when user asks for an operation. This seems like a reasonable design, so I didn't see any need to suggest making the user explicitly wake the sensor when they're ready to use it.

[krwq]

Looks good, thanks!