Comfort Automation/ Security System Forums > Support > Comments, Suggestions & Feedback > User Flags to change to Nonvolatile |
Comfort Automation/ Security System Forums > Support > Comments, Suggestions & Feedback > User Flags to change to Nonvolatile |
| Moderated by: admin | ||
| Author | Post | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
ident Administrator 
|
User flags in Comfort have always been all cleared to 0 (off) when the system is reset. It has been proposed to change the flags so that a system reset will not clear the flags, ie the flags would maintain their on or off status after a reset. However this would apply only to a reset and not power off. Power off would still clear the flags This should be better for the use of flags which can be used to indicate the state of objects in Comfort This may (or may not) affect existing programmed comforts We are looking for feedback on this proposed feature before we go ahead to make the change in firmware |
|||||||||
|
juwi_uk Member 
|
I think the feature should be the same for counters and sensors too. IMHO if calculations are going to be involved they include one or more of the above so just preserving the content of flags on reset could lead to unplanned calculation outcomes? |
|||||||||
|
Ingo UCM Pi Users 
|
I am thinking the complete opposite. A reset is just as the name suggests, it resets everything. If you now introduce some variables that are persistent then a reset is not something to start your system from scratch. If you persist certain variables then you have to introduce a new reset command that can either, like in the BGP Networking world, do a SoftReset, to perhaps retain your persistence and maybe even your TCP connection or a HardReset that starts from scratch without needing to power off/on the unit (for remote support). Calculations based on data received should make provision if a system resets, it can either be an external reset, a software forced reset or power off/on reset. The connected system wouldn't know either way. When data is persistent then there needs to be some indicator that can be queried to indicate either a 'persist' reset occurred or it was a power on reset. What if a Counter changes while Comfort is in a reset state? Hmm... Does the UCM also reset? Yes. Does a UCM do a full scan once back up again? Yes. (UCM/CBus referenced in my assumptions) Just throwing some food for thought into the mix... Ingo |
|||||||||
|
juwi_uk Member
|
So to get a "Power Off" I presume you need to turn off power to the unit and unplug the battery? That then suggests taken case off etc which is bad. I'm tending to side with Ingo then unless.... Could you introduce the ability to either "Warm" or "Cold" reset the system via software/pcb button. If "RS" is a "warm" reset then maybe add "RSX" or something to "Cold" boot. For buttons maybe hold down for 4 seconds for "warm start" and 8 for "cold start"? Then values only preserved with "Warm" reset. I cant see how a counter could reset while the system is resetting as don't the UCM's reset at the same time? I like the idea of not having to request all values again from comfort in my ComfortClient app if I know they haven't changed since "warm" boot. It would save some delays and network traffic and my UI could retain state. Julian |
|||||||||
|
ident Administrator
|
Reset happens after write to comfort so it is not just be pressing the reset button (which may be not easy to access anyway) You would not want your status from Cbus and KNX to be cleared to 0 everytime you write to comfort (although the UCMs may query for the state at reset ) Take the example of a Thermostat function in Comfort You may use Flags to keep the On or Off mode of each thermostat Counters may be used for the temperature setpoints Sensors receive the room temperature After setting up these registers to perform the function, a system reset due to write to Comfort or other reset should not clear them and cause the thermostats to be switched off and setpoints to be cleared Or perhaps you may be using the counters to keep some value or count Are there any actual cases where the registers really need to be cleared by a reset? An action code to "Clear All registers" should be a better solution for this, and it can be used whenever you wish, not just at reset |
|||||||||