Simple Heat device implementation

[mposzywak]

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

2. 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

[lballaty]

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 -

[mposzywak]

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.

[lballaty]

On 26 Apr 2021, at 18:05, mposzywak ***@***.***> wrote: override state must be set in eeprom 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 - 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. LB? Well it’s not controlled from Raspy it is actually controlled from the controller - he decides to set it if the raspy is gone - otherwise it doesn’t work, once the raspy is back again he sets it - if the Raspy dies then it would never be set otherwise. 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 - I'm generally not in favour of having a need to periodically send the value. The communication between raspy/arduino is ensuring delivery.

LB ? Sending a value is more meaningful because it means the db communication works too - w out that you may have just a ping working fine which is useless for operation. It is better to exercise the entire communication chain.

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.

LB ? If the controller detects a failure sooner what happens that is bad? Only that the flag is set a bit sooner - this is also why it is better to use an actual message - it is more likely to be a real failure. Only the controller has to detect a failure - there is nothing for the Raspy to detect and set on any basis - the raspy is passive in this scenario - The only time it is not passive is if you as the user set or unset the flag - in either case the communication between raspy and db and controller has to be working then.

…

You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACLIYY4CLYORUYSQ7GXT2NDTKWFMBANCNFSM43SPUCAQ>.