Simple Heat device implementation about iot-hub-c HOT 3 OPEN

The Simple Heat device shall be composed of one input and one output type, hence it can be a type of digitOUT class.

By default initially its input pin will work as a press-hold to control the digitOUT state.

The Simple Heat device shall have a flag that will shift the control between the input pin or the ARiF. The Heat device can be controlled either by the thermostat connected to the input pins or the raspy.

Initial phase will only work based on the input pin state and two ARiF command:

heatON
heatOFF

the heat device state is not stored in the EEPROM, only the device type and its settings:

device type: SIMPLE_HVAC
override flag: true/false

There will be an override flag implemented to indicate if the output pin is controlled by the raspy or by the input pins:

1. Override flag set to false:

• output pin controlled solely based on the input pin.
• ARiF commands for this device are ignored
• no change in operation whether the raspy is up or down

1. Override flag set to true:

• output pin controlled by the ARiF heatON and heatOFF commands. Default state is the output pin off - in caes raspy is up, but no commands comes from it. The system after boot should wait couple of seconds until raspy connection is recognized, not to start with input pin control and then switch immediately to raspy control once heartbeat starts going.
• input pin state is ignored
• if the raspy is detected down after few seconds the device should switch to input pin control
• if the raspy gets up after heartbeat failure, the system should wait few seconds for the heatON or heatOFF command. in case no command is received it switches the output pin to off.

The override heat flag shall be set by the commands:

overrideON
overrideOFF

override state must be set in eeprom

If the controller is booting up - and it is not the first time - and he finds he can't register/reach the Raspy he must check and unset the flag and write the correct value to eeprom -

I am not sure the heartbeat is enough - once in a while he should check w Raspy what the override flag status should be - if the Raspy doesn't answer this properly then he should unset the flag - and send an error/event message - to the SD card and to ethernet - cloud -

from iot-hub-c.

override state must be set in eeprom
[MP]: That is in the spec above, it must be written into eeprom indeed.

If the controller is booting up - and it is not the first time - and he finds he can't register/reach the Raspy he must check and unset the flag and write the correct value to eeprom -
[MP]: That's actually invalid. Exmple: if it boots up with override set to true and the raspy heartbeat doesn't come, then he sets the override flag to false and then raspy comes up and sends heatON, but he has the override flag disabled, so the command is ignored. I would stick to the concept that the override flag is controlled by the raspy and hence it can be enabled/disalbed only from it through ARiF. This way there is no chance that it all gets desynced.

I am not sure the heartbeat is enough - once in a while he should check w Raspy what the override flag status should be - if the Raspy doesn't answer this properly then he should unset the flag - and send an error/event message - to the SD card and to ethernet - cloud -
[MP]: I'm generally not in favour of having a need to periodically send the value. The communication between raspy/arduino is ensuring delivery. But actually this reminded me that we need to make sure that the arduino won't detect a failure quicker than the raspy, this would mean that only one detects the failure. We could actually make sure it tells raspy that it detect a failure and hence requires refresh of everything that raspy controlls. That would be just that override flag at the moment.

from iot-hub-c.

from iot-hub-c.